1846712 - [Top 100] Fails to remain logged in while browsing the page on msn.com

Status: REOPENED

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[Calin Tanase]

Attachment: msn logged out.mp4

Environment:
Operating system: Windows 10
Firefox version: Firefox Nightly 118.0a1 (2023-08-01)

Steps to reproduce:

1. Go to https://www.msn.com
2. Log into your account.
3. Access the "SPORT" category.
4. Click on any article.
5. Check the account icon.

Expected Behaviour:
The account remains logged in after browsing the page.

Actual Behaviour:
The account is logged out while browsing the page.

Notes:

1. Screen rec provided
2. At first it reproduce only when opening new articles in a new tab, now it seems it reproduces regardless when browsing the page
3. Reproducible regardless of the ETP status
4. Not reproducible on Firefox Release and Chrome
5. Issue found during WebCompat team [Top100] websites testing

Comment 1

[Raul Bucata]

Reproducible on mobile as well. Seems like a duplicate of : https://github.com/webcompat/web-bugs/issues/124586

Comment 2

[Ksenia Berezina [:ksenia]]

Attachment: Nightly, network.cookie.cookieBehavior=5

Another way to test this (as described in the webcompat bug), after account login is performed, reload the page and the account icon will appear as you're not logged in.

It starts working as expected in Nightly if I change network.cookie.cookieBehavior to 4, so this is related to TCP.

The site injects an iframe to check whether a user is authenticated with this url:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=..., which then redirects to
https://login.live.com/oauth20_authorize.srf?client_id=... , which
redirects to the url with an "error" hash https://www.msn.com/staticsb/statics/latest/auth/auth-redirect-blank.html?lc=1033#error=login_required&error_description=Silent+authentication+was+denied.+The+user+must+first+sign+in+and+if+needed+grant+the+client+application+access+to+the+scope+'User.Read+openid+profile+offline_access'.&state=... , which makes the auth check fail.

Looks like most of the required cookies are missing in the request to https://login.live.com, so it returns this error in response.

Comment 3

[Ksenia Berezina [:ksenia]]

Attachment: Firefox release

These are the cookies sent in Firefox release (or Nightly with network.cookie.cookieBehavior=4), where auth check is successful

Comment 4

[pdenomy]

This also happens when I log into Outlook Online. If I use either my username and password/authenticator or my Windows Hello, the credentials for Outlook Online are not retained upon a re-start of Firefox.
I'm currently at Firefox V117.0b9.
The same is true using Firefox Nightly.

Comment 5

[Tim Huang[:timhuang]]

Attachment: Bug 1846712 - Implement s shim for MSN login. r?pbz!,twisniewski

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/44c4867428c6
Implement s shim for MSN login. r=twisniewski,pbz,webcompat-reviewers

Comment 7

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/44c4867428c6

Comment 8

[Calin Tanase]

The issue started to reproduce again on both Android and Windows.

Environment:
Operating system: Google Pixel 5 (Android 13) / OnePlus 6 A6000 (Android 11) / Windows 10
Firefox version: Nightly 121.0a1-20231102094447 / 121.0a1 (2023-11-02)

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 10

[Tim Huang[:timhuang]]

I cannot reproduce the issue on my MAC. Calin, would you be able to verify if this issue is reproducible on MAC?

Comment 11

[Calin Tanase]

Doesn't seem to reproduce on my Mac as well. Still reproducible on Windows 10.

Comment 12

[Mathew Hodson]

I think it would be easier to track if this bug remained closed since the shim landed on Firefox 119, and then another bug can be opened for the new failures we are seeing.

Comment 13

[pdenomy]

I still see intermittent log-offs with Nightly... 121.0a1 (2023-11-13) (64-bit).
There isn't a pattern that I can report that causes Nighly to dump the Microsoft login credentials. Some days the login sticks other days the login gets dumped and I have to log back into the service.

I'm also seeing this behaviour with Firefox 119.0.1 (64-bit).
Cheers.

Comment 14

[Tim Huang[:timhuang]]

I tested it on Windows 10 with a fresh profile and could not reproduce the issue. Calin, would you be able to provide a captured video of the issue again?

Comment 15

[Tim Huang[:timhuang]]

Lower the severity because we have deployed a shim for this and now it's a platform-dependent issue.

Comment 16

[Calin Tanase]

Attachment: msn with Strict Standard OFF ETP (mobile).mp4

Seems to work now on Windows 10 with the latest Nightly. However I'm still able to reproduce it on Android with both Standard and Strict ETP.

Browser / Version: Firefox Nightly 121.0a1-20231114093013 / Firefox Nightly 121.0a1 (2023-11-14)
Operating System: OnePlus 6 A6000 (Android 11) / Windows 10

Comment 17

[Tim Huang[:timhuang]]

Please help with testing on Android. Thanks.

Comment 18

[Harshit Sohaney [:hsohaney]]

Working on it! Getting my android simulator setup, and I'll look into it within the week!

Comment 19

[Paul Zühlcke [:pbz]]

This came up in the meeting today. I'm setting the NI again to ensure it doesn't get lost.

Comment 20

[Harshit Sohaney [:hsohaney]]

Finally got my Android Emulator running, verified on Android 15 (VanillaIceCream) on Pixel 8.
Looks like turning ETP off works, so this remains to be an ETP issue (reproducible with ETP standard).