Tracking cookie restrictions breaks Facebook comment plugin
Categories
(Firefox :: Protections UI, defect, P3)
Tracking
()
People
(Reporter: timhuang, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
533 bytes,
text/plain
|
Details |
Preference: - set 'network.cookie.cookieBehavior' to 4 STR: 1. Visit www.imdb.com and navigate to any news, like this one https://imdb.to/2Bx4oTg 2. Scroll down to the Facebook comment and leave some comments. 3. Press 'Log In to post' then log in to the Facebook account with the pop-up window. Expected result: - The comment is added. Actual result: - Nothing happens to the Facebook comment. - If you send the comment again, it will pop-up a window and disappear immediately. Still, nothing happens to the Facebook comment. Affected version: 63.0a1 (2018-08-21) (64-bit) (build id: 20180821100053)
Updated•6 years ago
|
Comment 1•6 years ago
|
||
Here the facebook comment iframe has a URL like https://www.facebook.com/plugins/feedback.php?api_key&channel_url=https%3A%2F%2Fstaticxx.facebook.com%2Fconnect%2Fxd_arbiter%2Fr%2FQX17B8fU-Vm.js%3Fversion%3D42%23cb%3Df1625dfaa14757e%26domain%3Dm.med... and it is embedded in yet another iframe with a URL like https://m.media-amazon.com/images/G/01/imdb/html/facebook-comments-1539331670._CB470047335_.html#commentUrl=https%3A%2F%2Fwww.imdb.com%2Fnews%2Fni62178992%2F&commentPostLimit=10&sourceOrigin=https%3A%, so there is 3 levels of embedding, rather than two. This causes our heuristics to break. More specifically, we bail out early from here <https://searchfox.org/mozilla-central/rev/3fa761ade83ed0b8ab463acb057c2cf0b104689e/toolkit/components/antitracking/AntiTrackingCommon.cpp#43> (coming from a call from <https://searchfox.org/mozilla-central/rev/3fa761ade83ed0b8ab463acb057c2cf0b104689e/toolkit/components/antitracking/AntiTrackingCommon.cpp#146>) because of this check: <https://searchfox.org/mozilla-central/rev/3fa761ade83ed0b8ab463acb057c2cf0b104689e/dom/base/nsGlobalWindowInner.cpp#6274>
Comment 2•6 years ago
|
||
This patch fixes the bug. But I'd like to wait for baku to come back to discuss the strategy for addressing this...
Comment 3•6 years ago
|
||
Comment on attachment 9003266 [details] Example fix >diff --git a/dom/base/nsGlobalWindowInner.cpp b/dom/base/nsGlobalWindowInner.cpp >index 5bc2020b423af..3cea1433def06 100644 >--- a/dom/base/nsGlobalWindowInner.cpp >+++ b/dom/base/nsGlobalWindowInner.cpp >@@ -6265,7 +6265,7 @@ nsGlobalWindowInner::GetTopLevelPrincipal() > nsIPrincipal* > nsGlobalWindowInner::GetTopLevelStorageAreaPrincipal() > { >- nsPIDOMWindowOuter* outerWindow = GetParentInternal(); >+ nsPIDOMWindowOuter* outerWindow = GetTopInternal(); > if (!outerWindow) { > // No outer window available! > return nullptr;
Updated•6 years ago
|
Comment 4•6 years ago
|
||
I kinda forgot about this bug. :-(
Comment 5•6 years ago
|
||
Well, this is an important changes! This means that we don't care about the parent context, but the top one. This is different than what Safari does: my initial approach was doing what you are proposing here, but then you suggest to use just the parent context. If we want to go for this, Rename GetParentPrincipalAndTrackingOrigin to GetTopPrincipalAndTrackingOrigin But more important question: here a scenario: site.com loads trackerA in an iframe. trackerA loads trackerB in a sub-iframe. trackerB does a window.open(trackerB/popup). Which permission key should we use? site.com-trackerB or site.com-trackerA-trackerB? I'm not sure we can ignore that trackerA was involved here.
Comment 6•6 years ago
|
||
You're right. I agree this is an important change, and I'm not sure if there is a good justification for it yet. Thinking more about this, I think it would only make sense to do this if this breakage were more common. FB comments being embedded through m.media-amazon.com is probably a *very* special case for IMDB given that it is an Amazon website, unlike most other embedders of FB comments. So perhaps the way forward here would be to ask Facebook to use the Storage Access API here unless we hear about this similar issue on other web properties? I should also test how Safari deals with this... Maintaining my needinfo for that purpose.
Updated•6 years ago
|
Comment 7•6 years ago
|
||
This is broken in Safari 12 as well. I recommend WONTFIX here.
Comment 8•5 years ago
|
||
(In reply to :Ehsan Akhgari from comment #7)
This is broken in Safari 12 as well. I recommend WONTFIX here.
Ehsan, the Facebook comments on Politico.com [1] load correctly in Safari 12.1 and Safari Technology Preview 12.2, but do not load in Firefox with Standard or Strict Tracking Protection. Does this change in Safari's behavior change your recommendation about WONTFIX'ing this bug?
[1] e.g. https://www.politico.com/magazine/story/2019/04/08/alexandria-ocasio-cortez-new-york-226578
Comment 9•5 years ago
|
||
(In reply to Chris Peterson [:cpeterson] from comment #8)
(In reply to :Ehsan Akhgari from comment #7)
This is broken in Safari 12 as well. I recommend WONTFIX here.
Ehsan, the Facebook comments on Politico.com [1] load correctly in Safari 12.1 and Safari Technology Preview 12.2, but do not load in Firefox with Standard or Strict Tracking Protection. Does this change in Safari's behavior change your recommendation about WONTFIX'ing this bug?
[1] e.g. https://www.politico.com/magazine/story/2019/04/08/alexandria-ocasio-cortez-new-york-226578
I just tested this site and with a cursory test I couldn't see any problems, FB comments seemed to work just fine on this site for me on Nightly. If you see a bug please file it with steps to reproduce and needinfo me.
This specific bug wasn't "we don't care to make FB comments work at all", it was more "we don't care to make the specific way that IMDB (an Amazon subsidiary) has chosen to embed FB comments using the Amazon helper to work" (see comment 1). I think maybe it gave you the wrong impression?
Description
•