Secure Context in bundles that don't have an origin?

[josephrocca]

Regarding the "navigate-to-bundle" use case of web bundles, is it currently possible for a standalone, originless bundle to be considered a secure context by the browser, such that the web page could use geolocation and other sensitive features like that?

If not, are there specific security concerns that would need to be addressed before originless bundles could be considered secure contexts by browsers?

An increasingly large number of useful browser features are gated behind the secure context requirement, and so I think it's important that originless web bundles are able to access these features.

I'm not sure on the details of how this would work spec-wise or user-agent-wise, but it might have something to do with how localhost is treated as a secure context? Just a random guess.

[hayatoito]

Note that in "navigate-to-bundle" case, a browser doesn't use the URL of the resource in the bundle as Origin.

For example if you drag-and-drop a bundle (e.g. todomvc.wbn) into a browser, the URL in the address bar would be:

The address bar: file:///<file_system_path_in_your_local_machine>/todomvc.wbn?https://preact-todom.vc/

instead of

The address bar: https://preact-todom.vc/.

(https://preact-todom.vc/ is the primary URL specified in the bundle).

The each resource's URL is just appended to the bundle's URL. The bundle's resource can't claim its origin because the bundle is not signed.

Note we don't have any plan to support a signed web bundle in "navigate-to-bundle" at this point. That's a hard unresolved problem.

[josephrocca]

Thanks for your reply!

The bundle's resource can't claim its origin because the bundle is not signed.

That makes sense. But, to be clear, this question was in regard to bundles that don't have a "real" origin - i.e. where a "dummy" origin like webbundle.example is used as discussed here.

Is it not possible for originless web bundles to have a secure context - a bit like localhost? If it's not currently possible, then is there a good reason to restrict originless web bundles from using browser features that would normally require a https connection?

It seems like a bad idea to prevent standalone web bundles from using features like clipboard, geolocation, getUserMedia, accelerometer, bluetooth, storage, etc.

My impression is that wbn files could end up (sort of) being a safe-by-default "exe" file format, but if a standalone wbn file is unable to access a lot of normal browser features, then its utility as a portable "executable" replacement is limited.

Apologies if I'm misunderstanding some important details here!

[cmfcmf]

My impression is that wbn files could end up (sort of) being a safe-by-default "exe" file format, but if a standalone wbn file is unable to access a lot of normal browser features, then its utility as a portable "executable" replacement is limited.

We're in the process of prototyping "isolated apps", which are similar to what you describe here. You can find an explainer here: https://github.com/reillyeon/isolated-web-apps and more details on the integration with web bundles here: https://github.com/WICG/webpackage/blob/main/explainers/integrity-signature.md.

[josephrocca]

@cmfcmf I'm super excited about that proposal! That said, I got the impression that Isolated Web Apps are very "locked down" and designed for super high-security use cases, at the cost of many conveniences that are normally taken for granted in web dev. I imagined that Web Bundles would be more like a regular website. But I might have gotten the wrong impression, since I didn't dive too deep when I looked into it. And just reading the README of Isolated Web Apps now I noticed this:

However, since Web Bundles support capturing the HTTP response headers for individual resources, validating that the headers are already present is also an option and would allow applications to customize these protections as long as the modifications can still be considered safe

So if some of the harsher restrictions can be eased (e.g. inline script stuff, switching COEP header to credentialless, etc) such that it's more like a "regular" secure context, then I think Isolated Web Apps would solve my problem here.

[cmfcmf]

That said, I got the impression that Isolated Web Apps are very "locked down" and designed for super high-security use cases, at the cost of many conveniences that are normally taken for granted in web dev

That's fair! The fact that isolated apps lose a lot of convenience compared to regular websites is something we are aware of.

I imagined that Web Bundles would be more like a regular website

This could still become true. The fact that isolated apps happen to use web bundles in a more locked-down way doesn't mean that there couldn't be a future where web bundles are also used more similar to regular websites, but in an "exe" format, co-existing with the isolated app use case. I didn't want to suggest that isolated apps would fit this use case exactly, but rather bring them to your attention as something related (not realizing that you were already aware of the explainer).

[hayatoito]

[Issue Triage]

It seems we can close this.
@cmfcmf Thanks for explaining isolated apps.