1747889 - "Sign in" is not recognized after enabling "Data Visualizer" add-in on office.com with ETP - Standard

Status: ASSIGNED

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

Description

[Oana Arbuzov [:oanaarbuzov]]

Attachment: StandardVsDisabled.png

Environment:
Browser / Version: Firefox Nightly 97.0a1 (2021-12-29)
Operating System: Windows 10 Pro

Prerequisites:
ETP - Standard enabled.
Signed into Enterprise Microsoft account.

Steps to Reproduce:

1. Navigate to
2. Open a new blank workbook.
3. Click "Insert" button from "Options" menu and choose "Office Add-ins" option.
4. After "Office Add-ins" popup is displayed, click the "STORE" button.
5. Select "Microsoft Visio Data Visualizer" add-in and add it to the workbook.
6. Observe the "Data Visualizer" popup.

Expected Behavior:
"Sign in" is recognized and available "Flowcharts" are displayed.

Actual Behavior:
"Sign in" is not recognized, even if already sign into Microsoft account.

Notes:

1. Screenshot attached.
2. The issue is not reproducible with ETP disabled.

Comment 1

[Tim Huang[:timhuang]]

I can reproduce the issue. The root cause is that https://login.microsoftonline.com/ doesn't have storage access under https://outlookwebtest-my.sharepoint.com/. So, it cannot access its login credential. This means that the Storage Access API should be called in https://login.microsoftonline.com/ when it's embedded in https://outlookwebtest-my.sharepoint.com/ so that this can work. And a shim is possible to fix this issue.

Comment 2

[Paul Zühlcke [:pbz]]

We have an intervention in place, see Bug 1740763. Lowering severity.

Comment 3

[Paul Zühlcke [:pbz]]

Tim, could you confirm this intervention is still working? Testing on Firefox stable on PROD RemoteSettings the Data Visualizer still does not seem to recognize the login.
The *,https://login.microsoftonline.com entry is still in place.

Comment 4

[Tim Huang[:timhuang]]

Yes, this is also broken to me. I think they change their auth process because I need to allow the domain https://visio.officeapps.live.com to make it work. Maybe we need to add it to our list.

Comment 5

[Paul Zühlcke [:pbz]]

Thanks! Tim, since you're assigned, could you please update the skiplist entries and the respective bugs? Perhaps we can (after testing) just drop the generic entries for the the microsoftonline and live endpoints now?

Comment 6

[Tim Huang[:timhuang]]

Sure thing. I will do that.

Comment 7

[Tim Huang[:timhuang]]

I am not entirely sure if we can drop those two entries. But I can check if it's possible.

Comment 8

[Tim Huang[:timhuang]]

Per my testing, we still need the live.com endpoint to display the avatar icon. So, we couldn't drop it.

Comment 9

[Tim Huang[:timhuang]]

Oh, weird. The Data Visualizer addon works again even without allowing https://visio.officeapps.live.com. Maybe Microsoft change something that doesn't require this allowlist entry anymore.

Comment 10

[Paul Zühlcke [:pbz]]

Could you please check again if we still need the allowlist entries for MS login? afaic this is the last remaining bug before we can remove the entries.

Comment 11

[Tim Huang[:timhuang]]

I can no longer access the Microsoft Enterprise test account.

Raul, Calin,

Could you help with testing this? To test if we still need the allowlist entry, you can disable the allowlist by flipping the pref privacy.antitracking.enableWebcompat. And see if the problem still exists after disabling WebCompat interventions.

Comment 12

[Raul Bucata]

Hi Tim. I can still reproduce the issue with the pref set to FALSE in a clean profile. Setting the pref to TRUE (by default) in a clean profile does not present the reported issue, as with ETP set to STRICT, the account sign-in is recognized.

Tested with:

Browser / Version: Firefox Release 113.0.2 (64-bit)/ Firefox Nightly 115.0a1 (2023-05-23) (64-bit)
Operating System: Windows 10 PRO x64

Notes:

1. Reproducible on the latest build of Firefox Nightly and Release.
2. Accessing in a clean profile for the first time with the pref set to TRUE does not present the issue when accessing again with the pref set to FALSE.

Comment 13

[Raul Bucata]

Attachment: pref false vs pref true

Comment 14

[Raul Bucata]

Comment on attachment 9335608 [details]
pref false vs pref true

There was an error when uploading the screenshot
Link: https://prnt.sc/8HxVjJjKZWlp

Comment 15

[Calin Tanase]

Attachment: 3 Strict vs OFF ETP.png

The issue is reproducible for me as well with the pref set to false and Strict ETP.

Tested on:
• Browser / Version: Firefox Nightly 115.0a1 (2023-05-23)
• Operating System: Windows 10