Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I was thinking less of the knowledge being considered an armament, and more that an actual program that takes advantage of it being one. I don't consider the the scientific knowledge required to create a gun as an armament, nor even specific schematics, but governments may view it differently (indeed, they weren't happy about the 3D printable gun).

Also, I don't think this concept is limited specifically to exploiting bugs. I think a program that was meant to access and catalog social media accounts for a person while hiding it's accesses as much as possible, but run from a third party's location, might be considered an armament. Same with something designed to DoS a service.If the purpose is to cause harm, it might be an armament. I am aware there's probably a fine line here, and one that would inevitably be abused. I'm not sure how to deal with that, and whether the negatives there outweigh the possible positives overall.



Separating code from knowledge was part of the fun of the decss debacle. "That's not a haiku; that's an illegal perl script!"


And fundamentally it's the knowledge that matters. Programmers are "expensive" but not that expensive. Give any decent off-the-shelf code monkey the specifics of a vulnerability and he can give you exploit code.

Which means restricting the exploit code is quite useless. But restricting the knowledge itself doesn't work because the same knowledge is necessary to mitigate the vulnerability and to test that the mitigation is effective.


These days, exploiting vulnerabilities in most interesting code actually seems to be quite fiddly thanks to all the mitigation techniques and requires a bunch of specialist knowledge and tools that isn't exactly trivial to come by. The knowledge is already restricted, just for commercial rather than legal reasons.


Which is still knowledge. If you have the information you can make the tools.

I mean obviously in reality the line between "information" and "software" is non-existent because software is just a type of information, but if you insist on trying to draw a line anyway then it still fails because it's still possible to convey everything of significance using natural language, and the skillset required to convert plain language instructions into software is not rare enough to be prohibitive.


>thanks to all the mitigation techniques and requires a bunch of specialist knowledge and tools that isn't exactly trivial to come by

Eh, specialist knowledge yes. Restricted, no. Getting documents on how chips and software has always been somewhat restricted, just be a linux person and try to get documentation from Broadcom on how their wifi/lan chips work, for example.


I don't recall seeing that spirit and creativity in a long time. Or am I just getting old and cranky?

The battle for end-user control seems surrendered, at least by all but a few.




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

Search: