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.

[LuHuangMSFT]

@martinthomson
I have updated the explainer [1] significantly to incorporate feedback and move the contentious portion involving the header design out of scope (this portion will be rewritten as a new, additional explainer).

Could we re-open this review?

[1] https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-explainer.md

[ylafon]

We discussed this during our last teleconference, and we are closing it with concerns,
Those concerns are about UX and security where we would like to see a review from SING who are more qualified to give proper feedback.
Thanks for having incorporated TAG's feedback.

[HowardWolosky]

Thanks to all of you for your time, diligence and feedback with this review. We'll look into getting a SHIN review started soon.