Privacy/Features/Shortened HTTP Referer header

From MozillaWiki
< Privacy‎ | Features
Revision as of 21:32, 9 July 2012 by Sidstamm (talk | contribs)
Jump to navigation Jump to search
Please use "Edit with form" above to edit this page.

Status

Shortened HTTP Referer header
Stage Definition
Status `
Release target `
Health At risk
Status note stalled - lack of resources

{{#set:Feature name=Shortened HTTP Referer header

|Feature stage=Definition |Feature status=` |Feature version=` |Feature health=At risk |Feature status note=stalled - lack of resources }}

Team

Product manager Sid Stamm
Directly Responsible Individual Sid Stamm
Lead engineer `
Security lead Curtis Koenig
Privacy lead Sid Stamm
Localization lead `
Accessibility lead `
QA lead Virgil Dicu
UX lead `
Product marketing lead `
Operations lead `
Additional members `

{{#set:Feature product manager=Sid Stamm

|Feature feature manager=Sid Stamm |Feature lead engineer=` |Feature security lead=Curtis Koenig |Feature privacy lead=Sid Stamm |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=Virgil Dicu |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}

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: User global control. In the first phase, we should create a pref so users can select at most how much of the URL is sent as referrer. They will be able to chose a full referrer value, a referrer that is {scheme, host, port, path}, {scheme, host, port}, or just host.

Phase 2: Site-based control. 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 the HTTP response indicating that outgoing referrers should be reduced. Stripping options should include the same options mentioned in phase 1. One mechanism could be to support the rel="noreferrer" attribute to omit referers from link clicks.

Site-based control also might be accomplished using the meta referrer tag. See whatwg wiki and see also bug 704320.


Next steps

  • [NEW] (Product Manager) Socialize pref idea via mailing list, brown bag, or some public discussion.
  • [NEW] (Feature Team) Nail down user-initiated shortening requirements
  • [NEW] (Feature Team) Nail down server-initiated shortening requirements
  • [NEW] (Engineer?) Make test plan
  • [NEW] (Engineer) Write patch for phase 1 and land
  • [NEW] (Engineer) Write patch for phase 2 and land

See also: bug 587523

2. Users & use cases

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

See also the noreferrer link type

6. User experience design

`

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=* Site breakage (tolerable? need to quantify this)

  • User confusion (make it hidden pref?)

|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: User global control. In the first phase, we should create a pref so users can select at most how much of the URL is sent as referrer. They will be able to chose a full referrer value, a referrer that is {scheme, host, port, path}, {scheme, host, port}, or just host.

Phase 2: Site-based control. 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 the HTTP response indicating that outgoing referrers should be reduced. Stripping options should include the same options mentioned in phase 1. One mechanism could be to support the rel="noreferrer" attribute to omit referers from link clicks.

Site-based control also might be accomplished using the meta referrer tag. See whatwg wiki and see also bug 704320.


Next steps

  • [NEW] (Product Manager) Socialize pref idea via mailing list, brown bag, or some public discussion.
  • [NEW] (Feature Team) Nail down user-initiated shortening requirements
  • [NEW] (Feature Team) Nail down server-initiated shortening requirements
  • [NEW] (Engineer?) Make test plan
  • [NEW] (Engineer) Write patch for phase 1 and land
  • [NEW] (Engineer) Write patch for phase 2 and land

See also: bug 587523 |Feature users and use cases=; 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.

|Feature dependencies=` |Feature 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.

|Feature non-goals=* We are not removing the HTTP referer header

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

|Feature functional spec=See also the noreferrer link type |Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=* Facebook write-up on "HTTP-Referer" woes

|Feature landing criteria=` }}

Feature details

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

{{#set:Feature priority=P2

|Feature rank=4 |Feature theme=Tracking Control |Feature roadmap=Privacy |Feature secondary roadmap=` |Feature list=Platform |Feature project=` |Feature engineering team=Networking }}

Team status notes

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

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}


Retrieved from "https://wiki.mozilla.org/index.php?title=Privacy/Features/Shortened_HTTP_Referer_header&oldid=448839"