76326 - Restrict which pages can see HTTP referrer

Status: RESOLVED WORKSFORME

(Core :: Security: CAPS, enhancement, P1)

Description

[Markus Hübner]

http pages shouldn't be able to see file:/// referers, but file:/// pages 
should be able to see file or http referers

Comment 1

[Doron Rosenberg (IBM)]

is there some sort of spec? belongs into dom 0 probably.

Comment 2

[timeless]

interesting, but i'm not sure the spec agrees.

how about CAPS settings which would allow the user to specify which transitions 
pass refererr and which do not

Comment 3

[Andreas M. "Clarence" Schneider]

RFC 2616, section 15.1.3:

  Clients SHOULD NOT include a Referer header field in a (non-secure)
  HTTP request if the referring page was transferred with a secure
  protocol.

I consider file:/// a secure protocol.

However, I cannot confirm this bug with 2001-04-15-20, Win NT. To test you can
make up a local document linking to http://clarence.de/utilities/http.cgi
(sorry, language is german, but you'll understand it).

Meta bug for HTTP Referer is bug 61660.

Comment 4

[Mitchell Stoltz (not reading bugmail)]

Interesting idea, I'll look into it. Yes, we could allow the security/privacy
policy to control who can see the referrer field.

Comment 5

[Andreas M. "Clarence" Schneider]

For the second part of this bug:
- Pages retrieved via HTTP cannot access file: URLs. See bug 40538.
- There is no referrer for the file: protocol. We could emulate it for JS/DOM
  (4.x does so), but that would be a bug on its own (low priority, IMHO).

Comment 6

[Mitchell Stoltz (not reading bugmail)]

Target is now 0.9.5, Priority P1.

Comment 7

[Mitchell Stoltz (not reading bugmail)]

time marches on...retargeting to 0.9.6

Comment 8

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 9

[Hakon]

I believe there's also a thing named "e-mail (from:)" which could supply your 
POP3 e-mail program's information to the site. Dunno if it's e-mail address, 
sender nick or which information. Anyway, as I see it, a restricting function 
for this would be even more urgent.

Comment 10

[Markus Hübner]

This bug has been around for quite a long time now - any chance to get this in 
soon?

Comment 11

[Markus Hübner]

Really think this one would need some attention now after such a long time
passing by.

Comment 12

[Daniel Veditz [:dveditz]]

WFM, http: pages do not see file:/// referrers. This got fixed somewhere along the way in another bug.