Open Whisper Systems Partners with Google on End-To-end Encryption for Allo(whispersystems.org)
whispersystems.org
Open Whisper Systems Partners with Google on End-To-end Encryption for Allo
https://whispersystems.org/blog/allo/
220 comments
Making someone else's crypto not suck is not the same as endorsing their product.
Matrix uses the same encryption protocol but is also federated, which is nice.
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 :)
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.
Vector is now out on both Android[1] and iOS[2], and the web version of Vector has improved significantly.
It doesn't have end to end encryption support yet, but they're working on it.
1: https://play.google.com/store/apps/details?id=im.vector.alph... 2: https://itunes.apple.com/us/app/vector.im/id1083446067
It doesn't have end to end encryption support yet, but they're working on it.
1: https://play.google.com/store/apps/details?id=im.vector.alph... 2: https://itunes.apple.com/us/app/vector.im/id1083446067
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!)
Vector and recently Tensor are pretty awesome.
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.
> 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:
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:
#!/usr/bin/dash
/opt/google/chrome-unstable/google-chrome-unstable --user-data-dir=/home/dmix/.config/google-chrome-unstable --profile-directory=Default --app-id=bikioccmkafdpakkkcpdbppfkghcmihkI 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.
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 you have to use Chrome? You just need Chrome as a platform to launch your chrome app...
I don't get it
I don't get it
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?
Any ideas?
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.
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.
Because some of us don't want to use Chrome? How is vendor lock-in at the browser level any better than at the OS or device level?
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.
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) .
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) .
Wish I could remove the "lazy" part, my apologies webdevs!
Still: wish less companies would be fine with shipping web apps that break in one or more of modern browsers.
Still: wish less companies would be fine with shipping web apps that break in one or more of modern browsers.
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.
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 ;-)
Anything that reinforces this automatically qualifies as bad (and I'm only partially joking here ;-)
This is exactly it! People are now making chrome apps instead of web apps.
How many times have you been to a webapp and it said "Your browser is not supported, for best results please use Google Chrome."
How many times have you been to a webapp and it said "Your browser is not supported, for best results please use Google Chrome."
I use Firefox and hate Chrome. I don't see how this affected by how much you use Chrome
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.
An incognito mode allows the default mode to have more functionality, and matches their approach with Chrome. It's not a bad tradeoff.
> 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.
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.
Message backup is there on iOS too.
Didn't WhatsApp Web require the phone to be on, before they got encryption?
It still does
> WhatsApp makes a lot of sacrifices to have encryption by default, like no backup of messages
Huh? I have backup of messages.
> no real search functionality
I can search on my phone.
> desktop client that requires the phone to be on, etc.
I want this: the messages should live on my phone.
Huh? I have backup of messages.
> no real search functionality
I can search on my phone.
> desktop client that requires the phone to be on, etc.
I want this: the messages should live on my phone.
I don't get why encryption and incognito (not leaving a trace on the device) go together. I should be able to have one without the other.
They wouldn't be able to insert a chat bot to all of your conversations if they were all end to end encrypted. I agree it's a good trade-off
But why not allow E2E without incognito? Have both as separate options.
What use-case does E2E without incognito address?
* 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.
* 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.
Protecting against dragnet surveillance. Which is what the encrypted-by-default in Whatsapp achieved over night.
Combined with full disk encryption it ensures nobody can get it.
Or maybe you want to use an open WiFi hotspot without letting anyone get your data. (Https solves this, though.)
Or maybe you don't want Google to have your messages for targeting purposes.
Or maybe you want to use an open WiFi hotspot without letting anyone get your data. (Https solves this, though.)
Or maybe you don't want Google to have your messages for targeting purposes.
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.
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.
Providing separate options would make it easier to make mistakes.
Pretty much no other E2E app feels the same way, and certainly doesn't enforce that.
You have this in qTox and uTox
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.
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.
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.
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.
> If Google wants people to believe it cares about their privacy
They don't, it's just more easibly marketable this way since it's a checkmark on someones Powerpoint slide.
> but it should make it easy for them to use it if that's what they want.
Google doesn't cater to users, since they aren't customers (services are free), but advertisers are.
They don't, it's just more easibly marketable this way since it's a checkmark on someones Powerpoint slide.
> but it should make it easy for them to use it if that's what they want.
Google doesn't cater to users, since they aren't customers (services are free), but advertisers are.
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.
It's not ephemeral messaging like Snapchat or something, although they are discussing it as a future feature.
I followed the arstechnica liveblog. http://live.arstechnica.com/google-io-2016-keynote/#post-885...
>Incognito also offers message expiration. When you close incognito mode, your message is gone forever.
I assumed that was accurate. Did they misrepresent it somehow?
>Incognito also offers message expiration. When you close incognito mode, your message is gone forever.
I assumed that was accurate. Did they misrepresent it somehow?
Possibly - the two sites I've seen with "hands-ons" do not mention this anywhere.
http://www.wsj.com/articles/google-takes-on-apple-facebook-w... (https://archive.is/ELitC for paywall)
>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.
>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.
> There's no reason to only allow those two features to be used together.
UX simplicity is, in fact, a reason.
UX simplicity is, in fact, a reason.
Then have the default incognito be as described, with an option in settings to separate the two features.
I don't think you've thought this through.
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.
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.
>If one side enabled this "use E2E encryption for everything" feature
That's not what I'm suggesting. I want E2E to be separate from the "delete chats when I'm finished" feature.
Wanting an E2E chat that stays on my device when I'm done should be fine.
I'm fine with having E2E require a separate mode, but that shouldn't be bundled with the incognito feature of not remembering history.
That's not what I'm suggesting. I want E2E to be separate from the "delete chats when I'm finished" feature.
Wanting an E2E chat that stays on my device when I'm done should be fine.
I'm fine with having E2E require a separate mode, but that shouldn't be bundled with the incognito feature of not remembering history.
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).
Are you assuming that all storage ends up on Google's servers (because that's what hangouts does, maybe)?
Why can't it store E2E chats locally and never upload to google, or even encrypt with a passphrase like Chrome sync does?
Why can't it store E2E chats locally and never upload to google, or even encrypt with a passphrase like Chrome sync does?
Congrats, you have dug it down to the core. Google just doesn't need chats that it can't mine for useful data.
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.
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.
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 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.
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.
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.
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.
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.
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.
Your phone federates your contacts, email, calendars, etc because those are all open protocols.
> 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?
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?
I've used NW and electron based applications and don't have chrome installed. Why is Chrome needed at all for those to work?
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.
it's a chrome app, you can launch it independently of chrome. At this point I don't know why they didn't go the Electron route.
Signal Desktop does not use GCM. You can use the extension with Chromium or any Chromium-based browser.
Really? Wow, how did I miss that... Thanks for correcting me!
Electron uses chromium as the renderer.
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]
[1] - https://lh3.googleusercontent.com/1ai7j4RhAwXDz33dFcS5xcxk1I...
[1] - https://lh3.googleusercontent.com/1ai7j4RhAwXDz33dFcS5xcxk1I...
Has anyone given this
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.
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.
Wire doesn't even encrypt chats and images, only calls.
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
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
Moxie replied in this Forbes article: http://www.forbes.com/sites/thomasbrewster/2016/05/11/wire-s...
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.
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".
[0] https://www.scribd.com/doc/311974670/Wire-Swiss-GmbH-v-Quiet...
[1] https://www.law.cornell.edu/wex/information_and_belief
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...
[1] https://www.law.cornell.edu/wex/information_and_belief
Here's an article including first hand account and quotes from Moxie: http://news.softpedia.com/news/wire-drops-lawsuit-alleging-e...
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.
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.
https://twitter.com/moxie/status/730230490653851648
https://twitter.com/moxie/status/730230320553828352
The Wire guys also withdrew the complaint.
https://twitter.com/moxie/status/730230320553828352
The Wire guys also withdrew the complaint.
> 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.
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.
So, https://github.com/WhisperSystems/libsignal-protocol-c is GPL3.
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.
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?
You kinda repeat yourself here, and it's not really a response to my post here.
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.
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.
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.
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...
When you're the author, you can publish your code under whatever license you want.
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.
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.
And what would be the reasoning for that?! It doesn't seem to make sense. It seems like another one of Apple's arbitrary rules.
[deleted]
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.
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.
Seriously? Oracle? Maybe this cultural reference will be clearer:
https://frinkiac.com/gif/S07E18/362795/366966/IExvb2sgb3V0IE...
This is FUD.
https://frinkiac.com/gif/S07E18/362795/366966/IExvb2sgb3V0IE...
This is FUD.
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'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.
Sorry, I'm just eager to deploy Frinkiac.
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.
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.
> accountable for what Oracle does with Java
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.
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.
Explanation for the wife beating comment: http://meta.stackexchange.com/questions/212706/on-using-phra...
[deleted]
[deleted]
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.
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.
Nadim had a legitimate and reasonable question.
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.
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 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.
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.)
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.)
>If he'd said that on HN he'd have been (I assume) banned
No he wouldn't.
https://news.ycombinator.com/item?id=5883501
https://news.ycombinator.com/item?id=6098474
No he wouldn't.
https://news.ycombinator.com/item?id=5883501
https://news.ycombinator.com/item?id=6098474
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.
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.
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.
What did he do? Does he know what he did? Do we ever get to find out? The people want answers.
fa9c5885a129a3dd5faf1b55bfdaf2d3e3a3de442bf6c817724febaa2b01bc71
Nadim has enough information to know what that hash corresponds to. Maybe he'll tell you. I won't. Not until I'm ready.
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 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.
> I think Hacker News should be better than this.
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 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.
"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?
[0] https://github.com/wireapp/proteus/tree/develop/src/intern
[1] https://github.com/WhisperSystems/libsignal-protocol-java/tr...
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...
The very code you linked to settles this:
// Based on libsignal-protocol-java by Open Whisper Systems
// Based on libsignal-protocol-java by Open Whisper Systems
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?
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?
"To conclude a messy lawsuit"? They're the ones who filed the lawsuit!
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.
Though I did just Google it, and throwing an extortion claim on top sounds... well, like a big mess.
[deleted]
> 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.
[0] https://github.com/wireapp/proteus
[1] https://github.com/WhisperSystems/libsignal-protocol-java
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
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.
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.
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.
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'd like to learn some possible reasons why one should avoid cryptocat, is there any material you could link for further reading?
Thank you
Thank you
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.
[0] https://tobtu.com/decryptocat.php
[1] https://nakedsecurity.sophos.com/2013/07/09/anatomy-of-a-pse...
* 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...
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.
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.
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.
From the Decryptocat post:
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 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 authors have been incompetent. Cryptocat has had several severe bugs that demonstrate cluelessness around fairly simple cryptographic stuff.
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...
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...
Thanks, amended my post.
According to https://twitter.com/moxie/status/730289041493483520 Moxie is fine with reimplementations.
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
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.But he's not happy with recompilation of Signal?
https://fdroid.eutopia.cz/
> Any other distribution channel we be treated as malware
> Any other distribution channel we be treated as malware
He isn't fine with anyone distributing unsigned or resigned Signal. What he says is more or less "my app, my signature".
The fdroid people could recompile, check that the binary matches the one Moxie signed, and distribute the one with Moxie's signature.
The fdroid people could recompile, check that the binary matches the one Moxie signed, and distribute the one with Moxie's signature.
I'm not sure I got it right.
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.
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.
Saving time and hand movement typing "LOL=)" could be quite an appeal, depending on how many times a day you're doing it.
"What if surveillance looked cute and lovable?" [1]
~Aral Balkan
[1] https://www.youtube.com/watch?v=jh8supIUj6c
~Aral Balkan
[1] https://www.youtube.com/watch?v=jh8supIUj6c
For someone concerned about privacy, it's baffling to me that we'd be forced into sharing our phone number in order to communicate.
Does this require a phone number like the rest of Open Whisper Systems products?
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.
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].
[1] https://xkcd.com/1129/
[1] https://xkcd.com/1129/
If you move internally within a country, sure. But when you actually move country, you'll need to get a new sim (or be charged roaming fees).
I live in Europe, and I've had 4 different phone numbers in the past 3 years.
I live in Europe, and I've had 4 different phone numbers in the past 3 years.
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.
* 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.
Over here (Germany) it commonly costs 30 bucks to transfer a phone number to another provider, at least if you are on cheap plans.
Changing counties comes to mind.
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.
Allo was announced at I/O to use your phone number as your identifier. It's a mobile-only app.
Ugh, how did this EVER catch on so much!?
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.
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.
[deleted]
I wonder how many other signal protocol integrations are in progress...
azet(2)
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.
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.
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.
"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.
It hasn't even launched yet; won't be out until later this Summer.
It's going to end up on a lot of Android phones. If it's any good, it will catch on. Hangouts hasn't caught on that much because, imho, it has bad UI.
Agreed.
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.
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.
The Hangouts mobile app is also incredibly buggy.
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."
The UI is awful (even as a very tech-savvy person I find it confusing!), and the web version only work properly on chrome/chromium.
>The two largest messaging platforms on the Internet
Wait, what? What is Allo?
Wait, what? What is 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.
If Android starts including it by default instead of Hangouts, then sure.
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.
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.
[deleted]
Skype is the last major messaging platform to not have end-to-end encryption in any way.
No, only WhatsApp has it. Facebook Messenger doesn't, SMS doesn't.
There's an option for SMS: https://silence.im/
(Yup, that's a TextSecure fork before Moxie had dropped encrypted SMS support.)
(Yup, that's a TextSecure fork before Moxie had dropped encrypted SMS support.)
Is Skype actually still considered a "MAJOR messaging platform"?
The article didn't make it clear. Will the two systems be able to interoperate?
Great news! Hopefully this also means that identity verification (through a key fingerprint) will be available in Allo (and in Duo?)
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).
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.
It's "Off The Record" in that they claimed not to store history. As I understand this is completely unrelated to the OTR encryption system.
I got rate limited so here's my late reply:
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.
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.
It has nothing to do with "off the record" check boxes in some UI.
akerro(1)
I really wonder what the people of allo.im are thinking now.
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.
Whoa, I wonder what the story is there. Did Google know this allo.im existed before naming their thing?
I suspect they don't care. And I'm guessing allo.im will get booted from the Play Store for using the same name as a Google product.
It's not in the US playstore, so it obviously doesn't exist.
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.
Moxie's on the record as being opposed to federated services.
https://whispersystems.org/blog/the-ecosystem-is-moving/
https://whispersystems.org/blog/the-ecosystem-is-moving/
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."
Also, as djb points out: https://twitter.com/hashbreaker/status/732912508089032706
Also, as djb points out: https://twitter.com/hashbreaker/status/732912508089032706
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.
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.
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.
[deleted]
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.
Why didn't Google just develop this in house? It almost feels like they're admitting to having no credibility on privacy without an external partner.
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.
Being open source or closed source doesn't make code more secure. What make code more secure is making it more secure. Have you audited the code?
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?
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?
The only reason I (somewhat) trust the encryption in Whatsapp is that it came from OpenWhisperSystems. For Allo, I imagine I'd feel the same.
Some of the value is in signalling to your users.
Some of the value is in signalling to your users.
Why bother if there is a ready solution, that's already got the trust of other market leaders?
I'd distinctly trust it more because Google didn't create it.
NN88(2)
* 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.