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

Status: RESOLVED FIXED

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

Description

[Sergiu Logigan [:sergiu]]

Attachment: 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.

Comment 1

[Steven Englehardt [:englehardt]]

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.

Comment 3

[Rachel Tublitz [:rachel]]

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

Comment 4

[Steven Englehardt [:englehardt]]

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.

Comment 5

[Steven Englehardt [:englehardt]]

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.

Comment 6

[Tim Huang[:timhuang]]

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.

Comment 7

[Steven Englehardt [:englehardt]]

(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.

Comment 8

[Tim Huang[:timhuang]]

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.

Comment 9

[Steven Englehardt [:englehardt]]

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?

Comment 10

[Dennis Schubert [:denschub]]

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. :)

Comment 11

[Steven Englehardt [:englehardt]]

Verified fixed by intervention in Bug 1663980

Comment 12

[Calin Tanase]

This is still an issue on the latest Firefox Nightly 112.0a1 (2023-02-21). The issue is not reproducible with ETP OFF.

Note: Turning ETP OFF and ON, the content will stay on the page until cache/cookies are cleared.