rfc8674xml2.original.xml   rfc8674.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.10 -->
<!DOCTYPE rfc SYSTEM "../Tools/rfcbootstrap/rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
]>
<?rfc toc="yes"?> <rfc number="8674" xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
<?rfc sortrefs="yes"?> docName="draft-nottingham-safe-hint-11" category="info" obsoletes=""
<?rfc strict="yes"?> updates="" submissionType="independent" xml:lang="en" tocInclude="true"
<?rfc comments="yes"?> symRefs="true" sortRefs="true" version="3">
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc tocdepth="1"?>
<rfc ipr="trust200902" docName="draft-nottingham-safe-hint-11" category="info"> <!-- xml2rfc v2v3 conversion 2.30.0 -->
<front> <front>
<title abbrev="Preference for Safe Browsing">The "safe" HTTP Preference</tit <title abbrev='The "safe" HTTP Preference'>The "safe" HTTP Preference</title
le> >
<seriesInfo name="RFC" value="8674" />
<author initials="M." surname="Nottingham" fullname="Mark Nottingham"> <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
<organization></organization> <organization/>
<address> <address>
<email>mnot@mnot.net</email> <email>mnot@mnot.net</email>
<uri>https://www.mnot.net/</uri> <uri>https://www.mnot.net/</uri>
</address> </address>
</author> </author>
<date year="2019"/> <date month="December" year="2019"/>
<area>General</area> <area>General</area>
<keyword>safe</keyword> <keyword>preference</keyword> <keyword>child-protect <keyword>safe</keyword>
ion</keyword> <keyword>preference</keyword>
<keyword>child-protection</keyword>
<abstract> <abstract>
<t>This specification defines a preference for HTTP requests that
<t>This specification defines a “safe” preference for HTTP requests that exp expresses a desire to avoid objectionable content, according to the
resses a desire to avoid definition of that term by the origin server.</t>
objectionable content, according to the definition of that term by the origin se <t>This specification does not define a precise semantic for
rver.</t> "safe". Rather, the term is interpreted by the server and within the
scope of each web site that chooses to act upon this information.</t>
<t>This specification does not define a precise semantic for “safe”. Rather, <t>Support for this preference by clients and servers is optional.</t>
the term is interpreted
by the server and within the scope of each Web site that chooses to act upon thi
s information.</t>
<t>Support for this preference by clients and servers is optional.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<section anchor="introduction" title="Introduction"> <name>Introduction</name>
<t>Many web sites have a "safe" mode to assist those who don't want to be
<t>Many Web sites have a “safe” mode, to assist those who don’t want to be exposed (or have their
exposed (or have their
children exposed) to content to which they might object.</t> children exposed) to content to which they might object.</t>
<t>However, that goal is often difficult to achieve because of the need to
<t>However, that goal is often difficult to achieve, because of the need to go t go to every web site that
o every Web site that might be used and navigate to the appropriate page (possibly creating an account
might be used, navigate to the appropriate page (possibly creating an account al along the way) to get
ong the way) to get a cookie <xref target="RFC6265" format="default"/> set in the browser, for each
a cookie <xref target="RFC6265"/> set in the browser, for each browser on every browser on every device used.</t>
device used.</t> <t>A more manageable approach is for the browser to proactively indicate
a preference for safe content. A user agent that supports doing so
<t>A more manageable approach is for the browser to proactively indicate a prefe (whether it be an individual browser or through an operating system HTTP
rence for safe library) need only be configured once to ensure that the preference is
content. A user agent that supports doing so (whether it be an individual browse advertised to a set of sites, or even all sites.</t>
r, or through an <t>This specification defines how to declare this desire in requests as an
Operating System HTTP library) need only be configured once to assure that the p HTTP Preference <xref target="RFC7240" format="default"/>.</t>
reference is <t>Note that this specification does not define what content might be
advertised to a set of sites, or even all sites.</t> considered objectionable, so the concept of "safe" is not
precisely defined. Rather, the term is interpreted by the server and
<t>This specification defines how to declare this desire in requests as a HTTP P within the scope of each web site that chooses to act upon this
reference <xref target="RFC7240"/>.</t> information.</t>
<t>That said, the intent is to allow end users (or those
<t>Note that this specification does not define what content might be considered acting on their behalf) to express a desire to avoid content that is
objectionable, and so considered objectionable within the cultural context of that site;
the concept of “safe” is also not precisely defined. Rather, the term is int usually (but not always), the objectionable content is content
erpreted by the server unsuitable for minors. The
and within the scope of each Web site that chooses to act upon this information. safe preference is not intended to be used for other purposes.</t>
</t> <t>Furthermore, sending the preference does not guarantee that the web sit
e will
<t>That said, the intent of “safe” is to allow end users (or those acting on use it or that it will apply a concept of "objectionable" that is
their behalf) to express consistent with the requester's views. As such, its effect can be
a desire to avoid content that is considered objectionable within the cultural c described as "best effort" and not to be relied upon. In other words,
ontext of that sending the preference is no more reliable than going to each web site
site; usually (but not always) content that is unsuitable for minors. The “saf and manually selecting a safe mode, but it is considerably easier.</t>
e” preference is not <t>It is also important to note that the safe preference is not a reliable
intended to be used for other purposes.</t> indicator that the end
<t>Furthermore, sending “safe” does not guarantee that the Web site will use
it, nor that it will
apply a concept of “objectionable” that is consistent with the requester’s
views. As such, its
effect can be described as “best effort,” and not to be relied upon. In othe
r words, sending the
preference is no more reliable than going to each Web site and manually selectin
g a “safe” mode,
but it is considerably easier.</t>
<t>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 have a desire for unobjectionable content, an d some children user is a child; other users might have a desire for unobjectionable content, an d some children
might browse without the preference being set.</t> might browse without the preference being set.</t>
<t>Note also that the cultural context applies to the hosting location of a site , the content <t>Note also that the cultural context applies to the hosting location of a site , the content
provider, and the source of the content. It cannot be guaranteed that a user-age nt and origin provider, and the source of the content. It cannot be guaranteed that a user age nt and origin
server will have the same view of the concept of what is objectionable.</t> server will have the same view of the concept of what is objectionable.</t>
<t>Simply put, it is a statement by (or on behalf of) the end user to the effect <t>Simply put, it is a statement by (or on behalf of) the end user
“If your site has a indicating that "if your site has a safe setting, this user is hereby
‘safe’ setting, this user is hereby opting into that, according to your defi opting into that, according to your definition of the term."</t>
nition of the term.”</t>
<t>The mechanism described in this document does not have IETF consensus and is
not a standard. It is
a widely deployed approach that has turned out to be useful, and is presented he
re so that server
and browser implementations can have a common understanding of how it operates.<
/t>
<t>This mechanism was presented for publication as an IETF Proposed Standard, bu
t was not approved for
publication by the IESG because of concerns that included the vagueness of the m
eaning of “safe”,
the ability of a proxy to insert the hint outside of a user’s control, the fac
t that there was no
way to know whether the hint was or was not applied to the response returned by
the server, and how
the use of this preference may incentivize increased censorship and/or targeting
of minors.</t>
<t>The specification has been updated to address those concerns, but the IESG ha
s not approved
progressing this document as an IETF Proposed Standard. As a result, it is publi
shed in the
Independent Stream.</t>
<section anchor="notational-conventions" title="Notational Conventions">
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHA <t>The mechanism described in this document does not have IETF consensus
LL NOT”, “SHOULD”, “SHOULD NOT”, and is not a standard. It is a widely deployed approach that has turned
“RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this out to be useful and is presented here so that server and browser
document are to be interpreted as implementations can have a common understanding of how it operates.</t>
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and <t>This mechanism was presented for publication as an IETF Proposed
only when, they appear in all capitals, as Standard but was not approved for publication by the IESG because of
shown here.</t> concerns that included the vagueness of the meaning of "safe", the
ability of a proxy to insert the hint outside of a user's control, the
fact that there was no way to know whether the hint was or was not
applied to the response returned by the server, and the possibility that
the use of this preference may incentivize increased censorship and/or
targeting of minors.</t>
<t>The specification was updated to address those concerns, but the IESG
did not approve progressing this document as an IETF Proposed
Standard. As a result, it has been published in the Independent Stream.</t
>
</section> <section anchor="notational-conventions" numbered="true" toc="default">
</section> <name>Notational Conventions</name>
<section anchor="safe" title="The “safe” Preference">
<t>When present in a request, the “safe” preference indicates that the user <t>
prefers that the origin The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
server to not respond with content which is designated as objectionable, accordi "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
ng to the origin NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
server’s definition of the concept.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
<t>For example, a request that includes the “safe” preference:</t> </section>
</section>
<section anchor="safe" numbered="true" toc="default">
<name>The "safe" Preference</name>
<t>When present in a request, the safe preference indicates that the user
prefers that the origin
server not respond with content that is designated as objectionable, according t
o the origin
server's definition of the concept.</t>
<t>For example, this is a request that includes the safe preference:</t>
<figure><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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
]]></artwork></figure> ]]></artwork>
<t>Typically, user agents that emit the “safe” preference will include it in
all requests with the
“https” URI scheme, although some might expose finer-grained controls over w
hen it is sent; this
ensures that the preference is available to the applicable resources. User agent
s MUST NOT emit the
“safe” preference on requests with the “http” URI scheme (see <xref targ
et="security"/>). See <xref target="browsers"/> for
more information about configuring the set of resources “safe” is sent to.</
t>
<t>Safe MAY be implemented in common HTTP libraries (e.g., an operating system m <t>Typically, user agents that emit the safe preference will include it in
ight choose to insert all requests with the
"https" URI scheme, although some might expose finer-grained controls over when
it is sent; this
ensures that the preference is available to the applicable resources. User agent
s <bcp14>MUST NOT</bcp14> emit the
safe preference on requests with the "http" URI scheme (see <xref target="securi
ty" format="default"/>). See <xref target="browsers" format="default"/> for
more information about configuring the set of resources the safe preference is s
ent to.</t>
<t>The safe preference <bcp14>MAY</bcp14> be implemented in common HTTP li
braries (e.g., an operating system might choose to insert
the preference in requests based upon system-wide configuration).</t> the preference in requests based upon system-wide configuration).</t>
<t>Origin servers that utilize the safe preference ought to document that
<t>Origin servers that utilize the “safe” preference ought to document that they do so, along with the
they do so, along with the
criteria that they use to denote objectionable content. If a server has more fin e-grained degrees criteria that they use to denote objectionable content. If a server has more fin e-grained degrees
of “safety”, it SHOULD select a reasonable default to use, and document that of safety, it <bcp14>SHOULD</bcp14> select a reasonable default to use and docum
; it MAY use additional ent that; it <bcp14>MAY</bcp14> use additional
mechanisms (e.g., cookies <xref target="RFC6265"/>) to fine-tune.</t> mechanisms (e.g., cookies <xref target="RFC6265" format="default"/>) to fine-tun
e.</t>
<t>A response corresponding to the request above might have headers that look li <t>A response corresponding to the request above might have headers that l
ke this:</t> ook like this:</t>
<figure><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Transfer-Encoding: chunked Transfer-Encoding: chunked
Content-Type: text/html Content-Type: text/html
Preference-Applied: safe Preference-Applied: safe
Server: ExampleServer/2.0 Server: ExampleServer/2.0
Vary: Prefer Vary: Prefer
]]></artwork></figure> ]]></artwork>
<t>Here, the Preference-Applied response header (<xref target="RFC7240"/>) indic ates that the site has applied the <t>Here, the Preference-Applied response header <xref target="RFC7240" for mat="default"/> indicates that the site has applied the
preference. Servers are not required to send Preference-Applied (even when they have applied the preference. Servers are not required to send Preference-Applied (even when they have applied the
preference), but are encouraged to where possible.</t> preference) but are encouraged to where possible.</t>
<t>Note that the Vary response header needs to be sent if the response is
<t>Note that the Vary response header needs to be sent if the response is cachea cacheable and might change
ble and might change depending on the value of the Prefer header. This is not only true for those res
depending on the value of the “Prefer” header. This is not only true for tho ponses that are
se responses that are safe but also the default unsafe response.</t>
“safe”, but also the default “unsafe” response.</t>
<t>See <xref target="RFC7234"/> Section 4.1 for more information the interaction
between Vary and Web caching.</t>
<t>See <xref target="servers"/> for additional advice specific to Web servers wi
shing to use “safe”.</t>
</section>
<section anchor="implementation-status" title="Implementation Status">
<t><spanx style="emph">Note to RFC Editor: Please remove this section before pub
lication.</spanx></t>
<t>This section records the status of known implementations of the protocol defi
ned by this
specification at the time of posting of this Internet-Draft. Please note that th
e listing of any
individual implementation here does not imply endorsement by the IETF. Furthermo
re, no effort has
been spent to verify the information presented here that was supplied by IETF co
ntributors. This is
not intended as, and must not be construed to be, a catalog of available impleme
ntations or their
features. Readers are advised to note that other implementations may exist.</t>
<t><list style="symbols">
<t>Microsoft Internet Explorer - see https://support.microsoft.com/en-hk/help/
2980016/</t>
<t>Microsoft Bing - see https://developer.microsoft.com/en-us/microsoft-edge/t
estdrive/demos/familysearch/</t>
<t>Mozilla Firefox - see https://support.mozilla.org/en-US/kb/block-and-unbloc
k-websites-parental-controls-firef</t>
<t>Cisco - see http://blogs.cisco.com/security/filtering-explicit-content</t>
</list></t>
</section>
<section anchor="security" title="Security Considerations">
<t>The “safe” preference is not a secure mechanism; it can be inserted or re
moved by intermediaries
with access to the request stream (e.g. for “http” URLs). Therefore, it is p
rohibited from being
included in requests with the “http” scheme.</t>
<t>Its presence reveals information about the user, which may be of assistance i
n “fingerprinting” the
user by sites and other entities in the network. This information which provides
insight into the
preferences of the user, might be used to make assumptions about the user and so
could be used to
target categories of user for purposes such as targeting (including advertising
and identification
of minors). Therefore, user agents SHOULD NOT include it in requests when the us
er has expressed a
desire to avoid such attacks (e.g., some forms of “private mode” browsing).<
/t>
<t>By its nature, including “safe” in requests does not assure that all cont
ent will actually be safe;
it is only when servers elect to honor it that content might be “safe”.</t>
<t>Even then, a malicious server might adapt content so that it is even less “
safe” (by some
definition of the word). As such, this mechanism on its own is not enough to ass
ure that only
“safe” content is seen; those who wish to ensure that will need to combine i
ts use with other
techniques (e.g., content filtering).</t>
<t>Furthermore, the server and user may have differing ideas regarding the seman
tics of “safe.” As
such, the “safety” of the user’s experience when browsing from site to sit
e as well as over time
might (and probably will) change.</t>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>This specification registers the following entry in the “HTTP Preferences
registry <xref target="RFC7240"/>:</t>
<t><list style="symbols"> <t>See <xref target="RFC7234" sectionFormat="of" section="4.1"/> for
<t>Preference: safe</t> more information about the interaction between the Vary header field and
<t>Value: (no value)</t> web caching.</t>
<t>Description: Indicates that “safe” / “unobjectionable” content is p <t>See <xref target="servers" format="default"/> for additional advice
referred.</t> specific to web servers wishing to use the safe preference.</t>
<t>Reference: (this document)</t> </section>
<t>Notes:</t> <section anchor="security" numbered="true" toc="default">
</list></t> <name>Security Considerations</name>
<t>The safe preference is not a secure mechanism; it can be inserted or re
moved by intermediaries
with access to the request stream (e.g., for "http" URLs). Therefore, it is proh
ibited from being
included in requests with the "http" scheme.</t>
<t>Its presence reveals information about the user, which may be of
assistance in fingerprinting the user by sites and other entities in
the network. This information provides insight into the preferences of
the user and might be used to make assumptions about user; thus, it
could be used to identify categories of users for purposes such as
targeting (including advertising and identification of minors).
Therefore, user agents <bcp14>SHOULD NOT</bcp14> include it in requests
when the user has expressed a desire to avoid such attacks (e.g., some
forms of private mode browsing).</t>
</section> <t>By its nature, including the safe preference in requests does not ensur
e that all
content will actually be safe; content is safe only when servers
elect to honor it.</t>
<t>Even then, a malicious server might adapt content so that it is even
less safe (by some definition of the word). As such, this mechanism on
its own is not enough to ensure that only safe content is seen; those
who wish to ensure that will need to combine its use with other
techniques (e.g., content filtering).</t>
<t>Furthermore, the server and user may have differing ideas regarding
the semantics of "safe". As such, the safety of the user's experience
when browsing from site to site, as well as over time, might (and
probably will) change.</t>
</section>
<section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>Per this specification, IANA has registered the following entry in
the "HTTP Preferences" registry <xref target="RFC7240"
format="default"/>:</t>
<ul spacing="normal">
<li>Preference: safe</li>
<li>Description: Indicates that safe (i.e., unobjectionable) content is
preferred.</li>
<li>Reference: RFC 8674</li>
</ul>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<references title='Normative References'> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7240.xml"/>
<reference anchor="RFC7240" target='https://www.rfc-editor.org/info/rfc7240'> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<front> ence.RFC.2119.xml"/>
<title>Prefer Header for HTTP</title> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<author initials='J.' surname='Snell' fullname='J. Snell'><organization /></auth ence.RFC.8174.xml"/>
or> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<date year='2014' month='June' /> ence.RFC.7234.xml"/>
<abstract><t>This specification defines an HTTP header field that can be used by
a client to request that certain behaviors be employed by a server while proces
sing a request.</t></abstract>
</front>
<seriesInfo name='RFC' value='7240'/>
<seriesInfo name='DOI' value='10.17487/RFC7240'/>
</reference>
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></
author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify
the requirements in the specification. These words are often capitalized. This
document defines these words as they should be interpreted in IETF documents.
This document specifies an Internet Best Current Practices for the Internet Comm
unity, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor="RFC7234" target='https://www.rfc-editor.org/info/rfc7234'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><o
rganization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham' role='editor
'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><org
anization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application
- level protocol for distributed, collaborative, hypertext information systems.
This document defines HTTP caches and the associated header fields that control
cache behavior or indicate cacheable response messages.</t></abstract>
</front>
<seriesInfo name='RFC' value='7234'/>
<seriesInfo name='DOI' value='10.17487/RFC7234'/>
</reference>
</references>
<references title='Informative References'> </references>
<reference anchor="RFC6265" target='https://www.rfc-editor.org/info/rfc6265'> <references>
<front> <name>Informative References</name>
<title>HTTP State Management Mechanism</title> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<author initials='A.' surname='Barth' fullname='A. Barth'><organization /></auth ence.RFC.6265.xml"/>
or> </references>
<date year='2011' month='April' />
<abstract><t>This document defines the HTTP Cookie and Set-Cookie header fields.
These header fields can be used by HTTP servers to store state (called cookies)
at HTTP user agents, letting the servers maintain a stateful session over the m
ostly stateless HTTP protocol. Although cookies have many historical infeliciti
es that degrade their security and privacy, the Cookie and Set-Cookie header fie
lds are widely used on the Internet. This document obsoletes RFC 2965. [STANDA
RDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6265'/>
<seriesInfo name='DOI' value='10.17487/RFC6265'/>
</reference>
</references> </references>
<section anchor="acknowledgements" title="Acknowledgements"> <section anchor="browsers" numbered="true" toc="default">
<name>Sending the "safe" Preference from Web Browsers</name>
<t>Thanks to Alissa Cooper, Ilya Grigorik, Emma Llanso, Jeff Hughes, Lorrie Cran <t>As discussed in <xref target="safe" format="default"/>, there are many
or, Doug Turner and possible ways for the safe preference to be generated.
Dave Crocker for their comments.</t> One possibility is for a web browser to allow its users to configure the prefere
nce to be sent.</t>
</section> <t>When doing so, it is important not to misrepresent the preference as bi
<section anchor="browsers" title="Sending “safe” from Web Browsers"> nding to web sites. For
<t>As discussed in <xref target="safe"/>, there are many possible ways for the
safe” preference to be generated.
One possibility is for a Web browser to allow its users to configure the prefere
nce to be sent.</t>
<t>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:</t> example, an appropriate setting might be a checkbox with wording such as:</t>
<figure><artwork><![CDATA[ <ul empty="true">
[] Request "safe" content from Web sites <li>[] Request safe content from web sites</li>
]]></artwork></figure> </ul>
<t>along with further information available upon request.</t>
<t>… along with further information available upon request.</t>
<t>Browsers might also allow the “safe” preference to be “locked” – th
at is, prevent modification
without administrative access, or a passcode.</t>
<t>Note that this specification does not require browsers to send “safe” on
all requests, although
that is one possible implementation; e.g., alternate implementation strategies i
nclude blacklists
and whitelists.</t>
</section>
<section anchor="servers" title="Supporting “safe” on Web Sites">
<t>Web sites that allow configuration of a “safe” mode (for example, using a <t>
cookie) can add support Browsers might also allow the safe preference to be locked to
for the “safe” preference incrementally; since the preference will not be su prevent modification without administrative access or a
pported by all clients passcode.
</t>
<t>Note that this specification does not require browsers to send the
safe preference
on all requests, although that is one possible implementation;
alternate implementation strategies include blacklists and
whitelists.</t>
</section>
<section anchor="servers" numbered="true" toc="default">
<name>Supporting the "safe" Preference on Web Sites</name>
<t>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 supporte
d by all clients
immediately, it is necessary to have another way to configure it.</t> immediately, it is necessary to have another way to configure it.</t>
<t>When honoring the safe preference, it is important that it not be
possible to disable it through the web site's interface, since the safe
preference may be configured and locked down by the browser or
computer's administrator (e.g., a parent). If the site has such a means
of configuration (e.g., stored user preferences) and the safe preference
is received in a request, the "safer" interpretation ought to be
used.</t>
<t>When honoring the safe preference, it is important that it not be possible to <t>The appropriate level of safety is a site-specific decision. When
disable it through selecting it, sites ought to bear in mind that disabling the preference
the Web site’s interface, since “safe” may be configured and locked down b might be considerably more onerous than using other means, especially
y the browser or if the preference is generated based upon the
computer’s administrator (e.g., a parent). If the site has such a means of con operating system configuration.</t>
figuration (e.g., <t>Sites might offer different levels of safety through web configuration;
stored user preferences) and the safe preference is received in a request, the they will need to
safer” either inform their users of what level the safe hint corresponds to or provide
interpretation ought to be used.</t> them with some
<t>The appropriate level of “safety” is a site-specific decision. When selec
ting it, sites ought to
bear in mind that disabling the preference might be considerably more onerous th
an through other
means, especially if the preference is generated based upon Operating System con
figuration.</t>
<t>Sites might offer different levels of “safeness” through Web configuratio
n, they will need to
either inform their users of what level the “safe” hint corresponds to, or p
rovide them with some
means of adjusting it.</t> means of adjusting it.</t>
<t>If users express a wish to disable safe mode, the site can remind
<t>If the user expresses a wish to disable “safe” mode, the site can remind them that the safe preference is being sent and ask them to consult
them that the safe their administrator (since the safe preference might be set by a locked-do
preference is being sent, and ask them to consult their administrator (since “ wn
safe” might be set by operating system configuration).</t>
a locked-down Operating System configuration).</t> <t>As explained in <xref target="safe" format="default"/>, responses that
change based upon the presence of the safe preference
<t>As explained in <xref target="safe"/>, responses that change based upon the p need to either carry the "Vary: Prefer" response header field or be uncacheable
resence of the “safe” preference by shared caches
need to either carry the “Vary: Prefer” response header field, or be uncache (e.g., with a "Cache-Control: private" response header field). This is to avoid
able by shared caches an unsafe cached
(e.g., with a “Cache-Control: private” response header field). This is to av
oid an unsafe cached
response being served to a client that prefers safe content (or vice versa).</t> response being served to a client that prefers safe content (or vice versa).</t>
</section>
</section> <section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Thanks to Alissa Cooper, Ilya Grigorik, Emma Llanso, Jeff Hughes, Lorri
e Cranor, Doug Turner, and
Dave Crocker for their comments.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAPt0RF0AA61aW3MbuXJ+x69AuA+WXCRlOZs9Z+mHRGvLayW+xZKzlUql
UuAMSOJoOOABZkhzT3l/e77uBuZCyT55yIstzgwuffv66wZms5lqXFPZhb7b
WD2JZmUn+s3d3Uf9MdiVDbYurDLLZbD7xeCRXvmgb/Gx/iX4Q3T1WpW+qM0W
E5XBrJpZ7ZsGjzdmO6NJZxtXN7PLS1WaBt88f3b5syrw59qH40K7euWVcruw
0E1oY/P82bOfnz1XJliz0L/a2gZTqYMP9+vg291C3dsjfpULpWeaZqf/d/1+
8avYuKqc7YJvbNE4XysVG1OX/2MqX2P9o41q5zBeN76Qn1pHHxpMErvfTXBF
k38Vfru1ddO9dXXl8lRah1Vhy9gcq+4JJi7trtks9KVSpm02PvB+MRBzvJvr
952G8LXWorx3JtyfvvFhbWr3uyE5FvzEbo2rFnoLJf8L/TOvbcMv2uAWetM0
u7i4uDgcDvP89kKp2oct5tjbBVQNhfe/1Gw202YJeU3RKHW3cVHHnS3cyhW8
qi7tCsJGbbKL7MauwB4T7F9bG5uom41ptP2Cb2LkQaWNLlioRJu9d6Xyy7+I
WcyystBs3UCzU22KAlaF5PRlA3/kZR3vwK9k2saGrV4e+bUPbu1qHW3Y2zB/
fOMeG4AOkgTYC3ZVuGgxamvqxhW8f5Fqrj8ZzBumPDuvhAnhuDZgVGNLlRaW
FTUcSh9cA9eWp4XfWdqoNcVG/2aXOrrGyraLjfekC1JB0eh252kMz54s4WtI
cNvudvBC3hO/HugZaxeVIxfkhWUPkXbod6zLap5MuXVlWVmlftA3dRN82aYQ
eGfqY7evqDdmb3uLbn1pp7y/GF2EojfYsD5sPHRYP2n0Adqi10tLpsW7Up9h
lzwJpHdBccxhr/n9OX2ejEt/HjYOesG3R+xwvWm0uAF2/cYf7F70Dl2tvalY
rBVG6tKtYM22akR3G4cvp9hFYdpoxS2sri22g/drT//SXMexAZSsiM1jVDlF
tO3d2jQ2e5rZASt2wdGjnVlbfQYRoltWUDpQiMIRWmcPbSENwciaBx7MkeVc
IwINpPX3zuq//e2fP71++dPzn/7p61cYqtHJQ5YEliQn2Ze9JD3RcAfZdWn3
rpBdQjFXMAsCB56KPXGw8EZpJBQkXtJNS9vglxTW2LirSwqD5PTDcGXMTJaZ
6ytaDd68ZjuRBaK4YYTpSfDo9dlhYyk0tGMlQhU0+96VLWzVicX7AUSvN/hC
fdgBt1lzt8fY2K2gROWWwQQojW3ma2x0yRiwcus28KPCJj9sQwofknIgg4vK
lFBX46LY3bCW4Qzs2bwRqBP2qip59A10SLC28QeapbRFZXhJfJkwC5brcM0Q
lp0kR9j6H2DrPz3/8dnXr1gF2N3t+e+i0YGhIUVI56F4EF1pWRdDoJxK3HtF
2ihITTuWOQUwVjMVTEXzJ5Crjmml8u9Cmx5Bm/r/h7Y7dizjStmCE6FH26cZ
qgq2sFidfDIyxAgSkVvDlXhyoA0UtTHVimMvpRr1INH06EOLY4VvqXYoK2FN
C8Ihg780OfUoEvkF9gWXh2LPlm3DujYVMCCeP1irrWPrGp6dYm7rkIDjfMiz
Rh5NcynWSik+nbCKB3uOvV0bCFjJmV+3gR4ROkxhs5qzZpq287J1awJQ2w6C
qDPdwSE0CEEdEm/NWqZtN/xCAWUgohl52Uhhk7FKI0tOSuRVUsTY8CTqvbMH
iH2FWGiLzRRLRGVXK0ylC8DIkrJ8LIJbQlQE2GSJgRofAH+mE/Z4EkX0ESwS
YMkuNkduS2ohKhh7LeCZOtWswCgNZ3tg7zVyRWIaY5+mFYG3YmSEkBW/G+dJ
RcZ3I5cylCusiY6pyE3TxaPbEpam7FkP4OHbfoDVur0mFM8WomEQVDFk0xJC
dV8kXUjUCJSk/J5igtyorb/FvBhYtlbnHJ7zJSM7G9a3D2B4aTk72CbjHsvb
bfNBIJFXOUEKeo+wZtVWPsEjvMywEQQi0u5gTL8nDcs2GY58G4ou+XeJ7IZd
ivQHX+mcv5QdGdbNTLIcTSTsUSUux/GQyQxwCrogzx2skQPhkBx/pEribjA0
XGDXNtPkGhCmQf6lsoHglbDM1wm4MNN5Nqbk36SVFBuTm5U+Qkxxyg2lHvWE
3OUJKZz0NhWUzY4A61ssQlwQOgWQiCVOWDVPeUqrJSHMJwTSIBu2QHi4uB0E
pkuQjiKvZXE6jGGV3VzfveZAsMA8oaedI3PdZULJ5qHEDVWXkpl2lT9S1GdK
w3YiUeE2NUF02/RAuGqraZ6Z4B67wCcktc5ON8hdmRKRTdgA7GGRISfFBRV0
0EALvA28SU4vKyYDsJ9n9tIzh14tBzPcAcXVrl1WOceTpWrRyEdQSibKt0kH
4K1tw+NZNyT3XqZQwylSKr65vv11SHTZB0Od6itXF1XLqQKf7s26RZkcYzbo
1mKvIo+AzJRZg1m6yjVHiTSs/uVICkZFCi4lMekoKbcNQZp8Rf71hGEOpUQl
kbmiRJ/jPNgkkUIepOnua2gw88VuUvoGqhoIz1ievB7q3JH/4I9k/BEfEcvD
MixFR/zHBdLWEOctYBYQ098JOYm6k/7xDMV93LgdzXNBWGoCGHvSUErN4v5j
xkbeuLRgku2OOhdCNsuS6EbiJdkqYtvObpsTIxOKrWmYpKhhLH3PYzhxUjaI
ANOMK+wrcZPj0qob+PCOiANmu20g9JZKwR9+oE6CkdpQv/T1nlQDLYug96jD
OHXqybvPt3eTqfyv33/gvz9d//vnm0/Xr+jv2zdXb992f+Qvbt98+Pz2Vf+X
PFcY+fLDu3fX71/JYDzVJ4/eXf3nREw6+fDx7ubD+6u3k4cYY4TJLe2Ip5qo
Rrj0y8uP+vLHRMOfX17+jJJLfvz58k8/4gc8sZbFuNiQn1yFwjbWBJqE6oTC
7EDXKhgSS0T4Ws3owpocsrYh9/+BHn1V6jdMmjGB58sUaPqtPJ9qs9inSwZy
+WTwdJylhEGkaBGG3vFOKa9T5bKujSjrQQlx2mMZLfAkPpIcUu4j1kl11RdD
mDrtZRzhUXxc4IVSf/zxh/r1+k5frLyfb5ptxaXUxeX8EvV/bBaa+lVp9rkP
a/WZ8vUV5euFvpbnvwisY9AzJXZYSDFLk6u74w5KBW+bDira3I7aum9xLk79
afscYeIPXdmXaa2acGdtoj9/ukFFtEFegRYqokYoeJk+CWuS/oemwivM1sFQ
AZYBFAZhukEOI9FMPvOCXV9R+gxDnxgzQ7M3rhIC23UtKGnQEwxjUgSq/Xkg
e47oTn71UH5fP5RVs6xDUfVZtFTtRlu0ATnk69fzub7lRynZRgQbpTLm2oPi
D1mHMnku8RNHzxV7t/FBIRilY0SkinrMgAtGgZzLJfBT/h40FYhbntn5ek7h
nhI4M1RpP4hxpFzt05461fNAG0vOHlzRyhwz4i6dJCzdOXb5YdiITOZrG6Ta
3+03fI5chslNh3bZ5iBGHs40TT2mzvmAeABBZwYftiIHYJ/I96PUHqyLSbXA
ByUltg65ZueZpUVislFlrtAcJ5xpEqpLDcThbmKaHSBhUksOmxB0HUnygiYg
u9EekTCdZCHVsajOUtIyi6OeGVf1vMemrS33wTqCAPhK8DcAsYxE8LS9HZY/
G2vKziQVloKr3EuHJ0FSBiH9/Nkz/eHf1B2qhggzza7rwtMaC7hMW98jhb8U
nc6AM3ahqaS5IBxTfUaYXQmtSah0y2rv0Et+XjwHeP2HoXMPGSjg9caGVPc8
nK6XXuTRZ8Ou0/lj2aQvGzLRGpXFFLrirJRlJaf8tXVBGA6V0o9t44ybaoxd
7IDCpB9d4Fz4EM2On4hwAFIpXWBijKm7ak86ZlaTYh6IS63CmLiApNjVmDVS
HY4KIrVIqYJPsW7qtVVCjvruEehy1Xbl40QEnaTFqEPjYq5fmDI0obWp2epj
v2rSNkRMoJpEliK4D5JJW0v854GEa7bvHP4jsZRbiV39IzyR20WnIJqbZnRG
w0WCbQ5ETFlhJDJ1MEgJkLNbICGSAPMgDvEnt5kz2SXdcgckOcUB9DKFFwVw
Oh5hJnQzqqiIqDYtGOVTMaPXEElfYx0Pv/9YEf+G3Fu/T23VaPP2VyThoOyZ
P8092vRJsAXTU3ZnXoZMRtVF/aCuS7akAz9f+Cq3PaWKQGYds/rka43bshfs
UiMi1xQ3pObaNrNXdJQ5z2KMezdg4HmQqY9q0A4f701K1K5eliYB3BEVR9cZ
kKrh7vVcj/p6tU+NMApkxWUI5JBGEszkVsfkFb2XnFTGvFsquaijz1GK1XK1
3oBDt01qSrLLK95h7kGaKMC+baN0OlNvmsIhdSiJBUKnSFWiiI6gPLBPkLat
WlkYMhBN+ZSgmSCC3DG18nstS0frdCaq8uwXKB/u+FS/c0Xw0a+azmgA210F
9QU6G0YQ5NPQdKYx3+YRcxCIC1vPNvcXG1vtLp7//Odnzy5/uhjN+guZeDxR
CRCsiFw8nKqNF92zmS3X9gKY3JTB7S2GbX28WJmtq44RZUex4ZX872CfRr8G
9K78l2/tWb4iVkzLfL69uF9eLCtf3M9goFlby98Hu+TDjtkOOoXCqlkmnbMV
zY/1XrpY+MEqWARj13Fe0AuWIxO8i5WriHHU6xkILaLUNbPckiMguE3fUWUp
HVAxEIqiTBGl0PxOl5O/HLScmDaktrDQM2oDhYQg7L2MgVtbOuZ7ivkRihou
yMdkIHIlLDxDTnkzp30bz7kRHxiEurI6+I1bOm7qBL+V9qbq+izuOzRZKDL3
fXNvqKCN7C2ywSNcONd701S1kVMvpeHCp68mMdEJUGxNpS+kxl8TTrJc20AT
corLhS1HClX3DVGpdJCBYKA7Ezm6B5uQRVNflV5FTpepaThM4x2yym5Hp6ik
760Bm6KTuu1OrD+WLzWWARttVQ7GKem/6HQFxMk6PEL6aXLQwUcGVMT27Zoz
sQe35NMRoJzNwkDU/+hAXnWNnbGth5Vh37c4qf96QyeuI8OIT+V7DcBHdXrc
JNttGlPcd/yW60JSPYs4gSn3dCZLxwgTaVNi/1RE/HKksxFdMz5OdS9nrosG
2+rSyfCQlJsYuRlANS2YghxjEG3CHC+UOHrXB+nyvVB8yLHxdBbkUjny4Giy
IwLXe9ELdVbgBIQOvo25zpDvTWl2/Ry5SStbYCJZUdAm6c7IoaEq9bD/QE2q
88EJUjNux/qa9casQJSCeogq8pMzZJI6V795U8w2bP1C97cdiPrwqVDdD2Vt
5jsGwMglHd7Som06HJEIVA02VTuyUV/dyEIdlp6fHt6d3CdhPyM4YG5Nlx94
GDk3nC/YtQllX0HLFZbYtXnnE6hJZTXZrp4bRvET9mHMKs0PcoPshoJ7crTr
03EYYsCSL6XGBXGmdDh0RvsFiCz56It0dJ4YNzFFoopX769OssOjx/CQik4Q
g1C9laczYNoNFBeOGc0mJwfvcZLG4ZNhNbQgWtB/liqxp+DJ4PwLfQZSxfT/
HM9ecSORkWsBAjEqopKnXBB9Pzn6HHiPIGWgyxpPwWi6Rc9GrUxai/hxzJet
lkAI0tBVQXS2IqrAl8v4mLy+51R2BYYZDfRHXGOqb6qj0b8GR3B5P9XX263R
byvUqn6q/xU0Ub+Bz9Pdh7cokJ3VL1HHeox7hVjQd9RTZwdTr8ivXgbwhQS2
cpyer7fNU24fnSizW1B9kPpvlOS7pg+qc0gK+tAyKsJcqDuoLfp1mo4HjFxh
OXZVH92a6a+vPOQHUumt+eJfQ7r9UOeSUc4v0uUXw5saXH+R6wMpMkNMF5Dk
ZslpQ60vJ+epgZtvu2RC0J/cpiPorYvB5jbvyXR0UOC6pkR3ywqU3gfVN03r
0VWjdJTXAywd59rifgkqyLhySM3alAhTz0Lr//pveJvQnBNI62zFy0tvYT6f
D9tJK8GfMS/pqDu3u1KmobSUTZ5AnapbUfP3bDchQmrLiYazp5sCU/pqz+nE
l32azmfLpkS2pnDmW4mJ0vFNHqN3wPECCfP/fL8mNTOya8SuqZH268ct3r6N
q/K1Bl/3TYqTGuSFTj1GgnTqs59WfCwEsImpldCKZYWIp5IxytWaDYzDP1O8
CdEfhBymISPeMscjSi2FPDy1u7+Xkz5MMepIyrnd4LqCPlsNG/etMKbUeTtn
vm3KMt/6Ut+OSz5RYznBKl5gG2zwcRxIrpRqMc0oxJ3piVxgVG7LDB46OOZg
qy0ZnJoZREO4sVSn+x1yrNgHsusilulKlw6pV9zv5GEUZ/6RdteZl3qoLkrd
Sl+F5An9dZkn6a7UytC8IndWsDm9wEYGFveHQx6649zuql9QANtdK9djBm4P
tefutZYK7pzbt6N2ngABn+/GdCg8sLyMVxFz2XJ4osQZ87y/QDFWFakpQP9u
LwD+2PFVmKjuGC65We5hL7v7incnVykrqpX1oLGcrkVAmlnXeyrprho1gPRv
wknznRu6miSunpdSy3RgB6Wlex1iuewDw+Pg0/t0TFO4r4bgDkRX+R5QvrEo
FI4VO9WWd8fk2a1OZ4YMXW4anhE8uPA4Mg5fESFh0uVXYnaJ4BEosqp6JkeH
+ZNub9zbG06WTjCHxFRZN0D1lNYlDeZbK2KOQWzzyXzfUSecZMhNpSF9upWc
wdy88zpT/qWNyUZU9fbscnTvO3PpHF3jq8bZrQl/ACtiUbsd9LCJuY31nq8c
5UtLJt6nQQwQkQ8lWPKTwBrHbHYNOoNaHpVJ8TrjeP2+GYnAXzGFruT4ZER4
TnrDQoeHPpJcSRoEuQN9CrQq1xrJpIUJQUBkMjw4mDxolK+crUq2IMVk3ffE
qbraGAIFfhZVQhppn+jJS3o6eyntooVOVeo3Fjjve+Rd6WvoJg3DCi9Qqm5k
NlnY57u6kgVEQ/nAW4YmDkM3pbg/TTnPQOP/C9QriFqoMgAA
</rfc> </rfc>
 End of changes. 44 change blocks. 
536 lines changed or deleted 262 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/