Open EternityForest opened 3 years ago
jyasskin
commented
3 years ago This sort of thing is supported by the same mechanism that supports domain-trusted signatures. Making it work is primarily a matter of having a client that will define the implications of the bundle being signed by a particular kind of X.509 certificate. For a browser to be that client, we'd need a good answer to "what appears in the URL bar?"
EternityForest
commented
3 years ago @jyasskin That really is the big question. What goes in the URL bar?
Files create a bit of a conflict, because we want the actual file path to be obvious, but it's not really a unique consistent identifier for the document. A new browser icon letting us know the whole thing was served from a file might be needed for this kind of thing.
I commented about this in the PDF forms thread (#606), but in short, I think the advantage of allowing certificate-based names based on the overall signature, in the forms use case, is that you can persist form data directly into a bundle file, and it will be immediately obvious to a viewer that this a modified version, in addition to giving it an isolated origin.
In the other thread, I suggested that the origin could be a synthetic URL along the lines of "OverallSignatureHash.originalSXGBasedName.com", thus authenticating both the modifications, and the original document template.
Suppose a more advanced web app were distributed as a bundle that could have self-modifying form data. If the web app asked me to sign in to decrypt something, and my browser stored that password, I would NOT want any of those credentials to also apply to some other modified file created from that same form.
Going further, with the synthetic domain approach that also authenticates that the HTML template came from the original source, it would prevent me from creating my own bundle with malicious JS code to do something the original form publisher didn't intend.
If someone sent me an app which was some kind of calculator spreadsheet, that had been customized with some formulas to handle some engineering process (let's say keyhash692nsiNsirhni82.spreadsheet.example), then I would feel a lot more comfortable knowing that the app can only do what spreadsheet.example intends, so I don't have to purely trust the modified version.
hayatoito
commented
2 years ago [Issue Triage] FYI. there is an effort, called Isolated Web Apps, which uses WebBundles with a signature.
I propose that bundles should have an overall signature, which is done with a key specific to that particular bundle.
We see this kind of thing with Android APKs, and one of the best use cases for bundles is essentially "APKs for web apps".
When downloading a bundle, we should be able to download an update to that bundle from a third party source, and know that it is a legitimate replacement. This allows auto-updates from multiple sources with fallbacks.
As offline apps ideally have a lifetime much longer than the standard certificate expiry, it may be desirable to publish an app that does not rely on the same certificate used in web requests.
W feature like this would allow for centralized blacklists of bad bundles to be compiled, meaning that a bundle could potentially be used in some contexts, or even updated, without the original domain still being valid.
It also has benefits for the PDF forms use case mentioned in other issues, as modified versions of documents will carry a signature, and authors will be able to send updated versions more securely, meanwhile it will be possible to clearly distinguish between original and unmodified documents.
On top of that, it allows bundles that would otherwise be unsigned to have a unique origin that is not tied to the filesystem, enabling local storage and the like to work properly, or even allowing users to grant access to powerful features like web serial, without a domain name.
This could potentially have benefits for the IoT, as no-name devices could ship with their apps and drivers in web bundle format.
As it would be a complete new thing, security could also be much stricter. These self signed web apps could even be totally blocked from making any external web requests without explicit user permission.
Of course traditional web bundles are best for most apps, but this expands the range of possibilities into domains traditionally covered by an excel spreadsheet.