WICG / isolated-web-apps

Repository for explainers and other documents related to the Isolated Web Apps proposal.
Other
173 stars 12 forks source link

Question: Can security constraints be loosened such that a IWA is basically like a "navigate-to" Web Bundle? #15

Closed josephrocca closed 1 year ago

josephrocca commented 1 year ago

I was looking forward to the "navigation to" Web Bundles paradigm as a kind of "exe" format for the web - portable, offline-friendly applications bundled into a single file. Using file:// to run a bundled HTML file is not a great solution because of limit that need to be placed on file://-served HTML files.

Recently it seems that Chrome has decided not to ship Web Bundles that can be navigated to - in favor of Isolated Web Apps.

I'm looking forward to Isolated Web Apps, but IIUC, they are for very "locked down" apps only. This is an important and exciting use case, but I'm really hoping that there is a way to use web bundles for "regular" apps as was originally envisioned with "navigate to" Web Bundles.

So, TL;DR is in the title of this issue - I'm wondering if it's possible to loosen IWA security constraints, and if so, how close can we get to a "regular" website, except served "from the bundle" instead of served from a server?

reillyeon commented 1 year ago

I'm not too familiar with exactly how navigation to Web Bundles was intended to work but I think it would suffer from similar issues to file:// URLs because these don't have any kind of persistent identity. This is something IWAs solve by being served from a Signed Web Bundle that is identified by its primary signing key.

I'm curious which security constraints you'd like to see relaxed for your application. For offline-friendly applications the CSP requirements seem reasonable since you wouldn't want to load code from a remote server in an offline app anyways.

josephrocca commented 1 year ago

Thanks for your reply!

I think it would suffer from similar issues to file:// URLs because these don't have any kind of persistent identity

I don't have a lot of knowledge here either, but my (very possibly incorrect) understanding was that each Web Bundle comes with a "primary URL" hard-coded that could be used for persistent identity. But if I'm misunderstanding, please disregard the comparison to Web Bundles - I might have incorrectly assumed that it had advantages over a simple index.html served via file:// - more than just grouping resources into the same file, I mean.

I'm curious which security constraints you'd like to see relaxed for your application.

I also don't know enough about IWAs to know which constraints would need relaxing, but in my particular case the user needs to be able to load community "plugins" which must be able to make network requests, load e.g. images in their markdown from arbitrary origins, and stuff like that. Note offline-friendly != offline-only, but to be clear a key thing I'm looking for in Web Bundles is portability. Like a "safe exe" (safe in the same way that visiting a random website is "safe", I mean), or like (the golden age of) flash game swfs, in a way.


Also, separately, I have needs on the other end of the spectrum too - so I guess the theme here is customizable constraints - different applications will have different needs. But for my purposes in this specific issue, all I really need is a "fully-bundled index.html" type file with same abilities as a normal web page (i.e. not limited by file:// issues).

reillyeon commented 1 year ago

I also don't know enough about IWAs to know which constraints would need relaxing, but in my particular case the user needs to be able to load community "plugins" which must be able to make network requests, load e.g. images in their markdown from arbitrary origins, and stuff like that. Note offline-friendly != offline-only, but to be clear a key thing I'm looking for in Web Bundles is portability. Like a "safe exe" (safe in the same way that visiting a random website is "safe", I mean), or like (the golden age of) flash game swfs, in a way.

The CSP rules allow external content to be loaded in iframes. The intention of the policy is just to keep that content sandboxed from the bundled content, since it is less trustworthy.

josephrocca commented 1 year ago

@reillyeon Ah, this might work then. It's still possible for the main frame to communicate with the iframe, though, right? E.g. if it's a app like this where the user can paste a URL to load an ML model from a remote server like Hugging Face - then I would do the actual download from within an iframe and then send it to the main thread via a transferable stream or something like that?

reillyeon commented 1 year ago

@reillyeon Ah, this might work then. It's still possible for the main frame to communicate with the iframe, though, right? E.g. if it's a app like this where the user can paste a URL to load an ML model from a remote server like Hugging Face - then I would do the actual download from within an iframe and then send it to the main thread via a transferable stream or something like that?

If you are loading a data file like a model you can do that with a call to fetch() from directly within the app. The iframe restriction is for loading HTML/CSS/JS since that is considered "executable". The intent being to protect you from loading a malicious script that would have access to your app's data.

josephrocca commented 1 year ago

Oh, then this sounds like it's exactly what I'm looking for - a portable, safe "exe" type file where people can just bundle up a html file with some resources, and then share it around easily. For some reason I thought IWAs were super locked-down and not really practical for "regular" web apps/games. Thanks for your work on this and for answering my questions here. Very excited for this proposal!