Bug 35745 – Add hook for always disabling the HTTP Referrer.

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: New Bugs

Add hook for always disabling the HTTP Referrer.

Created attachment 50017 [details]
Patch

This hook allows Chromium to disable referrers in webkit. It's not enough to do this on the network layer, since referrer information is accessible from javascript using document.referer

[Jeremy Orlow]

+ Darin for opinion.

[Jeremy Orlow]

Comment on attachment 50017 [details]
Patch

I'm not sure what te best way to do this is, but this is definitely not it.  My guess is that the chromeClient should be used to query this type of information...and it should probably be done somewhere else (or injected into SecurityOrigin on creation).

(In reply to comment #4)
> (From update of attachment 50017 [details])
> I'm not sure what te best way to do this is, but this is definitely not it.  My
> guess is that the chromeClient should be used to query this type of
> information...and it should probably be done somewhere else (or injected into
> SecurityOrigin on creation).

The problem is that this method of SecurityOrigin is static.

[Jeremy Orlow]

(In reply to comment #5)
> (In reply to comment #4)
> > (From update of attachment 50017 [details] [details])
> > I'm not sure what te best way to do this is, but this is definitely not it.  My
> > guess is that the chromeClient should be used to query this type of
> > information...and it should probably be done somewhere else (or injected into
> > SecurityOrigin on creation).
> 
> The problem is that this method of SecurityOrigin is static.

What about the callers of it?

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (From update of attachment 50017 [details] [details] [details])
> > > I'm not sure what te best way to do this is, but this is definitely not it.  My
> > > guess is that the chromeClient should be used to query this type of
> > > information...and it should probably be done somewhere else (or injected into
> > > SecurityOrigin on creation).
> > 
> > The problem is that this method of SecurityOrigin is static.
> 
> What about the callers of it?

The function is invoked several times in FrameLoader, and once in SubresourceLoader, and two Mac plugins plus WebSecurityPolicy and WebFrameImpl in chromium.

I'm no expert on this, but SecurityOrigin seemed to be the central place to control this

[Jeremy Orlow]

Lets see what Darin thinks then.  He usually knows of creative ways to add Chromium bits in clean ways.

[Darin Fisher (:fishd, Google)]

Yeah, hacking out a method from SecurityOrigin.cpp using #if !PLATFORM(CHROMIUM), and then implementing it in ChromiumBridge.cpp is not going to make this very maintainable.  Do you really need the ability to restrict referrers on a host-by-host basis?

If the goal is to just always disable HTTP referrers, then we can probably just add a method on SecurityOrigin to denote that setting.  I'd like abarth's input.

[Sam Weinig]

Please note it is also a layering violation for WebCore classes to know about WebKit level concepts.

(In reply to comment #9)
> Yeah, hacking out a method from SecurityOrigin.cpp using #if
> !PLATFORM(CHROMIUM), and then implementing it in ChromiumBridge.cpp is not
> going to make this very maintainable.  Do you really need the ability to
> restrict referrers on a host-by-host basis?
> 
> If the goal is to just always disable HTTP referrers, then we can probably just
> add a method on SecurityOrigin to denote that setting.  I'd like abarth's
> input.

The goal is to disable referrers in all cases. This option has to be a static member variable thou, because the method is also static.

Any hints on how to expose access to this variable?

[Adam Barth]

I don't understand the motivation for this change.  Can you explain the use case?

I'm not sure why we'd want to control referrers on a global level.  It would seem to make much more sense to control this on a load-by-load basis, which we can achieve with a FrameLoaderClient method.

[Adam Barth]

Come to think of it, isn't willSendRequest sufficient for this purpose?  If it's not, we should make it work.

[Darin Fisher (:fishd, Google)]

abarth: good catch, willSendRequest should definitely be sufficient for stripping referrers.  the Referer header is set before willSendRequest is called!

I think this bug is WORKSFORME.

[Darin Fisher (:fishd, Google)]

jochen: be sure to test that both the HTTP level Referer header and document.referrer are cleared.

(In reply to comment #15)
> jochen: be sure to test that both the HTTP level Referer header and
> document.referrer are cleared.


works, thanks for the help!