Dan: talks through discussion on Isolated webapps. push notification on IOS requiring installation

Peter: installing to homescreen vs. saving a bookmark.. distinction of a user opt-in...

Dan: we could document that as a pattern that makes sense...

Peter: given such a model there are other things we can turn off by default...

Peter: in their explainer they talk about prior art - firefoxos - signed archive... would be nice if there were signed in some way... Bundling and signed exchanges may not be the answer but there are other mechansisms... that people don't usually buy into.. Subresrouce integrity...

Dan: Related to more powerful APIs.

Sangwhan: I have context. This effort is driven by needs of ChromeOS. PWAs are good but from an app vendor perspective not good enough. There to fill the gap. But we need some level of alignment from different browser vendors. Related to Electron, etc... Clear business need from different operating systems. If there was parity compared to native apps. Potential to have more adoption. Even with the risk of bring too powerful. We have to balance this well. The PWA rollout has been fairly sueccessful but there are gaps. Like you can't have Netflix offline on a PWA. The WICG way of doing this would be one way. The middle ground could be an icubation chamber. Without being able to buld an experimental applicatiomn you can't do much... This effort would have merrit in that regard. But I want to have one other browser interested in this. It could be powerful for the future of the web.

discussion of a potential task force on powerful webapps

Dan: could we develop a model that has multi-stakeholder buy-in?

Sangwhan: we could have a model for isolated webapps that could be stricter - like communicating with only one origin. The user has opted into a particular constraint - via installation... A trade-off could be "you get all this power but you lose a bunch of capabilities." A new, fundamentally different thing for powerful APIs...

Dan: also related to packaging and bundling...

Sangewhan: in some cases you can't have cross-origin communicaiton functionality and powerful functionality at the same tine... I feel like if you get both superpowers in one package... people could abuse...

Dan: A new permissions model?

Sangwhan: is installation an implicit grant for a set of permissions? That's not well defined. When it comes to installation, how the permission model should work would be different. We should have a different model for weak permissions -- in the web every permission is equal. There's an upside of having in-context permission requests - but if you have too many permission requests in an installed app then that doesn't work. Tiered permission?

Sangwhan: this issue is focused on ChromeOS business needs. I'll review - standard type review - but also expanding...

Amy: this is a dependency for Borderless mode.

Hadley: borderless mode is google only, no signal of interest from other browser vendors. Doesn't make sense outside of that context

Lea: don't know enough about CSP to evaluate the API.. The use case does seem motivating. Woudl love to add more features that discourage people from moving things to electron apps. People still feel they need native apps, I wish we could reduce that need. Whether this is reducing the need in a good way, not sure if I can evaluate that.

Hadley: packaging and bundling?

Lea: do you have to install it?

Peter: seems like they're leaving that as a problem for other people. Don't see the mechanism for how you sign... can sign the web app in its entirety, not a bundle of resources, but where is the signature, how it's controlled, how it's distributed... seems to be missing from the explainer.

Max: should have some description from the user experience perspective

Lea: goal of having apps that have powerful APIs make sense... lots of use cases for these powerful APIs.. a model like this could make access to these APIs a possibility. Right now if you want to have an editor .. you have to store files in the cloud... The model where a webapp opens files and saves is not possibile. People need to trust cloud servers with their data. Also motivates people to move away from the web platform because native apps can do this trivially. So I think it's important ... to make these types of things secure for web apps. Maybe something like this could be that mechanism but these kinds of use cases should be taken into account. Not 5 different installation mechanims ...

Dan: +1

Hadley: +1

Hadley: related work part of the explainer - they've said there's other stuff going on but it's different.

Lea: it's missing comparison to related work.

Hadley: good topic for a workshop or for a task force.

Dan: how does this relate to pwes? can look at in the browser, also has manifest, and can save to home screen, may have service worker etc. This feels like another step beyond that? Rather than something orthogonal. Regular web app, PWA with these aspects, then Isolated Web App which is like a PWA but with even more restrictions.. both using web app manifest. But there's no wording in the explainer to indicate that there's any relationship to all of the prior art on PWAs. That is bothersome. Are they thinking about what's gone before?

Hadley: chrome status says it's an extension on existing work on pwas that provides other protections against server tampering... presumably take over from PWAs?

Dan: they don't use the words desktop or mobile anywhere in the explainer. They need to be explicit about the types of user experiences they're trying to enable. Is this purely about editor applications on chromeos that need access to local filesystem? Or is this about something I could potentially encounter as an end user. Like i really want a video editing application provided by vimeo that I install in the same way I would have installed a PWA but now it's got these extra characteristics that allows me to read and write files off my local file system?

Peter: what concerns me is their non-goals, which seems to exclude that

Hadley: should not be considered desriable for most web based applications... why not? why aren't we aiming for that?

Lea: user experience must be impacted in some way that means the tradeoff is only worth it for certain security-sensitive applications. But they're not describing the user experience, so we have no way to evaluate that tradeoff ourselves

Peter: I'd like to see an upgrade path from an installed pwa to an installed web app. Seems like they're not thinking that, but more like a replacement for electron, installed completely outside the web.. though uit's updated through the web (somehow).

Dan: we shouldn't be promoting the elctron model of downloading an application and installing it, but yet it's a web application. I have 5 different web runtimes on my computer right now.

Lea: since chrome status mentions it's part of a separate app installation mechanism... I guess it doesn't present an app installation mechanism, that's separate?

Peter: are we saying we think it should?

Lea: have we reviewed pwa web packaging work that they allude to?

Peter: they link to web bundles..

Dan: it's not the same as bundling, pwa installation is basically a bookmark. But on android there's webapk, which bundles up that bookmark with a signature provided by the Play Store that enables it to have additional access to resources or capabilities, and operate more like a native app on android. There's no equivalent on iOS. Web bundles stuff I thought we'd just heard they're moving away from.

Peter: also assumes signed web bundles. I don't see any spec for that. Curious why they don't do something more like a lock file that package managers use. Then the bundle could be optional.

Lea: I'd like to see some use cases that do not involve end to end encryption and messaging. If all the use cases considered are the same thing, there's a higher concern that this api may be overfitting.

Hi @reillyeon,

We looked at this today during our plenary call. First, we do agree that the use cases should be possible to address within the Web Platform itself, but do have some concerns:

1. We are unclear on how this compares to some of the related work on this topic (a lot of which is also listed in the explainer). Given that the use cases presented are all different brands of the same use case (end-to-end encryption for instant messaging) we are a bit concerned about the solution being overfitted to very specific use cases, and having to be redesigned later, as more diverse use cases emerge.

Given that this presents an app installation mechanism, we think it's important for it more broadly take the use cases for app installation into account (e.g. installation as a more explicit indication that certain very powerful APIs should be available, where a permissions prompt or user activation is not a sufficient signal). We don't want the Web Platform to end up with several different installation mechanisms.

2. The explainer mentions signed web bundles, but there is no reference to how signed web bundles would work. Is that in scope for this work? Is it defined somewhere else? How do developers sign these?

3. We are unclear on what the user experience looks like from the end-user’s point of view. You mention that this is not a desirable model for most web applications, which implies that the user experience is impacted in some way that makes the trade-off only worth it in security-sensitive applications, but there is no description of what this user experience looks like.

4. What’s the upgrade path from a PWA of today into an Isolated Web App?

5. We are concerned about the lack of multistakeholder support. Looking at the Chrome Status entry, there are no signals from any other stakeholder, not even web developers. If this is going to be a thing we think it's really important to get other stakeholders involved. A W3C workshop or a TAG task force might be an appropriate mechanism to achieve multistakeholder support and to bring in existing related work.

6. We want to note that Borderless mode has a dependency on this work. We are concerned about going ahead with that before these packaged and signed apps are consensus-based and more stable.

Thank you for working with us, and we look forward to your thoughts.

Lea: we have looked at it and replied to them...

Matthew: mentioned in the feedback from them is the tradeoff between making IWAs deep linkable... something related to miniapps having solved this?

Lea: we got feedback. Not sure what they mean by IWAs are not deep linkable and ephemeral... because you're downloading an app you don't get automatic updates? Presumably internal links would work fine?

Yves: talking back to the origin - in that case having the webapp serving things locally and perhaps invented a kind of fake origin when it's installed or something like that? That would be definitely bad because you wont' have a proper verified origin and it can be an issue for the security model - repeating what happened for miniapps.

Lea: does that mean these apps cannot talk, send requests to remote server?

Yves: possibly. Not clear.

Lea: should be clear.. regular apps, native apps, do have that capability. Seems like a weird restriction. Especially if users go through this whole thing of downloading the app

Yves: they want to have apps installed to bypass some of the security rules that regular webapps have. I don't know what other limitation they want to circumvent.. filesystem accesss? webusb? In that case should they be allowed to do whatever they want?

Lea: even native apps have to ask for permissions. I'm not sure if the reason this is happening is so the user demonstrates enough intent. I don't understand why they'd go through this whole process of downloading the web bundle and installing it, as long as the UX makes it clear that's what you're doing. More relevant.. They should clarify what they mean by deeplinking doesn't work.

Dan: Why do they need to do this? if this is like a native app then why not make it a native app? Why do isolated web apps need to be web apps, if they're downloaded and installed separately and run in a separte instance and nto linkable and have different security characteristics from the rest of the web... maybe they're not the web. Why do we need isolated web apps?

Lea: the web is many things. The web includes the origin modle, but is also a set of technologies that many people find very convenient. I do think this set of technologies is.. open, not proprietary, most technologies for native apps are tied to a specific organisation. I don't think there is anything that is as convenient as the web for developers and is not proprietary. There are frameworks that let you use web technologies to transpile to native... but I don't think that should be necessary. We should not need electron, it's a workaround because of the lack in the web platform.

Dan: is that the intention? Is it a standardisation of the model that electron has? In which case that's a lot more understandable. We also discussed that as a motivating use cases for the powerful apis idea that we talked about in the breakout at tpac.

Lea: I think it's part of it. I don't think they're trying to cover all of the use cases. We should definitely ask them to clarify. Do we want to see the web's origin model as intrinsically part of the web platform?

Dan: that's the feedback we gave to miniapps. They were using web technologies but without the security guarantees.

Lea: if it is identical to a native app then whether it uses web technologies is an implementation detail

Yves: depends where it is served from

Lea: it's installed locally

Peter: I think IWAs still have a lot of the web security model, still have an origin.. CSPs, cross origin is being applied..

Lea: so it's more secure than a native app. And the UX is similar so users know what they're getting into? One thing is that users don't have permission to install applications into certain environments, would it bypass that?

Peter: weird that it has all these extra security restrictions, but enables direct network sockets which bypasses everything. Is it more locked down or not?

Dan: I think they'd say by putting all those other security structures in place they make it less possible to abuse the things they want to open up further? Like more powerful network apis.

Peter: but if I can open up a raw tcp connection to anything then origin restrictions are irrelevent. [...]

Lea: that is weird. I don't think should be prevented. I think part of the issue here is they're framing it as installable web applications but there's this extra security thing.. but I'm not sure what they're protecting you against..

Peter: they're adding all this extra security, then opening up the world at the same time

Lea: yes, it's weird

Hello there,

Thank you for responding to our questions, and apologies for taking so long to respond.

This means that IWAs aren't the deep-linkable and ephemeral experiences that a normal web app is, which is an unfortunate but I believe necessary tradeoff.

Could you please elaborate on this? What is not possible compared to a normal web app?

Chrome is still exploring what the user experience will look like

We think that’s an important piece of the puzzle. Perhaps since it's been a while since that comments, there is some evolution

Peter: We were concerned about WebSockets being allowed.

Reilly: We worked with Chrome security team. There are some apps that use non-web transports. We are trying to create an environment were the author's original code and intent is present, but alos granting access to facilities that some devs need.

... One need, as noted in the Explainer, is e2e encrypted messaging. Also applications that are completely offline. Such apps can declare all of their code, and the browser could verify. We need to allow access to these capabilities in some occasions, but in exchange the app has to adaopt a stronger security posture.

Peter: Helps to understand the use cases. Still have concerns. CSP would stop you from downloading scripts from other origins perhaps unintentionally. Doesn't stop you from connecting to anywhere else with raw sockets. Still some danger here, despte the CSP.

Reilly: There are some parts of this that depend on some kind of external vetting of applications that would allow browser vendors, or third-party auditors, to check that the application isn't doing something that intentionally subverts the protections. The goal is to force you to make it obvious that you're subverting the protections. A systme that looks at web content and detects malicious patterns could work here, as the app is more restricted.

Peter: The assurance that someone has audited the code tends not to work in the wild.

Martin: Who's signing this?

Reilly: The explainer doesn't go into some of how this could be deployed more broadly. The current prototype only includes signatures from the origin. The design is extenisble in that you could add additional signatures from an additional trusted party that would make those kinds of assertions about the checks they've done on the app.

Martin: Signatures don't provide the property of non-repudiation. If you have a chunk of code signed by your origin and you wish to disavow that fact, that's relatively straightforward to do. Signatures provide you with existential unforgeability. For a given key, you can show the content was produced under that key, but someone else could take a different key and make an assertion about the code. This does not seem to provide the desired protections.

Martin: This problem has come up before... https://dennis-jackson.uk/assets/pdfs/signatures.pdf covers some of these challenges.

Reilly: We were wondering if we could link these to DNS origins - that raised additional processes around ownership and longevity. Not sure how these concerns apply in this situation.

Peter: How would I check?

Reilly: Most browser extension systems I'm aware of use a key that represents the identity of the app across updates. The browser does the hash comparisons for you.

Peter: That would cover an update scenario, but if I get App B from Source A, this may not help. What happens if a key gets owned? Can I tell that these two apps came from the same person? We don't necessarily have to dive into all the edge cases, but we're trying to understand the broader scope here.

Reilly: There's an implementation question around the signatures. How do you do transparent updates. Good discussion in WebAppSec at TPAC around e2e messaging and binary transparency for web apps which delves into the same problem. You'd need to include a set of CSP protections. If you can load in cross-origin scripts, you don't have binary transparency anymore.

... The more interesting question to explore is: is the idea of trying to construct this environment that gives you these integrity properties (we can noodle on what they are) - is that something we want to tackle as web standards organization, rather than at the browser level.

Martin: Key question is what sort of protections are essential here - what level of assurance must we have to be able to e.g. trust the code to read our password file. Not sure these are articulated clearly in your proposal so far. I don't quite understand what you think helps you achieve that goal. Would be helpful to lay out those preconditions. I would also like to see that it's possible to achieve them; understanding them is the key.

Reilly: There's a strong correlation between the preconditions necessary for e2e messaging apps and our use cases here. The proof of that may not be immediately obvious, but the use cases are helpful, and may have consensus.

Martin: I think there are differences with the requirements to e2e messaging and the capabilities extension we worked on for this. Relies on having a way to deploy code that can't be individually targeted at people. The app you're running has to be the same as everyone else. That's a productive line of discussion (and we are pursuing it). If that's one of the preconditions we need here, this could be a good approach.

Reilly: That is the primary precondition. Looking at the platforms that provide these capabilities. Legacy native platforms have no controls. Modern native platforms are moving to app stores. With the app store model, someone is checking the app and determining it's not malware. In the legacy model, a virus scanner does this after the fact. In the modern, the app is checked before it's deployed. In the browser, we have extensions, which go through a similar review process. In Chrome, we extended the extensions platform into this app platform, which shares its security properties.

... The core properties are like those that apply to the extension framework. Properties to protect devs from themselves (e.g. CSP) and the capabilities to look at code before it goes to somoen's machine and check it's not malicious.

Martin: You're not including anything here that would suggest there's independent review.

Reilly: IIRC distribution methods in the Explainer is vague, but imples there could be a review process - I could make that clearer.

... Back to comparison with e2e messaging. That guarantee that code running on one user's machine is the same as on another's enables you to have that kind of review.

Martin: That's necessary, but not sufficient. If it's a WASM blob, which a lot of these apps end up being, the abiltiy to audit that, and understand the ways it can access the network is limited.

Reilly: I wouldn't disagree with that.

... An additional property that's useful in e2e messaging is in the reputational problem (e.g. app name can be faked) - being able to tie the app to the developer can help with copycat issues. This can't let you audit obfuscated code, but if a dev hides something malicious, their reputation would commensurately suffer, and be conveyed to users.

Martin: If your core capability is direct socket access, I don't think this is appropriate. At the moment we can guarantee that everyone has the same code that could be used to attack a network within which the browser is deployed.

Reilly: One place where we've seen a need for this bag of dangerous capabilities is any kind of desktop remoting. VDI apps deployed in enterprise situations, and others. A web-focused example of where this class of application needs something we'd never deploy on the web platform is WebAuthn. If you're remoting into a system, then using a browser, you can't remote the passkey exchange. This is bad news for remote desktop operators. One of the APIs we've been looking at for this environment is WebAuthn for remote clients. If you have a sufficiently trusted client (everyone's running it, and someone's looked at it and is happy with it) then you give it the capability to pass through the credentials. This is a feature that is provided on native remote desktop solutions.

... One school of thought is that "remote desktop apps can be left to native apps" - I think we can do better.

Peter: We could just not do direct socket access. When we first reviewed this, the primary case was IMAP. We responded "why not just build an IMAP API?" (and then same in other areas).

... How can we explain what the app is doing, to the user? Can we make a permissions prompt they could understand? A prompt like "I'd like to talk to your mail server" rather than opening up the whole world.

Reilly: This is why I like the WebAuthn example. If we had an extension to the API to allow remote tunelling, what requirements would we place on web apps that use it?

Peter: But if you devise a specific API, users have more control over these decisions.

Reilly: It's a good idea to concentrate on concrete examples. Is some kind of permission prompt that indicates you're doing more than a normal WebAuthn transaction good enough, or would you like some extra security restrictions on the app?

Peter: I get that these are not independent issues. There is such a thing as permissions prompt fatigue. But we don't necessarily have to open the doors to everything, keeing things fairly well sandboxed.

Reilly: Some of these capabilities are in the "we don't really know how to explain this to the user" camp. In cases like WebAuthn and e2e messaging, we need extra assurances to communicate to users.

... Part of the proposal includes this permissions-based system. For normal web content, policies are allowed by default, and web sites/apps can decline. In this approach, apps have to decleare which permissions they could possibly request. Anti-footgun mechanism for devs. Makes it easier for people looking at the code to understand the blast radius of the app.

... It doesn't automatically get everything becuase it has these properties.

Peter: There are apps (e.g. on native) that do just ask for everything at install time. Some devs don't play nice.

Reilly: Permissions policy isn't requesting at install time. It's saying what the app might request.

... This is why there's been a move away from asking at install time.

Peter: Though devs may still say they might ask for X in future, so they'll ask for it now.

Reilly: This would cause extra scrutiny at auditing time.

Peter: This feels a lot like MiniApps.

Reilly: Yes.

Peter: Wondering about the boundary between what's a MiniApp and what's a WebApp.

Tess: Is there an attempt to converge the two?

Reilly: I'd like to converge things. I'm concerned that the MiniApp proposal is throwing a whole bunch of new technologies into the web stack - our approach is trying to add as little as possible. Convergence would be good though.

Peter: Question TH Lea. What's the difference from the user's perspective between an installed PWA and an IWA? Difference between a web app that's added to the home screen, and something that's been installed fully trusted.

Reilly: The requirement that these be installed comes from a couple of directions. Building the trust relationship requires a well-defined install event. Also desire to have them behave more like native apps. We're leaning on the idea of install as the point at which you express trust in the app because you've installed it. Users have different expectations between something they explicitly install vs something they get from any web site.

... What will user expectations be like in 10yrs from now, when users experience more apps as web installed apps, and native apps are less special? I don't have an answer to that.

Peter: Could this lead to a PWA that's been installed getting access to more things than a PWA that hasn't? This seems like a way to cross that bridge, but it's not clear that there's a path from one state to the other, nor that it's clear to the user.

Reilly: Now this has some technical teeth to the trustworthiness, but does the user understand that transition? Open question. Also it depends what the installation process looks like to a user. Today's PWA install process is seamless in Chrome. Shows off the fact that nothing changed. If you install a web app distributed via the Play store, this is a very different thing from the user's perspective, even if the web app is the same.

... We've explicitly chosen not to make it super-easy to install these things from their publisher's web site, and make it obvious that you're really installing something. We don't want the web experience, that is far less of a trust decision.

Martin: Thanks for giving us all these details; very helpful.

Peter: +1 helpful to understand the developers' thoughts

Discussed https://cryptpad.w3ctag.org/code/#/2/code/edit/6L3cfzmBjZv5tKRRkwV4k-ll/

Discussion about whether to close the issue and whether the advice here, which seems final is indeed so. Resolution was to provide the feedback, but leave the issue open to give the proponents a chance to respond.

Still pending external feedback. Have been waiting for 4 months.