Comment by timtadh | Hacker News Reader

Comment by timtadh | Hacker News Reader

Parent Full thread

> If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime.

It is trivial to compromise the browser context of the page. In the case of a browser bug another tab can interact badly with the current tab. In the case of a MITM attack on (sadly quite possible given the potential adversary) the attacker can modify the JS in flight to the browser. In the case of an externally loaded resource embedded on the page that resource may modify the execution of your crypto. There are also CSFR, XSS and other JS vulnerabilities to account for.

Javascript is a hopelessly bad place to do crypto. Consider doing an signed browser extension that does this on the desktop and native apps on the phone. I would also suggest a native app on the desktop as well. People seem to really like them for twitter.

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).

> 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.

Reply on news.ycombinator.com