How to extend the scope to ensure that the PWA provides the same user experience when accessing pages in different domains?

[MichaelWangzitao]

Now that the "scope" attribute presents a single navigation scope. But in some cases, a WPA may contain a set of cp pages that come from different companies and have different domain names. According to the existing solution, when a PWA accesses a CP page of a different domain name, the PWA exits the full-screen mode and switches to the browser mode of the corresponding page.

[marcoscaceres]

Unfortunately, PWAs are limited to same origin. I don't think there is plan to expand scope across multiple origins because things get very tricky from a security perspective (this has come up quite a few times... search for "cross origin" in the issues and see in particular some of the closed issues). Keeping things same-origin keeps things a little more manageable.

[alancutter]

There is a URL Handler proposal that more or less expands a web app's scope across origins via a web-app-origin-association file.
https://github.com/WICG/pwa-url-handler/blob/main/explainer.md

[dannysu]

hi @marcoscaceres Could you please help me understand a bit more on the security aspect or where to read more?

There are definitely a bunch of different scenarios. The specific scenario I'm trying to figure out is for enterprise services that have multiple origins. It's extremely common.
For example:

• Slack: companyA.slack.com, companyB.slack.com
• Quip: companyA.quip.com, companyB.quip.com
• Workplace: companyA.workplace.com, companyB.workplace.com

This is unlike the other scenarios discussed before:

1. auth provider on different origin
2. different apps from the same company like mail.google.com, calendar.google.com
3. or portal-type sites linking the different apps on completely different domains (a.com, b.com)

With these services like Slack, it's really the same app to the end user. On native app stores, these services provide a single native app and include UI switches in the app to change the organization. Trying to do the same in a PWA is impossible with current "scope" member.

I can see how things like *.github.io or *.herokuapp.com, where each subdomain is a completely separate app, then security issue applies. Users need to know they've transitioned to a different place. However, in the case of Quip, Workplace, and Slack, the subdomains are really the same app still.

There's the complication with needing a service worker per origin, and the permissions would need to be prompted per origin.

Security concern is mentioned on issues related to this but never in detail, and I just want to understand a bit more.
Seems like the only solution currently is to introduce a proprietary manifest member and process in the UA like what ManifoldJS did.

Thanks

[alancutter]

I'm currently working on a generalisation of the URL Handler proposal called Scope Extensions that aims to cater to this use case.
WICG/manifest-incubations#13

[MichaelWangzitao]

I'm currently working on a generalisation of the URL Handler proposal called Scope Extensions that aims to cater to this use case.
WICG/manifest-incubations#13

Great! I would like to contribute to this work.

[aarongustafson]

@alancutter Would this be an alternative to or complimentary to First Party Sets?

[LuHuangMSFT]

First Party Sets (FPS) as implemented might not have the right precision for this application. The smallest First-Party Set contains all origins of a single domain name.

I imagine it's possible to use FPS as the validation mechanism for a manifest scope extension.

We should also consider the difference between extending app scope in general and extending app scope for a particular application (eg. the URL Handling scope extension).

Slack: companyA.slack.com, companyB.slack.com
Quip: companyA.quip.com, companyB.quip.com
Workplace: companyA.workplace.com, companyB.workplace.com

We need to consider the app identity problem here. For these scenarios, it would be ideal to be able to install an app from multiple origins with the same app identity.

There's the complication with needing a service worker per origin, and the permissions would need to be prompted per origin.

Origin boundary still make sense to me for service worker, local storage, permissions, etc. in the CompanyA/CompanyB scenario. CompanyA should not be able to access state from the users activities at CompanyB, and vice versa.