1363952 - The counter isn't updated after tapping the Like button in "ltn.com.tw" website

Status: NEW

(Core :: DOM: Security, defect, P3)

Description

[Cynthia Tang [:cynthiatang]]

Preference
 － Create the perf "privacy.firstparty.isolate" and disable it 
 － Disable the perf "network.predictor.enabled"
 － Disable the perf "network.predictor.enable-prefetch" 
 － Disable the perf "browser.safebrowsing.malware.enabled"
 － Disable the perf "browser.safebrowsing.phishing.enabled" 
 － Create the perf "privacy.firstparty.isolate.restrict_opener_access" and disable it 

Steps to reproduce
 1. Sign in to Facebook with your account and password
 2. Visit ltn.com.tw
 3. Tap a news headline to view the article in Fennec
 4. Tap the Like Button

Expected result
 - People can vote its preferred article by the Like Button

Actual result
 - It will pop up a window (Url is about:blank)
 - The counter is not updated after tapping the like Button 
 - This issue can be reproduced in Firefox desktop with FPI feature
 - This issue cannot be reproduced in Fennec without FPI feature

Device
 - Sony Z3C (Android 4.4.4)

Firefox
 - Fennec:  55.0a1 (2017-05-10) 
 - Firefox: 55.0a1 (2017-05-09)

Comment 1

[Tim Huang[:timhuang]]

The reason of this issue is because post messages cannot go across different first party domains after Bug 1363952. Before that, post messages can be sent to different first party domains. The facebook in 'ltn.com.tw' is based on the post message to sent data across windows with different first party domain. However, after Bug 1363952, this will not happen anymore, see [1]. 

In my opinion, it is much better in terms of first party isolation since two windows with different first parties should be segregated. So, the post message should not go across.

Arthur, what do you think about this?

[1] http://searchfox.org/mozilla-central/source/dom/base/PostMessageEvent.cpp#108

Comment 2

[Tom Ritter [:tjr]]

Tim you have the wrong bug reference.  Did you mean Bug 1345961? That fix shouldn't affect this, because the comparison is made using IsOriginAttributesEqualIgnoringFPD() Additionally, wouldn't the browser either crash outright after failing MOZ_DIAGNOSTIC_ASSERT or if those are disabled, write the TargetPrincipalDoesNotMatch error to console?   

Am I thinking about this correctly?

Comment 3

[Tim Huang[:timhuang]]

Oh, I posted a wrong bug number, sorry about that. It should be Bug 1314361.

Comment 4

[Tom Ritter [:tjr]]

(In reply to Tim Huang[:timhuang] from comment #1)
> In my opinion, it is much better in terms of first party isolation since two
> windows with different first parties should be segregated. So, the post
> message should not go across.

From our discussions about this, the crux of it is the difference between "opening the new domain in a new window" and "opening the new domain in an iframe."  If it was in an iframe, the postmessage would go across (and we want it to go across). But because it's in a window, the postMessage is blocked (and we want it to be blocked).  (For containers, we want it to go across.)

Maybe in some future revision of FPI, we could track popup windows and understand when a popup window is associated with an opening window and relax FPI to work better. Maybe. Maybe not.