6 ms·

I’m totally against the Australian approach and goal here, but come off it, you know that isn’t what was meant. Three lines of argument are especially notewort

I’m totally against the Australian approach and goal here, but come off it, you know that isn’t what was meant. Three lines of argument are especially noteworthy: “It is impossible to regulate cryptography.” or “Banning cryptography is like banning math.” This argument misses the point in confusing the knowledge about cryptography with the wide-spread use of cryptography - or more specifically the use of cryptography to protect confidentiality. While it would be beyond the reach of governments to remove the knowledge about cryptography from the public sphere, it is certainly not impossible to threaten those that employ “illegal” cryptography with sanction. This is exactly what happens with most regulation: Speed limits do not prevent the thought about driving fast, instead they address actually driving fast. It is behavior that is regulated, not thought. So, similar arguments about the futility of regulation or the impossibility of enforcement aim a bit too high. Regulation does not require perfect adherence. Often it is enough if some people adhere to the specific law, and others can be punished in case of being caught. Again, speed limits are not perfectly enforceable, but they limit the number of drivers that drive recklessly, and it allows taking action against some drivers and thus nudging other drivers into compliance. https://opaque.link/post/fog_of_cryptowar/ https://opaque.link/post/fog_of_cryptowar/ Shallow arguments don’t help anyone, they just marginalize the speaker beyond a narrow audience that already agrees with them.

lokopodium 8y ago
Australia requires companies to provide backdoors. It does not (and can't) require that non-companies do the same. This means every Jihadi with half a brain will be using XMPP with OTR or something like that. At the same time, it provides a requirement for EMPLOYEES to make backdoors when asked without letting their employers know.
- baroffoos 8y ago
  >This means every Jihadi with half a brain will be using XMPP with OTR or something like that. Or they could just use SMS and still be fine because the government has no idea how to actually identify problem data in the sea of data they have.
  - lokopodium 8y ago
    In this case it doesn't appear that the government intends to mass-decrypt data, but rather only tap into targeted individuals' communications.
    - acct1771 8y ago
      Today.
- toufiqbarhamov 8y ago
  As I said, I don’t agree with either their methods or their goals. It’s because I don’t want these kinds of laws in the world that I want to see shallow dismissals of them replaced by effective arguments. No one here needs convincing, what they need is to improve their ability to communicate beyond the tech bubble.
- gregmac 8y ago
  > it provides a requirement for EMPLOYEES to make backdoors when asked without letting their employers know. I'm very curious about how this will actually work, in practice, anywhere that uses any form of source control and even a modicum of process. I mean, do you sneak this into an unrelated pull request and hope everyone reviewing it doesn't catch it? Do these changes by committing directly to master (assuming you even can do that), and just hope no one notices? What commit message do you use? Even if you don't put this in source control, how do you get it deployed? Do you just tell your ops team "uh, don't use the automated deployment or the artifacts the build server produced, instead install from this zip file I made on my machine"? What happens if they are deploying a new version on a day you happen to not be there? Even assuming you manage to do all this, what happens when you're eventually caught? For example, someone finds a remote exploit bug in the code, does a blame, sees your name next to an innocent-sounding-but-clearly-misleading commit message and injection of an apparent deliberate exploit... are you allowed to explain? I would assume, especially if you can't/won't explain, that the employer could fire you on the spot, so do you just have to go along with that?
  - justinclift 8y ago
    > I'm very curious about how this will actually work, in practice, anywhere that uses any form of source control and even a modicum of process. A capable ;) agency wouldn't target the developers. They'd target the SysAdmin's who look after the build servers. With agency backed er... malware added to the build servers, they'd be capable of adding on-the-fly exploit code to the shipped binaries. Things like reproducible builds - gaining popularity among some OSS Communities for few years now - help to at least detect this. Could be very difficult to detect for lots of situations. eg side loaded mobile apps, proprietary desktop apps, likely others too

lokopodium 8y ago

Australia requires companies to provide backdoors. It does not (and can't) require that non-companies do the same. This means every Jihadi with half a brain will be using XMPP with OTR or something like that. At the same time, it provides a requirement for EMPLOYEES to make backdoors when asked without letting their employers know.

baroffoos 8y ago
>This means every Jihadi with half a brain will be using XMPP with OTR or something like that. Or they could just use SMS and still be fine because the government has no idea how to actually identify problem data in the sea of data they have.
- lokopodium 8y ago
  In this case it doesn't appear that the government intends to mass-decrypt data, but rather only tap into targeted individuals' communications.
  - acct1771 8y ago
    Today.
toufiqbarhamov 8y ago
As I said, I don’t agree with either their methods or their goals. It’s because I don’t want these kinds of laws in the world that I want to see shallow dismissals of them replaced by effective arguments. No one here needs convincing, what they need is to improve their ability to communicate beyond the tech bubble.
gregmac 8y ago
> it provides a requirement for EMPLOYEES to make backdoors when asked without letting their employers know. I'm very curious about how this will actually work, in practice, anywhere that uses any form of source control and even a modicum of process. I mean, do you sneak this into an unrelated pull request and hope everyone reviewing it doesn't catch it? Do these changes by committing directly to master (assuming you even can do that), and just hope no one notices? What commit message do you use? Even if you don't put this in source control, how do you get it deployed? Do you just tell your ops team "uh, don't use the automated deployment or the artifacts the build server produced, instead install from this zip file I made on my machine"? What happens if they are deploying a new version on a day you happen to not be there? Even assuming you manage to do all this, what happens when you're eventually caught? For example, someone finds a remote exploit bug in the code, does a blame, sees your name next to an innocent-sounding-but-clearly-misleading commit message and injection of an apparent deliberate exploit... are you allowed to explain? I would assume, especially if you can't/won't explain, that the employer could fire you on the spot, so do you just have to go along with that?
- justinclift 8y ago
  > I'm very curious about how this will actually work, in practice, anywhere that uses any form of source control and even a modicum of process. A capable ;) agency wouldn't target the developers. They'd target the SysAdmin's who look after the build servers. With agency backed er... malware added to the build servers, they'd be capable of adding on-the-fly exploit code to the shipped binaries. Things like reproducible builds - gaining popularity among some OSS Communities for few years now - help to at least detect this. Could be very difficult to detect for lots of situations. eg side loaded mobile apps, proprietary desktop apps, likely others too