OCSS · Open Child Safety Specification · openchildsafety.com STANDARD v1.0 · DRAFT FOR REVIEW
§ 1

The website

What openchildsafety.com collects, which is very little.

openchildsafety.com is a static documentation site with a member area for the coalition. The public pages set no advertising or cross-site tracking cookies and build no marketing profiles. Our servers keep ordinary request logs (IP address, user agent, and timestamp) for security, abuse prevention, and operations; we retain them only as long as those purposes require, and we do not sell or rent them.

The member area at /review is for coalition participants. Sign-in is handled by our authentication provider, which stores only what is needed to authenticate an account, such as an email address and a session. We use that information to give a member access to coalition working documents, and for nothing else.

If we add analytics to understand which pages are useful, those measurements stay aggregate and privacy-respecting: they are not tied to an advertising identity and are not shared for advertising. Any change to what this site collects will appear here before it takes effect.

§ 2

The standard carries no identity

Privacy is the design goal of OCSS, not a footnote to it.

OCSS exists so a parental-safety signal can be enforced everywhere a child goes online without that signal becoming a tracking identifier. Three properties of the Trust Framework make that concrete.

A signal carries an age band, such as "13–17", and never a birthdate or an identity. The household identifier is a domain-separated hash (family_hash), derived per receiver, so the same household resolves to a different opaque token at every intermediary and no two intermediaries can join their logs to re-identify a minor. The record itself is JWE-sealed to the receiver's key, so a routing intermediary forwards bytes it cannot read.

The parts of the system that move the most data therefore see the least about any child. The full design and its threat model are public in the standard and the Trust List.

§ 3

Questions and requests

One address for anything privacy-related.

For a data request, a question about this statement, or a concern about how the site or the standard handles information, write to [email protected]. The full specification text and threat model are open for review, so a claim made here can be checked against the standard rather than taken on trust.