4 ms·
For code signing to work you need to trust whoever is signing the code. As you mentioned, with HTTPS, all the contents are already signed by the web server. If
by PureParadigm 6y ago
For code signing to work you need to trust whoever is signing the code. As you mentioned, with HTTPS, all the contents are already signed by the web server. If Jitsi published a native app and signed it, would that even help you? You still have to trust them because they could have signed anything.
Maybe you mean to compare it to a copy that has already been audited by someone else? Then you might as well use the auditor's web server to get the client (and you can do this because Jitsi can be self-hosted). So I think it just comes down to connecting to web servers run by people you trust, since HTTPS already takes care of integrity checking.
- michaelt 6y agoIf you are running a project like Tor Browser, that needs the highest security going, you would want: 1. Signing with an offline key, so an attacker can't make a release just by hacking the web server, and the key doesn't end up on however many hundred CDN web servers around the world. 2. Clear boundaries between releases, and a slow enough release schedule that third-party auditors can keep up. 3. Non-repudiation, so users know everyone else saw the same version they saw. 4. Reproducible builds from code in a public repo, so third-party auditors know what was released is what they reviewed. 5. An update process that verifies 1-3 before applying an update. These requirements are fundamentally incompatible with webapps - where a no-questions-asked software update is only a press of F5 away, by design.
- dane-pgp 6y ago> These requirements are fundamentally incompatible with webapps - where a no-questions-asked software update is only a press of F5 away, by design. If by "webapps" you mean "applications that run inside a web browser" then I disagree, since it is possible to pin a specific (presumably third-party audited) version of a webapp by using a static local bookmarklet or saved file. See my other comment [1]. You're right, though, that this is not the typical user experience for a web app, and you might reasonably believe that all webapps should be visibly associated with a domain on the internet. Personally I think it is acceptable if a high security webapp requires a slightly less convenient UX compared to normal webapps. Nevertheless, it should still be quicker and safer to "install" a bookmarklet than install a native application like the Tor Browser. [1] https://news.ycombinator.com/item?id=22862376 https://news.ycombinator.com/item?id=22862376