Slashdot Mirror
CipherCloud Invokes DMCA To Block Discussions of Its Crypto System
New submitter brennz writes "Cryptographers on StackExchange were discussing CipherCloud, using some promotional material from the same to provide detail. CipherCloud responded with a DMCA takedown request that some have characterized as abusive."
StackExchange appears to have put the question back up, but remove from it the screenshots which the DMCA takedown demand claimed constituted copyright infringement.
The screenshots should be a pretty solid fair-use case, though, so even that part of the takedown demand is groundless.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
There is no other way to characterize the DMCA.. It was no accident.
“He’s not deformed, he’s just drunk!”
If you have to go to such extremes to cover up what people are saying about your product, your product must really suck.
Now I know to stay well clear of anything that has to do with Ciphercloud. I certainly wouldn't have seen the Stack exchange discussion (much less the fact that Ciphercloud feels that cryptanalysis is bad for them) if they didn't do what they did, though. Thanks, Ciphercloud!
One guy comes right in with an answer that pretty much blows CC's false BS claims out of the water.
That's why the DMCA was invoked, to hide their criminal lying. That's why the images were removed, because all it took was a look at the images to figure out their bullshit.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
The question whether something promoted as "secure" actually is depends highly on exactly this: Someone coming and trying to break it. It's not like any other software product you use, where you, the user, can easily tell whether it does its job or not. You use some word processing software, you can instantly check whether it does what YOU want it to do (even if it happens to fail in some other department, you'll easily be able to tell whether it does what YOU want). You use some game, you can easily tell whether it gives you what you wanted in it.
Security software ... not quite. Whether it delivers what it promises isn't something you can check as the average user. Because, as the average user, you don't "use" it. Even as the person responsible for security in a company, you hardly have the time nor necessarily the knowledge to test it thoroughly. And before someone pipes in with "but if you can't break through bad security, you fail at your job", be aware that the job description for CISO hardly includes doing pen tests. If anything, you order them from companies who have the time and money to keep current with security issues.
So the question whether a product is good or snake oil highly depends on peer review, on people going out and hammering it. If you now go out of your way to keep people from just doing that, well, how should I judge such a move? This is much like a scientist publishing a breakthrough in anti-gravity, while at the same time forbidding everyone to attempt to reproduce his results.
That's about as much credibility is left after such a move.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Look elsewhere--the only thing that should be obscure about a crypto system is the key.
http://i.stack.imgur.com/xJ6V8.png http://i.stack.imgur.com/oBXZJ.png http://i.stack.imgur.com/h7ntP.jpg http://pages.ciphercloud.com/AnyAppfiveminutesdemo.html?alild=1
Cryptographics? In a few hours I could conjure up cryptographic algorithms, which encrypt text in a way I could not decrypt myself in a 1000 years. Too bad I can never be sure that a cryptographic expert could read my encryption almost like plain text. Odds are that exactly something like that would happen.
You have a healthy respect for cryptography, and that's good. However, I will point out that many standard crypto algorithms have test suites. If your crypto implementation yields the expected result for all the test cases, then you can be reasonably certain that your implementation is correct rather than having self-canceling bugs on encrypt/decrypt.
However, then you have to ask yourself *why* you are reimplementing a standard crypto algorithm when there are multitudinous well-tested libraries available for such.
Of course, this neglects implementation concerns like timing attacks, improperly secured key material, etc... which one would hope that the standardized, well-tested implementation libraries have already addressed insofar as possible.
Maybe they meant "homeopathic" encryption. The worse the encryption scheme, the safer your data is!