Clear Cookies and Site Data does not clear third party cookies
Categories
(Toolkit :: Data Sanitization, defect, P3)
Tracking
()
People
(Reporter: zombie, Unassigned)
References
(Blocks 1 open bug)
Details
STR:
-
Clean profile and move to EU or use a VPN :)
-
Load http://pcworld.com, see GDPR consent dialog appear
-
Either click [Accept] or click [Settings] and then [Save & Exit]
-
[Clear Cookies and Site Data] from the Site Information panel (url bar lock icon)
-
Reload page, see GDPR dialog not appear
-
Menu > Library > History > Clear Recent History
-
select Last Hour and only the Cookies checkbox, then [Clear Now]
-
Reload page, see GDPR dialog appear again
Expected:
Both methods of clearing cookies should produce the same result.
|
||
Comment 1•5 years ago
|
||
Yeah, this is a known issue (we're only clearing the cookies of the first party and parent/sub-domains, not any third party embedded on the site). In this specific case pcworld.com is using https://consent.sourcepoint.com/ for their consent dialog (not sure how that works legally, since you're giving consent to a different domain, but whatever).
Since we have the content blocking log, it's actually possible to know which third parties have actively set cookies while loaded on the page, so there's no technical limitation here, but an unsolved UX issue. Many of the third parties on a site are popular domains such as facebook.com or google.com that a user might actually be logged in to. While some of them are now being blocked as part of ETP, I don't think we should assume that's generally the case. So, if we would delete data for these domains by default, users would be automatically signed out of Google, Facebook, Twitter etc. (which in some cases even means data loss).
A mitigation would be designing a new dialog for deletion that allows to optionally also delete third parties and makes it clear that this will also delete their data.
A solution for all this would be first-party isolation everywhere :)
We've already talked about how to solve this issue before, but I don't think there's a bug for it, so I'm using this one.
|
|
||
Comment 2•5 years ago
•
|
||
Ah, I forgot to say, as a third option, this is also massively helped by the recent SameSite=Lax default proposal from the Chrome team that I believe we're also prototyping. i.e. we delete all cookies from active third parties on the site that are marked as SameSite=None.
|
Reporter | |
Comment 3•5 years ago
|
||
Thanks for the quick investigation, I expected something like this, but lack familiarity to be able to easily identify what's going on.
Many of the third parties on a site are popular domains such as facebook.com or google.com that a user might actually be logged in to. While some of them are now being blocked as part of ETP, I don't think we should assume that's generally the case. So, if we would delete data for these domains by default, users would be automatically signed out of Google, Facebook, Twitter etc. (which in some cases even means data loss).
I wonder why we can't distinguish between those two obviously different use cases: sites that user visited before, vs domains which never ran in a top context (as a first party), and which were only ever loaded from the site being cleared.
(Not implying any of this is easy)
|
|
Reporter | |
Comment 4•5 years ago
|
||
Hey Johann, on a related issue, could you please describe in short how you were able to determine what's happening in this case? If this is something doable from within Firefox UI, just a sentence or two in the original github issue would be very appreciated!
Or alternatively if this involved some poking at the browser console, I could use a pointer to any related code on searchfox.
(GCM is a mozilla project where we regularly run into issues like this, and would love to be able to investigate on our own in the future :)
|
|
||
Comment 5•5 years ago
|
||
Hey, I guess we've chatted about GCM so I'll leave this mostly unanswered here, I'm mostly using devtools and Firefox internals like the content blocking log to figure this out.
This functionality will be enabled by dFPI and there's a separate bug for that, so I'm duping forward.
Description
•