Internet DRAFT - draft-sahib-httpbis-off-the-record
draft-sahib-httpbis-off-the-record
HTTP S. K. Sahib
Internet-Draft Brave Software
Intended status: Standards Track 5 July 2023
Expires: 6 January 2024
The Off-The-Record Response Header Field
draft-sahib-httpbis-off-the-record-00
Abstract
This document specifies an HTTP response header field that enables a
server to inform the client that the requested website should be
treated as "off-the-record." The purpose is to indicate that the
server considers the content sensitive in some way, and the client
may choose not to retain any record of accessing it.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://brave-
experiments.github.io/draft-sahib-httpbis-off-the-record/#go.draft-
sahib-httpbis-off-the-record.html. Status information for this
document may be found at https://datatracker.ietf.org/doc/draft-
sahib-httpbis-off-the-record/.
Discussion of this document takes place on the HTTP Working Group
mailing list (mailto:ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/.
Source for this draft and an issue tracker can be found at
https://github.com/brave-experiments/draft-sahib-httpbis-off-the-
record.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Sahib Expires 6 January 2024 [Page 1]
Internet-Draft OTR July 2023
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 January 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Request-OTR Response Header . . . . . . . . . . . . . . . . . 4
3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Off-The-Record Session . . . . . . . . . . . . . . . . . . . 5
5. Comparisons With Other Client-Side Approaches . . . . . . . . 5
5.1. Private Browsing . . . . . . . . . . . . . . . . . . . . 5
5.2. Manual Editing . . . . . . . . . . . . . . . . . . . . . 5
5.3. Clear-Site-Data . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6.1. Navigation History . . . . . . . . . . . . . . . . . . . 6
6.2. Malicious Websites . . . . . . . . . . . . . . . . . . . 6
6.3. Consent . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.4. Doesn't Protect Against the Website . . . . . . . . . . . 7
6.5. Third Parties on Websites . . . . . . . . . . . . . . . . 7
6.6. Only Applicable for UI-bound Attackers . . . . . . . . . 7
6.7. Fingerprinting . . . . . . . . . . . . . . . . . . . . . 7
6.8. Self-Identification as Sensitive . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
Sahib Expires 6 January 2024 [Page 2]
Internet-Draft OTR July 2023
1. Introduction
Browsers record information about users' browsing behavior and
interests, both explicitly (e.g. browsing history, DOM storage,
cookies) and implicitly (e.g. cache state, saved credentials, URL
auto-complete). In situations where an attacker has physical access
to the victim's device, this information constitutes a privacy leak
and can be used for surveillance. This kind of physical access is
especially common in cases of intimate partner violence [IPV].
Client software currently provide some tools to help users hide their
activity on sensitive sites, such as incognito/private mode or the
ability to edit browsing history. However, these tools are
insufficient to protect people whose safety depends on it: they
either hide too much (thus inviting suspicion from abusers), too
little (thus allowing abusers to recover browsing history), or are
otherwise difficult to use successfully in a stressful situation.
The Request-OTR HTTP response header described in this document
allows websites to classify their own content as "sensitive" and
request to be treated as "off-the-record." The client can then
choose to not record the site visit and remove evidence of the site
visit by preventing persistent storage of related data to disk (such
as [COOKIES]). See Section 5 for a comparison with other approaches
a client can take to remove evidence of accessing a sensitive
website.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terminology is used throughout the document:
* UI-bound adversary: An attacker who has authenticated access to a
victim's device via standard user interfaces [FREED_ET_AL].
* registered domain: Also known as "effective top level domain + 1"
or "eTLD+1", an origin's "registered domain" is the origin's
host's public suffix plus the label to its left, with the term
"public suffix" being defined in a note in [RFC6265], Section 5.3
as "a domain that is controlled by a public registry" [PSL].
* sensitive: This document uses "sensitive" content to mean anything
that a website thinks is worth hiding from a UI-bound adversary.
Websites self-report their content as sensitive.
Sahib Expires 6 January 2024 [Page 3]
Internet-Draft OTR July 2023
* client: Software acting on behalf of users, typically a Web
browser.
* Off-the-record (OTR): Client operation mode where the client tries
to not record or persist state or evidence of having visited a a
particular site (see Section 4).
* OTR session: A client is said to be in an OTR session for a site
when it is treating interactions with the site as being off-the-
record. The scope of an OTR session is the site's registered
domain.
This document uses the following terminology from Section 3 of
[RFC8941] to specify syntax and parsing: Boolean.
3. Request-OTR Response Header
3.1. Definition
Request-OTR is an Item Structured Header [RFC8941]. Its value MUST
be a Boolean [RFC8941], Section 3.3.6. Its ABNF is:
Request-OTR: sf-boolean
For example:
Request-OTR: ?1
3.2. Operation
The Request-OTR response header field is used to indicate that the
client SHOULD treat the site as sensitive and not keep traces of the
user having visited the site. See Section 4 for details on
considerations and protections a client can use in an OTR session.
The scope of the OTR session is defined as the requesting site's
registered domain. Sites request an Off-The-Record session by
including the Request-OTR header in the initial navigation request.
On receiving this header, a client MAY ask for the user's consent
before initiating an OTR session for the site (see Section 6.3).
A header field value of ?0 i.e. false is treated as if the header was
not present.
Sahib Expires 6 January 2024 [Page 4]
Internet-Draft OTR July 2023
4. Off-The-Record Session
The main purpose of an OTR session is to not persist the user's
interactions with the site. A client can apply a number of
protections and mitigations in order to achieve this:
1. Construct a new, empty, temporary storage area for the site for
explicit (cookies, localStorage) and implicit storage (caches,
autocomplete) attached to the OTR session. Every site in OTR
mode should get its own temporary storage.
2. Prevent browser extensions from running in the OTR session.
3. Users are notified before they navigate away from the site (and
thus away from the OTR session).
5. Comparisons With Other Client-Side Approaches
5.1. Private Browsing
Many web browsers come with a private browsing mode, also known as
incognito mode. Private windows enable users to browse the internet
without their browsing activity being recorded locally. However,
private browsing has limitations when it comes to protecting users
from on-device surveillance. It is easy to forget to open a private
window before visiting a site, especially when experiencing stress,
resulting in the site visit being permanently recorded. Similarly,
forgetting to close the private window may lead to unintended
browsing in private mode beyond the target sensitive site. This can
alert potential abusers to the use of private browsing, as the
absence of browsing history may raise suspicion or put the victim at
further risk.
5.2. Manual Editing
Certain browsers provide advanced controls that allow users to
manually delete browser storage for specific sites. This approach
requires performing the deletion after visiting the site, rather than
protecting the user during the visit. This can put the user at risk
if the browser needs to be closed quickly. Furthermore, these
controls are often challenging to locate and even more difficult for
non-technical users to use correctly. Additionally, these browser
controls typically only allow the user to delete specific stored data
for the site, such as cookies or permissions, but do not provide the
ability to remove other traces of the site, like browsing history or
caches.
Sahib Expires 6 January 2024 [Page 5]
Internet-Draft OTR July 2023
5.3. Clear-Site-Data
Clear-Site-Data HTTP response header ([CLEAR_SITE_DATA]) lets
websites ask a user agent to clear specific kinds of locally stored
data. As noted in Section 6.1 of [CLEAR_SITE_DATA], Clear-Site-Data
acts after the fact, meaning the user agent retains data until the
website requests its removal. In contrast, Request-OTR takes a
preventative approach, where the client avoids storing data once it
receives the header. Furthermore, with Clear-Site-Data, it is the
website that defines which data should be cleared, not the client,
which may leave the user exposed to identifying storage that the
website may have overlooked. It's important to note that Clear-Site-
Data does not provide a means to clear browser history; it only
addresses web-visible storage.
6. Security Considerations
6.1. Navigation History
OTR mode only applies to the specific site requesting OTR mode.
Notably, a user might have taken certain actions before getting to
the sensitive site which would reveal the identity of the website.
For example: a user looking for reproductive health centers near them
would search for "reproductive health centers" on a search engine
before navigating to a website that requests OTR mode; the browsing
history would reveal the user's intentions. Request-OTR would only
conceal activity on the site, not the navigation history leading up
to it.
6.2. Malicious Websites
Malicious websites could exacerbate harm by abusing this feature to
hide traces of malicious activity. For instance, a malware website
could use OTR mode as a means to conceal the download of malware onto
the user's device.
6.3. Consent
To address the issue of malicious websites misusing OTR mode, one
possible solution is to get the user's consent before enabling this
mode. However, it's important to recognize that placing the
responsibility of detecting and preventing abuse on clients can be
challenging. Detecting malicious intent and ensuring appropriate
consent can be complex tasks.
Sahib Expires 6 January 2024 [Page 6]
Internet-Draft OTR July 2023
6.4. Doesn't Protect Against the Website
OTR mode is not a privacy protection against the website operating in
OTR mode. It simply treats the website as sensitive and prevents
persistent storage of the site's contents on the client.
6.5. Third Parties on Websites
Third-party trackers on websites services may still collect and
retain data, even if the primary website is operating in OTR mode.
6.6. Only Applicable for UI-bound Attackers
OTR mode is explicitly used to provide protection against UI-bound
attackers who snoop local storage and browsing history.
Sophisticated attackers could install local monitoring software on
the device, or intercept and modify network traffic between the
client and server, bypassing OTR mode's protections.
6.7. Fingerprinting
A site MUST NOT be able to tell that a client is in OTR mode.
6.8. Self-Identification as Sensitive
A censor could leverage this feature to conduct measurement studies
aimed at identifying and subsequently banning websites that respond
with the Request-OTR header.
7. IANA Considerations
This document has no IANA actions.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Sahib Expires 6 January 2024 [Page 7]
Internet-Draft OTR July 2023
[RFC8941] Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
<https://www.rfc-editor.org/rfc/rfc8941>.
8.2. Informative References
[CLEAR_SITE_DATA]
West, M., "Clear Site Data - W3C Working Draft, 30
November 2017", n.d.,
<https://www.w3.org/TR/clear-site-data/>.
[COOKIES] Bingler, S., West, M., and J. Wilander, "Cookies: HTTP
State Management Mechanism", Work in Progress, Internet-
Draft, draft-ietf-httpbis-rfc6265bis-12, 10 May 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
rfc6265bis-12>.
[FREED_ET_AL]
Freed, D., Palmer, J., Minchala, D., Levy, K., Ristenpart,
T., and N. Dell, "“A Stalker’s Paradise”: How Intimate
Partner Abusers Exploit Technology", 2018,
<https://dl.acm.org/doi/pdf/10.1145/3173574.3174241>.
[IPV] Celi, S., Guerra, J., and M. Knodel, "Intimate Partner
Violence Digital Considerations", Work in Progress,
Internet-Draft, draft-celi-irtf-hrpc-ipvc-00, 13 March
2023, <https://datatracker.ietf.org/doc/html/draft-celi-
irtf-hrpc-ipvc-00>.
[PSL] Mozilla, "Public Suffix List", n.d.,
<https://publicsuffix.org/>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/rfc/rfc6265>.
Acknowledgments
This document is based on work done by Mark Pilgrim, Sofía Celi, Pete
Snyder and Shivan Kaul Sahib.
Author's Address
Shivan Kaul Sahib
Brave Software
Email: shivankaulsahib@gmail.com
Sahib Expires 6 January 2024 [Page 8]
