RFC 8674

The "safe" HTTP Preference 🎀

okay bestie, let's do the title block first 🌸 This is RFC 8674, written by M. Nottingham. It's an Independent Submission (so it didn't come through the IETF stream), its category is Informational, it's dated December 2019, and its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there ✨

Abstract ✨

ok so this spec defines a preference for HTTP requests that says "please avoid objectionable content" 🙈 What counts as objectionable is up to the origin server (the site itself) 💅

It doesn't pin down a precise meaning for "safe" 🫶 The server interprets the term, and each website that decides to act on the preference gets to decide what it means in its own scope.

Supporting this preference is optional for both clients and servers 🍓

Status of This Memo 💜

this one's giving "not a standard, just sharing" energy 🧚 It is not an Internet Standards Track specification and it's published purely for informational purposes.

It's a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no claims about how useful it is to implement or deploy. Documents approved by the RFC Editor aren't candidates for any level of Internet Standard, see Section 2 of RFC 7841 🔥

For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc8674 🦋

Copyright Notice 🌈

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved 💖

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜

Table of Contents 🧚

1.  Introduction
  1.1.  Notational Conventions
2.  The "safe" Preference
3.  Security Considerations
4.  IANA Considerations
5.  References
  5.1.  Normative References
  5.2.  Informative References
Appendix A.  Sending the "safe" Preference from Web Browsers
Appendix B.  Supporting the "safe" Preference on Web Sites
Acknowledgements
Author's Address

1. Introduction ✨

okay so a lot of websites have a "safe" mode 🫶 It's there so people who don't want to see stuff (or don't want their kids seeing it) can avoid content they'd object to 💅

The problem is that getting there is a whole chore 😭 You have to visit every site you use, find the right page (maybe make an account while you're at it), and get a cookie [RFC6265] set in your browser. And you have to do that for every browser on every device 💀

A way more manageable approach is for the browser to proactively say "hey, I'd like safe content" 🎀 A user agent that supports this (whether that's one browser or an operating system HTTP library) only needs to be set up once so the preference goes out to a bunch of sites, or even all of them 🌸

This spec explains how to declare that desire in requests as an HTTP Preference [RFC7240] 🦋

Note that this spec doesn't define what counts as objectionable, so "safe" isn't precisely defined either 🙈 The server interprets the term, within the scope of each website that chooses to act on this info.

That said, the intent is to let end users (or people acting for them) say they want to avoid content that's considered objectionable within the cultural context of that site. Usually (but not always) that means content unsuitable for minors 🧚 The safe preference isn't meant for any other purpose ✨

Also, sending the preference doesn't guarantee the site will use it, or that its idea of "objectionable" matches the requester's 😭 So its effect is "best effort" and shouldn't be relied on. In other words, sending it is no more reliable than visiting every site and manually picking safe mode, but it's way easier 💅

Here's another important thing: the safe preference isn't a reliable sign that the end user is a child 🫶 Other users might want unobjectionable content, and some kids might browse without the preference set.

The cultural context also applies to where a site is hosted, the content provider, and where the content came from 🌍 It can't be guaranteed that a user agent and an origin server will see "objectionable" the same way.

Simply put, it's a statement by (or on behalf of) the end user saying, "if your site has a safe setting, this user is opting into it, according to your definition of the term" 💖

The mechanism in this document doesn't have IETF consensus and isn't a standard 🔥 It's widely deployed, it's turned out to be useful, and it's written up here so server and browser implementations can share a common understanding of how it works.

This mechanism was submitted for publication as an IETF Proposed Standard, but the IESG didn't approve it 😭 Their concerns included how vague "safe" is, the ability of a proxy to insert the hint outside of the user's control, the fact that there was no way to know whether the hint was actually applied to the response from the server, and the possibility that this preference could encourage more censorship and/or targeting of minors.

The spec was updated to address those concerns, but the IESG still didn't approve it as an IETF Proposed Standard 💀 So it was published in the Independent Stream instead 🌈

1.1. Notational Conventions 🍓

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. The "safe" Preference 💅

When it's present in a request, the safe preference says the user would prefer that the origin server not respond with content designated as objectionable, going by the origin server's definition of the concept 🫶

For example, here's a request that includes the safe preference 🎀

GET /foo.html HTTP/1.1
Host: www.example.org
User-Agent: ExampleBrowser/1.0
Prefer: safe

Typically, user agents that send the safe preference will include it in all requests with the "https" URI scheme. Some might give you finer-grained controls over when it's sent, but this way the preference is available to the resources it applies to ✨ User agents MUST NOT emit the safe preference on requests with the "http" URI scheme (see Section 3) 🙈 Check Appendix A for more on configuring which resources the safe preference gets sent to 🦋

The safe preference MAY be implemented in common HTTP libraries 🌸 (for example, an operating system might choose to insert the preference into requests based on system-wide configuration).

Origin servers that use the safe preference ought to document that they do, along with the criteria they use to flag objectionable content 📜 If a server has more fine-grained degrees of safety, it SHOULD select a reasonable default to use and document that. It MAY use additional mechanisms (for example, cookies [RFC6265]) to fine-tune 🧚

A response to the request above might have headers that look like this 💖

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/html
Preference-Applied: safe
Server: ExampleServer/2.0
Vary: Prefer

Here, the Preference-Applied response header [RFC7240] shows that the site applied the preference ✨ Servers aren't required to send Preference-Applied (even when they've applied the preference), but they're encouraged to whenever possible 🌈

Note that the Vary response header needs to be sent if the response is cacheable and might change depending on the value of the Prefer header 🔥 This applies not only to responses that are safe, but also to the default unsafe response too.

See Section 4.1 of [RFC7234] for more on how the Vary header field interacts with web caching 🎀

See Appendix B for extra advice for web servers that want to use the safe preference 🦋

3. Security Considerations 🔥

bestie, this section is serious business, so read it carefully 😭

The safe preference is not a secure mechanism 💀 Intermediaries with access to the request stream (for example, for "http" URLs) can insert or remove it. That's why it's prohibited from being included in requests with the "http" scheme.

Its presence also reveals information about the user, which can help sites and other entities on the network fingerprint them 🙈 It gives insight into the user's preferences and might be used to make assumptions about the user. That means it could be used to identify categories of users for purposes like targeting (including advertising and identifying minors). So user agents SHOULD NOT include it in requests when the user has expressed a desire to avoid such attacks (for example, in some forms of private mode browsing) 🔒

Including the safe preference in requests doesn't ensure all content will actually be safe 💅 Content is only safe when servers choose to honor the preference.

Even then, a malicious server might adapt content so it's even less safe (by some definition of the word) 😱 So this mechanism on its own isn't enough to make sure only safe content gets seen. People who want that guarantee will need to combine it with other techniques (for example, content filtering) 🫶

Also, the server and the user may have different ideas about what "safe" means ✨ So how safe the user's experience is while browsing from site to site, and over time, might (and probably will) change 🌪️

4. IANA Considerations 🌸

Per this specification, IANA has registered the following entry in the "HTTP Preferences" registry [RFC7240]:

• Preference: safe
• Description: Indicates that safe (i.e., unobjectionable) content is preferred.
• Reference: RFC 8674

5. References 📜

5.1. Normative References 💜

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
           Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
           RFC 7234, DOI 10.17487/RFC7234, June 2014,
           <https://www.rfc-editor.org/info/rfc7234>.

[RFC7240]  Snell, J., "Prefer Header for HTTP", RFC 7240,
           DOI 10.17487/RFC7240, June 2014,
           <https://www.rfc-editor.org/info/rfc7240>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

5.2. Informative References 🧚

[RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
           DOI 10.17487/RFC6265, April 2011,
           <https://www.rfc-editor.org/info/rfc6265>.

Part 1 of 2, more to come! 🎀

Appendix A. Sending the "safe" Preference from Web Browsers ✨

okay so, back in Section 2 we talked about how there are a bunch of different ways the safe preference can get generated 🌸 one option is for a web browser to let its users configure the preference so it gets sent 💖

when you're doing that, it is important not to misrepresent the preference as binding to web sites 🙈 like, an appropriate setting might be a checkbox with wording along the lines of:

[] Request safe content from web sites

with further information available upon request 🎀

browsers might also let the safe preference get locked so nobody can change it without administrative access or a passcode 🔒✨

and ngl this part is important: this specification does not require browsers to send the safe preference on all requests 💅 sending it everywhere is one possible implementation, but alternate strategies include blacklists and whitelists 🦋

---

Appendix B. Supporting the "safe" Preference on Web Sites 🧚

web sites that let you configure a safe mode (for example, with a cookie) can add support for the safe preference little by little 🍓 the preference won't be supported by all clients right away, so it's necessary to have another way to configure it too 💜

when a site honors the safe preference, it is important that it not be possible to disable it through the site's interface 😭 the reason is that the safe preference may be configured and locked down by the browser or the computer's administrator (e.g., a parent) 👑 if the site has its own means of configuration (e.g., stored user preferences) and the safe preference shows up in a request, the "safer" interpretation ought to be used 🫶

the right level of safety is a site-specific decision 🌈 when picking it, sites ought to keep in mind that disabling the preference might be considerably more onerous than using other means, especially if the preference is generated based upon the operating system configuration 💀

sites might offer different levels of safety through web configuration 🦋 but they will need to either tell their users what level the safe hint corresponds to, or give them some way to adjust it ✨

if users express a wish to disable safe mode, the site can remind them that the safe preference is being sent and ask them to check with their administrator 🙈 (since the safe preference might be set by a locked-down operating system configuration, so this is a real thing!) 💅

As explained in Section 2, responses that change based upon the presence of the safe preference need to either carry the "Vary: Prefer" response header field or be uncacheable by shared caches (e.g., with a "Cache-Control: private" response header field). This is to avoid an unsafe cached response being served to a client that prefers safe content (or vice versa). 😭🔥

---

Acknowledgements 🫶

Thanks to Alissa Cooper, Ilya Grigorik, Emma Llanso, Jeff Hughes, Lorrie Cranor, Doug Turner, and Dave Crocker for their comments 💖 you all are literally the best 🌸

---

Author's Address 🎀

Mark Nottingham

Email: mnot@mnot.net
URI:   https://www.mnot.net/