whatwg
Add support for <meta name="rating" ...>
What problem are you trying to solve?
Users may not want to have content that is meant to be restricted to adults displayed in their browser. Thousands of sites already label their content as such with a meta tag because they do not want to distribute their content to children. Some OSs provide account-level controls for enabling web content filtering for a user. However, these are not plumbed together in the browser.
What solutions exist today?
Users can install browser extensions to do this.
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?
Add insertion steps for the meta tag with name="rating" to halt the document's parser, disable scripts, and redirect the user to an error page.
Anything else?
This is in support of finding a better way to do age verification online. There's a workshop happening about it next week with a lot of position papers: https://datatracker.ietf.org/group/agews/materials/.
Several of the positions point to self-labeling like this as a least-bad option, including my own.
Hmm, what would go in content=""? Maybe there's an existing ontology with broad support that could be referenced, instead of inventing something anew.
From https://www.ietf.org/slides/slides-agews-paper-device-based-age-verification-00.pdf
When inserting a meta tag to the document, if the "name" attribute is "rating" and the "content" attribute is "RTA-5042-1996-1400-1577-RTA" or "adult", and if the browser is configured by the host platform to restrict adult content, the operation must fail and the browser may redirect the user to an error page.
Maybe there's an existing ontology with broad support that could be referenced, instead of inventing something anew.
This is an existing ontology, as far as I can tell.
https://developers.google.com/search/docs/specialty/explicit/guidelines#add-metadata https://www.rtalabel.org/?content=howto#top
There's apparently also a response header: https://www.rtalabel.org/?content=howtofaq#responseheader
Needs some details as to whether this should work for nested documents and such and what this would look like if the document has a relationship with a popup or some such. Probably want to require a BCG swap of sorts.
Hmm, what would go in
content=""? Maybe there's an existing ontology with broad support that could be referenced, instead of inventing something anew.
I'd propose we start with the ontology Simon linked, accepting both values. But I am open to expanding the ontology to something more descriptive of the nature of the content or that more closely aligns with new OS signals.
Needs some details as to whether this should work for nested documents and such and what this would look like if the document has a relationship with a popup or some such. Probably want to require a BCG swap of sorts.
I'd say it should work for nested documents, but only affect the nested document. I hadn't thought of forcing a BCG swap, I was leaning on the navigation being cross-origin. How is the BCG swap observable?
Something pointed out at the IAB/W3C workshop last week was the need to handle "age-conscious design" in which a page may need to present itself differently to younger visitors, e.g. removing algorithmic feeds. I think to that end, it may make sense to use the same ontology, but extend to an attribute that interacts with platform signals similarly, but forces display: none.
I think that this is fundamentally the wrong approach for a number of reasons. I far prefer an approach like has been done with GPC: the user agent holds a signal that prefers levels of content and the site responds accordingly. It is dangerous to have a system in which sites publicly self-identify and user agents act as censors of the site according to some arbitrary system of identification and user-preference. Even in this short thread, we can see the degree in which the user agent is required to manipulate the site on behalf of its users is increasing and the choices it must make or--in this format--end up required to make will only increase in complexity and scope. This is inappropriate as a model to respond to the question of age limitation of content.
It is very easy to see where this goes in the philosophical and real-world senses. It is one thing for a coalition of adult-content websites to make choices around their industry specifically, but if we choose to standardize this tag for the web the unfortunate consequences roll out in front of us. As a publisher that experiences these types of pressure I will make a few predictions of the next steps after standardization: in 6 months it is required to be indexed by most search engines who will decision on it. 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.
If the intent here is to avoid web-fracturing censorship of the web by state entities, it will succeed only in that it will move the responsibility for that censorship to the centralized to the small number of entities that maintain browser engines and other user agents and will almost certainly find it cheeper to enforce a consistent approach even where the law does not require it.
On the other hand, a signal in the browser that is set by the user's choices or operating system has many more options and many more individual entities that must make choices around it. Every publisher will decide on their own how to respond to such a signal and be able to make convincing arguments about why. The question of what to do about U18 users will remain where it should be, in the hands of content publishers, as opposed to a metadata tag which will move it to search engines, LLM systems, and user agents. This is an extremely important distinction. Publishers may choose to publish their self-assessment or simply respond to the signal, that must be a choice on their part and the standardization of this meta tag will inevitably defeat that choice. The difference between a UA signal and a meta tag is very important.
We should not move forward on standardization of this particular tag.
EDIT: What the signal should be that the server would then have to handle and if it should be digital credentials is something I'm more open to discussion on, but I don't have a strong opinion on these signals yet.
An easy signal from the browser to the site about a known underage user e.g. due to the age setting being applied that California now wants could be a simple HTTP header. It might also help to try to nudge Linux desktops to support specifying an optional account age.
Thanks for the feedback Aram and ell1e! Based on that, I've filed an issue against fetch to document a signalling-based approach: https://github.com/whatwg/fetch/issues/1891.