Hacker News new | past | comments | ask | show | jobs | submit login

I like to grab old books at yard sales, and found this an interesting read (Arms Control Disarmament And National Security, 1961, https://archive.org/details/armscontroldisar013124mbp). It's a collection of essays by various authors on a variety of arms control subjects.

Everyone sees nuclear / Cold War negotiations in hindsight, but in 1961 (and probably also ~1950) the logic is much more interesting, given that the theories were developed from a position of profound ignorance. How would things turn out? What did the other side actually want? How reasonable was the other side? Unknown!

On a technical point, is there a reason that javascript doesn't tend to be signed in any way? Or is it? Even if you're serving unsecured content for whatever reason, it'd be nice to allow the user to verify the code they received was as you intended. (Admittedly, encrypting all traffic as a default solves this)




On a technical point, is there a reason that javascript doesn't tend to be signed in any way?

A good point. I think it's convenience that we don't do it, but I'd hope we move in that direction. It seems like a prudent move.


> A good point. I think it's convenience that we don't do it, but I'd hope we move in that direction. It seems like a prudent move.

After a bit of Googling, (a) http://stackoverflow.com/questions/1368164/javascript-code-s... (b) http://www-archive.mozilla.org/projects/security/components/...

It seems it's simultaneously too difficult to do without ECMA spec support & would require a certificate chain anyway. And if you're running a cert chain infrastructure, why not use the one that already exists and run TLS?

Other side thought: with regards to the usefulness & impracticality of cert pinning, has any work been done on systems specifically designed to target low % injection systems? If 1/10 visitors gets the poisoned page, then it seems you'd have a 9/10 chance to pull a good page for comparison & verification if you (or a proxy you trust) made another request from a different IP.


In this case, the problem with any kind of technical workaround on the server side is that Baidu is under the jurisdiction of the government implementing the DDoS and is thus unlikely to be able to actively work to defeat it. If another country tried to do the same... well, that's what HTTPS is for.


HTTPS is not secure when we talk about China it is false sense of security! Last case 7days ago: http://www.theregister.co.uk/2015/03/24/google_ssl_cnnic/


That's fairly off topic - I mentioned that HTTPS is somewhat irrelevant here since Baidu is located in China, and anyway a forged certificate could not be used in a mass attack like this one since the issuing CA would come to the attention of browser vendors rather quickly. For the record, hopefully Google's upcoming Certificate Transparency feature in Chrome will help address the general issue, although who knows what kind of adoption it will have in practice.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: