canmove, Confirmed users
1,537
edits
Privacy/2010-10-27 Shorten-Referer Meeting Notes: Difference between revisions
Privacy/2010-10-27 Shorten-Referer Meeting Notes (view source)
Revision as of 16:12, 31 May 2011
, 31 May 2011no edit summary
(Created page with "Meeting notes from 2010-10-27 Attendees: Adam Barth, Google Nate Chapin, Google Dirk Pranke, Google David Recordon, Facebook Scott Renfro, Facebook Jona...") |
No edit summary |
||
| Line 1: | Line 1: | ||
Meeting notes from 2010-10-27 | Meeting notes from 2010-10-27 | ||
Attendees: | |||
* Adam Barth, Google | |||
* Nate Chapin, Google | |||
* Dirk Pranke, Google | |||
* David Recordon, Facebook | |||
* Scott Renfro, Facebook | |||
* Jonas Sicking, Mozilla | |||
* Sid Stamm, Mozilla | |||
* Paul Tarjan, Facebook | |||
Absent: | |||
* Mike Beltzner, Mozilla | |||
* Darin Fisher, Google | |||
= Subject = | = Subject = | ||
| Line 25: | Line 25: | ||
URLs escaping to third parties accidentally through the Referer Header. | URLs escaping to third parties accidentally through the Referer Header. | ||
While there are a number of ways to protect the Referer today [ | While there are a number of ways to protect the Referer today ([http://www.facebook.com/note.php?note_id=392382738919 Existing alternatives for cloaking the referer]), they are | ||
all awkward and have various interoperability problems. FB has drafted a | all awkward and have various interoperability problems. FB has drafted a | ||
proposal for a "Shorten-Referer" header | proposal for a "Shorten-Referer" header to be added to the HTTP response | ||
that would tell user agents to send only a subset (or none) of the | that would tell user agents to send only a subset (or none) of the | ||
Referer header on subsequent requests from the page (or contained | Referer header on subsequent requests from the page (or contained | ||
| Line 113: | Line 113: | ||
= Mozilla's Content Security Policy proposal = | = Mozilla's Content Security Policy proposal = | ||
We discussed Mozilla's Content Security Policy proposal | We discussed Mozilla's [[Security/CSP|Content Security Policy]] proposal and how | ||
these requirements might fit in. We observed that (a) so far it was a | these requirements might fit in. We observed that (a) so far it was a | ||
very experimental API, although a good idea, (b) it was slowly heading | very experimental API, although a good idea, (b) it was slowly heading | ||
| Line 170: | Line 170: | ||
Potential advantages: | Potential advantages: | ||
# clean general solution to the problem of sensitive data in URLs - this makes the "web key" design technique of URLs as bearer tokens or capabilities potentially more compelling since the full token is not leaked nearly as easily (see Waterken's use of URI fragments for a similar approach) | # clean general solution to the problem of sensitive data in URLs - this makes the "web key" design technique of URLs as bearer tokens or capabilities potentially more compelling since the full token is not leaked nearly as easily (see [http://waterken.sourceforge.net/web-key/Waterken's use of URI fragments] for a similar approach). | ||
# should be relatively easy to implement on the server side | # should be relatively easy to implement on the server side | ||
# easy for authors to understand | # easy for authors to understand | ||
| Line 222: | Line 222: | ||
All of us to continue thinking about the pros and cons of the various | All of us to continue thinking about the pros and cons of the various | ||
approaches. | approaches. | ||