Meeting minutes
👋
Presenting: https://
Can an isolated app iframe other sites? Yes, but all iframes are x-origin (because Isolated Apps are on a private origin)
x-site iframes can do a lot! Would it be an option to reduce capabilities that iframes have? Yes. The goal of ensuring these are x-site iframes is to reduce their capabilities, but we might want even stricter policies.
Another option is to put the iframe in Fenced Frames, has this been considered? A: understanding is fenced frames might be too isolated. The opt in requirement might be a problem here.
w/HTML Sandbox we could apply restrictions to them that are dangerous to the embedder. It might be possible that there are generally useful for the web policy restrictions that we might want to create to restrict iframe behavior.
General feedback: cool approach, fills in a gap where electron+PWA is needed, but cannot have certain capabilities in PWA. This has advantages for developers as they don't need to worry about keep an electron repo up to date, and for users and there is no need for a 3rd electron instance open there is a browser already there and open. Also compatible with how devs build apps, as they probably already have a modular bundler.
Goal for Isolated Apps is that this should not be a radical departure from how a developer builds an app today, offline is handled by bundle rather than SW but SW would be useful for other things like notifications
LG has many applications running from packages so it is relevant for their use cases. Isolated Web Apps might require some platform adaptation, WebOS has it's own manifest and packaging methodology.
A number of platforms have their own ad hoc packaging systems, in current specs packaging is left undefined, part of what we hope to do is define if we were to package into a bundle what would serving rules look like. We want to ensure we're reusing spec wherever possible so for example this will use existing manifest spec (with a few additional fields such as supplying an update URL)
If today devs want to build an electron app or reactive native app, there's no standardization on how that works, it needs to be run in the native framework the developer chose. Whereas if this is implemented by multiple engines the user can choose the application in the browser of their choice
One common extension used by Electron app is the ability to use standard node packages/APIs that are outside the web platform API surface. Don't think we want to standardize on how say, a node environment would work, but we could specify an interface for Isolated Apps to ocmmunicate with native companion code so if the user installed next to native platform code.
One of the progressive enhancements we are discussing including in Isolated App scope is a WebView
These are useful for specific use cases, so having a sandbox environments that could use a WebView might be helpful.
WebView use case examples would be, for example MS Teams, current Teams apps is an electron app, W11 has a WebView2 chat app in it, integration between WebView2 and native code components. PWA can be installed and works in teh web, native app uses web for UI, with native component in a separate process. Web + bolt_ons.
WebView tags are underspecified. WebView CG is discussing the general problems. This is not directly part of Isolated App proposal. However, it would be an environment for them to exist in. It could be a good environment for consensus building in WebView API shape.
Observation: in the beginning of hybrid apps, we saw a mimicking of web APIs and this was never standardized. It would be good to have this standardized.
There is this question about whether this is a path we want most developers to take? And the answer is no. There's an inherent tradeoff. And if anyone doesn't need what this provides: provenance & auditability, then we want developers to land their apps in the browser.
Chrome security recognizes there is a gap in the platform capabilities in app integrity and would like to land more capabilities to support this without requiring packaging
WhatsApp + CloudFlare collaboration : https://
This is an extension based integrity system that provides a similar guarantee, an attested list of resources and validated integrity
The model of looking at security as a progressively enhancing gradient is interesting.
We would be open to approaches that placed a smaller burden on developers if we can get the same security guarantees
Binary transparency is one way to mitigate server compromise circumstances, there are ways this could be handled.
There are a variety of code integrity rules that exist across different platforms today. iOS & Android use review processes, there is also code signing such as what is used on Windows & OS X.
How would we feel if an application wants to bypass the security protections of the isolated app. What if the app uses an iframe or some other way to bypass isolated app security mechanism. A: we cannot mitigate risk of an app that is seeking to compromise it's own security policy. Workarounds exist, for example, could include a JavaScript interpreter and run strings it's fetched over the network.
Penelope's twitter handle: @b1tr0t