TAG review for web app scope_extensions

[diekus]

Hola TAG!

I'm requesting a TAG review of scope-extensions.

This document describes a new scope_extensions manifest member that enables web apps to extend their scope to other origins. This allows sites that control multiple subdomains and top level domains to behave as one contiguous web app and also enables web apps to capture user navigations to sites they are affiliated with.

• Explainer¹ (minimally containing user needs and example code): Scope Extensions explainer
• Specification URL: N/A
• Tests: N/A
• User research: N/A
• Security and Privacy self-review²: url
• GitHub repo (if you prefer feedback filed there): url
• Primary contacts (and their relationship to the specification):
  • Lu Huang, Microsoft
  • Diego Gonzalez, Microsoft
  • Daniel Murphy, Google
• Organization(s)/project(s) driving the specification: Microsoft (Edge)
• Key pieces of existing multi-stakeholder review or discussion of this specification: N/A
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): ChromeStatus entry

Further details:

• [ X ] I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: [please provide]
• The group where the work on this specification is currently being done: WICG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WICG
• Major unresolved issues with or opposition to this specification: N/A
• This work is being funded by: Microsoft

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify [luhuangmsft and diekus]

[alancutter]

The link to the security review needs updating: https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-security-privacy-questionnaire.md

[torgo]

Hi @diekus – Thanks for sending us this. Briefly, we're concerned about the way that this proposal changes the same-origin model, which is a fundamental part of the security apparatus of the web. Hence we think we need to tread very carefully. We think the explainer should be very explicit about what the expanded scope does and does not allow access to. We'd also like to see some specific use cases and discussion of abuse cases (and how those abuse cases are mitigated). E.g. if you are tricked into visiting or downloading a malicious app that is spoofing your bank, and it includes your bank's origin in its scope_extensions field, are there additional exploits that the malicious party could exploit (e.g. obtaining credentials or capturing links)? Are there any implications for access to local storage from different origins?

[LuHuangMSFT]

@torgo Discussed with @diekus and below are our thoughts. I'll organize the important parts and add to the explainer. Thanks for your feedback.

• Storage and permissions models are unaffected by this proposal and should remain so.
• In Chromium, there are 2 behaviors we are working on in the near term that will be able to influenced by scope_extensions. These are essentially UX treatments.
  • Web app windows will not display out-of-scope UI when navigating within extended scope
  • Links to extended scope can cause the app window to launch

To prevent spoofing attacks, the implementation in Chromium will flash the web origin of the content in the window title bar after every top level navigation. The origin information will also be visible in the app's main menu.

If the user is tricked into visiting or installing a malicious app that is spoofing my bank

• they can already do this without scope_extensions
• if the malicious app includes my bank's origin in scope_extensions but my bank does not validate the association, my bank's content will appear with out-of-scope UI, and won't share any storage or permissions regardless. This is no different that if the malicious app simple redirected to my bank's site.

To use scope_extensions, the owner of the app should either also directly own/control the listed origins in scope_extensions or monitor them closely if working by agreement with parties that own them.

Browser security tools such as Microsoft Defender SmartScreen should still identify unsafe origins that are navigated to from the app window.

[ylafon]

Hi, we discussed the issue during our breakout today.
Could there be cryptographic proof that the added origins are agreeing to being embedded in that web app.
Pretty much like Universal Link or App Link?

[LuHuangMSFT]

The apple-app-site-association file used by Universal Links references apps by an appID string of the format <Application Identifier Prefix>.<Bundle Identifier>. [1] I don't see usage of a cryptographic hash. Please correct me here if I'm missing something.

assetlinks.json, used by Android App Links, refers to apps by an app id and SHA256 fingerprints of the app's signing certificate. [2]

Use of a unique app id [3] should be sufficient evidence that the added origins are agreeing to being embedded in that uniquely identified web app. In the scenario where the app is signed or delivered as an immutable package, use of a cryptographic hash would be useful to further specify that the association is only valid when the app is unchanged. Being able to specify that the app remain unchanged doesn't seem like a useful feature for web apps with frequently changing content served through the web.

One scenario we should consider: if the web app is taken over by another party which does not have access to the original signing certificate, they would be unable to modify the app and produce cryptographic evidence matching the original - thus the origin association would become invalid.

The dominant method of delivery of web apps is over the web and managed by a browser without signing or packaging/bundling. Referencing web apps by unique app id is an acceptable solution that doesn't significantly complicate the steps developers need to take to set up the association.

To mitigate app takeover issues (where app ownership changes), we recommend that the web app and associated origins are owned and controlled by the same entity. Failing that, both the app and associated origins are advised to monitor ownership and condition of their counterparty.

[1] https://developer.apple.com/documentation/xcode/supporting-associated-domains
[2] https://developer.android.com/training/app-links/verify-android-applinks#web-assoc
[3] https://github.com/philloooo/pwa-unique-id/blob/main/explainer.md#requirements

[alancutter]

Could there be cryptographic proof that the added origins are agreeing to being embedded in that web app.

Is it sufficient that the added origin explicitly grants the web app permission in a file hosted on the origin served over HTTPS?

[ylafon]

In the case of apps, the verification of app links is done by the store owner, in the case of a web app, you need to have verification done in another way. This is similar to the origin issue in MiniApps Having something hosted on the origin server might work, but it would require network access.

To mitigate app takeover issues (where app ownership changes), we recommend that the web app and associated origins are owned and controlled by the same entity.

controlled in legal term (in which jurisdiction?) or in technical terms (as same hosting)

[LuHuangMSFT]

Controlled in practical terms - as it requires some level of control over the domain to be able to add /.well-known/ configuration. What's an appropriate way to phrase that in spec language?

[ylafon]

Well, the site has to agree that a web app can impersonate its content, so it is more than putting one file and be done (as other web apps could rely on its presence and do the same), there need to be something along the line of what is done in the ACME protocol, or else, in the case of offline web apps, a way to check this offline.

[alancutter]

as other web apps could rely on its presence

The site identifies a particular web app to associate with via the web app's manifest id, other web apps will be excluded by this.

in the case of offline web apps, a way to check this offline.

Does "offline" mean offline at all stages even during installation? A fully offline web app should probably be built as an IWA rather than use any HTTPS.

[torgo]

Hi @LuHuangMSFT - just coming back to this now. I think the risk is not necessarily that https://siteb.com can spoof https://sitea.com, but rather than since https://sitea.com can serve content from https://siteb.com as if it comes from https://sitea.com that content from https://siteb.com can therefore completely hijack https://sitea.com without the user's knowledge. So if that understanding is correct then that breaks the security guarantee for web content. The proposal would need to mitigate against this risk in some way way - for example, scoping this very tightly so that it cannot be abused in this way. We also think the spec needs a privacy review and we would suggest that you request that separately. Also, as Sangwhan mentioned, we remain concerned about the uniqueness of the identifier.

[LuHuangMSFT]

since https://sitea.com/ can serve content from https://siteb.com/ as if it comes from https://sitea.com/ ...

I want to push back against saying that https://sitea.com/ would serve content from https://siteb.com. I would describe it as: both https://sitea.com/ and https://siteb.com/ can be displayed in an app window with the same app window treatment [1]. Either site would have its web contents displayed at the top level. Neither is enclosed in a frame or webview.

[1] In our implementation in Chromium, both https://sitea.com/ and https://siteb.com/ have their origin briefly displayed in the title bar. Also, origin information is clearly displayed in the window options menu. Do these UI treatments sufficiently mitigate the issue that users may be unaware of where the currently viewed content comes from?

There is a question of whether to users, the installed web app (which includes the recognizable app window, taskbar pins, shortcuts, and other assets) is equivalent to the site from which it was installed. If the sitea app is distinct from https://sitea.com, it wouldn't necessarily seem strange to also sometimes display content from https://siteb.com (provided users are sufficiently informed of the origin transition during navigations.)

In the same example, https://sitea.com explicitly says in its web app manifest that when installed, it allows the app window to host content from https://siteb.com. This is also an explicit endorsement of the content of https://siteb.com/ to the user.

What does "hijack" mean in this context? How is the security guarantee for web content broken?

[dmurph]

Voicing support for scope_extensions here from Google. This is a very important use-case for web developers trying to enable app experiences on the web platform, and comes from how organizations often don't use just a single origin for their product.

Feedback from @torgo: I believe this is already scoped very tightly:

• This only affects logic that asks if a given url is "in-scope" of an app. This is done currently in one place - when we choose whether or not to show the toolbar in web apps showing an 'out of scope' origin. Please see how this works with this site - if you install this site in Chrome or Edge, clicking on either of those links will demonstrate this toolbar. With scope extensions, the 'secondary' link will no longer show that toolbar.
• There is a two-way handshake here, demonstrating the ownership of both origins here by the app entity.
• This does NOT show content from one origin on another origin. When opening the url here back in Chrome or Edge, all is correct.

Illustrative example:

• Zoom is at www.zoom.com
• Zoom has an app installed there, the manifest entity is rooted to that origin (start_url / manifest_id are at that origin).
• Zoom also owns all other *.zoom.com subdomains, and each organization gets a subdomain.
• Currently, all zoom links for customers, when opened in the app, show the toolbar.
• This feature allows them to assert they own these subdomains and the manifest entity can consider those "in-scope", and not show that toolbar for their owned subdomains or other origins they own.

Feedback for @cynthia:

• The identifier here is spec'd and comes from the manifest entity of the app.
• This uniquely identifies the app, and the 'origin' part of the identifier MUST match the origin of the document that links to this manifest.
• This means that it is impossible for an app to replicate an identifier for an origin they do not own. For an identifier to be 'https://www.a.com/id', this MUST have been from a document on that origin that has a manifest link (like <link rel="manifest" href="manifest.json" />) to a manifest to create that manifest entity. We can talk more about parsing options here, but the main guarantee here is that origin must match the document origin.
• Thus - it is safe to assume that specifying an identifier here with a given origin means that the app referenced there must be tightly coupled to that origin, and was defined by & linked from a document on that origin.

Hopefully those constraints are enough to make this reasonable?

More abstractly - the feature is communicating & verifying 'what other origins are part of this app', so the user agent can work for the user accordingly.

[torgo]

Hi folks - I think we can best progress this review with a call where we can talk through the proposed use cases a bit more interactively. Given that we have the W3C Advisory Committee meeting coming up, I'd like to suggest that we hold this call in our of our TAG breakouts the week of the 22nd of April. I'll follow up by email to arrange.

[hober]

• This only affects logic that asks if a given url is "in-scope" of an app. This is done currently in one place - when we choose whether or not to show the toolbar in web apps showing an 'out of scope' origin. Please see how this works with this site - if you install this site in Chrome or Edge, clicking on either of those links will demonstrate this toolbar. With scope extensions, the 'secondary' link will no longer show that toolbar.

How relevant is this feature outside of the Chromium project? When I add the example site to the Dock in Safari on macOS, I don't see whatever toolbar you're talking about.

[LuHuangMSFT]

Thank you to all who gave feedback at the breakout session.

I'm pleased we were able to address concerns about storage/cookies/permissions/preferences remaining separate by origin. We can and will call that out more clearly in the explainer.

We will also look into whether the information conveyed through the existing manifest field + web app origin association file can be expressed using feature-restricted URLPattern.

We will do some research on CORS extensions and reply with pros and cons of using this instead of web app origin association. Associated Website Sets is unsuitable as it operates on full domains instead of origins and does not have the primitives to select between different web app IDs on the same domain for association.

I do support the high-level goal of not introducing multiple ways of configuring similar things to the web platforms. I'm ready to consider and do due diligence on any alternative association mechanisms that fulfil our requirements for web apps. I want to reiterate that it seems reasonable to me for a web first app-to-website association format to exist (similar to windows-web-app-link, assetlinks.json, etc.) as app-to-website association has some different requirements from website-to-website association.

[alancutter]

How relevant is this feature outside of the Chromium project? When I add the example site to the Dock in Safari on macOS, I don't see whatever toolbar you're talking about.

UI when navigating out of scope is mentioned in the manifest spec:
https://www.w3.org/TR/appmanifest/#nav-scope

If the application context's active document's URL is not within scope of the application context's processed manifest, the user agent SHOULD show a prominent UI element indicating the URL or at least its origin, including whether it is served over a secure connection. This UI SHOULD differ from any UI used when the URL is within scope of the application context's processed manifest, in order to make it obvious that the user is navigating off scope.

[tomayac]

How relevant is this feature outside of the Chromium project? When I add the example site to the Dock in Safari on macOS, I don't see whatever toolbar you're talking about.

macOS Safari just opens out-of-scope links in the default browser (nice touch!). It's relevant on iOS and iPadOS, where you do see an in-app browser with the Done button in the upper left corner.

[torgo]

Thanks @LuHuangMSFT - let us know when you have updated the explainer and we'll re-review. Much appreciated. I'd like to encourage you to include more info on abuse cases - and mitigations against these. Can you also tighten up the scope to the problem you're trying to solve and explicitly exclude things like permissions, local storage sharing, etc... Can you also please add an "alternatives considered" section of the explainer with some of the alternatives that we discussed in the call?