So how should that protect against attacks?

[rugk]

So let's take https://client.etesync.com/ as an example. Our thread model is a malicious server.

1. You run https://client.etesync.com/.
2. You sign the page with a PGP key you own.
3. We verify each page we get from https://client.etesync.com/ and assure it is signed by your key.

So when the server (i.e. you) turns evil, they can just sign each page anyway. we verify it and that's it.

So maybe you should clarify that this nylon helps if:

1. the private key is stored securely (i.e. not on the server!)
2. the owner of the private key is not an attacker/evil in your thread model
3. i.e. that only helps against a server compromise, not against adding "backdoors"

Also it helps when:

4. you want to make sure self-hosted installations correspond to the official hosted one.

To prevent against a rogue server owner you would additionally have to verify that the minified code (or, the signature) corresponds to the one hosted at GitHub, respectively, that the signature is published on GitHub and it signs a valid release. That would be a hard task.

[tasn]

Thanks for reaching out.

While it's only implied and not explicitly spelled out, you are supposed to sign it on a secure device, and not on the server, because otherwise, as you said, what's the point? It's implied in the note about dynamic websites in the developer instructions. So point 1 is not an issue.

As for 2-3, yes, it's not covered by this extension. This extension assumes the developer is trusted, the same way you trust a developer (packager) when using Linux, or a developer when using PGP signed binaries. Reproducible builds could help us take it to the next step and protect against such backdoors, because then actual distributed javascript can be verified against the source (assuming your javascript is built).

@twiss and I are planning on making a service worker that helps verifying the signatures of pages (similar to this extension), but also, following his lead, verification against github. This can give some more assurances regarding the integrity of the code, but it brings in a few issues.

If you ask me about the "dream" solution. I'd say, follow what happened in https land. First there was https (essentially this extension), and then certificate transparency (would be great to have it here too) and reproducible builds (if your js is bundled) so one can verify the source really matches the binary.

Anyhow, just to confirm. The actionable item you expect from this ticket is to improve the readme to include some more info about the risks and threat model?

Thanks.

[rugk]

it's only implied and not explicitly spelled out, you are supposed to sign it on a secure device,

It's implied in the note about dynamic websites i

You get the issue, don't you? Indeed nothing should imply this, it should be started very explicitly. Always make the these model of your software clear. Just because one thing is obvious to you, does not mean it is obvious for others. You have to make sure users (or admins) know what thus thing protects against and against what it does not. They must know the do's and don't's.

So in short:

The actionable item you expect from this ticket is to improve the readme to include some more info about the risks and threat model?

Yes.

[tasn]

I completely agree about the need to clarify the readme, and will do so now.

Was just trying to figure out if there are any other actionable items I may have missed.

Thanks for bringing this up!