Open Whisper Systems Partners with Google on End-To-end Encryption for Allo
whispersystems.org
whispersystems.org
* 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.
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
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 :)
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=bikioccmkafdpakkkcpdbppfkghcmihkSmall 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.
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) .
Still: wish less companies would be fine with shipping web apps that break in one or more of modern browsers.
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 don't get it
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.
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.
Anything that reinforces this automatically qualifies as bad (and I'm only partially joking here ;-)
How many times have you been to a webapp and it said "Your browser is not supported, for best results please use Google Chrome."
An incognito mode allows the default mode to have more functionality, and matches their approach with Chrome. It's not a bad tradeoff.
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.
It's not ephemeral messaging like Snapchat or something, although they are discussing it as a future feature.
>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?
>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.
UX simplicity is, in fact, a reason.
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.
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.
Why can't it store E2E chats locally and never upload to google, or even encrypt with a passphrase like Chrome sync does?
Of course they won't be open about this, because they're making the world a better place <insertcuteemojihere>
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.
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.
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.
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.
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.
Providing separate options would make it easier to make mistakes.
* 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.
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.
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.
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.
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.
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.
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.
Generally, we've taken a big step backwards where chat is concerned.
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?
[1] - https://lh3.googleusercontent.com/1ai7j4RhAwXDz33dFcS5xcxk1I...
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.
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.
If I implement haskell-signal and consult documentation and the code to understand the protocol but do not copy code, it's not clean room, but Open Whisper wants to see the protocol spread, so it's in their interest to more clearly state how someone is allowed to reimplement Signal in Common Lisp or FORTH, if one were so inclined, and release it under MIT.
I found the answer from a sibling post: https://twitter.com/moxie/status/730289041493483520
Moxie should use this incident to prominently make it clear in the protocol documentation that independent implementations are welcome. That's our best bet until there's an IETF RFC based on Axolotol everyone can implement instead.
https://frinkiac.com/gif/S07E18/362795/366966/IExvb2sgb3V0IE...
This is FUD.
I'm not sure if you're missing the context. This branch of the thread forked off me asking the same thing as another poster, namely the likelihood of being bothered by IP or Copyright claims for a real, proper clean room implementation of the protocol, zero code copied, assuming there is sufficient documentation available.
Oracle vs Google is relevant, but it seems we're talking past each other and maybe I'm missing a point you're making.
I simply disagree with you that Moxie Marlinspike is in any way accountable for what Oracle does with Java.
I also take exception to the argument that Open Whisper Systems needs to do something to mitigate your false impression that they've disallowed developers from using their documentation. They have not, nobody has credibly claimed otherwise, even the Wire people, and so I don't think it's proper to suggest that OWS take this "opportunity" to address a fictitious concern.
Maybe my English is imprecise, but that's not what I tried to express. We may have to disagree that the OracleVsGoogle fallout is relevant in the hypothetical case of Axolotl IP, but as we're both not lawyers, it's moot to continue that debate.
> I don't think it's proper to suggest
It wouldn't cost Moxie anything to clear such concerns, even if it's just a handful of HN reader (including me), in light of this public event and would increase the positive profile of the protocol. You make it seem like by documenting that clearly Moxie would admit to doing something, but that's wrong and a curious way to look at things, especially as you're confident of there being no problem like that.
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.
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.
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.
https://twitter.com/moxie/status/730230320553828352
The Wire guys also withdrew the complaint.
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.
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...
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.
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.
Given that I'm mentioned by name (and tied to a bunch of exaggerated claims), I'd like to clarify a few points.
1. I never claimed that a GPL violation was impossible because of different programming languages. I merely questioned whether this was the case with Wire's Rust codebase [0], given that its data structures, namespacing etc. are substantially different from the OWS Java code [1]. To me, different code organization + different implementation style + different programming language don't exactly amount to a line-by-line conversion from Java to Rust as OWS seems to be claiming.
2. Cryptocat does not compete with Signal: it's a desktop XMPP client that focuses on synchronous messaging (that I write in my free time and with no funding or business plan, to boot), and does not at all target the mobile space. I was very happy to adopt a variant of Signal Protocol into Cryptocat and consider Signal's contributions to the field of secure messaging to be highly valuable. I'm not sure why tptacek brings up Cryptocat (completely unrelated to this discussion) but by all means, don't avoid it! The recent rewrite is pretty good, actually.
Overall, this situation just struck me as very ugly. Moxie seemed at some point to be reticent to allow fully independent implementations of the protocol, and Wire's lawsuit was pretty aggressive. Both parties locked in a catfight and then (apparently?) realized their approaches were counterproductive and gave it up.
The best resolution here, in my view, would have been for Moxie to publish a public-domain reference specification document of Signal Protocol that's independent of the code, and for Wire to be allowed to write a Rust implementation of it without any party causing drama.
[0] https://github.com/wireapp/proteus
[1] https://github.com/WhisperSystems/libsignal-protocol-java
Your messages on Twitter are right there for everyone to read.
Here's a helpful starting point:
https://twitter.com/kaepora/status/730165751240364033
The preceding link where you referred, unbidden, to Moxie's last post about their take on federation for their own implementation of Signal as a "dishonest rant" is left as an exercise for the reader.
Thank you
* AES-CTR counter-reuse (2012)
* Biased Fortuna CSPRNG implementation [1] (2013)
To be sure, Cryptocat's substandard reputation was well-deserved; but all the same, I think that every vulnerability that did pop up was addressed responsibly and with full disclosure.
Since then, there has been a major rewrite that I am conversely quite happy with.
[0] https://tobtu.com/decryptocat.php
[1] https://nakedsecurity.sophos.com/2013/07/09/anatomy-of-a-pse...
Steve was paid two separate bug bounties and invited to a Cryptocat hackathon in NYC. I also consider him a friend and never heard a complaint from him regarding the project's disclosure policies.
The bug that lasted 347 days was the confusion between a string and an array of integers. This made the ECC private keys ridiculously small because they passed a string of decimal digits into a function expecting an array of 17, 15 bit integers. Each character was considered an element in the array. So each of those "15 bit integers" were only the values 0 to 9 (3.32 bits). Also the least significant 3 bits are zeroed giving you a key space of 210^16 (2^54.15).*
When they fixed that bug the commit message was: "Fix private key format to match curve25518-donna. THIS BREAKS COMPATIBILITY WITH PREVIOUS CRYPTOCAT VERSIONS." Even though this does not break compatibility at all. I don't know if they knew what they fixed and just wanted to slide this under the radar or they legitimately believe that. Both are scary one is violating their principles "Cryptocat is developed under a principle of radical transparency" and the other is just incompetence. There is a blog post by them saying this is inaccurate. Apparently they have too many serious bugs to keep straight. That they don't know which one breaks compatibility. The other error in the change log for version 2.0.42 is a bug where the counter in AES-CTR is reused. This means the first 32 bytes of your messages are easy to decipher with no effort at all. Which breaks compatibility, but everywhere they mention compatibility they say key generation.
Good for his consulting rate, no doubt, but probably not good for society.
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...
And indeed, with a quick browse through the Wire [0] and OWS [1] repositories I just can't find any kind of commonalities at all. Not in the structure, not in the comments, not in naming, not in the data structures, etc. Am I missing something, is there anything at all in the code itself that suggests the two codebases are related in any way at all? Or is the "GPL's OWS code" you refer to something else entirely?
[0] https://github.com/wireapp/proteus/tree/develop/src/intern
[1] https://github.com/WhisperSystems/libsignal-protocol-java/tr...
// Based on libsignal-protocol-java by Open Whisper Systems
If there's GPL violation and code was copied, there should be some traces of that. Is it truly so unreasonable to ask what those traces were?
Though I did just Google it, and throwing an extortion claim on top sounds... well, like a big mess.
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 don't think it should. I think us pretending that we are some group of regal statesmen is a bunch of pretentious bullshit.
Being civil is preferable, but not if it means being fake.
People aren't any less "mean" on HN, they're just good at bullying in more subtle ways, and we are all worse off for it.
I don't understand this. Everything is fake to some degree. Being civil is a good thing.
The knives are out for Signal. It's not hard to see that. Of the "independent" messaging schemes, Signal is probably the only one that has a chance of relevance 5 years from now. Everyone else is working on something that will be a checkbox feature for Apple, Google, Microsoft and Facebook in less time than that.
I'm happy about that. Clearly, not everyone else is.
Which is exactly why I, even though I don't care much for drama (infosec drama especially), find myself "complaining" about Signal from time to time. Because we are going to have to live with it. If I could go back and "complain" about PGP, before that became the preferred "just use" argument, I would.
What did he do? Does he know what he did? Do we ever get to find out? The people want answers.
Nadim has enough information to know what that hash corresponds to. Maybe he'll tell you. I won't. Not until I'm ready.
I'm not sure how linking to twitter supports your comment that HN needs to improve. If he'd said that on HN he'd have been (I assume) banned. dang is constantly asking people not to be mean or dumb, or banning people for being mean.
dang is great. I just wish we had a bit less negativity.
--
Finally, a brief history for readers who dont know yet:
* Cryptocat v1 was a cat themed anonymous chat webapp with very broken homebrew encryption. It was basically Nadim's crypto learning project as far as I can tell when he was ~20 years old.
* Snowden allegedly used it at some point. Oops.
* Crypto experts reviewed it and found significant flaws. Tptacek wrote about how terrible it was, how JS crypto is Considered Harmful, how amateurs shouldn't write crypto because they could get someone killed, etc
* Cryptocat v2 a desktop chat app using Axolotl / Signal Protocol for e2e encryption. Nadim is a phd student now. It's a new and totally separate codebase.
tldr; there's no reason to assume that Cryptocat v2 sucks in the ways the original did. It may be totally sound.
(I have no involvement w the project and have not reviewed the code.)
No he wouldn't.
Quoting
If you'd like to do the work of developing a strong copyleft
version of the GPL that you feel is appropriate for use in the
app store, and get it OSI approved, we'd certainly look at
using that.
We'd like to get this better documented [...] It's a priority [...]
hopefully we'll have more to publish this year.
We haven't patented any of the concepts here, and we've done a
lot to explain and popularize them. We're happy for people to
use these concepts to build their own implementations of similar
protocols, but we don't want people slapping things together and
calling that Signal Protocol.> Any other distribution channel we be treated as malware
The fdroid people could recompile, check that the binary matches the one Moxie signed, and distribute the one with Moxie's signature.
On March 10, 2016 Wire rolled out end-to-end encryption and from that on everything (chat, photos, files, video messages, all calls) are end-to-end encrypted. More + security whitepaper at wire.com/privacy
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.
It might do well, but it could also easily be a flop (as many other social initiatives from Google have been). Either way it's a long ways from catching up to WeChat, Viber, or even Facebook Messenger.
Hangouts didn't catch on because it was delivered as a group video calling service that then also did (or perhaps became about?) text, even becoming the default SMS app on Android.
It also hasn't caught on because it is overly complex. With any other video calling service you call a person and they have a conversation with you - of you initiate a group conference and off you go.
Hangout needs you to invite someone, but then what - you're still having this video broadcast by yourself? Actually, is it a broadcast? Can other people just join in? Apparently they could depending on your settings (in the past), but not this seems to have been separated to 'Hangouts On Air'? Who knows, I don't see why I should bother looking into it when there are clearer options available.
I love me some Google, so don't misunderstand me, and Duo is a big step in the right direction for the average users experience compared to Hangouts.
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.
Wait, what? What is Allo?
(Yup, that's a TextSecure fork before Moxie had dropped encrypted SMS support.)
Also, as djb points out: https://twitter.com/hashbreaker/status/732912508089032706
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.
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.
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.
~Aral Balkan
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 live in Europe, and I've had 4 different phone numbers in the past 3 years.
* 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.
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.
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).
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.
It has nothing to do with "off the record" check boxes in some UI.
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?
Some of the value is in signalling to your users.