Add `Prefer: safe` HTTP header

[bvandersloot-mozilla]

What problem are you trying to solve?

Users may not want to have objectionable content displayed in their browser. Two browsers (Firefox and Edge) consume OS signals for web content restriction and convey this information to websites as the user browses via the Prefer HTTP header (RFC 8674).

What solutions exist today?

Content labeling, e.g. the <meta name="rating" content="adult"> as proposed for HTML is one approach for this functionality.

Currently, governments seem to be turning toward cryptographic proofs of age from digital credentials to make similar use cases work. Even with fancy crypto, there are significant privacy risks

How would you solve it?

Currently the spec has the following step

20. Modify httpRequest’s header list per HTTP. Do not append a given header if httpRequest’s header list contains that header’s name.

I'd propose appending the following step before that step:

"If the user agent has a signal, either from the user directly or the operating system, that the user prefers that the server not respond with content that is designated as objectionable according to the server's definition of the concept, append (Prefer, safe) to httpRequest's header list. [RFC8674]"

We would also need to make it clear that these steps are exclusive operations. This is probably the right interpretation since RFC 8674 is informational.

Anything else?

No response

[ell1e]

I like this approach! Edit: I guess less so now after more thoughts, see below. Although I think it would make sense to explicitly refer to content that may not be that suitable for children and less a generic concept of objectionable, since that would encourage including things that merely may lead to discussions some people don't like.

[bvandersloot-mozilla]

I like this approach! Although I think it would make sense to explicitly refer to content that may not be that suitable for children and less a generic concept of objectionable, since that would encourage including things that merely may lead to discussions some people don't like.

The RFC's introduction goes into this" https://datatracker.ietf.org/doc/html/rfc8674#name-introduction. Some additional language reinforcing this paragraph's point: "That said, the intent is to allow end users (or those acting on their behalf) to express a desire to avoid content that is considered objectionable within the cultural context of that site; usually (but not always), the objectionable content is content unsuitable for minors. The safe preference is not intended to be used for other purposes."

[ell1e]

I don't like that way of phrasing it, it's like an invitation to just exclude anything anybody might find objectionable. "usually (but not always)" seems pretty weak in that regard. Edit: let me be constructive and propose a different wording, see next comment.

[ell1e]

After some more thought, I don't think "objectionable" sounds like a good criterion, what about "disturbing for children"?

Many web sites have a "safe" mode to assist those who don't want to be exposed (or have their children exposed) to content they might consider too disturbing for children.
[...]
Note that this specification does not define what content might be considered disturbing for chlidren, so the concept of "safe" is not precisely defined. Rather, the term is interpreted by the server and within the scope of each web site that chooses to act upon this information.
That said, the intent is to allow end users (or those acting on their behalf) to express a desire to avoid content that is considered too disturbing for children within the cultural context of that site. The safe preference is not intended to be used for other purposes.

If you don't phrase it clearly around children, I feel like not only is there a risk of encouraging it slipping into areas like e.g. xenophobia or suppressing political views, but also that it becomes instead some equivalent to trigger warnings for adults. Those are legitimate to exist of course, but it would risk quite some overblocking. If you wanted to serve trigger warnings too, I feel like you would need categories and a single flag isn't suitable for this.

But perhaps it's just me, I'm not sure.

[martinthomson]

I think that it's only fair to mention https://prefersafe.github.io/ here as well.

[ell1e]

I think that it's only fair to mention https://prefersafe.github.io/ here as well.

Interesting, I have to admit I didn't think of ads targeting kids. That seems like a potential issue for sure.

But I guess the main question is what's the least worst options of 1. gov id or strict age check linked measure like Online Safety Act, 2. Prefer: safe, 3. <meta name="rating" content="adult"/>, 4. or I guess trying to not have any of these mechanisms ever, but e.g. the 3rd one already is out there even for US platforms, and the 1st one is being pushed.

Re-reading one of the criticisms posted in the other issue about the meta tag:

In a year Texas will threaten to sue user agents who refuse to censor content about LGBTQ+ people in reaction to this meta tag, under the active today assertion that such content is fundamentally "adult" (the big user agents will comply). In three years browser owners and sites alike will find themselves operating under a regime based around this Comstock meta tag.

I feel like that's still possible to happen with the Prefer: safe one, so I wonder if adding a tag may actually have the least downsides, but I'm not sure. It's also the one mechanism that seems to have somewhat international use.

[linusmartensson]

I feel like this is interesting, but if it doesn't take into account different definitions of 'safe' for different regions (e.g. what is "PG13" may differ depending on user location) - it will be hard to enforce in practice, and it again pushes complexity to each website and relies on external legalese or website preferences to decide what should be shown.

'Safe' becomes intractable when one jurisdiction wants it to be safe for 5 year olds browsing on their parents' phones, while another wants it to be 'safe' for teenagers, and a third wants to restrict communication functionality but not content. I'm still of mind that the previously discussed tag provides a solution that can enable age restriction in a way that pulls the rug on the need for invasive legal frameworks altogether.

The parent decides on an OS with age restriction support and a browser with age restriction support, then configures as desired for a given age bracket. Not the governments, not the server.