4 ms·

i could bother to read what nadim has written, but then i would fall in the "successfully trolled" bucket. i consider daeken very kind for reading and systemati

i could bother to read what nadim has written, but then i would fall in the "successfully trolled" bucket. i consider daeken very kind for reading and systematically disassembling nadim's post. instead, i will make a few rude blanket statements. - having a misleading wired article (or several) written about you in no way qualifies you as an expert on cryptography. anyone who has any level of knowledge in the subject knows this guy is a total hack. - everything that is somewhat correct about his products is due to people who _actually_ know stuff about cryptography telling him "no, no, no, you need to do X". the entirety of the architecture is effectively crowd-sourced. people telling you how to be a good carpenter is no substitute for being a skilled woodworker. - nadim should stop making crypto products because bad crypto _puts people at risk_. if you make one bad product, i can see chalking it up to "well, at least he's trying". instead, nadim has routinely and repeatedly demonstrated his lack of real domain knowledge. i suggest nadim make some turd-like web 2.0/3.0 driven product where security doesn't matter. he clearly has the tenacity to code but lacks the intelligence and domain knowledge to make security-related software.

radm 13y ago
It seems to me that a fundamental problem in all software security systems is that you cannot necessarily trust the location where the software is deployed. Javascript has issues here, but I think it's a mistake to claim that anything but the instances of those issues is unique to javascript. If you do not know if your system is already compromised, you cannot guarantee that using your system is without risk. And that's even before we get to people willing to break down doors and other such nastiness. That said, these are not "crypto flaws" - these are flaws that exist in systems even if the math of the cryptography is perfect. That said, there's something to be said for interacting with other people. And focusing on security risks while ignoring denial of access risks seems silly. Anyways, my reading of the people writing here suggests to me that almost no one here is really serious about security. There's too much focus on trash talk and struggles with properly characterizing a now-non-existant version of a blog page not enough focus on useful security mechanisms for me to have learned anything useful. One thing to keep in mind, though: everything that happens on the internet has visibility. So if some code is advertised as stable and it changes from day to day? Something is wrong. Similarly if I download the same code from two different machines and I get something different for supposedly stable code, something is wrong... And, one of the nice things about open source browsers is that - hypothetically at least - anyone can take the browser and build it for themselves, with their own monitoring and tracking code. This can take time, and modern browsers seem to be updated almost as fast as they can be built, but they do seem to have internal APIs which are rather stable. (Other approaches are also possible - what I am describing here is an off-the-cuff variant tailored at some of the risk suggestion raised in other posts on the page where I am responding...) Grey boxes and human readable documentation for the win...

radm 13y ago

It seems to me that a fundamental problem in all software security systems is that you cannot necessarily trust the location where the software is deployed. Javascript has issues here, but I think it's a mistake to claim that anything but the instances of those issues is unique to javascript. If you do not know if your system is already compromised, you cannot guarantee that using your system is without risk. And that's even before we get to people willing to break down doors and other such nastiness. That said, these are not "crypto flaws" - these are flaws that exist in systems even if the math of the cryptography is perfect. That said, there's something to be said for interacting with other people. And focusing on security risks while ignoring denial of access risks seems silly. Anyways, my reading of the people writing here suggests to me that almost no one here is really serious about security. There's too much focus on trash talk and struggles with properly characterizing a now-non-existant version of a blog page not enough focus on useful security mechanisms for me to have learned anything useful. One thing to keep in mind, though: everything that happens on the internet has visibility. So if some code is advertised as stable and it changes from day to day? Something is wrong. Similarly if I download the same code from two different machines and I get something different for supposedly stable code, something is wrong... And, one of the nice things about open source browsers is that - hypothetically at least - anyone can take the browser and build it for themselves, with their own monitoring and tracking code. This can take time, and modern browsers seem to be updated almost as fast as they can be built, but they do seem to have internal APIs which are rather stable. (Other approaches are also possible - what I am describing here is an off-the-cuff variant tailored at some of the risk suggestion raised in other posts on the page where I am responding...) Grey boxes and human readable documentation for the win...