To me it seems like Open Whisper Systems are accepting a lot of concessions in order to have Signal included into products. The trust I once had for moxie is quickly dissipating.
* Privacy is only provided in Allo in a secondary mode. Not by default.
* Federation of the Signal protocol has been rejected for non-technical reasons.
Also, on a personal note, the desktop client requiring chrome is pretty awful.
WhatsApp makes a lot of sacrifices to have encryption by default, like no backup of messages, no real ability for the servers to do anything smart, no real search functionality, desktop client that requires the phone to be on, etc.
An incognito mode allows the default mode to have more functionality, and matches their approach with Chrome. It's not a bad tradeoff.
* Sharing naked pics on a monitored work network? No - there is at least some chance that your company owns your device, so therefore you want it to disappear from that
* Sharing politically outlawed content? No - you can be compelled to give up your device.
Wanting it "just because" is fine, but simplifying the UI is a pretty valid counter argument too.
Full disk encryption and end-to-end are not really ensuring no one can get it. I feel like I beat this point into the ground in these discussions, but all encryption is weak against rubber hose cryptography. If someone can compel you to give up your device and key, then all end-to-end does for you is make it less likely you will be caught by someone monitoring traffic.
Which brings us to point two: if that's your primary concern, then using Google may not be your best bet. If you are using Google messaging apps, it's likely because you value the additional convenience Google provides and privacy is a secondary concern.
Probably because proliferation of options is bad for UX for most user types and bad for uptake, and "incognito" is what they've named the package of privacy-related options, including E2E.
It seems to me that it's simpler to understand. If you really want to keep something a secret, it's probably not a good idea to keep a copy on your (or their) phone.
Providing separate options would make it easier to make mistakes.
Did you watch what Allo does? In its normal mode it couldn't possibly function with end-to-end encryption. They also have encryption to and from the server in the middle when you aren't in that mode.
Incognito is a useful feature. E2E encryption is a useful feature.
There's no reason to only allow those two features to be used together. You could have them both turned off by default, and have three modes, one which turns on E2E and one which turns on incognito.
Also, the incognito decision should be made by each side independently. Just because I want to delete my traces doesn't mean my partner does.
If one side enabled this "use E2E encryption for everything" feature, then the other side would presumably no longer have access to any of the smart assistant features. And it would not be obvious why.
Additionally, it would be hard to explain why you'd ever want to enable such a feature which means nobody would do it. I suspect you want default E2E encryption for political reasons. Such things don't work unless it's on by default.
I see. In that case, yes it'd make sense to have such a feature, probably implemented as an archive button in the incognito window (with a warning that archiving such a chat makes it non-private).
For Google privacy is a problem, since they want as much data they can get. So they've put in "incognito" so it sounds modern enough what competitors have with E2E, but they'll try and make it inconvenient and not default as much as they can.
Of course they won't be open about this, because they're making the world a better place <insertcuteemojihere>
Wanting an E2E chat that stays on my device when I'm done should be fine.
Only if all other participants in that chat are fine with it. So you'd end up with an implementation that only allows saving to disk if all parties allow saving. That's a lot more complexity than simply a separate checkbox.
I still agree with you, there is value in allowing the features to be controlled separately.
Why? I could always screenshot it, there's never a guarantee when you send information that it won't be retained by others with access. Letting me keep it without screenshotting is just a local convenience feature.
Sure, you could screenshot it. You can make a screencast too. But that would be your choice and your effort, not the tool's. There is a difference between a conversation partner that spends effort to violate the (possibly implicit) rules for that conversation, and a conversational tool that encourages subversion without effort.
In other words, it would be bad for Whisper to allow saving confidential conversations for two reasons:
- the user chooses to not save the conversation, but can't be sure if other partners save it regardless
- the user chooses to save the conversation, but can't be sure if the tool will really do so because of other partners' choices
Either of the options above will lead to more end-user questions (and necessary UI to prevent those) than simply combining E2E and persistence in one option.
I think this is a terminology issue - from what's been said elsewhere the only two differences in incognito mode is that it is E2E and doesn't show messages on your lockscreen.
It's not ephemeral messaging like Snapchat or something, although they are discussing it as a future feature.
>All chats will be encrypted, but a special incognito mode will have an end-to-end encryption, and expiring chats that are permanently deleted once you leave them.
I don't mind the two being used together. I've been using OTR in Gtalk/Hangouts for a long time, too (yes, I know Google actually keeps those messages anyway).
However, I would like an option to make the Incognito mode the default (always-on), just like Firefox can make Private Mode the default.
If Google wants people to believe it cares about their privacy (which is probably the reason they're even doing this in the first place), then it should not just offer the feature to them in an obscure way, but it should make it easy for them to use it if that's what they want.
I think it could if the AI was done locally, but don't expect Google to do that anytime soon, even if it becomes technically feasible and cheap to do. Didn't Apple already employ some client-side AI for photos and gave the reason that this is for privacy? I don't recall what the feature was exactly though.
As a sign of good faith, Google could also stop data-mining Hangouts now, since they have Allo for that, and make Hangouts end-to-end encrypted by default.
> WhatsApp makes a lot of sacrifices to have encryption by default, like no backup of messages
Small clarification: WhatsApp actually does seem to have a backup feature, at least on my Android phone. I was prompted by the application to enable it just this morning.
Having exactly same feelings towards moxie. He wrote a lot about Telegram and how they are not using encryption by default and security is optional, now he is accepting Allo, which is not going to use encryption by default, otherwise it cannot answer to questions like this[1]
I lament the fact that we're moving more and more to closed chat protocols. Shortly, nothing will work with Pidgin/Adium any more, and it's a shame because it's by far the best way to chat.
Moving to closed protocols isn't the whole problem. Everyone used to use AIM, ICQ, MSN Messenger, Yahoo! Messenger, which were all* closed protocols. And yet, the developers of gAIM (now Pidgin) and Trillian both developed clients that interoperated with all of these services and others.
Sure, we had five years when everyone was on XMPP. But given that rich history of protocol investigation, what's surprising to me is that progress on support for closed protocols is so much slower now than it was ten, fifteen years ago. Support for Skype, Facebook, Slack, Whatsapp, Signal, Telegram -- is poor or limited, and some of these are even open protocols. (Plus, there's still SMS to support, both natively on phones and via services like Pushbullet on the desktop.)
Is there simply no call for unified messaging anymore? Do people enjoy having to use four different messaging apps now? Are the protocols so much harder to figure out? Or are there simply not enough volunteers?
* AOL had two protocols: TOC was mostly open, but the closed OSCAR protocol offered many more features.
Most people use whatever is dominant. People who have contacts on more than one 'app' simply install those apps and mope about it a bit (but accept it nontheless). In the Netherlands (and a lot of other countries), the dominant player is Whatsapp, although some countries have their own dominant player, such as Kakao Talk in South Korea.
Of course there is call for unified messaging; it just isn't in the interest of the companies behind the currently dominant messing apps to facilitate it. To monetize their product, they need you to use their software, on (or through) an operating system approved by them, following their rules (e.g., Whatsapp's requirement of a relatively high-value personal identifier in the form a phone number). Using anything else to access their protocol causes a devaluation of their product — whatever their eventual business model will be after the make-sure-everyone-uses-us phase will be (advertising, user tracking/marketing profiles, freemium model), users will need to interact with them on their terms, with their software.
That was always the case, though. The problem with making a WhatsApp Pidgin adapter, for example, is that WhatsApp only allows a single client. I'm not sure why nobody has tried to make one that talks to the phone, like WhatsApp Web does (although that also only allows a single browser).
Generally, we've taken a big step backwards where chat is concerned.
I think federation has largely moved to the device. I do most of my messaging on my phone, where which app I'm using isn't invisible, but it's also not really a hassle to switch (mostly it involves dragging down my notification shade and tapping on the message I received). Not perfect, but also not really requiring the cognitive overhead that switching between desktop clients seemed to have. My phone federates my contacts, email, calendars, etc without much input from me and I believe chat will go that direction as well.
Matrix uses an encryption protocol of their own devising that employs the double ratchet, which is one component of Signal Protocol. But it's not Signal Protocol, it's their own thing.
Yup, just to reinforce from the Matrix side: Olm is an independent E2E protocol which happens to implement the double ratchet (formerly known as the axolotl ratchet), but it's not Signal Protocol and it's increasingly divergent from Signal, and it's completely independent of Open Whisper Systems. For instance, we're defining different behaviour for group chat ratchets, called Megolm, following our own design at http://matrix.org/speculator/spec/drafts%2Fe2e/client_server....
That said, we've tried to architect it such that we could implement compatibility with Signal if Moxie and OWS were ever open to it. But it looks like we'll need to first prove that Matrix can support a rapidly evolving yet federated ecosystem without compromising UX or privacy :)
And interesting enough, Matrix faces a different problem than Signal: It doesn't have many good clients at all (at least, last I had checked a few months back). I will agree it would be very nice if Matrix was the dominant messaging protocol that everyone needed to speak with their friends. However, that's not feasible until somebody makes an easy-to-use, beautiful Android and iOS client that doesn't require the user to install multiple bridges or wrangle several accounts to chat with their friends.
Yup, it's very true that until recently native Matrix clients have been geared up for developers. Hopefully the arrival of FOSS yet polished apps like Vector (https://vector.im) changes that - and meanwhile one can always benefit from Matrix via bridges from existing polished apps (e.g. Slack!)
I have no experience with iOS anything, but at least the Matrix Console Android client is pretty good for what I use it for. It even supports multiple simultaneous accounts which I really appreciate. I believe the iOS version of it is very similar.
> the desktop client requiring chrome is pretty awful
That's rubbish. They are a small company with not enough person-time to develop native versions for all OS. Would you prefer only to have a windows version available? Developing with Chrome/NW.js/Electron allows you to have an app that runs on 3 OS's from the start. I think it's pretty awesome.
Plus you only need chrome installed, it doesn't have to run if I understand correctly. Who doesn't have Chrome installed? Or why would you not install it?
To add to what rtkwe said, I assume the Signal client is a Chrome plugin because as far as I know you can't use GCM push messages with Chromium/NW/Electron, but only in Android and Google Chrome.
> on a personal note, the desktop client requiring chrome is pretty awful.
Why? I haven't had any issues with it.
I even have a shortcut on linux for dmenu, typing "signal" opens the chrome extension URL, opening the app in a new popup window (not a full browser, just the app in a chromeless window). So it functions just like a normal app to me. This is the `signal` bash script:
I don't use chrome for a number of reasons, the main one being I can't imagine using a browser which doesn't support the blocking of ads, and on Android there are no plugins at all, and given that I use firefox on multiple desktops, all syncing passwords, tabs etc, I'm not about to make an exception for this or that chrome-only feature. I have no idea why chrome doesn't support plugins on Android; they said they'd do it years ago.
>the main one being I can't imagine using a browser which doesn't support the blocking of ads
This hasn't been true for... ~6 years? And even then, it could block them, it just couldn't block their network download until... like 6 years ago or longer.
>I have no idea why chrome doesn't support plugins on Android; they said they'd do it years ago.
Chrome is removing all support for all plugins [see the deprecation policy they're about to introduce for Flash], but I suspect you're talking about extensions. I suspect they're coming very, very soon. They've been changing the desktop extension UI slightly and slowly and I suspect it's about enabling extensions on other form factors.
Not to mention this discussion is about using an app written for Chrome, not about somehow being forced to use Chrome for day-to-day browsing. I could (and do) use Chrome apps at times without actually using Chrome. I flip flop between Chrome and Firefox for months sometimes.
Why would I want to use a browser to do non broswery things? It's bad enough that we have to use browsers in the first place. Wouldn't we be better starting from scratch and developing a secure, standards-friendly way of deploying text, images and video rather than taking something which was designed to display just text and try and make it useful?
I don't really have any ideas. Software distribution should be a solved problem by now but even if we limit ourselves to GNU/Linux on x86-64 computers, we can't agree on a distribution mechanism. We are all over the place from the blessed apt and yum to oh just curl this url and pipe it to sh (I am a n00b so I may have said it incorrectly). There is no good way to make sure everyone gets updated. It is a mess.
I am typing this on Mozilla Firefox but I can see the draws of Chrome as a platform. I personally love the distraction that working on the plumbing on different platform involves but I would rather the people who work on secure communications -- that journalists, politicians, and policy makers, and social influencers in general can trust with their lives -- not be distracted by the fun plumbing.
The way I see it, we have to abstract it at some level. If systems folks can't agree on a standard, then applications will standardize on apps that live on top of them.
The script above basically acts like a wrapper script, launching in a small square chromeless window. So you don't even need to use Chrome, just launch that at startup so it runs in the background.
Small software companies have to make platform decisions. They chose the most popular browser (and notably most secure browser), allowing the app to work on all OSes.
I don't think you completely get how some of us feel about chrome.
Chrome is a good, modern browser but this constant pushing by google (telling me to download a "better browser" when I'm visiting their site in Firefox) as well as every lazy web developer annoys me (seriously, at least consider if you should test basic functionality in all major browsers even if you aren't directly paid for it) .
On what basis can "notably most secure browser" be asserted?
I think both aspects of this statement are definitely not clear - certainly not notably (reference?), and comparisons based on some searching seem to go one of numerous ways.
I would be happy to see a security expert's view on this though.
See also this link on Chrome devs essentially telling users that upgrading their kernel from 3.16 (not even > 7 months old at the time): https://news.ycombinator.com/item?id=9164251. Thankfully better sense prevailed and it was resolved fast. So even in terms of OS support it is not unambiguously better than others.
To me it is personally annoying because so many people and esp developers seems to want Chrome to become the new IE: a subpar (yeah, until google give you nested vertical tabs ;-) browser that web developers have fallen in love with to the point where they forget anything else.
Anything that reinforces this automatically qualifies as bad (and I'm only partially joking here ;-)
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.
You have this story backwards and you should correct your post. Moxie and OWS didn't threaten to sue Wire. Wire sued Open Whisper Systems. That suit made, but did not substantiate, a claim that OWS asked for money. OWS denies that. I believe OWS, and not Wire.
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.
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'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.
That's fair. Here on HN, tptacek writes negatively about Nadim surprisingly often. I do think it's bullying, though you're right that it's more subtle than his behavior on Twitter.
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.)
You know what? It's not part of my argument that I'm above all the vitriol and venom in amateur secure messaging. You're doing a fine job of positioning yourself right in the middle of it as well. As long as the typical HN reader leaves this thread understanding how much bullshit drama is attached to this field, I don't really care one way or the other what their opinion of me is.
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.
"Signal is probably the only one that has a chance of relevance 5 years from now"
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.
I think perhaps the worst thing you've done here is deprive the viewers at home of their closure to the question of whether or not kaepora knows what his ultimate transgression was, or if he is feigning ignorance to elicit sympathy from the audience.
What did he do? Does he know what he did? Do we ever get to find out? The people want answers.
I have no idea what that hash corresponds to and haven't even seen it before. Also, to be clear. I have absolutely not the slightest idea what kind of issue tptacek seems to be referring to in general. Honest. I'd swear under oath if I could.
"Impossible" is a tough standard to meet. But given how different idiomatic Java code and idiomatic Rust code are, it does seem kind of unlikely. I'd expect nothing at all would carry over from one codebase to the other even if you were making as straight a port as possible. Or alternatively one program would look like total garbage, like someone mechanically translating Lisp to C.
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?
That's exactly why I wrote "anything in the code itself". Yes, they made a mass commit adding that attribution to every file 9 days ago to conclude a messy lawsuit. That doesn't make the two codebases themselves appear any more related in isolation.
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?
I hadn't heard about this case before, and so I don't know the details, but just from your own description, filing a preemptive lawsuit in response to an explicit copyright demand doesn't sound unreasonable - the advantages of doing so over waiting to be sued include venue selection and, perhaps more importantly, forcing the claimant to make their case, rather than letting it turn into a frozen conflict (with the possibility of them filing DMCA notices against app stores at any time). That doesn't imply they actually wanted to go to court.
Though I did just Google it, and throwing an extortion claim on top sounds... well, like a big mess.
That's exactly what they eventually did. I wouldn't have, if I thought a copyright claim against me were truly bogus. Maybe they decided it wasn't bogus.
> 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.
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.
You're the author of a secure messaging system who is, to put it lightly, notorious for throwing shade on other people's secure messaging projects. This comment is a perfect example: OWS demanded that Wire comply with the GPL, and you've declared that "drama", and suggested that Wire was somehow "not allowed" to port it to Rust.
Your messages on Twitter are right there for everyone to read.
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.
It's pretty hard to reach a conclusion on this issue without spending some (more than I'm willing to) time looking at the code. I'm not sure I like the claiming of copyright on other implementations. I guess this is because they use a dual-licensing business model? Which would be understandable, but they should probably communicate that clearer.
These kinds of arguments may have force on Reddit, but they're verboten on HN. You need to engage the argument itself and not try to dredge things up about the arguer.
I am the original author of the software you refer to. Before its complete rewrite (released two months ago), Cryptocat was based on a codebase that I wrote starting in my early undergrad and that was notorious for containing many high-severity vulnerabilities. The most important was "Decryptocat", documented by Steve Thomas [0] but we also had:
* 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.
For what it's worth, Steve Thomas's vulnerability was not the most important in that code. I think Steve Thomas (fair warning: a friend) might dispute the "full disclosure" comment you made, as well.
Thomas, aren't you trying to make security-related products and infosec in general too "reputation-based"? Do you really think that some bad code or design or lack of theoretical background during early career should be an "out-of-profession" sentence for lifetime? Hadn't you ever made such mistakes yourself?
Yeah, whilst I generally agree with the sentiment that nobody should roll their own crypto nor use something you randomly find on the net, if nobodies creating these things, you will have no future professionals.
Good for his consulting rate, no doubt, but probably not good for society.
Of course, I was only referring to vulnerabilities I could verify are real.
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.
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.
That isn't quite a reply. It's a second hand account of Moxie denying that he asked for money. This story seems very troubling. The Wire guys made very specific claims (where did they get the >$2M figure from ... and why would they simply invent such a figure). If their implementation is in Rust then it cannot be the same as OWS' code.
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.
> The Wire guys made very specific claims (where did they get the >$2M figure from ... and why would they simply invent such a figure).
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".
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.
That's not what happened. Wire didn't consult OWS documentation. They used the code itself, and (apparently) baked it into a closed-source product. How much sympathy am I meant to have for those people?
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.
Since nobody has provided any evidence that OWS ever suggested that using their documentation was improper, you might just as well suggest Moxie use this "incident" as an opportunity to announce that he's stopped beating his wife.
I've been pretty quiet about this, but over the last couple of months I have been trying to negotiate with Moxie a way to distribute the GPL licensed AxolotlKit on the iOS App Store in ChatSecure (which is open source). After being denied a license, I was told by Moxie that I would be unable to write a non-GPL AxolotlV3 implementation because there is not publicly available documentation, and that any re-implementation will necessarily be a derivative work because the source code must be consulted. You may notice the AxolotlV2 documentation has been removed... and there was never documentation for AxolotlV3. The only public spec is the original double ratchet, and a few blog posts, which don't include things like signed prekeys and 4-way DH.
Hey Chris, as you know, we have no problem with you distributing our GPL software through the app store.
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.
The FSF and SFLC take the position that the GPL is incompatible with the iOS App Store restrictions, since it forbids adding additional restrictions. However, GPL3 has official support for "additional permissions" and it's still FSF / OSI approved with those added. It permits dropping the additional permissions and using the software as pure GPL3. So that seems like the best approach, but Apple's restrictions are probably a moving target and it would erode the copyleft aspect of the license.
When the author say "we have no problem with you distributing our software through the app store", then I would just get that in some more official writing that include you, apple, and more detailed description on what permission is exactly given. The primary purpose of any software license is to shield the downstream distributor against being charged under copyright infringement, but a personal permission is equally fine in a legal sense so long you don't intend that downstream from you should also be able to distribute your version.
It looks like you can publish GPL apps in the App Store if you are the author. If you want to use someone's GPL lib in your app, then you might have a problem...
The GPL is not compatible with the Apple App Store because it contains: "You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License." By submitting an app to the Apple App Store and signing the license an author can grant that right to Apple, but somebody that wants to use the code can't do that...
That's somewhat helpful but doesn't fully address Chris's story. Would Chris be able to write his own implementation, interoperable with AxolotlKit (the iOS Signal Protocol implementation), from scratch, without any explicit code reuse, and then publish it under whatever license he chooses?
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.
I don't understand the cultural reference and I'll assume it's irrelevant, but the Oracle vs Google saga made me very very cautious when it comes to clean room reimplementations of public bits, and if I were to earn money with such a library, I'm afraid I'd need more than Moxie's tweet.
This cultural reference I get even less than the first one, but I'll just ignore the references.
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.
> does not trigger any copyright claims by OWS even if doing so involved reading the GPLd version.
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.
Unfortunately, if I read https://news.ycombinator.com/item?id=11727870 right, Moxie formulated that more clearly by saying they would only approve of copyleft reimplementations. Unless I'm misreading things, this confirms the concerns and turns it more into something like the Java conformance testing case which the Apache folks ran into. I do get why they want protocol conformance, but expecting everyone to publish their implementation as copyleft is unreasonable and unrealistic. The only acceptable solution, if they want to see widespread use of the protocol, is to have a shared, no strings attached testing framework everyone can use to check their protocol implementation doesn't deviate. We have such things for web standards, why not for a secure chat solution? Their aim is good, but the solution is unacceptable for an industry standard to be.
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.
That was true when Wire launched in December 2014 but not any more.
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
This is fantastic news. The two largest messaging platforms on the Internet will both be using Signal protocol.
I could ask for more: E2E could be the default for Allo, and it isn't. That's not great. But the E2E you get when you ask for it will apparently be best-in-class.
Uh, where are you defining Allo as one of the largest messaging platforms on the internet? It literally just launched.
It might do well, but it could also easily be a flop (as many other social initiatives from Google have been). Either way it's a long ways from catching up to WeChat, Viber, or even Facebook Messenger.
Hangouts didn't catch on because it was delivered as a group video calling service that then also did (or perhaps became about?) text, even becoming the default SMS app on Android.
It also hasn't caught on because it is overly complex. With any other video calling service you call a person and they have a conversation with you - of you initiate a group conference and off you go.
Hangout needs you to invite someone, but then what - you're still having this video broadcast by yourself? Actually, is it a broadcast? Can other people just join in? Apparently they could depending on your settings (in the past), but not this seems to have been separated to 'Hangouts On Air'? Who knows, I don't see why I should bother looking into it when there are clearer options available.
I love me some Google, so don't misunderstand me, and Duo is a big step in the right direction for the average users experience compared to Hangouts.
I don't always agree something is "incredibly buggy" but when I do, it's because I experience multiple daily crashes on a Nexus 5X, which should be the most compatible and thoroughly tested platform it's running on. That qualifies as "incredible."
"Allo" is just one aspect of IMS in Android. While it isn't certain that Allo as a product will succeed, Google's approach to IMS, carrier messaging, and basing products like Allo and Duo on those APIs and underlying networks means that this is more like adding the Signal protocol to an open IMS-based ecosystem of messaging than it is depending on Allo.
Is Allo one of the largest messaging platforms yet? Will take a bit of times for users to adopt to it I'd imagine. And while WhatsApp has E2E, no mention of it for FB's Messenger. Agreed big shame they will not enable it by default given how those default settings are usually untouched.
I guess it's not e2e in all chats for the @google assistant to be able to be part of the conversation.
If it would be part of the e2e conversation you would be sharing all your messages with google anyways, kind of defeating the purpose.
At least they offer "incognito" chats. I think that's a fair compromise in the light of Allo being focused on the Assistant & Smart Replies.
The smart replies thing creeps me out. I already take swiftkey suggestions on how I talk sometimes. This just takes it to a whole other level where it's not even you writing the suggestions anymore.
WhatsApp is pretty big, but I doubt Google is even now second before Facebook, WeChat or QQ. Unless you include e-mail, but that isn't being encrypted as I understand.
What I'm curious about, and think would be really neat, is if one could take advantage of the shared Signal Protocol to send messages cross-platform. Specifically, sending an encrypted message to a Whatsapp user from Allo. Or to a Signal user from Whatsapp. Or any combination/permutation really.
I don't think I'd characterize his blog post that way. The last sentence captures what I got from reading it: "It may not be as beautiful as federation, but at this point it seems that it will have to do."
Moxie's essay is strong and djb's point is not: a "federated network" with a centrally controlled app that updates automatically might as well not be federated at all: at that point having multiple servers hardly matters. Who cares about running your own server if you can't run your own client?
Moxie has put into words what I've been thinking myself for a long time - the old federated protocols from the 1990s have been slowly dying off (with email being the main holdout, unless you count gmail). And the reason is that they just don't evolve. There's no incentive to evolve them, there's no organisational structure to evolve them, creating them takes huge effort AND they suffer from all sort of hidden ideological constraints that would prevent them from e.g. doing a partnership with Uber beause Uber is a corporation and an open protocol isn't. But users don't care about that.
I don't think he's opposed to it, he just recognises that in practice federation and open protocols impose large hidden costs that are typically undiscussed and unrecognised.
Federation between WhatsApp and Allo would face some obvious problems: features that don't work the same way or don't work at all, for instance. Moxie's point is that federation is just less important than it once was because there's no real lockin due to the pervasive use of phone numbers as identities. There's no real reason to use Allo to send message to a WhatsApp user or vice versa given you can just install both apps for free anyway.
My understanding is that the Signal protocol isn't an IM protocol like XMPP, but a messaging protocol like OTR. Just like you can use OTR with XMPP, Signal can work be used inside IM protocols like Matrix and XMPP. Or with proprietary ones like WhatsApp, Allo, and Signal itself. The former provides federation, the latter do not.
That app didn't exist until May 15th, and all the reviews for it are incredibly poor (as in, had zero functionality at all). I'd bet someone got an early leak of the name for Google's new messaging product, and tried to make a quick product and domain registration, so they can get tossed a few bucks when Google needs to buy the domain.
Is Google going to be scanning all my conversations to give me suggestions on what to say next? Really?
I understand the price of things like Gmail, where I get a robust email system in exchange of scanning my emails and mining my data. I got something very good from Google, they got my data. Not the best of the deals I ever made, but it has (had?) a strong appeal.
On the other hand I don't understand this Allo thing: There's no appeal in the smart assistant, it doesn't bring anything I want to have.
Ugh, I hate this phone number as identify business. My pone number changes every time I move and I have to keep paying to have it. I see the benefit to a number that I can easily share but I don't like tying it to the telephone system.
I'll keep using something like hangouts that allows me to keep my contacts when I move as well as a number of other benefits.
Why does it change? In my experience most people keep their first cell phone number for their entire lives. Area codes are indicative of nothing, except where you lived in 2005 [1].
Not everyone lives in the US. Here's how this affects me:
* If I lose my phone, I've permanently lost my number.
* Long-distance calls are a lot more expensive (about 5-10x as much).
* Switch companies? Number lost again.
I've had about 5-6 mobile numbers since during the last decade.
I went to school and got a new number because a lot of my friends didn't have free province-wide calling and I'm about to move from Canada to Europe. So for me this is a particular concern at the moment.
Lost your phone? Got mugged?
Now you've lost you only identifier on every major IM network out there. You need to contact everyone you know out-of-band and have them update your number.
That is awesome - now we also need to kill metadata collection. Is this feasible?
Oh and off-the-record was there on Hangouts/Gtalk before - I used it but the chats were replicated across clients (e.g. Pidgin vs gmail.com) - so not really off-the-record (i.e. they lied).
Metadata-free chat exists already on the desktop with Ricochet (https://ricochet.im) and it will soon exist on mobile with Briar (https://briarproject.org). Both work through Tor hidden services - Briar also allows to exchange messages over Bluetooth and direct wifi.
Yes, I labelled that incorrectly and I was not talking about the OTR encryption tech - Google still lied though in terms that they kept a conversation record and replicated it live and time-delayed across channels.
"Off The Record" is a technical term to describe a cryptographic scheme for allowing deniable authentication (meaning that only the two parties involved in a communication can be sure the other sent a message - they cannot prove to anyone else that the other person sent them a particular message). The Signal protocol is based off a similar system (Axolotl) which provides similar guarantees.
It has nothing to do with "off the record" check boxes in some UI.
"Apparently partners with NSA" is very different from "for plausibly-legitimate reasons, runs only a platform that has an increased attack surface".
That's like saying that Ubuntu partners with script kiddies because they're slow about fixing security bugs in LTSes. I understand the point you're trying to make, but no.
That's nonsense. In-house proprietary encryption is not peer reviewed and untrustworthy by definition and if you're going to work in the open, especially for a new proprietary chat app, it makes better sense to build on an open platform that's already proven and is handled by people that really know their stuff. More secure and probably cheaper as well.
The Signal protocol is for all intents asymptote the state of the art in the design of a secure messaging protocol. There doesn't seem to be any meaningful improvements to the design without changing the requirements.
New requirements might be
- Post Quantum forward secrecy
- Groups messaging with transcript verification
- Security weakness in x25519 or AES-CBC-HMAC or SHA256 primitives.
If you don't have any new requirements, crypto protocol developer time is a scarce resource. Why reinvent the state of the art?
* Privacy is only provided in Allo in a secondary mode. Not by default.
* Federation of the Signal protocol has been rejected for non-technical reasons.
Also, on a personal note, the desktop client requiring chrome is pretty awful.