-
Notifications
You must be signed in to change notification settings - Fork 970
mitigate HSTS fingerprinting #12223
Comments
adding to 0.20.x, per @BrendanEich suggestion currently the proposal seems to boil down to: don't apply HSTS on 3rd party subresource loads, unless that subresource has been visited as a first party (similar to Safari's 3rd party cookie policy) |
Moving to 0.21.x for now- let's move it back if this is finished before Jan 8th and doesn't require a Muon change 😄 |
@diracdeltas is this release blocking? |
it would be really good if this were included in 0.21.x since people have been asking for it for a while. cc @jumde |
Depends on brave/muon#527 @diracdeltas please note that the milestone was adjusted during today's triage meeting; once the work is complete, we can find the right place for it 😄 |
it now depends on brave/muon#532 which is a simpler change. moving to 0.22.x for now |
Re-opening after reverting browser-laptop code with #13638 |
Verified Win7 x64 v0.22.108 Steps used to verify:
Expected result: Steps used to verify:
Expected result: Verified on macOS 10.12.6 x64 using the steps above and the following build:
Verified on Ubuntu 17.10 x64
|
Test plan
See #13437
Original issue description
context: it has been reported in various places that Criteo is using HSTS supercookies (where they buy a bunch of domains and set HSTS on a different subset of domains for each user in order to uniquely identify them) for ad tracking. https://www.gothamcityresearch.com/single-post/2017/10/12/Criteo-SA-NASDAQ-CRTO-Why-We-Believe-Criteo%E2%80%99s-Undisclosed-Practices-are-Illegal-and-Harmful-to-Advertisers
possibilities:
The text was updated successfully, but these errors were encountered: