draft-nottingham-safe-hint-05.txt		draft-nottingham-safe-hint-06.txt
	Network Working Group M. Nottingham		Network Working Group M. Nottingham
	Internet-Draft		Internet-Draft
	Intended status: Standards Track October 3, 2014		Intended status: Standards Track February 13, 2015
	Expires: April 6, 2015		Expires: August 17, 2015
	The "safe" HTTP Preference		The "safe" HTTP Preference
	draft-nottingham-safe-hint-05		draft-nottingham-safe-hint-06
	Abstract		Abstract
	This specification defines a "safe" preference for HTTP requests,		This specification defines a "safe" preference for HTTP requests,
	expressing a desire to avoid "objectionable" content.		expressing a desire to avoid "objectionable" content.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 31		skipping to change at page 1, line 31
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 6, 2015.		This Internet-Draft will expire on August 17, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. The "safe" Preference . . . . . . . . . . . . . . . . . . . . 3		2. The "safe" Preference . . . . . . . . . . . . . . . . . . . . 3
	3. Implementation Status . . . . . . . . . . . . . . . . . . . . 4		3. Implementation Status . . . . . . . . . . . . . . . . . . . . 4
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6
	Appendix B. Setting "safe" from Web Browsers . . . . . . . . . . 7		Appendix B. Setting "safe" from Web Browsers . . . . . . . . . . 6
	Appendix C. Supporting "safe" on Web Sites . . . . . . . . . . . 7		Appendix C. Supporting "safe" on Web Sites . . . . . . . . . . . 6
	1. Introduction		1. Introduction
	Many Web sites have a "safe" mode, to assist those who don't want to		Many Web sites have a "safe" mode, to assist those who don't want to
	be exposed (or have their children exposed) to "objectionable"		be exposed (or have their children exposed) to "objectionable"
	content.		content.
	However, that goal is often difficult to achieve, because of the need		However, that goal is often difficult to achieve, because of the need
	to go to each Web site in turn, navigate to the appropriate page		to go to each Web site in turn, navigate to the appropriate page
	(possibly creating an account along the way) to get a cookie		(possibly creating an account along the way) to get a cookie
	[RFC6265] set in the browser, for each browser on every device used.		[RFC6265] set in the browser, for each browser on every device used.
	If this desire is proactively advertised by the user agent, things		If this desire is proactively advertised by the user agent, things
	become much simpler. A user agent that supports doing so (whether it		become much simpler. A user agent that supports doing so (whether it
	be an individual browser, or through an Operating System HTTP		be an individual browser, or through an Operating System HTTP
	library) need only be configured once to assure that the preference		library) need only be configured once to assure that the preference
	is advertised to all sites.		is advertised to a set of sites, or even all sites.
	Furthermore, a proxy (for example, at a school) can associate the
	preference with all (unencrypted) requests flowing through it,
	helping to assure that clients behind it are not exposed to
	"objectionable" content.
	This specification defines how to declare this desire in requests as		This specification defines how to declare this desire in requests as
	a HTTP Preference [RFC7240].		a HTTP Preference [RFC7240].
	Note that this specification does not precisely define what "safe"		Note that this specification does not precisely define what "safe"
	is; rather, it is interpreted within the scope of each Web site that		is; rather, it is interpreted within the scope of each Web site that
	chooses to act upon this information (or not).		chooses to act upon this information. Furthermore, sending "safe"
			does not guarantee that the Web site will use it.
	That said, the intent of "safe" is to allow end users (or those		That said, the intent of "safe" is to allow end users (or those
	acting on their behalf) to express a desire to avoid content that is		acting on their behalf) to express a desire to avoid content that is
	considered "objectionable" within the cultural context of that site;		considered "objectionable" within the cultural context of that site;
	usually (but not always) content that is unsuitable for minors. The		usually (but not always) content that is unsuitable for minors. The
	"safe" preference ought not be used for other purposes.		"safe" preference ought not be used for other purposes.
	It is also important to note that the "safe" preference is not a		It is also important to note that the "safe" preference is not a
	reliable indicator that the end user is a child; other users might		reliable indicator that the end user is a child; other users might
	have a desire for unobjectionable content, and some children might		have a desire for unobjectionable content, and some children might
	skipping to change at page 3, line 33		skipping to change at page 3, line 28
	content which is not objectionable is preferred, according to the		content which is not objectionable is preferred, according to the
	server's definition of the concept.		server's definition of the concept.
	For example, a request that includes the "safe" preference:		For example, a request that includes the "safe" preference:
	GET /foo.html HTTP/1.1		GET /foo.html HTTP/1.1
	Host: www.example.org		Host: www.example.org
	User-Agent: ExampleBrowser/1.0		User-Agent: ExampleBrowser/1.0
	Prefer: safe		Prefer: safe
	When configured to do so, user agents SHOULD include the "safe"		User agents SHOULD include the "safe" preference in all requests, to
	preference in every request, to ensure that the preference is		ensure that the preference is available to the applicable resources.
	available to all requested resources.		Note that the resources which "safe" is sent to is potentially
			configurable; see Appendix B for more information.
	See Appendix B for advice specific to Web browsers wishing to support
	"safe".
	Additionally, other clients MAY insert it; e.g., an operating system		Additionally, other clients MAY insert it; e.g., an operating system
	might choose to insert the preference in requests based upon system-		might choose to insert the preference in requests based upon system-
	wide configuration, or a proxy might do so based upon its		wide configuration.
	configuration.
	Origin servers that utilize the "safe" preference SHOULD document		Origin servers that utilize the "safe" preference ought to document
	that they do so, along with the criteria that they use to denote		that they do so, along with the criteria that they use to denote
	objectionable content. If a server has more fine-grained degrees of		objectionable content. If a server has more fine-grained degrees of
	"safety", it SHOULD select a reasonable default to use, and document		"safety", it SHOULD select a reasonable default to use, and document
	that; it MAY use additional mechanisms (e.g., cookies [RFC6265]) to		that; it MAY use additional mechanisms (e.g., cookies [RFC6265]) to
	fine-tune.		fine-tune.
	A response corresponding to the request above might have headers that		A response corresponding to the request above might have headers that
	look like this:		look like this:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	skipping to change at page 5, line 11		skipping to change at page 4, line 48
	o Cisco - see http://blogs.cisco.com/security/filtering-explicit-		o Cisco - see http://blogs.cisco.com/security/filtering-explicit-
	content		content
	o YouTube - based upon testing the live site (not formally		o YouTube - based upon testing the live site (not formally
	announced)		announced)
	4. Security Considerations		4. Security Considerations
	The "safe" preference is not a secure mechanism; it can be inserted		The "safe" preference is not a secure mechanism; it can be inserted
	or removed by intermediaries with access to the request stream. Its		or removed by intermediaries with access to the request stream (e.g.
	presence reveals limited information about the user, which may be of		for "http://" URLs). Its presence reveals limited information about
	small assistance in "fingerprinting" the user.		the user, which may be of small assistance in "fingerprinting" the
			user.
	By its nature, including "safe" in requests does not assure that all		By its nature, including "safe" in requests does not assure that all
	content will actually be safe; it is only when servers elect to honor		content will actually be safe; it is only when servers elect to honor
	it that content might be "safe".		it that content might be "safe".
	Even then, a malicious server might adapt content so that it is even		Even then, a malicious server might adapt content so that it is even
	less "safe" (by some definition of the word). As such, this		less "safe" (by some definition of the word). As such, this
	mechanism on its own is not enough to assure that only "safe" content		mechanism on its own is not enough to assure that only "safe" content
	is seen; those who wish to ensure that will need to combine its use		is seen; those who wish to ensure that will need to combine its use
	with other techniques (e.g., content filtering).		with other techniques (e.g., content filtering).
	skipping to change at page 7, line 29		skipping to change at page 6, line 29
	[] Request "safe" content from Web sites		[] Request "safe" content from Web sites
	... along with further information available upon request (e.g., from		... along with further information available upon request (e.g., from
	a "help" system).		a "help" system).
	Browsers might also allow the "safe" preference to be "locked" - that		Browsers might also allow the "safe" preference to be "locked" - that
	is, prevent modification without administrative access, or a		is, prevent modification without administrative access, or a
	passcode.		passcode.
			Note that this specification does not constrain browsers to send
			"safe" on all requests, although that is one possible implementation;
			e.g., an alternate implementation strategy would be to allow a
			blacklist (of sites that "safe" is not sent to).
	Appendix C. Supporting "safe" on Web Sites		Appendix C. Supporting "safe" on Web Sites
	Web sites that allow configuration of a "safe" mode (for example,		Web sites that allow configuration of a "safe" mode (for example,
	using a cookie) can add support for the "safe" preference		using a cookie) can add support for the "safe" preference
	incrementally; since the preference will not be supported by all		incrementally; since the preference will not be supported by all
	clients immediately, it is necessary to have another way to configure		clients immediately, it is necessary to have another way to configure
	it.		it.
	When honoring the safe preference, it is important that it not be		When honoring the safe preference, it is important that it not be
	possible to disable it through the Web interface, since "safe" may be		possible to disable it through the Web site's interface, since "safe"
	inserted by an intermediary (e.g., at a school) or configured and		may be configured and locked down by the browser's administrator
	locked down by an administrator (e.g., a parent). If per-site		(e.g., a parent). If the site has configuration (e.g., stored user
	configuration is present and the safe preference is received, the		preferences) and the safe preference is received in a request, the
	safer interpretation is always used.		"safer" interpretation is always used.
	The safe preference is designed to make as much of the Web a "safe"		If the user expresses a wish to disable "safe" mode, the site should
	experience as possible; it is not intended to be configured site-by-		remind them that the safe preference is being sent, and ask them to
	site. Therefore, if the user expresses a wish to disable "safe"		consult their administrator (since "safe" might be set by a locked-
	mode, the site should remind them that the safe preference is being		down Operating System configuration).
	sent, and ask them to consult their administrator (since "safe" might
	be set by an intermediary or locked-down Operating System
	configuration).
	As explained in Section 2, responses that change based upon the		As explained in Section 2, responses that change based upon the
	presence of the "safe" preference need to either carry the "Vary:		presence of the "safe" preference need to either carry the "Vary:
	Prefer" response header field, or be uncacheable by shared caches		Prefer" response header field, or be uncacheable by shared caches
	(e.g., with a "Cache-Control: private" response header field). This		(e.g., with a "Cache-Control: private" response header field). This
	is to avoid an unsafe cached response being served to a client that		is to avoid an unsafe cached response being served to a client that
	prefers safe content (or vice versa).		prefers safe content (or vice versa).
	Author's Address		Author's Address
End of changes. 15 change blocks.
	40 lines changed or deleted		36 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/