draft-nottingham-safe-hint-01.txt		draft-nottingham-safe-hint-02.txt
	Network Working Group M. Nottingham		Network Working Group M. Nottingham
	Internet-Draft		Internet-Draft
	Intended status: Informational April 22, 2014		Intended status: Informational April 22, 2014
	Expires: October 24, 2014		Expires: October 24, 2014
	The "safe" HTTP Preference		The "safe" HTTP Preference
	draft-nottingham-safe-hint-01		draft-nottingham-safe-hint-02
	Abstract		Abstract
	This specification defines a "safe" preference for HTTP, expressing a		This specification defines a "safe" preference for HTTP, expressing a
	user preference to avoid "objectionable" content.		user preference 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 2, line 16		skipping to change at page 2, line 16
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
	2. The "safe" Preference . . . . . . . . . . . . . . . . . . . . 3		2. The "safe" Preference . . . . . . . . . . . . . . . . . . . . 3
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 4		3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5.1. Normative References . . . . . . . . . . . . . . . . . . 5		5.1. Normative References . . . . . . . . . . . . . . . . . . 5
	5.2. Informative References . . . . . . . . . . . . . . . . . 5		5.2. Informative References . . . . . . . . . . . . . . . . . 5
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6
	Appendix B. Using "safe" on Your Web Site . . . . . . . . . . . 6		Appendix B. Setting "safe" from Web Browsers . . . . . . . . . . 6
			Appendix C. Using "safe" on Your Web Site . . . . . . . . . . . 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 to "objectionable" content, or who don't want their		be exposed (or have their children exposed) to "objectionable"
	children to be exposed to such content. YouTube [youtube], Yahoo!		content. YouTube [youtube], Yahoo! Search [yahoo], Google Search
	Search [yahoo], Google Search [google], Bing Search [bing], and many		[google], Bing Search [bing], and many other services have such a
	other services have such a setting.		setting.
	However, a user that wishes to have this preference honoured would		However, those who wish to have this preference honoured need to go
	need to go to each Web site in turn, navigate to the appropriate		to each Web site in turn, navigate to the appropriate page, (possibly
	page, (possibly creating an account along the way) to get a cookie		creating an account along the way) to get a cookie [RFC6265] set in
	[RFC6265] set in the browser. They would need to do this for each		the browser. They would need to do this for each browser on every
	browser on every device they use. As has been widely noted, this is		device they use.
	difficult [age-privacy].
	This can be onerous to nearly impossible to achieve effectively,		This is onerous to achieve effectively, because there are so many
	because there are too many permutations of sites, user agents and		permutations of sites, user agents and devices.
	devices.
	If instead this preference is proactively advertised by the user		If this preference is proactively advertised by the user agent,
	agent, things become much simpler. A user agent that supports this		things become much simpler. A user agent that supports doing so
	(whether it be an individual browser, or through an Operating System		(whether it be an individual browser, or through an Operating System
	HTTP library) need only be configured once to assure that the		HTTP library) need only be configured once to assure that the
	preference is advertised to all sites that understand and choose to		preference is advertised to all sites that understand and choose to
	act upon it. It's no longer necessary to go to each site that has		act upon it. It's no longer necessary to go to each site that has
	potentially "unsafe" content and configure a "safe" mode.		potentially "unsafe" content and configure a "safe" mode.
	Furthermore, a proxy (for example, at a school) can be used to ensure		Furthermore, a proxy (for example, at a school) can be used to ensure
	that the preference is associated with all (unencrypted) requests		that the preference is associated with all (unencrypted) requests
	flowing through it, helping to assure that clients behind it are not		flowing through it, helping to assure that clients behind it are not
	exposed to "objectionable" content.		exposed to "objectionable" content.
	skipping to change at page 3, line 24		skipping to change at page 3, line 24
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. The "safe" Preference		2. The "safe" Preference
	When present in a request, the "safe" preference indicates that the		When present in a request, the "safe" preference indicates that the
	user prefers content which is not objectionable, according to the		user prefers content which is not objectionable, 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"		When configured to do so, user agents SHOULD include the "safe"
	preference in every request, to ensure that the preference is applied		preference in every request, to ensure that the preference is applied
	(where possible) to all resources.		(where possible) to all resources.
	For example, a Web browser might have a "Request Safe Browsing"		For example, a Web browser might have a "Request Safe Browsing"
	option. additionally, other clients MAY insert it; e.g., an operating		option.
	system might choose to insert the preference in requests based upon
	system-wide configuration, or a proxy might do so based upon its		Additionally, other clients MAY insert it; e.g., an operating system
			might choose to insert the preference in requests based upon system-
			wide configuration, or a proxy might do so based upon its
	configuration.		configuration.
	Servers that utilise the "safe" preference SHOULD document that they		Origin servers that utilize the "safe" preference SHOULD document
	do so, along with the criteria that they use to denote objectionable		that they do so, along with the criteria that they use to denote
	content. If a site has more fine-grained degrees of "safety", it		objectionable content. If a server has more fine-grained degrees of
	SHOULD select a reasonable default to use, and document that; it MAY		"safety", it SHOULD select a reasonable default to use, and document
	use additional mechanisms (e.g., cookies) to fine-tune.		that; it MAY use additional mechanisms (e.g., cookies) to 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
	Transfer-Encoding: chunked		Transfer-Encoding: chunked
	Content-Type: text/html		Content-Type: text/html
	Server: ExampleServer/2.0		Server: ExampleServer/2.0
	Vary: Prefer		Vary: Prefer
	Note that the Vary response header needs to be sent if responses		Note that the Vary response header needs to be sent if cacheable
	associated with the resource might change depending on the value of		responses associated with the resource might change depending on the
	the "Prefer" header; this is not only true for those responses that		value of the "Prefer" header. This is not only true for those
	have changed, but also the "default" unchanged responses.		responses that are "safe", but also the default "unsafe" response.
	NOTE: currently, the safe preference doesn't have a payload, but one		See [I-D.ietf-httpbis-p6-cache] for more information.
	could be used to indicate a "level" of safety desired; e.g.,
	"safe=hi" or "safe=lo". Feedback appreciated.
	3. Security Considerations		3. 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 data stream. Its		or removed by intermediaries with access to the data stream. Its
	presence reveals information about the user, which may be of small		presence reveals information about the user, which may be of small
	assistance in "fingerprinting" the user (1 bit of information, to be		assistance in "fingerprinting" the user (1 bit of information, to be
	precise).		precise).
	Due to its nature, including it in requests does not assure that all		Due to its nature, including "safe" in requests does not assure that
	content will actually be safe; it is only when servers elect to		all content will actually be safe; it is only when servers elect to
	honour it that it might change content.		honour 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; users who wish to ensure that will need to combine its use		is seen; users 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).
	Furthermore, the server and user may have differing ideas regarding		Furthermore, the server and user may have differing ideas regarding
	the semantics of "safe." As such, the "safety" of the user's		the semantics of "safe." As such, the "safety" of the user's
	experience when browsing from site to site might (and probably will)		experience when browsing from site to site might (and probably will)
	skipping to change at page 5, line 24		skipping to change at page 5, line 22
	[I-D.snell-http-prefer]		[I-D.snell-http-prefer]
	Snell, J., "Prefer Header for HTTP", draft-snell-http-		Snell, J., "Prefer Header for HTTP", draft-snell-http-
	prefer-18 (work in progress), January 2013.		prefer-18 (work in progress), January 2013.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	5.2. Informative References		5.2. Informative References
			[I-D.ietf-httpbis-p6-cache]
			Fielding, R., Nottingham, M., and J. Reschke, "Hypertext
			Transfer Protocol (HTTP/1.1): Caching", draft-ietf-
			httpbis-p6-cache-26 (work in progress), February 2014.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	April 2011.		April 2011.
	[age-privacy]
	Moses, A., "Privacy concern as apps share data from kids
	left to their own devices", 2012,
	<http://www.theage.com.au/technology/technology-news/
	privacy-concern-as-apps-share-data-from-kids-left-to-
	their-own-devices-20121222-2bso6.html>.
	[bing] Microsoft, "Bing Help: Block Explicit Web Sites", 2013,		[bing] Microsoft, "Bing Help: Block Explicit Web Sites", 2013,
	<http://onlinehelp.microsoft.com/en-AU/bing/		<http://onlinehelp.microsoft.com/en-AU/bing/
	ff808441.aspx>.		ff808441.aspx>.
	[google] Google, "SafeSearch: turn on or off", 2013,		[google] Google, "SafeSearch: turn on or off", 2013,
	<http://support.google.com/websearch/bin/		<http://support.google.com/websearch/bin/
	answer.py?p=settings_safesearch&answer=510>.		answer.py?p=settings_safesearch&answer=510>.
	[yahoo] Yahoo! Inc., "Yahoo! Search Preferences", 2013,		[yahoo] Yahoo! Inc., "Yahoo! Search Preferences", 2013,
	<http://search.yahoo.com/preferences/preferences>.		<http://search.yahoo.com/preferences/preferences>.
	[youtube] Google, "How to access and turn on Safety Mode?", 2013,		[youtube] Google, "How to access and turn on Safety Mode?", 2013,
	<http://support.google.com/youtube/bin/		<http://support.google.com/youtube/bin/
	answer.py?answer=174084>.		answer.py?answer=174084>.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	Thanks to Alissa Cooper, Ilya Grigorik, Emma Llanso and Jeff Hughes		Thanks to Alissa Cooper, Ilya Grigorik, Emma Llanso, Jeff Hughes and
	for their comments.		Loorie Cranor for their comments.
	Appendix B. Using "safe" on Your Web Site		Appendix B. Setting "safe" from Web Browsers
	Web sites that allow configuration of a "safe" mode can add support		As discussed in Section 2, there are many possible ways for the
	for the "safe" preference incrementally; since it will not be		"safe" preference to be generated. One possibility is for a Web
	supported by all clients immediately, it is necessary to still have a		browser to allow its users to configure the preference to be sent.
	"manual" safety configuration option.
			When doing so, it is important not to misrepresent the preference as
			binding to Web sites. For example, an appropriate setting might be a
			checkbox with wording such as:
			[] Request "safe" content from Web sites
			... along with further information available upon request (e.g., from
			a "help" system).
			Browsers might also allow the "safe" preference to be "locked" - that
			is, prevent modification without administrative access, or a
			passcode.
			Appendix C. Using "safe" on Your Web Site
			Web sites that allow configuration of a "safe" mode (for example,
			using a cookie) can add support for the "safe" preference
			incrementally; since the preference will not be supported by all
			clients immediately, it is necessary to still have a fallback
			configuration option.
	When honouring the safe preference, it is important that it not be		When honouring the safe preference, it is important that it not be
	possible to disable it through the Web UI, since "safe" may be		possible to disable it through the Web interface, since "safe" may be
	inserted by an intermediary (e.g., at a school) or configured and		inserted by an intermediary (e.g., at a school) or configured and
	locked down by an administrator (e.g., a parent).		locked down by an administrator (e.g., a parent).
	The safe preference is designed to make as much of the Web a "safe"		The safe preference is designed to make as much of the Web a "safe"
	experience as possible; it is not intended to be configured site-by-		experience as possible; it is not intended to be configured site-by-
	site. Therefore, if the user expresses a wish to disable "safe"		site. Therefore, if the user expresses a wish to disable "safe"
	mode, the site should remind them that the safe preference is being		mode, the site should remind them that the safe preference is being
	sent, and ask them to consult their administrator.		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
			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).
	Author's Address		Author's Address
	Mark Nottingham		Mark Nottingham
	EMail: mnot@mnot.net		EMail: mnot@mnot.net
	URI: http://www.mnot.net/		URI: http://www.mnot.net/
End of changes. 19 change blocks.
	52 lines changed or deleted		78 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/