The genesis of this claim comes from Wire having used GPL'd OWS code, apparently for the Signal protocol, without complying with the GPL. OWS demanded that Wire comply with the GPL.
Apparently, upon being told that they would be required to comply with the GPL, they inquired instead about dual-licensing. That's standard practice when a company adopts GPL code for their own product but doesn't want to comply with the GPL: they instead have to pay for a private license.
Instead of paying for a private license, Wire has apparently chosen to comply with the GPL instead, and withdrawn their complaint. I think that was the right choice.
The knives are definitely out for Signal now that its importance is being recognized by a wider audience. Complaints about Signal are, unsurprisingly, getting dumber and more venomous. For instance, last week, Nadim Kobeissi (the author of Cryptocat, a competing secure messaging system that I think you should avoid) was on Twitter talking about how impossible a GPL violation could have been given that Wire's Signal implementation is in Rust.
For those who don't know, here was Thomas Ptacek recently joking about Nadim's penis: https://mobile.twitter.com/tqbf/status/705825790529662976
Here he is telling Nadim "go fuck yourself, forever": https://mobile.twitter.com/tqbf/status/705900243313758208
This is unprofessional. That kind of bullying is especially unacceptable coming from someone who has a lot of money and a pretty big audience, directed at someone who is young and just starting out.
I think Hacker News should be better than this.
I'm not sure how linking to twitter supports your comment that HN needs to improve. If he'd said that on HN he'd have been (I assume) banned. dang is constantly asking people not to be mean or dumb, or banning people for being mean.
dang is great. I just wish we had a bit less negativity.
--
Finally, a brief history for readers who dont know yet:
* Cryptocat v1 was a cat themed anonymous chat webapp with very broken homebrew encryption. It was basically Nadim's crypto learning project as far as I can tell when he was ~20 years old.
* Snowden allegedly used it at some point. Oops.
* Crypto experts reviewed it and found significant flaws. Tptacek wrote about how terrible it was, how JS crypto is Considered Harmful, how amateurs shouldn't write crypto because they could get someone killed, etc
* Cryptocat v2 a desktop chat app using Axolotl / Signal Protocol for e2e encryption. Nadim is a phd student now. It's a new and totally separate codebase.
tldr; there's no reason to assume that Cryptocat v2 sucks in the ways the original did. It may be totally sound.
(I have no involvement w the project and have not reviewed the code.)
No he wouldn't.
The knives are out for Signal. It's not hard to see that. Of the "independent" messaging schemes, Signal is probably the only one that has a chance of relevance 5 years from now. Everyone else is working on something that will be a checkbox feature for Apple, Google, Microsoft and Facebook in less time than that.
I'm happy about that. Clearly, not everyone else is.
Which is exactly why I, even though I don't care much for drama (infosec drama especially), find myself "complaining" about Signal from time to time. Because we are going to have to live with it. If I could go back and "complain" about PGP, before that became the preferred "just use" argument, I would.
What did he do? Does he know what he did? Do we ever get to find out? The people want answers.
Nadim has enough information to know what that hash corresponds to. Maybe he'll tell you. I won't. Not until I'm ready.
I don't think it should. I think us pretending that we are some group of regal statesmen is a bunch of pretentious bullshit.
Being civil is preferable, but not if it means being fake.
People aren't any less "mean" on HN, they're just good at bullying in more subtle ways, and we are all worse off for it.
I don't understand this. Everything is fake to some degree. Being civil is a good thing.
And indeed, with a quick browse through the Wire [0] and OWS [1] repositories I just can't find any kind of commonalities at all. Not in the structure, not in the comments, not in naming, not in the data structures, etc. Am I missing something, is there anything at all in the code itself that suggests the two codebases are related in any way at all? Or is the "GPL's OWS code" you refer to something else entirely?
[0] https://github.com/wireapp/proteus/tree/develop/src/intern
[1] https://github.com/WhisperSystems/libsignal-protocol-java/tr...
// Based on libsignal-protocol-java by Open Whisper Systems
If there's GPL violation and code was copied, there should be some traces of that. Is it truly so unreasonable to ask what those traces were?
Though I did just Google it, and throwing an extortion claim on top sounds... well, like a big mess.
Given that I'm mentioned by name (and tied to a bunch of exaggerated claims), I'd like to clarify a few points.
1. I never claimed that a GPL violation was impossible because of different programming languages. I merely questioned whether this was the case with Wire's Rust codebase [0], given that its data structures, namespacing etc. are substantially different from the OWS Java code [1]. To me, different code organization + different implementation style + different programming language don't exactly amount to a line-by-line conversion from Java to Rust as OWS seems to be claiming.
2. Cryptocat does not compete with Signal: it's a desktop XMPP client that focuses on synchronous messaging (that I write in my free time and with no funding or business plan, to boot), and does not at all target the mobile space. I was very happy to adopt a variant of Signal Protocol into Cryptocat and consider Signal's contributions to the field of secure messaging to be highly valuable. I'm not sure why tptacek brings up Cryptocat (completely unrelated to this discussion) but by all means, don't avoid it! The recent rewrite is pretty good, actually.
Overall, this situation just struck me as very ugly. Moxie seemed at some point to be reticent to allow fully independent implementations of the protocol, and Wire's lawsuit was pretty aggressive. Both parties locked in a catfight and then (apparently?) realized their approaches were counterproductive and gave it up.
The best resolution here, in my view, would have been for Moxie to publish a public-domain reference specification document of Signal Protocol that's independent of the code, and for Wire to be allowed to write a Rust implementation of it without any party causing drama.
[0] https://github.com/wireapp/proteus
[1] https://github.com/WhisperSystems/libsignal-protocol-java
Your messages on Twitter are right there for everyone to read.
Here's a helpful starting point:
https://twitter.com/kaepora/status/730165751240364033
The preceding link where you referred, unbidden, to Moxie's last post about their take on federation for their own implementation of Signal as a "dishonest rant" is left as an exercise for the reader.
Thank you
* AES-CTR counter-reuse (2012)
* Biased Fortuna CSPRNG implementation [1] (2013)
To be sure, Cryptocat's substandard reputation was well-deserved; but all the same, I think that every vulnerability that did pop up was addressed responsibly and with full disclosure.
Since then, there has been a major rewrite that I am conversely quite happy with.
[0] https://tobtu.com/decryptocat.php
[1] https://nakedsecurity.sophos.com/2013/07/09/anatomy-of-a-pse...
Good for his consulting rate, no doubt, but probably not good for society.
Steve was paid two separate bug bounties and invited to a Cryptocat hackathon in NYC. I also consider him a friend and never heard a complaint from him regarding the project's disclosure policies.
The bug that lasted 347 days was the confusion between a string and an array of integers. This made the ECC private keys ridiculously small because they passed a string of decimal digits into a function expecting an array of 17, 15 bit integers. Each character was considered an element in the array. So each of those "15 bit integers" were only the values 0 to 9 (3.32 bits). Also the least significant 3 bits are zeroed giving you a key space of 210^16 (2^54.15).*
When they fixed that bug the commit message was: "Fix private key format to match curve25518-donna. THIS BREAKS COMPATIBILITY WITH PREVIOUS CRYPTOCAT VERSIONS." Even though this does not break compatibility at all. I don't know if they knew what they fixed and just wanted to slide this under the radar or they legitimately believe that. Both are scary one is violating their principles "Cryptocat is developed under a principle of radical transparency" and the other is just incompetence. There is a blog post by them saying this is inaccurate. Apparently they have too many serious bugs to keep straight. That they don't know which one breaks compatibility. The other error in the change log for version 2.0.42 is a bug where the counter in AES-CTR is reused. This means the first 32 bytes of your messages are easy to decipher with no effort at all. Which breaks compatibility, but everywhere they mention compatibility they say key generation.
Here's one walkthrough of their broken PRNG: https://nakedsecurity.sophos.com/2013/07/09/anatomy-of-a-pse...
Decryptocat lists some of the other bugs: https://tobtu.com/decryptocat.php
The response - "bugs happen, we'll fix them" is okay for most other software, but probably not for cryptography. Especially not if you're marketing your software to people at risk of being murdered by their governments.
Here's a snippet from their blog, there are plenty of others:
> In working with young and middle-aged professionals in the Middle East region, we have discovered that desktop OTR clients suffer from serious usability issues which are sometimes further exacerbated due to language differences and lack of cultural integration (the technology was frequently described as foreign). In one case, an activist who was fully trained to use Pidgin-OTR neglected to do so citing usability difficulties, and as a direct consequence encountered a life-threatening situation at the hands of a national military in the Middle East and North Africa region.
They're the victims of being over hyped. There's some discussion to be had around how much they generated that hype. http://paranoia.dubfire.net/2012/07/tech-journalists-stop-hy...
It would be good if OWS could publicly clarify that reimplementing the Signal Protocol/Axoltl does not trigger any copyright claims by OWS even if doing so involved reading the GPLd version.
Their court filing[0] says the license fee was "unspecified" and the $2 million figure was based on "information and belief" which is legal terminology used to dodge perjury[1]. If they had really been told that, they wouldn't be using terms that mean "I heard that from somewhere second-hand and think it might be true".
[0] https://www.scribd.com/doc/311974670/Wire-Swiss-GmbH-v-Quiet...
IMHO, no credence should be given to lawsuits and accusations made without proof and right before OWS integrates with two huge partners. The accuser even filed a voluntary notice of dismissal with prejudice. Accusations without proof are just mudslinging.
Moxie has a great track record; the burden of proof is on the accuser, not the defendant.
If I implement haskell-signal and consult documentation and the code to understand the protocol but do not copy code, it's not clean room, but Open Whisper wants to see the protocol spread, so it's in their interest to more clearly state how someone is allowed to reimplement Signal in Common Lisp or FORTH, if one were so inclined, and release it under MIT.
I found the answer from a sibling post: https://twitter.com/moxie/status/730289041493483520
Moxie should use this incident to prominently make it clear in the protocol documentation that independent implementations are welcome. That's our best bet until there's an IETF RFC based on Axolotol everyone can implement instead.
Most of your communication has centered around asking us to change the license on our source base to something other than the GPL. We like the GPL for the quality control that it provides. If someone publicly says that they're using our software, we want to see if they've made any changes, and whether they're using it correctly.
You don't like the GPL because you feel that it is incompatible with the Apple App Store, despite our feelings to the contrary. If you'd like to do the work of developing a strong copyleft version of the GPL that you feel is appropriate for use in the app store, and get it OSI approved, we'd certainly look at using that.
As for documentation, there has never been a protocol called AxolotlV2. There was TextSecure, the crypto layer of which has evolved into Signal Protocol. We'd like to get this better documented so that people without crypto expertise can integrate it without having to talk to us, but that's a pretty heavy task that comes with a massive amount of responsibility, and some parts of this are still evolving. It's a priority, but we are taking the time to do it right, and hopefully we'll have more to publish this year.
We haven't patented any of the concepts here, and we've done a lot to explain and popularize them. We're happy for people to use these concepts to build their own implementations of similar protocols, but we don't want people slapping things together and calling that Signal Protocol.
To publish in the App Store some app you've been distributing under GPL, you basically have to give a separate, more permissive, license to Apple.
If the answer is yes, I strongly encourage you to publish an official statement from OWS stating so. I know for a fact that FOSS projects are losing their funding because of the impression that even if they write their interoperable implementation from scratch there would still be licensing questions.
You've clarified this somewhat on Twitter before, but if you can publish a short statement on behalf of OWS, that would go a long way into clearing up the issue for a lot of free software developers. Thanks.
https://frinkiac.com/gif/S07E18/362795/366966/IExvb2sgb3V0IE...
This is FUD.
I'm not sure if you're missing the context. This branch of the thread forked off me asking the same thing as another poster, namely the likelihood of being bothered by IP or Copyright claims for a real, proper clean room implementation of the protocol, zero code copied, assuming there is sufficient documentation available.
Oracle vs Google is relevant, but it seems we're talking past each other and maybe I'm missing a point you're making.
I simply disagree with you that Moxie Marlinspike is in any way accountable for what Oracle does with Java.
I also take exception to the argument that Open Whisper Systems needs to do something to mitigate your false impression that they've disallowed developers from using their documentation. They have not, nobody has credibly claimed otherwise, even the Wire people, and so I don't think it's proper to suggest that OWS take this "opportunity" to address a fictitious concern.
Maybe my English is imprecise, but that's not what I tried to express. We may have to disagree that the OracleVsGoogle fallout is relevant in the hypothetical case of Axolotl IP, but as we're both not lawyers, it's moot to continue that debate.
> I don't think it's proper to suggest
It wouldn't cost Moxie anything to clear such concerns, even if it's just a handful of HN reader (including me), in light of this public event and would increase the positive profile of the protocol. You make it seem like by documenting that clearly Moxie would admit to doing something, but that's wrong and a curious way to look at things, especially as you're confident of there being no problem like that.
https://twitter.com/moxie/status/730230320553828352
The Wire guys also withdrew the complaint.
I'm pretty sure having GPLed code open, reading it and writing some new software counts as a "derived work", and the GPL would apply. That's what most people who release FLOSS want to happen.
Quoting
If you'd like to do the work of developing a strong copyleft
version of the GPL that you feel is appropriate for use in the
app store, and get it OSI approved, we'd certainly look at
using that.
We'd like to get this better documented [...] It's a priority [...]
hopefully we'll have more to publish this year.
We haven't patented any of the concepts here, and we've done a
lot to explain and popularize them. We're happy for people to
use these concepts to build their own implementations of similar
protocols, but we don't want people slapping things together and
calling that Signal Protocol.> Any other distribution channel we be treated as malware
The fdroid people could recompile, check that the binary matches the one Moxie signed, and distribute the one with Moxie's signature.
On March 10, 2016 Wire rolled out end-to-end encryption and from that on everything (chat, photos, files, video messages, all calls) are end-to-end encrypted. More + security whitepaper at wire.com/privacy
https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7
more thought and whether one should avoid Signal and work with a more friendly project that doesn't seemingly fail at its desire to have widespread use of the protocol and actually tried to sue WireApp? WireApp's now approved as a non-infringing implementation in Rust, so that's great for reliability.
Edit: The suing part was initiated by Wire as a response to Moxie demanding GPL compliance over their claim Wire is infringing. I got that backwards.