Hacker News Reader

Comment by magikarp | Hacker News Reader

> When the server is providing the client with its crypto code, the server can read the plaintext no matter what.

What? I don't see how that's necessarily true. The crypto code can be verified and if it turns out to be fine, then the server shouldn't be able to read the plaintext "no matter what." That's silly.

> Hell, remove all the certs.

Is this seriously your solution?

> ...does not.

This borders on ad-homimen - under this logic, we should never strive to attempt creating new techniques but always rely on 10+year old ones. There will always be new techniques that need testing, and the fact that older ones exist is not sufficient to prevent the study and advancement of new research.

View on HN

Yes. I'm saying that if your execution environment is a browser, and your security code comes from a server, that server is going to be able to read your plaintext no matter what.

Yes. If you think China is intercepting your HTTPS traffic, remove all the root certs in your browser. Then browse to the key sites you're worried about protecting and create exceptions for each of them. China will not be able to use "fake certs" to intercept traffic to those servers.

Yes. In cryptosystems, 10+ years of study does count for a lot.

> that server is going to be able to read your plaintext no matter what.

I'm truly sorry, I follow you on Twitter and actually really respect your opinion, but that's just nonsense. the HTML, CSS and JS can all be verified, either by a plugin or by researchers studying what the server is sending, or by a variety of other ways. This ultimatum you're giving is silly.

> Yes. If you think China is intercepting your HTTPS traffic, remove all the root certs in your browser. Then browse to the key sites you're worried about protecting and create exceptions for each of them. China will not be able to use "fake certs" to intercept traffic to those servers.

That is not a real solution.

> Yes. In cryptosystems, 10+ years of study does count for a lot.

Of course - I never suggested it didn't - but that doesn't mean that new research can't undergo and survive skepticism.

You just stuck a plugin into the mix. You can make crypto work from a browser plugin. Just use the plugin for all the crypto; what the hell is the point of Javascript cryptography if you have a plugin? That's reckless to the point of negligence.

That is not a real solution.

Neither is YOUR FACE.

Neither is YOUR FACE

We don't write comments like this here.

Ref: https://news.ycombinator.com/item?id=2934523

Are you genuinely trying to be funny or is this OK coming from you on HN?

Sorry if this appears kvetchy, but clearly I need to get the rules around here straight before I open my mouth again.

I'm joking. Next time you have a question like this, you can email me; I put my email in my profile.

Although I don't really appreciates the tone here, I think that point that you are trying to make is that, if we are just going to use plugin, just use plugin all the way; why bother with Javascript for crypto at all.

...

I seriously don't appreciate your debate style, but I feel obligated to point out that your question has been discussed at another section of this thread: http://news.ycombinator.com/item?id=2935473

I think the point you are missing is that even if researchers/people can verify what the server is sending in general, there's no way for you to verify that the HTML/CSS/JS it sends you at that particular point in time is the same as the generally vetted version.

Reply on news.ycombinator.com