Amy: what actual additional power does this grant? What happens if a site lies about their urls?

Peter: the manifests scopes down the origin.. and this expands it... doesn't say if it grants access to data of the other origins or not. Doesn't say one way or the other. Does allow you to capture links. You download a malicious app, install it, it declares it's scoped to your bank, it has a link to your bank, displays a url that looks like your bank, and it fishes all your credentials from a login page. It does say your bank has to have an intercept links authorization for that to happen

Dan: where is that configured? THe bank?

Peter: presume that would be in a manifest file for your bank

Amy: as long as that's opt-in..

Peter: maybe not for a random bank, but amazon might use this and say yes intercept links because they're using it within their own domains, so a malicious app could then use it to phish your amazon credentials. It says it's allowing anybody to intercept links, not a specific list of other origins to intercept links. If it's a bidirectional association and both sides have to have installed apps with that association in the manifest, and all it does is allow link capturing and prevent the ui from saying you're going to another site, and doesn't expose any origin information, I could live with this. But there's a bunch of ifs.

• Breakout Rollup
• Issue Triage

Dan: ...same origin.. malicious apps.. exploits? Manifest file that in some ways mirrors the functions of FPS.. but on a web app basis.. we want to be clear about the scope

Yves: basically that. Also wondering why they don't do cryptographic verification of the other origin they want to add in like it's done for some other places. Like what we ask from miniapps. We want to ensure that the other origin that we want to cover allows being embedded in this web app. Nothing there that talks about that.

Dan: given the response could you leave that feedback?

Yves: yes

Dan: it's a good response addressing the issues that we've raised. I don't think we should rely on something like safe browsing modes that are to protect users

Yves: thinking of things like universal links for ios and the equivalent on android which is always the canonical example I use

punts to next week

Dan: they responded..

Yves: the fact that app links are verified by apple to be able to reach the store, and we don't have that here. There is a verification step that you don't see in the end product but that happened by going to the store. So it has to be replaced in another way in the case of a regular web app [leaves feedback]. No response on webkit and mozilla standards positions.

Yves: the fact that app links are using something similar to what is done for letsencrypt - requesting a hash to be put somewhere... different than putting something into .well-known ... verification stage. If you don't have that - the verification - then I think it's dangerous.

Dan: We need to feed back that they need some kind of cryptographic proof...

Yves: it can be many things - cryptographic verification - in that case it's about the manifest... in that case you need to ensure that the verification is done off-line. Or if it's online then you need something similar to what exists in the acme protocol... It's prettty similar to what we have in miniapps...

Yves: their answer is more "how can we do that?"

yves to leave feedback in that regard

Yves: you can do it but only in this case - and look at what acme has done for online use case, look at what miniapp is working on for off-line case.

no response yet

Yves: don't know if they want to circumvent cross domain comms ...

Yves: they want to have the webapp serve things on behalf of other origins. Wondering what is their understanding in ensuring things have to be done through https or with something that has the same properties in order to have powerful features, that might be an issue

Dan: Looks like we haven't received a reply from the proposers. Nudge for an update? There shouldn't be an issue with IWA here

Yves: scope extension to a regular webapp

Dan leaves comment

Yves: i view this as having the same security problem - trusting the origin - as miniapp...

Sangwhan: leaves comment

Max: read this proposal... seems that we asked a question about uniqueness of the identifier -- they gave an answer abnout that...

Yves: it's not clear that IDs can't be spoofed - if it's a hash for example it's potentially fake-able. Also the scope extension is to extend the origin - the URL plus other origins... If the ID is tied to the URL then do they have multiple APP ids? I'll look at that more closely to see how they are doing that... If an app served from site-a,com wants to serve content rom site-b.com, site-b.com must be aware and accepting that... Maybe we could have them on a call?

Dan: I will reach out to Diego...

bumped to 11-march week

Yves: latest response difficult to understand.. their extension extends site A's capabilities to serve things from site B... That's where the problem is.

Matt: one of the questions raised was about uniqueness of IDs for apps - they've pointed to an explainer that talks about unique app ids... after that sangwhan was still concerned about guaranteeing the unique keys... they are claiming there can be a unique ID but there is some question about that.

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.

Dan: no response to our feecback from last week.

Dan: pings Diego

Dan: we analyze LuHuang's comment

Matthew: a couple of things from that and also from Daniel Murphy - "there is a 2 way handshake that is there to ensure that both origins are cooperating." ... also "This does NOT show content from one origin on another origin" They give a concrete example with zoom...

we read through Daniel's zoom example

Yves: does "in scope" mean sharing things like array buffers or even cookies?

Yves: the proposal is not only about subdomains - but about any other domain...

Lu Huang: web app windows do this thing when you navigate outside the scope - or outside the origin - a big warning bar - the warning "you've gone somewhere else" the button "do you want to go back"? Some people say this is not desirable... because the webapp owner also owns the other domain... You can tell your webapp that these origins are also aprt of the app.

Dan Murphy: concrete examples - if you've tried to use slack as an installable webapp - there's always an issue with different origins for multiple orgs...

Tess: i don't think that happens when you add slack to a webapp on the doc in safari in macos....

Dan Murphu: slack may have changed... maybe safar is operating in a different way .. i know safari doesn't show the banner for login pages... when to do out of safari and when to stay in the app... the way that scope is defined needs to be in the same origin no way for it to be visible without

Dan: Embedded content as well?

Lu Huang: to me, it's similar to being not in a webapp window just in a browswer window... you navigate to another site and no alarm bells go off. For the implementation in chromium we show the user the (new) orgiin and also have security & origin info in the main menu in the webapp window... In this issue what

Lu Huang: iframes would work exactly the same way - everything we're talking about here is top level navigation... even then when you navitage to the new site it doesn't inheret any preferences...

Matthew: slightly related: we've been having conversations about heuristics ... might be something in relation to that...

Dan Murphy: there's product and then web platform... if there's a navigate=self link that navigates to the current document... this feature is all about the primary browsing context... the web content is in this other frame... Worst case scenario might be: a link in mastodon... there's a link in that page to another origin and it's a navigate=self link... user clicks on that, it goes to a different origin,... worst case scenario is .. mastodon.com origin says x.com is part of me, x.com says mastocon.com is part of me... In that case no notification would show...

Yves: what is the implication of considering that the application encompass other scope? sharing data between different.

Lu Huang: no tha's not part of the proposal...

Peter: is that always going to be clear to the user? I start out on one site and I move to another site that is related? Is that going to be clear to the user? Even if that's not the intent then we have a concern that someone will try to

Dan Murphy: the requirement for this feature is establishing an edge on a graph of origins - in a way that is safe... the feature needs that so we don't show the security boundary...

Peter: if you navigate to another origin and it's not displaying a URL bar...

Lu Huang: usually a clear origin that is asking for microphone or location permission... The UI should always make it clear. That's a reasonable thing to recommend in spec language. Also a way for the user to look up where am I...

Dan: Murphy - we can say "this is not an extentison of storage, or permission" ..

Peter: still concerned - the permissions case - most users don't understand the concept of origin so we need to be careful how we expose... maybe we should double-key these permissions...

Lea: reading the goals it reminded me of first party sets, related website sets...

Lu Huang: it's been suggested we look at that but related website sets does too much - has security implications we don't want. It works at the domain level. We can't use it to put together a set of subdomains.. For this set we have tried to not change assumptions aboue security, permissions, storage... not changing the model at all. Strictly talking about webapp features... The one effect we're talking about ... just the UI around the cct - custom tab bar - warns you that you're out of scope... Maybe there reasonable other webapp features to add to this...

Lea: my concern is that we don't want a bunch of differen to APIs to declare the same intent... should only declare this once... should not have to scatter this through multiple different APIs...

Dan Murphy: this is constructed for "manifest entities" a manifest isn't a whole origin it's often a subset of an origin... Really it's just a message to the user agent... file handlers is an example of a feautre added to manifest... I agree it's annoying that there are too many concepts. This one is specific to manifest files... tied to a specific app... ID that is specified there... In terms of furture APIs ... don't see any APIs that it makes sense for.. Chrome may have wanted to ehhance the user experienced based on this manifest entity...

Lea: once this ships if it enables certain permissions... scope has a certain meaning... Concerned about the increase in API sufrace area for declaring similar things.

Yves: if you have different origins

Lea: looks like this also specifies domains but also specifies subdomains as well?

Lu Huang: right now the entries are origins... we want it to be able to support more specific path filtering... we don't know what the right syntax is... URLpattern is supposed to solve that. but does it translate well to native for differnt to operating systems? Does it translate to OS specific registrations. We split it into two problems..

Lea: right now all the examples related to URLs... is there an example that shows an OS specific scope?

Lu Huang: as it stands web app scope is single origin and some path with the single origin.. if we make webapp scope more complicated then it's whether you can translate it to things you care about in operating systems... future concerns... that's why we didn't include a filtering syntax...

Lea: but wildcards are such a syntax.. if anything it seems to me that example under number 1 that could be a single URL pattern...

Yves: in service worker the patterns are similar for performance reasons...

Lea: we don't want multiple related patterns... different microsyntaxes for URL patterns...

Lu Huang: good point..

Dan Murphy: no way to parse that syntax right now .. our feedback was to make a separate entry for eTLD+1... happy to have other ways... it should be parsable by spec... simplest way to do what our partners need...

Lea: if the pattern is that URLpattern is more broad... you could just say that's it's a URLpattern with only host or only origin keyword... you can define that pattern as a hostname pattern...

Lu Huang: the examples are meant to be origins... the scheme is assumed to be https given that webapps only care about https urls... even if we set the same limitations - should only be an origin - we can still express that in terms of URLpattern...

Lea: yes because users can learn that only once... my cocnerns are (a) the patterns and (b) yet another API to

Dan: developer complexity

Lea: for smaller teams if you have to maintain a list of domains in different places... concerned about keeping those in scope...

Dan: other than fps ... related web sites .. is there anything else?

Lea: maybe a a CORS extentension? actual intent authors are trying to express ... how does this web site relate to other origins.. can they navigate, install, etc...

Lu Huang: CORS extension has not come up... I wonder how it would make a relationship between an APP ID and an origin... scope extensions can be split into 2 parts... what you do with it and what the webapp manifest says... not married to a brand new association format, but of the things we looked at there wasn't one that satisfied our requirements... we can have this without being fixed on one things...

Lea: this seems to keep coming up so maybe work with the first party sets people....

Dan: webapp manifest files vs. http headers

Lu Huang: I think the maifest is the right surface to have that... I think our discussion ... for those origins to confirm they want to take part in this... do they want a .well-known config file... cors header... the related website thing doesn't work... heavy burden... you have to apply to get your configurations...

Lea: i think the permissions should be explicit... Right now as someone reading the manifest ... unclear what these permissions are... can they change... what if the API made this explicit... these origins share these types of permissions...

Lu Huang: tagging syntax... can we also add tags there... the syntax is extensible...

Dan Murphy: I think we want to be ware of permission grant... my interpretation of the feature is that this tells UAs about a feature.. but could also be useful for install...

Dan: just noting the feedback from Lu Huang - they are going to do an update on the explainer... lookling at cors, looking at URL patterns...

Matthew: interesting difference in opinion of the spec between this group and what Apple /webkit has done.

Dan: the use case itself is clearly cross platform...

Dan: I think at this point we're waiting for an update to the explainer...

Matthew: one other thing I noticed - i don't think they have an "alternatives considered". so they maybe should add one.

sent

• explainer has updated

We're waiting for an update on the explainer, no activity yet.

Dan: They updated their explainer - considering that they have been responsive to the review comments I'm pretty positive...

Martin: do they need the ability to take an entire registerable domain?

Yves: there is a scope in it that is the path ....

Martin: it looks like a scope and scope extensions ... "the following origins are also included" - does that mean just /app under those domains or anything else in that domain... that's unclear to me. Does it meaan that if you want to extend your scope to another origin then you have to follow the same path construction rules?

Yves: weird if you want to import some images ...

Martin: i think this is for the top level navigations... you'd stay with the idea that you are in a particular app in the case that you navigate to another origin... Any subresouces on a top level page would be fine... This is all about navigation.. if there's a link in the page that takes you to another origin do you take them "to the browser" or within in the app.

Dan: i think the main point is to not show a warning ... if navigating to another origin within an app

Yves: linked to caching?

Martin: it shouldn't be - it's "im in an app - and i navigate to another site... "

Martin: another question - the external website doesn't have much of a say of how much the "app" is able to use of it... say you have a payment flow that uses a payment provider... the payment provider stays in app.. but if you've nominated the entire origin - say the payment's provider's home page - might stay in the app which could break the user experience...

Dan: e.g. you're in a payment flow and then you want to view the privacy policy of that payment provider...

Martin: the external web site might want to be able to say "this app can use the following URLs ... otherwise jump out and it's no longer in the app" there's a discussion in the explainer about authorizing with an association file - it only associates with an origin - and doesn't recognize the idea of multiple app...

Yves: in the explainer it's in "future extensions"... so maybe the comment should be that this shouldn't be a future example

Martin: We have a scope parameter on the manifest in the first place... It might be a set of prefixes.

Yves: needs to be in sync with what is done with service worker...

Martin: path prefix thing with a pattern...

Yves: planned as a future extention but we are discussing doing it now...

Dan: looks like a productive discussion... Martin needs to be involved in moving this forward...

Martin: feedback was let the web site in the scope have something to say about it... they wanted to do this on an origin-wide basis... Idea is that you have a webapp that includes stuff from outside the origin of that webapp - so the webapp declares please include this other stuff in my scope. The request from the feedback we gave is to give the other origin fine-grained control of what resources are in the app vs. not in the app... Reilly suggests a "CORS" mechanism - and trust but verify... Potentially too late at the point you've started to make requests though...

Martin: opt-in suggested in original explainer - at the target origin you would host a resource that says "these apps are ok on this site for all origins"...

Dan: a new type of resource that would be at a well-known location...

Martin: It's a reasonable thing to be able to do... Reilly is suggesting that the manifest sets the scope and that when you navigate, that navigation request uses a cors-like protocol that says "the following app has asked me to navigate to this resource" then the resource itself says "ok" (in a header). Don't know if it's reasonable to do this in the navigation and loading algs...

Martin: a file can be relatively straightforward...

Dan: https://example.co.uk/.well-known/web-app-origin-association (from explainer)

Dan: can we leave feedback to the tune of

Hi @LuHuangMSFT - as noted we are fine with the user need and we are generally fine with the design. @reillyeon has suggested a CORS or CORS-like approach. Whilst that has some advantages (in particular, not requiring a new well-known located file) it also has the disadvantage of requiring complex server configuration. Our main concern stands, however, that the Association file should allow for more specifying resources in a more fine-grained way. This could include wildcards to make it easy to create a very permissive Association file, but it should be possible to lock down the resources that are OK to share. Would you be OK with modifying the design to allow for such an approach? If so, we're happy to close this review as satisfied.

Matthew: urlpattern as also brought up

Martin: I think it's a secondary issue...

some discussion on install cross-origin

Dan: Leaves comment

Dan: I reached out to Diego to ask him to help clarify whether 👍 means "yes" to our proposal. If so, I suggest we close this as satisfied at the plenary.

No progress to report.

Martin: this was an early design review - they are going off and updating the spec. I think our involvement should end. We should ask them "when you're done, come back."

Dan: sounds reasonable to me.

Martin: because it's an early review...

Closed as "validated"