[tahoe-lafs-trac-stream] [tahoe-lafs] #1890: submit proposal for restrict-referrer-leakage to the CSP standardizers and implementors (was: submit proposal for restrict-referer-leakage to the CSP standardizers and implementors)

[tahoe-lafs]

#1890: submit proposal for restrict-referrer-leakage to the CSP standardizers and
implementors
-------------------------+--------------------------------
     Reporter:  zooko    |      Owner:  davidsarah
         Type:  task     |     Status:  assigned
     Priority:  normal   |  Milestone:  soon (release n/a)
    Component:  unknown  |    Version:  1.9.2
   Resolution:           |   Keywords:  referer referrer
Launchpad Bug:           |
-------------------------+--------------------------------
Changes (by davidsarah):

 * keywords:  referer => referer referrer
 * status:  new => assigned
 * milestone:  undecided => soon (release n/a)


Old description:

> In comment:31:ticket:127 and later comments on #127, David-Sarah has
> written a proposal for a CSP directive to restrict referer (sic) leakage.
> This would be a great fix for issue #127 if it were widely supported.
> Let's urge browser makers and standards bodies to support it!

New description:

 In comment:31:ticket:127 and later comments on #127, David-Sarah has
 written a proposal for a CSP directive to restrict Referer (sic) header
 leakage. This would be a great fix for issue #127 if it were widely
 supported. Let's urge browser makers and standards bodies to support it!

--

Comment:

 Replying to [comment:1 zooko]:
 > I recently learned from Brad Hill that it is possible for end-users
 using Firefox to impose CSP policies:
 >
 > https://blog.mozilla.org/tanvi/2012/09/18/user-specified-content-
 security-policy/

 There is incidentally already a Firefox pref that allows to never send the
 Referer header: [http://kb.mozillazine.org/Network.http.sendRefererHeader
 network.http.sendRefererHeader = 0]. Although the ability for end-users to
 specify CSP policy is interesting for us browser security geeks, it's no
 easier for security and privacy-conscious Firefox users than setting that
 pref. The advantage of a CSP policy is that:

 a) It just works (on new enough browsers) for sites that need it, without
 the user having to do anything.

 b) It won't be specific to Firefox or any other single browser.

 c) The Referer header is only one of several misfeatures that leak the
 referring site (and potentially the exact URL, when the site is displaying
 untrusted content). My proposal fixes all of the leaks I know of that are
 standard parts of HTML5, and states that implementors should apply
 equivalent policies to any non-standard features (so that other referrer
 leaks contrary to the policy can be treated as security bugs).

 d) It cannot break sites that hypothetically depend on Referer for intra-
 site links. I think that such sites are almost entirely fictional (and any
 few that exist deserve to be broken), but browser implementors are
 invested in such fictions and are therefore are unlikely to make not
 sending Referer the default, whereas the CSP approach is more politically
 acceptable.

 Part of me rails against writing a spec designed for political
 acceptability when I know the right thing to do instead (never send
 Referer, and plug the other cross-origin referrer leaks), but if it helps
 to stop users getting shafted by this long-standing privacy and security
 bug, I suppose it's worth it. The [https://tahoe-lafs.org/trac/tahoe-
 lafs/attachment/ticket/127/restrict-referrer-leakage.txt draft spec] at
 least says that it only specifies an upper bound on when you can leak
 referrers, i.e. it's always conformant to leak in fewer cases.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1890#comment:2>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage