Ensure that the referrerPolicy API can be used to override the default referrer policy that we apply to third-party tracking resources
Categories
(Core :: Privacy: Anti-Tracking, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox68 | --- | fixed |
People
(Reporter: ehsan.akhgari, Assigned: ehsan.akhgari)
References
Details
Attachments
(3 files)
The feature that I implemented in bug 1530076 was supposed to be a default referrer policy which could be overridden when the page specifies an explicit referrer policy. I got a little bit lazy and just assumed that I'm awesome and got everything correct and didn't write a test for ensuring that the page can indeed override the default... and guess what? the overriding part is broken.
The conclusion is that sometimes I have bugs in my code. That is highly surprising. ;-)
Here is why this happens. When we receive a referrer policy from JS/DOM here https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/netwerk/protocol/http/HttpBaseChannel.cpp#1661 mReferrerPolicy
will be a value other than REFERRER_POLICY_UNSET
and we'll skip using the default. But then we'll get to https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/netwerk/protocol/http/nsHttpChannel.cpp#10222 and here we've forgotten the original referrer policy that we had received from JS/DOM. We check the referrer policy that we have against the default and if it's not the default we call SetReferrer()
which brings us back to https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/netwerk/protocol/http/HttpBaseChannel.cpp# but this time mReferrerPolicy
will be our default policy value (because https://searchfox.org/mozilla-central/rev/6dab6dad9cc852011a14275a8b2c2c03ed7600a7/netwerk/protocol/http/HttpBaseChannel.cpp#1603) and that's how we overwrite the JS/DOM provided policy value with the default policy value.
The solution is straightforward: similar to mOriginalReferrer
also remember mOriginalReferrerPolicy
being the original referrer policy that we received from JS/DOM, and inside ReEvaluateReferrerAfterTrackingStatusIsKnown()
only set the referrer if the original policy value we had received was REFERRER_POLICY_UNSET
.
Assignee | ||
Comment 1•6 years ago
|
||
Assignee | ||
Comment 2•6 years ago
|
||
Assignee | ||
Comment 3•6 years ago
|
||
Comment 5•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/2fcb6eeb5afd
https://hg.mozilla.org/mozilla-central/rev/272dbcb4bc39
https://hg.mozilla.org/mozilla-central/rev/66ca3efa1ac2
Comment 6•6 years ago
|
||
Part 2: Remove the script test from browser_referrerDefaultPolicy.js since the <script> element doesn't provide support for the referrerPolicy API; r=baku
Hi Ehsan, could you please give me more details about the failure? I think we had referrerpolicy attribute supported in script element.
Assignee | ||
Comment 7•6 years ago
|
||
(In reply to Thomas Nguyen from comment #6)
Part 2: Remove the script test from browser_referrerDefaultPolicy.js since the <script> element doesn't provide support for the referrerPolicy API; r=baku
Hi Ehsan, could you please give me more details about the failure? I think we had referrerpolicy attribute supported in script element.
Oh, is that right? I based that decision on https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy#Integration_with_HTML. Was I being mislead by our documentation?
Comment 8•6 years ago
|
||
Currently, this page is synced with:
https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-delivery-referrer-attribute
But I think it should be updated:
https://html.spec.whatwg.org/multipage/scripting.html#the-script-element
https://github.com/w3c/webappsec-referrer-policy/issues/96
Comment 9•6 years ago
|
||
And our implementation:
https://bugzilla.mozilla.org/show_bug.cgi?id=1460920
Assignee | ||
Comment 10•6 years ago
|
||
Thank you, sorry, I should have checked what we actually support...
Description
•