1550899 - Embedded Google Presentation blocked by ETP

Status: RESOLVED FIXED

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

Description

[Arthur Edelstein [:arthur]]

In Nightly, with Content Blocking on, an embedded Google presentation is blocked. Turning off Content Blocking unblocks the presentation.

See https://www.mozdatacollective.com/extcontent/index/index/element/1199

Comment 1

[(no longer active)]

The embedded resource when loaded without cookies redirects to https://accounts.google.com/ServiceLogin?service=wise&passive=1209600&continue=https://docs.google.com/presentation/d/1W1e9omwgVOMn3yHfhbGcwrqBPrUVJ7aFcxlwDFpdmmg/preview&followup=https://docs.google.com/presentation/d/1W1e9omwgVOMn3yHfhbGcwrqBPrUVJ7aFcxlwDFpdmmg/preview&ltmpl=slides. That page is served with an x-frame-options: DENY header which prevents it from being rendered when embedded as an iframe.

Comment 2

[Steven Englehardt [:englehardt]]

accounts.google.com is in the content category, and thus will break with the strict list.

Comment 3

[(no longer active)]

(In reply to Steven Englehardt [:englehardt] from comment #2)

accounts.google.com is in the content category, and thus will break with the strict list.

That is almost true, but not because accounts.google.com is in the content category, but because docs.google.com is in the content category.

(When reproducing this bug, please note that any reason why login cookies aren't sent to docs.google.com would be sufficient to reproduce the bug. In addition to ETP, for example, if the user hasn't signed in to docs.google.com in a separate tab, or if the user is using a new profile, or a private window, or a container tab, etc., all of these conditions will result in the same breakage as what can be seen in comment 0, even though they all have different underlying causes behind why login cookies aren't sent to docs.google.com initially.)

Comment 4

[(no longer active)]

Test case that doesn't require LDAP login: https://tourmaline-peak.glitch.me/

Comment 5

[(no longer active)]

The Google team are working on a fix for this.

Comment 6

[Steven Englehardt [:englehardt]]

Ehsan do you have an ETA on their fix?

Comment 7

[(no longer active)]

(In reply to Steven Englehardt [:englehardt] from comment #6)

Ehsan do you have an ETA on their fix?

I don't.

Comment 8

[(no longer active)]

Update from the Google Docs team: "[T]he ETP integration have been rolled out to some of the users and we expect the rollout to be completed in the following couple of days."

Comment 9

[(no longer active)]

This seems to be fixed now.

Comment 10

[Rachel Tublitz [:rachel]]

I'm still seeing it happening here, in nightly

Comment 11

[(no longer active)]

(In reply to Rachel Tublitz [:tublitzed] from comment #10)

I'm still seeing it happening here, in nightly

Interesting, thanks for pointing this out. I took a closer look to that page, and it seems like there the google docs page isn't directly embedded using an iframe, but rather using the Google Docs Javascript API. The same page works fine in Safari.

I'll email the Google Docs team about this issue.

Comment 12

[(no longer active)]

(In reply to :ehsan akhgari from comment #11)

(In reply to Rachel Tublitz [:tublitzed] from comment #10)

I'm still seeing it happening here, in nightly

Interesting, thanks for pointing this out. I took a closer look to that page, and it seems like there the google docs page isn't directly embedded using an iframe, but rather using the Google Docs Javascript API. The same page works fine in Safari.

I'll email the Google Docs team about this issue.

This seems to be a bug in ServiceRocket, a Confluence integration for Google Docs. Filed as bug 1610684.