What this page is for
Use this page as the trust-policy hub for the UAIX launch surface. It connects the dedicated public pages for privacy and data, accessibility, and analytics to the current licensing and security release posture so reviewers can audit the whole trust layer from one governance section.
Current policy map
- Privacy and Data for the public-reading, discovery, and data-exposure posture.
- Accessibility for readable-launch expectations, keyboard and mobile QA, and accessibility-significant release handling.
- Analytics for the current published limits on measurement, telemetry-significant changes, and disclosure posture.
- Governance, the Changelog, and News for the authority model, dated release trail, and public narrative around trust-significant changes.
Current licensing posture
- Active public launch theme: the current UAIX Authority theme declares
GPL v2 or laterin its public package header. - Other packaged artifacts: evaluate each distributed package against its own shipped header, notice, or bundled source terms rather than assuming one broader site-wide code license where none has yet been published.
- Public standards pages: treat the canonical page paths as the public reading, citation, and review surface for UAI-1 and related records. Do not infer a broader trademark, certification, or endorsement right from public availability alone.
Security and release discipline
- The public site is a standards and publication surface, not a live security gateway or managed trust service.
- Launch checks should keep HTTPS, security headers,
.well-knowndelivery, sitemap delivery, validator behavior, and machine-facing route inventory aligned before public support claims are widened. - Use API Reference, Conformance Pack, the Validator, and Implementations when a release needs reviewable machine evidence instead of prose-only assurance.
Observable response hardening
Use the section below when a launch reviewer needs the concrete response-header layer that now backs the public trust posture on WordPress-rendered routes, plus the boundary between app-level hardening and host-level deployment work.
Security posture
Public response hardening that now backs the launch trust surface
Use this section when a launch reviewer needs the exact response-header layer that now ships with the public WordPress surface, plus the boundary between app-level hardening and edge-level deployment work.
X-Content-Type-Options
nosniff
Prevents content-type sniffing on public standards pages and machine-readable routes.
Applied to: Public HTML, JSON, XML, and similar WordPress-rendered responses.
Referrer-Policy
strict-origin-when-cross-origin
Keeps cross-origin referrer leakage narrower while preserving same-origin debugging context.
Applied to: Public document and API responses that can generate outbound requests.
Permissions-Policy
accelerometer=(), browsing-topics=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()
Declares that the launch surface does not rely on privileged browser capabilities or Topics-based advertising features.
Applied to: Public WordPress-rendered pages and machine-facing routes.
X-Frame-Options
SAMEORIGIN
Blocks third-party framing while preserving same-origin editorial and preview flows.
Applied to: Public WordPress-rendered pages and JSON responses.
Content-Security-Policy
frame-ancestors 'self'
Makes the framing boundary explicit in modern browsers without claiming a broader full-site CSP yet.
Applied to: Public WordPress-rendered pages and machine-facing routes.
Live now
Observable on WordPress responses now
- 已从公开响应中移除回链响应头。
- Host- or proxy-level version headers still need server-side suppression if the launch environment adds them after WordPress runs.
- These headers now travel with public WordPress-rendered HTML and REST responses instead of remaining only in roadmap prose.
Deployment gap
Still belongs to the host or edge layer
- HTTPS redirect and HSTS still belong at the launch host or CDN edge because the local Studio environment runs over plain HTTP.
- Any directly served static root files should be checked at the server or edge layer so their headers stay aligned with the WordPress-rendered trust posture.
- Host-level version disclosure such as proxy or PHP signature headers should be suppressed where the deployment stack adds them outside WordPress.
- Broader CSP directives should be added only after production asset and embedding behavior are validated against the launch host.
Scope boundary: 当前响应头层应用于公开的 WordPress 前端渲染响应和 REST 响应，包括验证器与面向机器的评审路由。
How these policy pages fit together
- Use this page as the hub: start here when the question is “which published policy surface should I read next?”
- Use the dedicated pages for the actual posture: Privacy and Data, Accessibility, and Analytics each publish the current launch-stage boundary for that area.
- Use References and Contributors and
/.well-known/uaix.jsonwhen a reviewer needs the current public discovery and handoff packet without relying on screenshots or private instructions.
What is still future work
- A broader consent center, account-intake policy stack, or institutional legal program beyond what the site explicitly publishes today.
- A published certification authority, public security operations center, or claims of universal runtime assurance beyond the named implementation tracks and release evidence.
- A broader multi-stakeholder governance body, contact center, or policy office unless and until those are formally published on canonical UAIX pages.
Next step
Continue to Privacy and Data, Accessibility, or Analytics for the detailed public posture in each area, then use Changelog and News when a trust-significant change needs dated release context.