[Extension] Unable to log in to Hypothesis from USA Today pages in Extension

[chrisshaw]

Related

Depends on #333 , but focused on solving the problem for the extension.

---

Bug report form

Steps to reproduce

1. Make sure you are logged out Hypothesis
2. Open any page at USA Today e.g. https://www.usatoday.com/story/news/politics/2022/03/07/ukraine-russia-invasion-live-updates/9404740002/
3. Activate Hypothesis extension or bookmarklet, and click the sidebar link to Log In

Expected behaviour

The Hypothesis login pop-up window should appear with appropriate username and password fields available.

Actual behaviour

An entirely blank pop-up window displays.

Browser/system information

Tested on:

• Chrome 99
• Firefox 97
• Brave 1.36.109

Note: The issue does not seem to affect Safari 15.3

Additional details

If you are already logged in to Hypothesis all functionality works as expected.

---

Prior Art

From #333

The cross-origin-opener-policy header in particular is a new thing that may be relevant. From this related Chrome issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1221127:

Sites that wish to continue using SharedArrayBuffer must opt-into cross-origin isolation. Among other things, cross-origin isolation will prevent cross-origin popups from having access to their opener. This behavior ships today in Firefox, and Chrome aims to ship it as well in Chrome 92.
As part of crossOriginIsolation, websites must send a Cross-Origin-Opener-Policy: same-origin header. COOP same-origin prevents pages with different top-level origins from being able to communicate with each other. This breaks many OAuth or payment flows that rely on opening a cross-origin popup that will communicate back with the page through window.postMessage for example.

I'm not clear how this interacts with iframes yet.

This feature request in this issue is written with the assumption that the target audience is a web developer who can change the headers that web pages are served with. We can change these headers in Via, but not in the bookmarklet or browser extension.

I was able to reproduce in Chrome using Sauce Labs to load the page from a US-based server, using the browser extension. The window.open call that the OAuthClient class in the client makes is returning null.

This might be something to do with the headers the top-level frame is returning:

content-type: text/html; charset=utf-8
etag: W/"36e87-xQxIdQhDQBw7nNrIxHR+WGsIvwA"
x-content-type-options: nosniff
x-frame-options: deny
x-xss-protection: 1; mode=block
feature-policy: camera 'none';display-capture 'none';geolocation 'none';microphone 'none';payment 'none';usb 'none';xr-spatial-tracking 'none'
permissions-policy: camera=(),display-capture=(),geolocation=(),microphone=(),payment=(),usb=(),xr-spatial-tracking=()
referrer-policy: strict-origin-when-cross-origin
content-security-policy-report-only: script-src https: blob: 'unsafe-inline' 'unsafe-eval' 'self';base-uri 'self';report-uri https://reporting-api.gannettinnovation.com;report-to default
content-security-policy: upgrade-insecure-requests;frame-ancestors 'none';object-src 'none'
cross-origin-opener-policy: same-origin
cross-origin-resource-policy: same-origin
origin-agent-cluster: ?1
accept-ranges: bytes
date: Wed, 16 Mar 2022 14:39:52 GMT
age: 5
set-cookie: gup_anonid=c4d0b197-c729-4a26-8d66-d91134674253; Domain=.usatoday.com; Max-Age=31536000; Path=/; SameSite=Lax; Secure
set-cookie: gup_clientid=3216a3a7-781d-4a99-b099-5d5d66f39e1c; Domain=.usatoday.com; Max-Age=31536000; Path=/; SameSite=Lax; Secure
cache-control: no-store
set-cookie: gnt_ub=1; domain=.usatoday.com; path=/; secure; samesite=lax; max-age=31536000;
set-cookie: gnt_sb=1; domain=.usatoday.com; path=/; secure; samesite=lax; max-age=31536000;
set-cookie: gnt_eid=control:1; domain=.usatoday.com; path=/; secure; samesite=lax; max-age=5184000;
gannett-cam-experience-id: control:1
nel: {"report_to":"default","max_age":31557600,"include_subdomains":true,"success_fraction":0.005}
report-to: {"max_age":31557600,"include_subdomains":true,"endpoints":[{"url":"https://reporting-api.gannettinnovation.com"}]}
link: <https://www.usatoday.com/tangstatic/svg/weather/7-q1a2z3371d08dc.svg>;rel=preload;as=image;nopush
set-cookie: gnt_d=%7B%22w%22%3A%7B%22t%22%3A%2248%22%2C%22f%22%3A%227-q1a2z3371d08dc%22%2C%22c%22%3A%22Cloudy%22%7D%2C%22z%22%3A%2295123%22%2C%22c%22%3A%22san%20jose%22%2C%22s%22%3A%22CA%22%7D; domain=.usatoday.com; path=/; samesite=lax; secure; priority=high;
x-cache: MISS, HIT
x-timer: S1647441593.799128,VS0,VE1
vary: X-AbVariant,X-AbVCfg,X-AltUrl,Accept-Encoding,User-Agent
strict-transport-security: max-age=63072000
content-length: 199138

[chrisshaw]

If this is affecting extensions that require users to log in, then either everyone with basic auth is going to be affected or there must be a solution for extension developers. So I imagine part of the investigation will be into that question.

[chrisshaw]

Focusing only on extension (Via in #333)

Per @robertknight in #333 (comment):

The situation with standards is fluid, but whatwg/html#6364 has the most up-to-date discussion. My understanding of where this is likely to end up is:

1. Browsers will eventually provide a way for a popup window to communicate with a cross-origin frame that opens it via window.opener, even if that iframe or its parent document are using Cross-Origin-Opener-Policy. The window.opener reference would be limited to just use of the postMessage and closed properties, which would be adequate for us. Enabling this might require the parent document or popup to set a custom Cross-Origin-Opener-Policy headers. If headers have to be changed on the site where the client was embedded, as opposed to the URL opened in the popup window, that's more complicated and would depend on the method of embedding the client:

   • In Via we can override headers on any document.
   • In the bookmarklet we can't. This would add another category of site (in addition to those that use Content-Security-Policy) where the bookmarklet simply can't work.
   • In the Chrome extension we'd have to ask for additional permissions, which is undesirable, so I think we'd use some other extension-specific mechanism to handle the login

2. In today's browsers, BroadcastChannel can be used as a workaround for pages that use COOP in Firefox and Chrome but not Safari. The same applies to other mechanisms of same-origin communication such as localStorage. BroadcastChannel is liable to stop working in future though as Firefox/Chrome are planning to partition it similar to Safari. Hopefully by then they will have implemented (1) however

3. It might be possible to use document.requestStorageAccess() together with document.cookie to allow the popup to communicate with the iframe in Safari/Firefox. I need to prototype this.

So the status quo seems to be that there is no solution that works in all browsers, all methods of delivering the client and does not affect the page's ability to use web platform features that are depend on COOP.

Some options solutions we can implement today:

1. Strip the Cross-Origin-Opener-Policy header in Via, and rely on sites not actively using the web platform features that are gated behind it. When the solution described in (1) is available, we could change the header to one that allows popups rather than strip it entirely.
2. Use BroadcastChannel or document.cookie as popup <-> iframe communication mechanisms, with the understanding that these may become unavailable in future.
3. Use an alternative method of communicating the access token from the popup to iframes in the extension. This will involve extension-specific APIs.

@robertknight Same question as with Via: if we have users complete a workaround where they go log in on a site that does not use this COOP (maybe even one we host), can they then come back to this page, would that work to "log them in?" In my testing, it seems like no, but you've mentioned this affects only new logins, which make me think I'm just doing it wrong.

If you can do this and I am just doing it wrong, then perhaps another option would be to point people to this workaround rather than resorting to a short-lived BroadcastChannel solution or extension APIs. (Not that this is the right one, because I don't know what you were thinking, but the identity API for OAuth flows is supported in Chromium and Firefox but not Safari.)

[robertknight]

This comment is a summary of what I've learned so far from investigating this issue and how it affects Hypothesis:

Web browsers are introducing a new set of headers that will enable "cross-origin isolation" documents, and the availability of certain web platform features will be tied to documents being in a cross-origin isolated state. https://web.dev/why-coop-coep/ explains the rationale for introducing this feature and how the various headers interact with it. A consequence of enabling cross-origin isolation today is that popup windows, such as our OAuth login window, lose access to the frame/window that opened them via window.opener. Our OAuth login window relies on this in order to send an access code back to the sidebar after the user logs in. We are not unique in being affected this way. See #333 (comment) for links to related web standards discussions.

The Cross-Origin-Opener-Policy header does not pose a problem for Via today, because it only takes effect when applied to the top frame. Via always displays HTML content inside an iframe. In public Via this is a ViaHTML iframe embedded in a Via frame. In the LMS this is a ViaHTML iframe embedded inside the LMS frontend app which in turn is embedded inside the LMS.

The a site sets the Cross-Origin-Opener-Policy header this can however prevent logging in to from either the bookmarklet or browser extension. Since Chrome has not yet blocked third-party cookies, a workaround for extension users is to visit some other page first, login there, and then re-visit USA Today (or the other page using COOP). A workaround for bookmarklet users is to use Via.

The situation with these web standards is fluid. There are some proposals being discussed (see #333 (comment)) which would help us, specifically the one that would allow limited access to window.opener from popup windows, but these are not yet implemented by any browser.

In terms of what we need to do right now, I agree with your conclusion @chrisshaw: We don't need to do anything for Via at the moment, and for the browser extension we have a simple workaround. For bookmarklet users the workaround is to use Via, similar to sites that use Content-Security-Policy. We can keep an eye on the evolution of web standards over the next few months and then follow whatever the final recommendations are for sites which use login popups.

[chrisshaw]

I'm going to close this here as the only work remaining for now is some documentation by either @mattdricker or myself. I will open the requisite work in the support backlog.