Our great sponsors
-
Tutanota makes encryption easy
Tuta is an email service with a strong focus on security and privacy that lets you encrypt emails, contacts and calendar entries on all your devices.
-
webclient
Discontinued Angular webclient (with Linux, macOS and Windows desktop clients) for CTemplar's encrypted email service. (by CTemplar)
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
> Their implementation for the checksum is actually cool, I like it.
For those interested, I think the checksum trick referred to above (in the context of the service offered by CTemplar) is described at [0] and there is a step-by-step how-to guide at [1].
Basically the top level index.html contains integrity hashes for the JavaScript it fetches, and you're expected to copy-paste the source of the page you're viewing into an editor, save the file, and run a local checksum on it.
That is clever, but it seems like a more convenient design would be to use a "bootstrap" page which only has the minimal set of tags on it needed to run a single . Then the user can do a quick visual inspection that there's nothing suspicious in the DOM and confirm that the integrity hash matches the value in an append-only log somewhere.<p>Mozilla actually had a clever idea for building binary transparency using the existing certificate transparency infrastructure for domains[2], by registering something like $version_number-$hash as a sub-domain of the domain where the app is hosted, e.g. v14-abc123.ctemplar.com which the user could search for using one or more certificate transparency logs.<p>Anyway, this manual checking process can be avoided entirely if the site is made available as a SecureBookmark[3], although that has the disadvantage that the browser would show a Data URI as the page address rather than a standard URL/domain which users are more familiar and comfortable with.<p>[0] <a href="https://ctemplar.com/ctemplar-checksum-implementation/" rel="nofollow">https://ctemplar.com/ctemplar-checksum-implementation/</a><p>[1] <a href="https://github.com/CTemplar/webclient/tree/gh-pages" rel="nofollow">https://github.com/CTemplar/webclient/tree/gh-pages</a><p>[2] <a href="https://wiki.mozilla.org/Security/Binary_Transparency" rel="nofollow">https://wiki.mozilla.org/Security/Binary_Transparency</a><p>[3] <a href="https://coins.github.io/secure-bookmark/" rel="nofollow">https://coins.github.io/secure-bookmark/</a>
If you trust them with your keys, why not trust them with your plaintext? At which point, why bother with E2EE at all?
The answer should be "because one day web browsers will be able to pin specific versions of specific web apps, with specific hashes, corresponding to specific releases tagged in their repo, which have been audited by a certain threshold of auditors that I trust".
What that looks like in practice is probably some mixture of the following projects:
https://github.com/kpcyrd/pacman-bintrans
https://users.rust-lang.org/t/rust-code-reviews-web-site-for...
https://paragonie.com/blog/2022/01/solving-open-source-suppl...
Something like a browser extension for this does already exist, fortunately:
https://github.com/tasn/webext-signed-pages