search

WICG / first-party-sets

https://wicg.github.io/first-party-sets/
276 stars 64 forks source link

Origin specificity #46

Open LuHuangMSFT opened 3 years ago

LuHuangMSFT commented 3 years ago

I understand from the explainer that currently the smallest possible FPS would include all origins of a single domain name. Would it be possible to include only specific origins from a single domain or from multiple different domains?

krgovind commented 3 years ago

That's an excellent question! Unfortunately, the current design doesn't allow for this. We did consider designing FPS so that it is specified as origins, see the alternative design section; but did not pursue it further due to complexity?

Could you explain further the motivation/use-case behind your question?

krgovind commented 3 years ago

Hi @LuHuangMSFT - just pinging this discussion to see if you are able to expand upon the motivation/use-case behind your question.

LuHuangMSFT commented 3 years ago

@krgovind Sorry I lost track of this issue.

I work on PWA features and would like be able to define a first party set of origins such that each of those origins can be treated as though they are part of the same app. Currently a PWA must be implemented within a single origin. If a PWA window navigates outside of that window, privacy/security considerations often require the window to show warning UI. This is unnecessary if the developer can configure first party origins. What's particular about PWAs is that it's a common pattern to structure them at subdomains like "app.domain.com" so it would be necessary to include individual origins. Imagine trying to create a PWA that spans app.domain.com, app.domain.co, app.domain.uk, app.domain.fr, and so on. When navigating the PWA window to URLs within first party origins, displaying UI that highlights URLs/origin boundaries would not be necessary and the user can be shown a more seamless, native-like app experience.

krgovind commented 3 years ago

@LuHuangMSFT Could you expand on the warning UI that is displayed? Is it a warning displayed by the browser, or by the destination origin? Or perhaps, were you referring to how a cross-origin navigation inside a PWA can result in the opening of the destination in a Custom Tab?

LuHuangMSFT commented 3 years ago

referring to how a cross-origin navigation inside a PWA can result in the opening of the destination in a Custom Tab?

Yes, that's the example I was thinking about. The Custom Tab solution isn't required by any web spec. so there could be other solutions to make the user aware about cross-origin or out-of-app-scope navigation in PWA windows.

The general problem I would like to solve is to allow the creation of a multi-origin PWA (whether of origins from the same domain or from multiple different domains.) This can be either 1.) implicit: the browser detects a FPS and allows the app window to navigate freely to URLs within the FPS, or 2.) explicitly: the PWA developer specifies multiple origins for the app scope, and the browser must verify that there is a suitable FPS. The origins involved need to validate the relationship for a multi-origin PWA concept to work.

davidben commented 3 years ago

I'm not familiar with the PWA setup, but the latter (explicit) seems preferable to me. If we overload FPS with lots of meanings, we'll weaken privsep. Suppose a site says "from this PWA, origins A, B, C are allowed to do something, but in the context of XSRF protections on this particular resource, I want C, D, E". If those all use FPS implicitly, it would need to contain the union and we'd end up with weaker protections.

More explicit strategies avoid this. And then, where the feature has cross-site tracking implications, a same-site/FPS/whatever check can be layered in addition to what the site declared.

krgovind commented 3 years ago

+1 to what @davidben wrote.

For the case of PWAs, something explicit like scope_extensions would indeed be preferable.

We had a similar discussion about how FPS could apply to cache partitioning, where we concluded that an explicit opt-in is preferable because there are side-channel/security implications.

LuHuangMSFT commented 3 years ago

The scope_extensions proposal as it is currently written relies on the web-app-origin-association format (originally proposed at https://github.com/WICG/pwa-url-handler/blob/main/explainer.md#web-app-origin-association-file) to perform the 2-way handshake between a PWA and an origin. Appreciate any feedback either of you may have for that proposed format since there may be some overlap in functionality with First Party Sets. One discussed usage of scope_extensions is to allow seamless navigation in an app window between participating origins without showing CCT or equivalent UI.