Firefox not including cookies for same-domain requests from addons with third party cookies disabled
Categories
(Core :: Networking: Cookies, defect)
Tracking
()
People
(Reporter: BlueRaja.admin, Unassigned, NeedInfo)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
Simple repro with an existing popular addon:
- Disable "third party cookies" in Firefox (tools --> options --> Privacy and Security --> Cookies --> All Third Party Cookies)
- Install the "Augmented Steam" addon for Firefox from https://es.isthereanydeal.com/
- Visit any Steam game store page (ex. https://store.steampowered.com/app/210970/The_Witness/ )
- Add the game to your Steam wishlist
- Click the "wishlist" button again
Actual results:
Game is removed from your wishlist
Expected results:
Game is not removed from wishlist. Firefox does not include any cookies in the XHR to https://store.steampowered.com/api/removefromwishlist, even though it's on the same domain as the page the request originated from.
Note that the addon (with the exact same code) works just fine in Chrome with third party cookies disabled.
|
Reporter | |
Comment 1•6 years ago
|
||
(Er, sorry I swapped "actual" and "expected" results)
|
||
Comment 2•6 years ago
|
||
(In reply to BlueRaja.admin from comment #1)
(Er, sorry I swapped "actual" and "expected" results)
I also think you missed one step and maybe the title is a bit misleading:
4'. Click Empty wish list (which should empty the wishlist)
Case A: Cookies set to "All third-party cookies" blocked
the wishlist will not be cleared.
Case B: Cookies set to "Cross-site and social media trackers" blocked
the wishlist will be cleared.
Using comment 0 testcase with the above extra step and results, this report reproduces on:
Windows 10 Pro x64 using:
Fx 71.0a1 2019-09-09
Fx 70.0b4 2019-09-05
Fx 69.0 2019-08-27
I'm not certain what is going on here, but I guess that people from the tracking protection will have a better opinion on the validity of this bug, so let's confirm it and triage it there.
|
|
Reporter | |
Comment 3•6 years ago
|
||
No, it's not missing a step, and the title is correct.
If you click on the "wishlist" button for a game on your wishlist WITHOUT THAT ADDON INSTALLED, it brings you to your wishlist.
However, after installing that addon, clicking that button keeps you on the same page and removes the game from your wishlist. It does this by making an XHR call to https://store.steampowered.com/api/removefromwishlist. If you have "third party cookies" disabled, that call fails because the request has no cookies header, even though the request is to the same domain as the page.
|
||
Comment 4•6 years ago
|
||
Phew, this could fit in a few categories (WebExtensions, Core:Privacy or Necko). I'll put it in Necko for now and CC a few folks who might want to look at it.
Honza or Luca, do you know what's going on here?
|
||
Comment 5•6 years ago
|
||
I took a quick look and double-checked if it was something related to the behaviors we have deprecated in Bug 1525917, especially given that in Bug 1537753 we recently removed the preference that temporarily allowed to bring back the behaviors we have deprecated in Bug 1525917, but it doesn't seem to be related to it (I tested it on 69.0, with and without the "extensions.cookiesBehavior.overrideOnTopLevel" pref set to true).
By running the STR from comment 0 with the verbose AntiTracking logs enabled (MOZ_LOG="AntiTracking:5:sync" ...), the following messages are logged when the request to "https://store.steampowered.com/api/removefromwishlist" has been triggered:
[Parent 16950: Main Thread]: D/AntiTracking Computing whether channel 0x7f195d958040 has access to URI https://store.steampowered.com/api/removefromwishlist
[Parent 16950: Main Thread]: D/AntiTracking Our loadInfo lacks a top-level principal, use the loadInfo's loading principal instead
[Parent 16950: Main Thread]: D/AntiTracking Nothing more to do due to the behavior code 1
And so in bool AntiTrackingCommon::IsFirstPartyStorageAccessGrantedFor it seems that:
-
AntiTracking is unable to retrieve the top level principal for a content script request and it is falling back to use the loading principal (which should be the ExpandedPrincipal used by the content script sandbox)
-
CookiesBehavior(loadInfo, channelURI); is returning nsICookieService::BEHAVIOR_REJECT_FOREIGN
-
the request is detected by
thirdPartyUtil->IsThirdPartyChannel(aChannel, aURI, &thirdParty);as third party and the method will return false becausebehaviorisnsICookieService::BEHAVIOR_REJECT_FOREIGN
By inspecting the request content in the network panel, I noticed that the request status is 200 and its result is {"success": false}, but the extension doesn't seem to be checking the result of the request and so it doesn't notice that the request failed.
I have briefly digged into the extension sources (https://github.com/tfedor/AugmentedSteam) and the request to https://store.steampowered.com/api/removefromwishlist is being originated by the content script using RequestData.post, which is internally calling fetch .
The content scripts have access to a fetch method coming from the sandbox and a copy of the fetch method coming from the window (accessible using content.fetch instead of just fetch), and when content.fetch is used the cookies are being sent even when the cookieBehavior is BEHAVIOR_REJECT_FOREIGN (See https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts#XHR_and_Fetch for more details about fetch vs content.fetch in content scripts).
|
||
Comment 6•5 years ago
|
||
Christoph, I think I remember seeing a related patch recently, about whether addon-inserted content scripts are third party or not? But I can't find the bug right now. Maybe it even fixed this problem. Do you happen to know the bug?
|
||
Comment 7•5 years ago
|
||
(In reply to Valentin Gosu [:valentin] (he/him) from comment #6)
Christoph, I think I remember seeing a related patch recently, about whether addon-inserted content scripts are third party or not? But I can't find the bug right now. Maybe it even fixed this problem. Do you happen to know the bug?
I suppose you meant this one Bug 1629436?
|
|
||
Comment 8•5 years ago
|
||
I think so.
@reporter: could you check with the latest nightly if the problem is fixed?
|
||
Comment 9•5 years ago
|
||
Closing for lack of information.
Description
•