Closed Bug 1631811 Opened 1 year ago Closed 5 months ago

Content loaded from datastudio.google.com broken with ETP Standard Level 2 List

Categories

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

All
Unspecified
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: sergiu, Assigned: englehardt)

References

(Blocks 2 open bugs, )

Details

Attachments

(1 file)

Attached image Screenshot_1.png

Browser / Version
Firefox Preview Nightly 200414 (🦎 77.0a1-20200410095419)
Firefox Nightly 77.0a1 (2020-04-21)

Operating System
Samsung Galaxy S8 (Android 9) - 1440 x 2960 pixels, 18.5:9 ratio (~570 ppi density)
Windows 10 Pro

Steps to reproduce:

  1. Go to https://ageor.dipot.com/2020/03/Covid-19-in-Greece.html
  2. Scroll down to the maps.

Expected Behavior:
The maps are loaded.

Actual Behavior:
A loading animation is displayed.

Notes:

  1. Screenshot attached.

This is broken because of the google.com origin on the Level 2 cookie blocking list. When I add a cookie blocking exception for datastudio.google.com, the maps load as expected.

The map is loaded from the following URL: https://datastudio.google.com/embed/reporting/d1661b54-8fd8-460e-86c3-bccbcdb2b750/page/r8nHB.

When that frame has its storage access restricted, we see the following error:

ERROR DOMException: "The operation is insecure." datastudio.js:3597:1087
    lg_Hna https://ssl.gstatic.com/analytics/rap/20200505_00020036/js/datastudio.js?cb=309771239:3597
    handleError https://ssl.gstatic.com/analytics/rap/20200505_00020036/js/datastudio.js?cb=309771239:3597
...

which appears to be related to a service worker exception. I was not able to track down the exact cause.

Blocks: etp-level-2-list
No longer blocks: etp-breakage
See Also: → 1550899
Severity: -- → S2
Summary: Maps on ageor.dipot.com are not loaded with ETP Standard ON → Content loaded from datastudio.google.com broken with ETP Standard Level 2 List
Duplicate of this bug: 1640425
See Also: → 1640425

S1 or S2 bugs need an assignee - could you find someone for this bug?

Flags: needinfo?(senglehardt)
Severity: S2 → S3
Flags: needinfo?(senglehardt)

It looks like there are two bugs now, but both can be fixed with technical interventions.

First, you'll see the following:

ERROR Error: Error while instantiating injectable 'InjectionToken LocalStorage': The operation is insecure.
    f https://ssl.gstatic.com/analytics/rap/20201019_00020000/js/datastudio.js?cb=337802568:3371

This script is embedded in the iframe loaded from https://datastudio.google.com/embed/reporting/d1661b54-8fd8-460e-86c3-bccbcdb2b750/page/r8nHB. Adding datastudio.google.com/embed/reporting/ to privacy.restrict3rdpartystorage.partitionedHosts fixes this by providing iframes loaded from that URL with temporary, partitioned localStorage.

With that fix in place, you'll see the error I mentioned in Comment 1. Turns out this is not service worker related, but rather IndexedDB related. This can be fixed through a webcompat intervention that pretends window.indexedDB doesn't exist. As a test, I adapted a fix that I wrote for similar breakage in embedded Twitter videos (i.e., changing the intervention to inject on https://datastudio.google.com/embed/reporting/*).

With both of these fixes in place, datastudio iframes will load properly.

Here's another site that uses datastudio and is broken in the same way: https://fall2020.princeton.edu/health-guidance/covid-19-dashboard. The fixes described in Comment 4 also fix the breakage on Princeton's site.

I am wondering if this is a good approach that we adopt the web compact intervention like this way. This equals disabling indexedDB for https://datastudio.google.com/embed/reporting/*. This can resolve the issue, but if a better approach would be a session-only and partitioned indexedDB like partitioned storage that we've built with privacy.restrict3rdpartystorage.partitionedHosts.

Flags: needinfo?(senglehardt)

(In reply to Tim Huang[:timhuang] from comment #6)

I am wondering if this is a good approach that we adopt the web compact intervention like this way. This equals disabling indexedDB for https://datastudio.google.com/embed/reporting/*. This can resolve the issue, but if a better approach would be a session-only and partitioned indexedDB like partitioned storage that we've built with privacy.restrict3rdpartystorage.partitionedHosts.

FWIW Indexed DB is disabled already for these iframes due to cookie blocking. This intervention just changes the functionality from throwing a SecurityError when the object is accessed to removing the object from the DOM entirely.

The process I think the webcompat team will use is to ship the intervention in their addon first to fix the breakage, and then reach out to Google so they're aware. There will also be a console log warning developers. Hopefully Google devs will engage and we can remove the intervention in the future.

Since our long-term goal is to remove the intervention, I think it's fine to do the minimum possible to get the embedded content working. If we found that datastudio frames were still broken without indexedDB, then we could consider implementing an in-memory partitioned version.

Flags: needinfo?(senglehardt)

Hi Thomas,

Would you be able to guide us on the webcompat intervention that we need in order to resolve this breakage?

First, which priority fits for this webcompat intervention? Low or high?

According to the URL https://datastudio.google.com/embed/reporting/*, it implies that it will only be used in iframes. But do we have an explicit way to only enable webcompat intervention in iframes?

In addtion, could we land the intervention directly to the mozilla-central? Or we have to land to the github repo first? Thanks.

Flags: needinfo?(twisniewski)
Depends on: 1677144

I've added a prototype intervention for this here: https://github.com/englehardt/webcompat-interventions/tree/master/bug_1631811. I've verified that this, combined with the partitionedHosts pref change still fixes the breakage from Comment 0 and Comment 5.

Dennis: is it possible to ship this intervention in the webcompat addon?

Flags: needinfo?(dschubert)

is it possible to ship this intervention in the webcompat addon?

Yeah, absolutely! Ksenia will be building and shipping the interventions in the Firefox 85 cycle, I added this bug to our tracking issue for that release. :)

Depends on: 1663980
Flags: needinfo?(dschubert)
Assignee: nobody → senglehardt
Status: NEW → ASSIGNED

Verified fixed by intervention in Bug 1663980

Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Flags: needinfo?(twisniewski)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.