What is Standard Notes stance on in-browser cryptography?

[alat-rights]

Since end-to-end encryption generally assumes hostile infrastructure, how can Standard Notes webapp users be certain that the webapp they are served is legitimate?

Does Standard Notes see this as an acceptable risk for most users (and those who do not see it as such can simply use available releases), or does Standard Notes have existing protections against a HushMail-style incident?

[moughxyz]

the webapp they are served is legitimate?

I think the more direct question would be "how can we be sure that the web app served is the same as the source we see on GitHub?"—this is an unsolved problem in the web ecosystem as far as I'm aware. Would probably require the use of a browser extension, or a 3rd party who could compute the integrity of the served web app on demand and compare that to signatures uploaded to GitHub.

[alat-rights]

Generally, I believe that good practice would be to inform users of the risk of web clients. It is often non-obvious to users that their web client can become evil, even if Standard Notes itself does not, and even without malicious intent from Standard Notes (as hosting means other parties are also trusted).

After that, it would be worthwhile to have either a code-verifying extension checking that the Standard Notes which is being served is correct or a browser extension implementation of Standard Notes itself. This extension can also enhance usability by providing a one-click shortcut to open Standard Notes from the extension shortcut.

Finally, it would be very useful to be able to run the webapp in a less-trusted, ad-hoc fashion as an Extension feature. Essentially, I would like to be able to delegate a sub-account with fine-tuned access (as far as which notes it can access and what it can do to the notes (read/write/append/embed images/upload files)), possibly with an audit log. The "minimum viable product" version of this would be an option to simply forbid "sub-accounts" from accessing protected notes.

The way I see this happening is a QR-code based flow, where one would open up Standard Notes on their phone, scan a QR code on their computer, go through a flow on their phone "are you sure you would like to delegate a sub-account to this PC? -> What notes would you like to grant it access to?"

This will have the added benefit of being able to use untrusted computers (such as computers in a library!) to write when I'm out, and can also allow for much more secure collaboration (Alice: "It's not public yet but let me scan you in so you can read my writing!")

[moughxyz]

code-verifying extension checking that the Standard Notes which is being served is correct

You mentioned wanting to contribute, this could be an interesting candidate :)

[silentsilas]

I wrote up a quick proof-of-concept for a Firefox extension that can run checksums on downloaded site files. I'd be up to have it moved under the Standard Notes organization after I refine it some more and make sure it works on Chrome/Chromium.

https://github.com/silentsilas/checksum-webextension

[JaspalSuri]

Thank you for working on that @silentsilas! I'm not sure if we'll add it to our organization just yet as we would need to commit enough time towards maintaining it, though.

[silentsilas]

Ah, that makes sense. I can remain the maintainer.

I have a quick question on how to implement this. I've been using the SN cloud service, and not a self-hosted instance this whole time. To create an official list of checksums for the JS files, would I just need to get standardnotes/standalone up and running, and it would have the files inside that docker container? Would they be identical to the ones that app.standardnotes.org currently serves?

[JaspalSuri]

Hi @silentsilas, sorry for the delayed response. I'll forward your question over to the dev team. 🙂

[karolsojko]

Hi @silentsilas ,

https://github.com/standardnotes/standalone is a subset of our server-side infrastructure for the purposes of self-hosting.

When it comes to app.standardnotes.org - it always serves what's currently on https://github.com/standardnotes/web in the main branch.

[moughxyz]

To add additional context, I think the best way to implement this would be:

1. Modify standardnotes/web to include a subresource integrity hash in the main html file of every asset (but primarily the JS files)
2. The browser extension would then compute these same hashes on its own.
3. If the browser_extension.hashes == standardnotes/web.hashes, then the browser extension displays a green checkmark showing that integrity verification has passed. Otherwise it displays a red X saying there's a mismatch in integrity.

For step 1, note that the distributable files are compiled on commit via GitHub actions, but I think it just hooks into the Webpack config files in the repo.

[silentsilas]

Sweet, that sounds perfect! You'll probably see a PR to add SRI's one of these EDT evenings.