Re: [w3c/manifest] How to extend the scope to ensure that the PWA provides the same user experience when accessing pages in different domains? (#964)

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/964#issuecomment-833072455