Content loaded from datastudio.google.com broken with ETP Standard Level 2 List
Categories
(Core :: Privacy: Anti-Tracking, defect, P3)
Tracking
()
People
(Reporter: sergiu, Assigned: englehardt)
References
(Blocks 2 open bugs, )
Details
(Whiteboard: [webcompat:sitepatch-applied])
Attachments
(1 file)
(deleted),
image/png
|
Details |
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:
- Go to https://ageor.dipot.com/2020/03/Covid-19-in-Greece.html
- Scroll down to the maps.
Expected Behavior:
The maps are loaded.
Actual Behavior:
A loading animation is displayed.
Notes:
- Screenshot attached.
Assignee | ||
Comment 1•4 years ago
|
||
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.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Comment 3•4 years ago
|
||
S1 or S2 bugs need an assignee - could you find someone for this bug?
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
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.
Assignee | ||
Comment 5•4 years ago
|
||
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•4 years ago
|
||
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
.
Assignee | ||
Comment 7•4 years ago
|
||
(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 withprivacy.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•4 years ago
|
||
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.
Assignee | ||
Comment 9•4 years ago
|
||
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•4 years ago
|
||
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. :)
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 11•4 years ago
|
||
Verified fixed by intervention in Bug 1663980
Updated•3 years ago
|
Comment 12•2 years ago
|
||
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.
Updated•1 year ago
|
Description
•