idnits 2.17.1 draft-nottingham-safe-hint-04.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 -- The document date (September 2, 2014) is 3524 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 (~~), 1 warning (==), 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 September 2, 2014 5 Expires: March 6, 2015 7 The "safe" HTTP Preference 8 draft-nottingham-safe-hint-04 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 March 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 4. Security Considerations 190 The "safe" preference is not a secure mechanism; it can be inserted 191 or removed by intermediaries with access to the request stream. Its 192 presence reveals limited information about the user, which may be of 193 small assistance in "fingerprinting" the user. 195 By its nature, including "safe" in requests does not assure that all 196 content will actually be safe; it is only when servers elect to honor 197 it that content might be "safe". 199 Even then, a malicious server might adapt content so that it is even 200 less "safe" (by some definition of the word). As such, this 201 mechanism on its own is not enough to assure that only "safe" content 202 is seen; those who wish to ensure that will need to combine its use 203 with other techniques (e.g., content filtering). 205 Furthermore, the server and user may have differing ideas regarding 206 the semantics of "safe." As such, the "safety" of the user's 207 experience when browsing from site to site might (and probably will) 208 change. 210 5. IANA Considerations 212 This specification registers the "safe" preference [RFC7240]: 214 o Preference: safe 216 o Value: (no value) 218 o Description: Indicates that "safe" / "unobjectionable" content is 219 preferred. 221 o Reference: (this document) 223 o Notes: 225 6. References 227 6.1. Normative References 229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, March 1997. 232 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, June 2014. 234 6.2. Informative References 236 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 237 April 2011. 239 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 240 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 241 2014. 243 Appendix A. Acknowledgements 245 Thanks to Alissa Cooper, Ilya Grigorik, Emma Llanso, Jeff Hughes, 246 Lorrie Cranor, Doug Turner and Dave Crocker for their comments. 248 Appendix B. Setting "safe" from Web Browsers 250 As discussed in Section 2, there are many possible ways for the 251 "safe" preference to be generated. One possibility is for a Web 252 browser to allow its users to configure the preference to be sent. 254 When doing so, it is important not to misrepresent the preference as 255 binding to Web sites. For example, an appropriate setting might be a 256 checkbox with wording such as: 258 [] Request "safe" content from Web sites 260 ... along with further information available upon request (e.g., from 261 a "help" system). 263 Browsers might also allow the "safe" preference to be "locked" - that 264 is, prevent modification without administrative access, or a 265 passcode. 267 Appendix C. Supporting "safe" on Web Sites 269 Web sites that allow configuration of a "safe" mode (for example, 270 using a cookie) can add support for the "safe" preference 271 incrementally; since the preference will not be supported by all 272 clients immediately, it is necessary to have another way to configure 273 it. 275 When honoring the safe preference, it is important that it not be 276 possible to disable it through the Web interface, since "safe" may be 277 inserted by an intermediary (e.g., at a school) or configured and 278 locked down by an administrator (e.g., a parent). If per-site 279 configuration is present and the safe preference is received, the 280 safer interpretation is always used. 282 The safe preference is designed to make as much of the Web a "safe" 283 experience as possible; it is not intended to be configured site-by- 284 site. Therefore, if the user expresses a wish to disable "safe" 285 mode, the site should remind them that the safe preference is being 286 sent, and ask them to consult their administrator (since "safe" might 287 be set by an intermediary or locked-down Operating System 288 configuration). 290 As explained in Section 2, responses that change based upon the 291 presence of the "safe" preference need to either carry the "Vary: 292 Prefer" response header field, or be uncacheable by shared caches 293 (e.g., with a "Cache-Control: private" response header field). This 294 is to avoid an unsafe cached response being served to a client that 295 prefers safe content (or vice versa). 297 Author's Address 299 Mark Nottingham 301 EMail: mnot@mnot.net 302 URI: http://www.mnot.net/