idnits 2.17.1 draft-nottingham-safe-hint-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 3, 2014) is 3491 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 7234 (Obsoleted by RFC 9111) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft 4 Intended status: Standards Track October 3, 2014 5 Expires: April 6, 2015 7 The "safe" HTTP Preference 8 draft-nottingham-safe-hint-05 10 Abstract 12 This specification defines a "safe" preference for HTTP requests, 13 expressing a desire to avoid "objectionable" content. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on April 6, 2015. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. The "safe" Preference . . . . . . . . . . . . . . . . . . . . 3 51 3. Implementation Status . . . . . . . . . . . . . . . . . . . . 4 52 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 53 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 54 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 56 Appendix B. Setting "safe" from Web Browsers . . . . . . . . . . 7 57 Appendix C. Supporting "safe" on Web Sites . . . . . . . . . . . 7 59 1. Introduction 61 Many Web sites have a "safe" mode, to assist those who don't want to 62 be exposed (or have their children exposed) to "objectionable" 63 content. 65 However, that goal is often difficult to achieve, because of the need 66 to go to each Web site in turn, navigate to the appropriate page 67 (possibly creating an account along the way) to get a cookie 68 [RFC6265] set in the browser, for each browser on every device used. 70 If this desire is proactively advertised by the user agent, things 71 become much simpler. A user agent that supports doing so (whether it 72 be an individual browser, or through an Operating System HTTP 73 library) need only be configured once to assure that the preference 74 is advertised to all sites. 76 Furthermore, a proxy (for example, at a school) can associate the 77 preference with all (unencrypted) requests flowing through it, 78 helping to assure that clients behind it are not exposed to 79 "objectionable" content. 81 This specification defines how to declare this desire in requests as 82 a HTTP Preference [RFC7240]. 84 Note that this specification does not precisely define what "safe" 85 is; rather, it is interpreted within the scope of each Web site that 86 chooses to act upon this information (or not). 88 That said, the intent of "safe" is to allow end users (or those 89 acting on their behalf) to express a desire to avoid content that is 90 considered "objectionable" within the cultural context of that site; 91 usually (but not always) content that is unsuitable for minors. The 92 "safe" preference ought not be used for other purposes. 94 It is also important to note that the "safe" preference is not a 95 reliable indicator that the end user is a child; other users might 96 have a desire for unobjectionable content, and some children might 97 browse without the preference being set. 99 Simply put, it is a statement by (or on behalf of) the end user to 100 the effect "If your site has a 'safe' setting, this user is hereby 101 opting into that, according to your definition of the term." 103 1.1. Notational Conventions 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. The "safe" Preference 111 When present in a request, the "safe" preference indicates that the 112 content which is not objectionable is preferred, according to the 113 server's definition of the concept. 115 For example, a request that includes the "safe" preference: 117 GET /foo.html HTTP/1.1 118 Host: www.example.org 119 User-Agent: ExampleBrowser/1.0 120 Prefer: safe 122 When configured to do so, user agents SHOULD include the "safe" 123 preference in every request, to ensure that the preference is 124 available to all requested resources. 126 See Appendix B for advice specific to Web browsers wishing to support 127 "safe". 129 Additionally, other clients MAY insert it; e.g., an operating system 130 might choose to insert the preference in requests based upon system- 131 wide configuration, or a proxy might do so based upon its 132 configuration. 134 Origin servers that utilize the "safe" preference SHOULD document 135 that they do so, along with the criteria that they use to denote 136 objectionable content. If a server has more fine-grained degrees of 137 "safety", it SHOULD select a reasonable default to use, and document 138 that; it MAY use additional mechanisms (e.g., cookies [RFC6265]) to 139 fine-tune. 141 A response corresponding to the request above might have headers that 142 look like this: 144 HTTP/1.1 200 OK 145 Transfer-Encoding: chunked 146 Content-Type: text/html 147 Server: ExampleServer/2.0 148 Vary: Prefer 150 Note that the Vary response header needs to be sent if cacheable 151 responses associated with the resource might change depending on the 152 value of the "Prefer" header. This is not only true for those 153 responses that are "safe", but also the default "unsafe" response. 155 See [RFC7234] Section 4.1 for more information the interaction 156 between Vary and Web caching. 158 See Appendix C for additional advice specific to Web servers wishing 159 to use "safe". 161 3. Implementation Status 163 _Note to RFC Editor: Please remove this section before publication._ 165 This section records the status of known implementations of the 166 protocol defined by this specification at the time of posting of this 167 Internet-Draft. The description of implementations in this section 168 is intended to assist the IETF in its decision processes in 169 progressing drafts to RFCs. Please note that the listing of any 170 individual implementation here does not imply endorsement by the 171 IETF. Furthermore, no effort has been spent to verify the 172 information presented here that was supplied by IETF contributors. 173 This is not intended as, and must not be construed to be, a catalog 174 of available implementations or their features. Readers are advised 175 to note that other implementations may exist. 177 o Microsoft Internet Explorer - see http://support.microsoft.com/ 178 kb/2980016 180 o Microsoft Bing 182 o Mozilla Firefox - see https://bugzilla.mozilla.org/ 183 show_bug.cgi?id=995070 185 o Cisco - see http://blogs.cisco.com/security/filtering-explicit- 186 content 188 o YouTube - based upon testing the live site (not formally 189 announced) 191 4. Security Considerations 193 The "safe" preference is not a secure mechanism; it can be inserted 194 or removed by intermediaries with access to the request stream. Its 195 presence reveals limited information about the user, which may be of 196 small assistance in "fingerprinting" the user. 198 By its nature, including "safe" in requests does not assure that all 199 content will actually be safe; it is only when servers elect to honor 200 it that content might be "safe". 202 Even then, a malicious server might adapt content so that it is even 203 less "safe" (by some definition of the word). As such, this 204 mechanism on its own is not enough to assure that only "safe" content 205 is seen; those who wish to ensure that will need to combine its use 206 with other techniques (e.g., content filtering). 208 Furthermore, the server and user may have differing ideas regarding 209 the semantics of "safe." As such, the "safety" of the user's 210 experience when browsing from site to site might (and probably will) 211 change. 213 5. IANA Considerations 215 This specification registers the "safe" preference [RFC7240]: 217 o Preference: safe 219 o Value: (no value) 221 o Description: Indicates that "safe" / "unobjectionable" content is 222 preferred. 224 o Reference: (this document) 226 o Notes: 228 6. References 230 6.1. Normative References 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, March 1997. 235 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, June 2014. 237 6.2. Informative References 239 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 240 April 2011. 242 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 243 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 244 2014. 246 Appendix A. Acknowledgements 248 Thanks to Alissa Cooper, Ilya Grigorik, Emma Llanso, Jeff Hughes, 249 Lorrie Cranor, Doug Turner and Dave Crocker for their comments. 251 Appendix B. Setting "safe" from Web Browsers 253 As discussed in Section 2, there are many possible ways for the 254 "safe" preference to be generated. One possibility is for a Web 255 browser to allow its users to configure the preference to be sent. 257 When doing so, it is important not to misrepresent the preference as 258 binding to Web sites. For example, an appropriate setting might be a 259 checkbox with wording such as: 261 [] Request "safe" content from Web sites 263 ... along with further information available upon request (e.g., from 264 a "help" system). 266 Browsers might also allow the "safe" preference to be "locked" - that 267 is, prevent modification without administrative access, or a 268 passcode. 270 Appendix C. Supporting "safe" on Web Sites 272 Web sites that allow configuration of a "safe" mode (for example, 273 using a cookie) can add support for the "safe" preference 274 incrementally; since the preference will not be supported by all 275 clients immediately, it is necessary to have another way to configure 276 it. 278 When honoring the safe preference, it is important that it not be 279 possible to disable it through the Web interface, since "safe" may be 280 inserted by an intermediary (e.g., at a school) or configured and 281 locked down by an administrator (e.g., a parent). If per-site 282 configuration is present and the safe preference is received, the 283 safer interpretation is always used. 285 The safe preference is designed to make as much of the Web a "safe" 286 experience as possible; it is not intended to be configured site-by- 287 site. Therefore, if the user expresses a wish to disable "safe" 288 mode, the site should remind them that the safe preference is being 289 sent, and ask them to consult their administrator (since "safe" might 290 be set by an intermediary or locked-down Operating System 291 configuration). 293 As explained in Section 2, responses that change based upon the 294 presence of the "safe" preference need to either carry the "Vary: 295 Prefer" response header field, or be uncacheable by shared caches 296 (e.g., with a "Cache-Control: private" response header field). This 297 is to avoid an unsafe cached response being served to a client that 298 prefers safe content (or vice versa). 300 Author's Address 302 Mark Nottingham 304 EMail: mnot@mnot.net 305 URI: http://www.mnot.net/