1319728 - Fx with FPI feature wrongly displays that sign-in on youtube has failed even though it did not

Status: NEW

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

Description

[Bogdan Maris, Desktop QA]

[Note]:
- Prerequisits:
Enable perf "privacy.firstparty.isolate"
Disable perf "network.predictor.enabled"
Disable perf "network.predictor.enable-prefetch"

[Affected versions]:
- latest Nightly 53.0a1

[Affected platforms]:
- Ubuntu 16.04 32bit

[Steps to reproduce]:
1. Visit youtube.com
2. Login to youtube using sign-in form

[Expected result]:
- After filing username and password, the user is successfully logged in to youtube account and redirected to homepage.

[Actual result]:
- User is redirected to https://www.youtube.com/oops and the message "There was an issue signing you into YouTube. Troubleshoot here." appears on the page.

[Regression range]:
- This is not a regression, It's still an experimental feature not enabled by default in any official build.

[Additional notes]:
- Screenshot attached showing the error.
- If clicking Sign-In again after the error appears Fx actually did successfully singed in, this provides a big confusion for the user.

Comment 1

[Bogdan Maris, Desktop QA]

Attachment: Screenshot showing the issue

Comment 2

[Bogdan Maris, Desktop QA]

[Additional notes]:
- I should have mentioned that I did not encounter the same issue on Tor Browser.

Comment 3

[Ethan Tseng [:ethan]]

I can reproduce this bug on Ubuntu 14.04 LTS 64-bit.
But cannot reproduce it on Mac OS (I tried OS X 10.11.6).

Comment 4

[Ethan Tseng [:ethan]]

Yoshi, please help to investigate the root cause, thanks.

Comment 5

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

I think the problem is when user logins, first the page will be redirected to https://accounts.google.com/, there will be an iframe which will be navigated to https://accounts.youtube.com/... , 
and we will get some cookies from accounts.youtube.com, however it's isolated because now the firstPartyDomain is google.com.
And once the login finishes, the page will be redirected back to youtube.com, it will show error because youtube cannot access the cookies that set in the iframe.

Also I can reproduce this on Firefox nightly on Mac, however Ethan told me this bug is Linux only.
I'd like to get confirm from reporter this should happen on Linux, Mac and windows.

Thanks

Comment 6

[Bogdan Maris, Desktop QA]

(In reply to Yoshi Huang[:allstars.chh] from comment #5)
> I think the problem is when user logins, first the page will be redirected
> to https://accounts.google.com/, there will be an iframe which will be
> navigated to https://accounts.youtube.com/... , 
> and we will get some cookies from accounts.youtube.com, however it's
> isolated because now the firstPartyDomain is google.com.
> And once the login finishes, the page will be redirected back to
> youtube.com, it will show error because youtube cannot access the cookies
> that set in the iframe.
> 
> Also I can reproduce this on Firefox nightly on Mac, however Ethan told me
> this bug is Linux only.
> I'd like to get confirm from reporter this should happen on Linux, Mac and
> windows.
> 
> Thanks

I confirm that this behavior can be seen across platforms (Mac OS X 10.12.1, Windows 8.1 32bit and as initially reported on Ubuntu 16.04 32bit). I also checked Tor browser on the same platforms and I could not see the issue there.
Please let me know if I can help further on.

Comment 7

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

I found Tor doesn't have this problem because it doesn't accept 3rd party cookies by default (network.cookie.cookieBehavior is 1).

In this bug, there will be some 3rd party cookies from accounts.youtube.com as I mentioned in Comment 5.

For Firefox with FRI(First Party Isolation), if we also set network.cookie.cookieBehavior to 1, the login will work well.
So Arthur, do you think we should also disable 3rd party cookies when we test FirstPartyIsolation?

Thanks

Comment 8

[Arthur Edelstein [:arthur]]

(In reply to Yoshi Huang[:allstars.chh] from comment #7)
> I found Tor doesn't have this problem because it doesn't accept 3rd party
> cookies by default (network.cookie.cookieBehavior is 1).
> 
> In this bug, there will be some 3rd party cookies from accounts.youtube.com
> as I mentioned in Comment 5.
> 
> For Firefox with FRI(First Party Isolation), if we also set
> network.cookie.cookieBehavior to 1, the login will work well.
> So Arthur, do you think we should also disable 3rd party cookies when we
> test FirstPartyIsolation?
> 
> Thanks

Thanks for asking about this! I think no, we shouldn't disable 3rd-party cookies. In the future, in Tor Browser, we would like to activate 3rd-party cookies, now that they can be isolated by first party. Maybe the right answer is to assign 3rd-party cookies sent with redirects to the first-party of the destination domain. I think this problem is closely related to bug 1319839.

Comment 9

[Ethan Tseng [:ethan]]

(In reply to Bogdan Maris, QA [:bogdan_maris] from comment #6)
> (In reply to Yoshi Huang[:allstars.chh] from comment #5)
> > Also I can reproduce this on Firefox nightly on Mac, however Ethan told me
> > this bug is Linux only.
> > I'd like to get confirm from reporter this should happen on Linux, Mac and
> > windows.
> I confirm that this behavior can be seen across platforms (Mac OS X 10.12.1,
> Windows 8.1 32bit and as initially reported on Ubuntu 16.04 32bit). I also
> checked Tor browser on the same platforms and I could not see the issue
> there.

Yoshi and Bogdan, thanks for your confirmation.
I tried to reproduce this bug again on Mac today, and you were right, it happened on Mac OS as well.
It seems I made some mistake or got confused in the first place.

Comment 10

[Ethan Tseng [:ethan]]

We didn't reach an agreement on the solution of this bug.
It is too late to resolve it before the coming merge date (2017-03-06 for Aurora 54).
Set it as P2.

Comment 11

[Ethan Tseng [:ethan]]

(In reply to Arthur Edelstein [:arthuredelstein] from comment #8)
> Thanks for asking about this! I think no, we shouldn't disable 3rd-party
> cookies. In the future, in Tor Browser, we would like to activate 3rd-party
> cookies, now that they can be isolated by first party. Maybe the right
> answer is to assign 3rd-party cookies sent with redirects to the first-party
> of the destination domain. I think this problem is closely related to bug
> 1319839.

Arthur, could you elaborate the reason why Tor Browser would like to activate 3rd party cookies?

Comment 12

[Georg Koppen]

(In reply to Ethan Tseng [:ethan] from comment #11)
> (In reply to Arthur Edelstein [:arthuredelstein] from comment #8)
> > Thanks for asking about this! I think no, we shouldn't disable 3rd-party
> > cookies. In the future, in Tor Browser, we would like to activate 3rd-party
> > cookies, now that they can be isolated by first party. Maybe the right
> > answer is to assign 3rd-party cookies sent with redirects to the first-party
> > of the destination domain. I think this problem is closely related to bug
> > 1319839.
> 
> Arthur, could you elaborate the reason why Tor Browser would like to
> activate 3rd party cookies?

We are disabling 3rd party cookies only because they are a cross-origin linkability risk. This goes away with double-keying and is all we need for our privacy-by-design requirement. And it has the additional benefit that less websites are broken which seems to be a big win. Leaving ni for Arthur in case he has more to add.

Comment 13

[Arthur Edelstein [:arthur]]

I agree with Georg!

Comment 14

[Ethan Tseng [:ethan]]

(In reply to Georg Koppen from comment #12)
> We are disabling 3rd party cookies only because they are a cross-origin
> linkability risk. This goes away with double-keying and is all we need for
> our privacy-by-design requirement. And it has the additional benefit that
> less websites are broken which seems to be a big win. Leaving ni for Arthur
> in case he has more to add.

Georg and Arthur, thanks for your prompt response and explanation!

Yoshi, let's consider using the solution that Arthur suggested in comment 8.

Comment 15

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

(In reply to Arthur Edelstein [:arthuredelstein] from comment #8)
> Maybe the right answer is to assign 3rd-party cookies sent with redirects to the first-party of the > destination domain. I think this problem is closely related to bug 1319839.

To my understanding, bug 1319839 is trying to isolate 'SSO cookies' on first party domain.
For Google's services, their identity service is located in accounts.google.com so those SSO cookies are all from accounts.google.com. In that bug we are trying to make it isolated by google.com, youtube.com, .... etc, i.e. isolated by the service provider domain, not the identity service domain.

Whereas this bug is slightly different, as explained in comment 5, even in Firefox we accept 3rd party cookies by default, but those 3rd party cookies are still isolated by first party domain, so for some websites depending on 3rd party cookies, they still have the same problems, like this bug.

If we were to allow those 3rd party cookies 'to be shared' by some first party domain, (for example, in this case, we allow those cookies isolated by 'google.com' to be shared with 'youtube.com'), I worry that we will have some cross-origin linkability risk again, so I'd need more time working on this.

Comment 16

[Tim Huang[:timhuang]]

The website 'as.com' has a similar issue that it requires third party cookies being disabled to successfully log in for Firefox with first party isolation is enabled.

Comment 17

[Ioana Chiorean]

Attachment: Screenshot mobile

Same thing on mobile with with firstPartyIsolation on Fennec 55 
See screenshot. 
If I go to account a second time it shows me connected