[mpowers]

I appreciate your concern, but you can't fault JS for browser bugs or OS bugs.

It's also not clear to me why you're any more secure with a signed browser extension or native app. Just because it's signed doesn't mean you can trust it any more than you can trust JS that you download via HTTPS from a server. What's worse, you didn't compile it from source, so how can you know there's nothing sinister lurking in there?

You are correct that people like native apps for their microblogging, and we want to encourage many native, hardened, peer-reviewed implementations for every platform imaginable.

Because the client is just appending signed entries to the end of an RSS file, send pushing and pulling those files over http, you could write a nice client running inside emacs (if you trusted your os crypto libs).

[e12e]

> It's also not clear to me why you're any more secure with a signed browser extension or native app. Just because it's signed doesn't mean you can trust it any more than you can trust JS that you download via HTTPS from a server.

For one, one would hope that a team takes more care to manage their private (code) signing key, than their ssl private key. The signing key should probably be on an air gapped system. That isn't feasible with the key use for https/tls.

You could compromise ftp-servers all day without being able to generate a valid signature for your bad code.

Now, on the subject of: Wouldn't it be possible, in the future, to create mechanism where we could deliver signed js code in a more secure manner than we do today? Absolutely. But it that future doesn't seem to be arriving any time soon.