Privacy/Features/Shortened HTTP Referer header

Please use "Edit with form" above to edit this page.

Status

Shortened HTTP Referer header
Stage	Development
Status	`
Release target	`
Health	OK
Status note	`

Team

Product manager	Sid Stamm
Directly Responsible Individual	Sid Stamm
Lead engineer	Sid Stamm
Security lead	Curtis Koenig
Privacy lead	Sid Stamm
Localization lead	`
Accessibility lead	`
QA lead	Mihai Morar
UX lead	`
Product marketing lead	`
Operations lead	`
Additional members	Owen Chu

Open issues/risks

Site breakage (tolerable? need to quantify this)
User confusion (make it hidden pref?)

Stage 1: Definition

1. Feature overview

There is the desire to remove the Referer header outright, possibly in favor of the Origin header or something with less information. It can leak sensitive data accidentally and can be abused as a form of ambient authority. Unfortunately, we can't just stop sending it on requests because too many things on the web might break. Sites like Facebook have expressed a desire for a referer-shortening capability, so this feature benefits both users and site developers.

This feature adds a way to attenuate the information that's sent as the referrer. This is multiple phases:

Phase 1: Plumbing for global and site-specific control. In the first phase, we will create a global pref so power users and addons can select at most how much of the URL is sent as referrer, globally. Additionally, on a site-by-site basis (probably via permission manager) a referrer policy can be applied to override the global setting.

Phase 2: Site-based control via CSP header and tag attributes. In the second phase, we enable sites to reduce the amount of data transmitted in referrers generated on their site. This is done by the site sending a signal with Content Security Policy response header indicating that outgoing referrers should be reduced. Stripping options should include the same options mentioned in phase 1. Sites will be able to specify a default policy for their pages, but we will also implement some per-link control (One mechanism could be to support the rel="noreferrer" attribute to omit referers from link clicks, or similar).

Phase 3: Site-based control via meta tag. Once the CSP HTTP response header can be used to set a site policy, we will extend CSP to be settable via the meta tag. This way sites can specify a referrer policy without having to send an HTTP header.

Note: Site-based control could be accomplished using the meta referrer tag, but we are opting to implement the same functionality in CSP to combine the security/privacy features. See whatwg wiki and see also bug 704320.

Phase 4: New Firefox defaults. Once sites have better control, we will decide how much to limit referrer sending by default (same-origin and cross-origin). Right now too much information is transmitted in referer headers, and we should reduce that to the extent possible. In this phase, we'll have an open discussion in dev-privacy about what defaults to choose.

Phase 5: Extra bonus phase - UI for users to control how much referrer is sent on a global basis, likely in the privacy settings for Firefox. Additionally, per-site control in the permissions and siteinfo UI. This may not be necessary if Phase 4 is successful and there's not much referrer sending by default.

2. Users & use cases

Nice document from Dan Aurbach: https://bug822869.bugzilla.mozilla.org/attachment.cgi?id=694472

Leaking search terms: From bug 587523#c0: "An example of this can be seen by searching for 'no knead bread' with Google, and clicking on the 4th search result, which takes you to www.breadtopia.com/basic-no-knead-method/, a page which "helpfully" lets you know that it is aware of the search terms that brought you to the site."
Outbound link anonymization: Many sites like gmail send outbound links through a common redirect to strip off any information that may be present in the URL. Supporting rel="noreferrer" reduces the need for extra HTTP traffic and redirects.

3. Dependencies

`

4. Requirements

Test plan must be created and implemented
Use cases must be clearly outlined and it must be clear how the feature addresses each.
Initially, Phase 1 (user-set) should not change default behavior until user initiates change.
Default referer behavior for sites should not change until sites activate attenuation features.

Non-goals

We are not removing the HTTP referer header
We are not replacing the HTTP referer header
This is not the Origin header

Stage 2: Design

5. Functional specification

6. User experience design

`

Stage 3: Planning

7. Implementation plan

Phase 1:

[DONE] global default referrer policy via pref (bug 822869)
[ON TRACK] site-specific setting via permission (bug 966505)

Phase 2:

[DONE] CSP referrer directive support (bug 965727)
[DONE] noreferrer attribute for anchor tags (bug 530396)
[NEW] referrer (policy) attribute for anchor tags

Phase 3:

[DONE] meta tag support for CSP (bug 663570)

Phase 4:

[NEW] discussion in dev-privacy about measuring success of new referrer defaults
[NEW] discussion in dev-privacy to choose new policy (and measurement of its effects)
[NEW] change global default policy for referrer bug 122453

Phase 5:

[NEW] decide if this phase should be dropped or completed
[NEW] about:permissions and siteInfo UI for per-site referrer settings
[NEW] privacy settings pane UI for global referrer settings

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

See above in Planning section for progress. Just some links here.

Facebook write-up on "HTTP-Referer" woes
the rel="noreferrer" attribute
bug 587523: strip referrer in a future anonymous mode

Stage 5: Release

10. Landing criteria

Has tests
Tests pass on B2G, Android and Desktop

Feature details

Priority	P1
Rank	4
Theme / Goal	Tracking Control
Roadmap	Privacy
Secondary roadmap	`
Feature list	Platform
Project	`
Engineering team	Networking

Team status notes

	status	notes
Products	`	`
Engineering	`	`
Security	`	`
Privacy	`	`
Localization	`	`
Accessibility	`	`
Quality assurance	`	`
User experience	`	`
Product marketing	`	`
Operations	`	`