HN - The bike is the wrong tool for transportation in mountains. For absolute safety you must only use a cable car or funicular.
Innovator - But cable cars and funiculars are impractical for the mountain trails I want to ride, and my current road race bike with weak frame and skinny tires is dangerous off-road.
HN - A sturdy frame and fat, knobby tires only provide the illusion of safety, which is worse than no safety at all. Never go to the mountains unless you're in a cable car or funicular.
You should be comparing bicycle locks.
Innovator - To help communicate with other HN readers, I created an analogy about mountain bikes and their tire size!
HN - Not a good analogy to compare tire sizes for mountain biking to information security in Javascript. You should be comparing bicycle locks.
Innovator - My analogy still makes sense though? Consider my physical safety to be roughly equivalent to information security. While bike locks could certainly work for the analogy as well they just weren't the choice we decided to go with.
HN - Your analogy falls apart with edge cases X, Y and Z', bike locks have been used for analogies since.....
This particular response really made me chuckle: https://news.ycombinator.com/item?id=19873801
My analogy related to SQL, but we ended up talking about the complexities of physics...
(Who says we're not fun?)
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
Ed: it might, for example be easier to email an attached minimal html file, than a 50mb electron app (multiply by 5 for working on the five major platforms; windows, Linux, Macos, Android and ios). That email might be internal, or signed however you usually sign mails (gpg, s/mime). Or you could host it on a minimal, secure webserver that only served static files over ssl etc
It would be a good PoC I guess, but not practical yet for most people.
<html>
<script
src=example.cdn/app.js (SRI hash) />
</html>
There are risks, and there are procedures for mitigating risk. If you're building an app for privacy and security, you are going to take the appropriate measures, and let your users knows how to use. For instance, you are not going to load some random 3rd party adware into the app, obvi.
At the end of the day, people have to combine a care for their security with available best practices, and then move on with life. People can't thrive in the either/or of infosec's paranoid-hermit mentality (and tech's "people can't understand" paternalism).
[1] https://github.com/tasn/webext-signed-pages [2] https://bugs.chromium.org/p/chromium/issues/detail?id=487422
This is actually one of the described use cases of the new webpackage specification: https://tools.ietf.org/html/draft-yasskin-webpackage-use-cas...
Here is the current draft: https://wicg.github.io/webpackage/draft-yasskin-dispatch-web...
That doesn't mean there are reasons to do client side crypto in the browser.
Finally, who is to say the web won't get TOFU someday.
I'm not even sure you can't do it today using service-workers.
I agree. A few months ago I experimented on ways [1] to automate side-channel verification of JS bundles (and other built assets) while linking them to the sources.
It's based on trusting both the public CI/CD server (to reproducibly build the sources as they are obtained from the repository) and the public repository provider (to serve everyone the same sources), which in a FOSS environment is a given (if services like GitHub and Travis are in the threat model, there's not much to be done). It was a PoC/WIP, but it seems there might be a use case for side-channel verification.
The threat models for this kind of "mistrust" in built assets (assuming traceability and transparency) would be:
- Any kind of MitM (proxy/cache/load balancer) in the path of the assets
- Hosting provider being compromised (unlikely but still a probability)
- Malicious external content being injected at runtime (XSS, CDN)
I'm surely missing more, and I'd love to discuss at lengths about what others may have setup to do side-channel verification (ie: when even TLS and/or the CA chain of trust can't be trusted).
And if you have dynamically generated HTML then you can't really authenticate it either.
To trust an application need in-browser fingerprinting of the whole page as it was served to the user and then pin that fingerprint. Combined with fairly strict CSPs.
Also, how do I trust the revelio.json? There's no signature.
That is indeed one of the hurdles I encountered, ideally the browser itself should be in charge of verifying these claims (resource integrity helps in this case).
> And if you have dynamically generated HTML then you can't really authenticate it either.
In the case of SSR/PHP/other means of backend-generation of HTML, yes. I initially limited the PoC to SPAs and deterministic JS bundles.
> Also, how do I trust the revelio.json? There's no signature.
For now, as I said it's a work in progress, but indeed a way to authenticate the tamper-proof properties of the manifest is necessary. This however brings up the issue of a chain of trust, which is what apparently Tanker is trying to provide with their product. Yet, it raises the question: why should they be trusted ? The commercial viability argument (we don't screw up to stay in business) is not enough IMHO, trust should be based on mathematical proofs, not business rules.
And even if the actual binary I'm running is secure, plenty of apps that claim to provide E2E encryption don't give me any way to verify the key of the other user. How do I know that iMessage or Facebook Messenger aren't inserting their own key pairs me and the people I'm messaging?
You can't TOFU in-browser JS, you can't trust audits and if any 3rd-party code is loaded into the environment you can't trust the entire origin.
The browser is the wrong tool for the job here.