27 ms·

Reasons from @alexstamos (CSO @ Facebook): - FBM is multi-device, and we'd like to see E2E usability improve to support this. For now, pick one device and keys

Reasons from @alexstamos (CSO @ Facebook): - FBM is multi-device, and we'd like to see E2E usability improve to support this. For now, pick one device and keys never leave it - Secret conversations don't currently support popular features like searching message history, switching devices, voice/video, etc - Hundreds of millions use Messenger from a web browser. No secure way to verify code or store keys without routing through mobile. "We don't want to disrupt people's current experience." Source: https://twitter.com/alexstamos https://twitter.com/alexstamos

arximboldi 10y ago
Hundreds of millions use Messenger from a web browser. No secure way to verify code or store keys without routing through mobile. I wouldn't use the web version if they had not disabled Jabber access... and then I could use OTR. This trend makes me very sad... IM networks are getting more centralized as ever. I don't feel thankful for this kind of development. End-to-end encryption should not be a feature of the service provider, but the client. The way this works with Whatsapp/FB/Google just requires us to believe that their proprietary client is actually doing what it promises. And for me that I don't have a smartphone they just don't even promise anything. I just wish I could use XMPP or Matrix with my non-nerdy friends. There was this time Google seemed to not be evil with GTalk/XMPP, but then... The business cynicism that dominates this industry, allowing people to claim that they "connect people" at the same time that they put everyone in digital prisons, makes me really want to leave computing and go live in a cave.
- rvense 10y ago
  I honestly find this centralization as worrying as mass surveillance itself. I'm as afraid of the Facebooks of this world as I am of any government, and I don't want all my communication locked in with one company. This is why I will not use or recommend Signal. Moxie's anti-federation stance is unacceptable to me. It's replacing one problem with another.
  - bogomipz 10y ago
    Can you elaborate on the "anti-federation" stance of Signal's creator? I'm not familiar with this.
    - Arnt 10y ago
      You can't run your own signal server. All accounts use phone numbers in the same namespace as ID, and all messages go from the phone to opensystems.org, further on to google, and from google to the destination phone (with lots of encryption being added and removed at various points). This has advantages (it's difficult for the Man distinguish a received signal message from other android notifications) but also disadvantage (moxie can do traffic analysis and you can't do anything about it).
      - lorenzhs 10y ago
        You can totally run your own server for yourself and your friends: https://github.com/WhisperSystems/TextSecure-Server https://github.com/WhisperSystems/TextSecure-Server (you'll have to change the server's URL in the client's source as well and compile it yourself, but that's really easy) What you won't be able to do is federate with the official servers. Oh, and there's also a WebSocket transport (used by the Desktop client) that doesn't involve Google. That just doesn't provide a pleasant experience on mobile.
        rvense 10y ago
        Yeah, so instead of being in Whisper Systems' walled garden, I can set up my own and ask people to install Rvense's Magical Messenger App. Sit there in my treehouse with a bucket on my head and a NO DUMMIES sign or something.
        whyever 10y ago
        Seems like you want the advantages of both centralization and federation without any of the disadvantages.
- josho 10y ago
  > digital prisons Did you just coin that? It appropriately captures what is going on, but without having the positive connotation that comes from a 'walled garden'. I love the phrase. As an example outside of messaging, I have a fitbit and 'digital prison' so aptly describes what happens with my personal health data. I can't get my heart rate data out of their prison, because the fitbit warden doesn't see it fit to grant me the privilege to access my raw data.
  - dragonwriter 10y ago
    "Walled garden" is more appropriate than "digital prison". No one is being sentenced involuntarily to these enclosures, they are voluntarily choosing to accept them because of what is inside them.
    - Forbo 10y ago
      "Cult compound" is probably how I would describe it. Sure, you can leave, but there is immense social pressure to continue in what has become the norm, despite there clearly being something not okay with what is going on. And good luck convincing others to leave when you do.
      - schlowmo 10y ago
        Never heard "cult compound" in this context so far and by thinking about it I really think it better fits then "walled garden". "Walled garden" sounds like you go there because of its beauty or for getting the best crops while in reality you go there because it's the most crowded place.
        Karunamon 10y ago
        It's also one hell of a loaded term with things like Heavens Gate and Jim Jones having existed. To my knowledge, Facebook has yet to cause a mass suicide by people worshiping Zuckerberg.
        10y ago
- tsunamifury 10y ago
  Unfortunately your use case, while valid, is for a very small demographic. In general people want the guaranteed experience that locked in products give them. A lot of people like to sideline complain about that, but tech is no longer its own customer -- there are billions of users who have different preferences than us and they are a lot more lucrative.
  - WorldMaker 10y ago
    People opted into several of these services before they were "locked in", many of whom never noticed the switch of XMPP backplanes in Facebook Messages and GTalk. Some of them haven't even seemed to notice the loss of a few technically minded friends from their messenger windows, changes in branding, and or even really changes in apps. The ambivalence is not a preference or a "want" for a locked in experience. There isn't even a preference for a type of experience: the general human thought process is "I want to talk to my friend Jim" never "I want to use [Facebook Messenger/Google Hangouts/SMS/smoke signals] to talk to my friend Jim". I've seen people that ritualistically open certain apps to talk to certain friends and networks of friends, but have no idea what apps they are using beyond the background navigation needs of "the one with the fuzzy green icon on my last page" and "the blue one with the annoying notifications". Locked in platforms are a consequence of network efforts, not a "preference" for some mystical "guaranteed experience": the experience and the platform don't matter if the social interactions aren't there. The diaspora of communications platforms hasn't hit home to the average consumer yet, and it's currently background inconvenience that people are using five to ten different apps to communicate these days in some cases, but that doesn't mean average consumers are entirely ignorant of the situation either. (To some extent that's why OS-level notification systems have become so important to the average consumer; at least when you have a half-dozen messenging apps all the notifications arrive in the same place.)
- Arathorn 10y ago
  Enabling interoperable chat to non-nerdy friends is basically Matrix's raison d'être. We're not there yet (see https://matrix.org/blog/2016/07/04/the-matrix-summer-special/ https://matrix.org/blog/2016/07/04/the-matrix-summer-special... for the current status), but if we don't provide it we will have failed in the whole mission to defragment these silos, letting users choose which service to trust without losing interoperability. The good news is that the Olm end-to-end cryptographic ratchet that Matrix is in the process of deploying (https://matrix.org/git/olm https://matrix.org/git/olm) is built using the same algorithms as Signal Protocol's ratchet (although it's an independent implementation) - so we're hopeful that at least technically the window is open in future for using Matrix to defragment all the services who have adopted Signal Protocol (WhatsApp, Google Allo, FB Messenger, Signal itself etc) without compromising the E2E privacy. Right now this is total sci-fi, and won't likely happen (whilst preserving E2E crypto) without cooperation from FB, Google etc. However, we hope to get Matrix to the point where they see that the longer term benefits of participating in a healthy open ecosystem outweigh the short term benefits of trying to lock users into a silo - just as email eventually interoperated over the early internet. That's a while off, but this is still the goal. The best way to make sure this happens is to play with Matrix in its current form, and help us write bridges (e.g. https://github.com/matrix-org/matrix-appservice-bridge/blob/master/HOWTO.md https://github.com/matrix-org/matrix-appservice-bridge/blob/...) to interface as many silos as possible into Matrix. The more bridges, the more useful Matrix is, and the higher the chance of building an ecosystem which eventually Google, FB and friends will find attractive.
  - arximboldi 10y ago
    Thanks a lot for your work on Matrix. It is definitely one of the projects (like Syncthing, IPFS or GNU Social) that gives me enough hope to not run to the caves so early :)
  - mafuy 10y ago
    Sorry if this is a stupid question, can I store chat logs of all (even encrypted) conversations locally?
    - 10y ago
- free2rhyme214 10y ago
  Have you used Signal before? You don't have to use Whatsapp, Allo, or FB Messenger. It's just a pain to get people to download it.
captainmuon 10y ago
> No secure way to verify code or store keys without routing through mobile. Weeeeeeell, not quite. Every device and browser the user uses can get it's own private key, and then you use Facebook's central servers and SSL to exchange keys. If I don't trust Facebook for key exchange, then I can't trust them with their app. Any encryption they implement, they can trivially circumvent by putting a backdoor in their app. But if I trust their (closed source, frequently updated) app at all, then I can trust them to relay people my public keys. Especially since MITM can be discovered by comparing hashes over a hard to manipulate channel (telefone, video, or IRL). And if you're really paranoid, you could think about using an open-source app and letting a trusted third party handle the keys.
- egeozcan 10y ago
  Yes I completely agree. Actually, what is the difference in security between an app that generates a key pair on first use and exchanges the public key via a 3rd party servers and a web application doing exactly that. As long as the connection is secure and you trust the 3rd party for not having you send the private key to them, the model seems reasonably secure for both scenarios. Though public key exchange can be improved on mobile by better direct communication capabilities like barcode scanning, rfid, bluetooth etc. Am I missing something or is this more of a "JS is not reliably fast on all devices so we rather don't" kind of thing?
  - WorldMaker 10y ago
    I assume the issue is more to do with private key storage on the device. JS provides several local storage mechanisms, but none of them have cryptographic guarantees and all are potentially vulnerable to attacks like XSS and "attacks" like development console disclosure. There's been calls for the Web Application Platform to standardize on an HTML5 "Key Store" for cryptography, but thus far it doesn't sound like any consensus has been managed to be reached on how that key store would operate. Certainly, there are mitigations such as very short lived private keys and relying on existing sandboxing and XSS protections browsers already have to do for JS local storages, but it's easy to understand how from a paranoia standpoint there's no guaranteed safe key store just yet in a browser, especially not one backed up by OS-level security guarantees as one would be able to use on mobile devices.
Spooky23 10y ago
> "We don't want to disrupt people's current experience." Hahaha. Sounded plausible until I saw that line. When did FB suddenly start caring about that?
- exolymph 10y ago
  Doesn't ring true after how they ripped all messaging functions out of the main Facebook app and forced me to download Messenger.
  - ulber 10y ago
    The fact that "We don't want to disrupt people's current experience." did not previously outweigh other considerations does not mean it is not a consideration. It does imply an upper bound on the weight though.
mtgx 10y ago
That's all fine, but why isn't there a setting somewhere, where I can just knowingly choose "always use end-to-end encryption" at least? The way it's implemented now still makes it a pain/inconvenient thing to do when you want private conversations. So let's face it. Facebook just wants to get away with the minimum necessary to convey that it cares about privacy, while knowing that only 0.1% of the conversations will ever be encrypted this way.
moxie 10y ago
Signal Protocol already supports multi-device. We've encouraged them to enable that for Secret Conversations. Voice/video etc are obviously straightforward; hopefully they'll continue to iterate towards support for e2e by default.
- wmccullough 10y ago
  "Signal Protocol already supports multi-device" This is what I thought. If one were starting a new messaging platform, how would you implement the Signal protocol from scratch I wonder? I'm assuming for people who don't have strong security backgrounds, this means dissecting the Signal source code from Github.
  - niftich 10y ago
    > I'm assuming for people who don't have strong security backgrounds That's already a bad start. You mean inventing Signal from scratch (which is rough) or incorporating the libsignal protocol into a new messaging app? All of the libsignal repos have a good readme that explains init [1][2] , so you can start there. Browsing Signal source is helpful not so much to understand the protocol, but to see if any special precautions were taken against side-channel and other implementation pitfalls. I mean, you could contract moxie (hey moxie, what's your price?) EDIT: there's also this [3] independent implementation of libsignal in golang that tries to make some targeted modifications to fit their need. Can't vouch for its quality, but it's an interesting effort nonetheless. [1] https://github.com/WhisperSystems/libsignal-protocol-java https://github.com/WhisperSystems/libsignal-protocol-java [2] https://github.com/WhisperSystems/libsignal-service-java https://github.com/WhisperSystems/libsignal-service-java [3] https://github.com/OpenBazaar/libsignal https://github.com/OpenBazaar/libsignal
    - wmccullough 10y ago
      It may be a bad start, but if we want to see this implemented in many products at a large scale, you'll have to expect that not everyone is a security expert. I swear HN has become riddled with people who want to be contrarian for the sake of being so.
mtgx 10y ago
> "We don't want to disrupt people's current experience." You don't say? (not you, Facebook) How about the dozens of times Facebook disrupted the user experience of the service for its own benefit? How about the dozen+ times it changed people's settings from private to public, after people previously manually enabled a certain setting to be private, or after having a setting by default as private initially and letting people believe that such action is private? Wasn't THAT disrupting to users' experience? Of course it was. But it benefited Facebook, and that's the difference here. They just don't want to "disrupt" the experience in a way that also hurts the company's bottom line, even if it's better for users. In other words, it's just a weak excuse for not doing it by default, or at least allowing people to always set it as default (although knowing Facebook, I'd probably worry that they'd revert it back to non-E2E without even making it obvious that it did that. Announcing a new privacy policy change doesn't really count).
Siimteller 10y ago
Alex Stamos should check out https://wire.com https://wire.com (full disclosure: I work there) • E2EE by default, in groups too • Has solved the multi device, sync problem • Has webapp • Fingerprinting of all devices • Does not sacrifice features for security - voice, video, media • Crypto and comms protocols open source https://github.com/wireapp https://github.com/wireapp • Privacy and security whitepaper https://wire.com/privacy https://wire.com/privacy
- newscracker 10y ago
  I recently started using Wire and liked the richer feature set. But I'd say it still has some way to go on usability, features and speed. I hope you look at Telegram as an inspiration on those (not on crypto though, where you seem to have the one commonly accepted as the best).

arximboldi 10y ago

Hundreds of millions use Messenger from a web browser. No secure way to verify code or store keys without routing through mobile. I wouldn't use the web version if they had not disabled Jabber access... and then I could use OTR. This trend makes me very sad... IM networks are getting more centralized as ever. I don't feel thankful for this kind of development. End-to-end encryption should not be a feature of the service provider, but the client. The way this works with Whatsapp/FB/Google just requires us to believe that their proprietary client is actually doing what it promises. And for me that I don't have a smartphone they just don't even promise anything. I just wish I could use XMPP or Matrix with my non-nerdy friends. There was this time Google seemed to not be evil with GTalk/XMPP, but then... The business cynicism that dominates this industry, allowing people to claim that they "connect people" at the same time that they put everyone in digital prisons, makes me really want to leave computing and go live in a cave.

rvense 10y ago
I honestly find this centralization as worrying as mass surveillance itself. I'm as afraid of the Facebooks of this world as I am of any government, and I don't want all my communication locked in with one company. This is why I will not use or recommend Signal. Moxie's anti-federation stance is unacceptable to me. It's replacing one problem with another.
- bogomipz 10y ago
  Can you elaborate on the "anti-federation" stance of Signal's creator? I'm not familiar with this.
  - Arnt 10y ago
    You can't run your own signal server. All accounts use phone numbers in the same namespace as ID, and all messages go from the phone to opensystems.org, further on to google, and from google to the destination phone (with lots of encryption being added and removed at various points). This has advantages (it's difficult for the Man distinguish a received signal message from other android notifications) but also disadvantage (moxie can do traffic analysis and you can't do anything about it).
    - lorenzhs 10y ago
      You can totally run your own server for yourself and your friends: https://github.com/WhisperSystems/TextSecure-Server https://github.com/WhisperSystems/TextSecure-Server (you'll have to change the server's URL in the client's source as well and compile it yourself, but that's really easy) What you won't be able to do is federate with the official servers. Oh, and there's also a WebSocket transport (used by the Desktop client) that doesn't involve Google. That just doesn't provide a pleasant experience on mobile.
      - rvense 10y ago
        Yeah, so instead of being in Whisper Systems' walled garden, I can set up my own and ask people to install Rvense's Magical Messenger App. Sit there in my treehouse with a bucket on my head and a NO DUMMIES sign or something.
        whyever 10y ago
        Seems like you want the advantages of both centralization and federation without any of the disadvantages.
josho 10y ago
> digital prisons Did you just coin that? It appropriately captures what is going on, but without having the positive connotation that comes from a 'walled garden'. I love the phrase. As an example outside of messaging, I have a fitbit and 'digital prison' so aptly describes what happens with my personal health data. I can't get my heart rate data out of their prison, because the fitbit warden doesn't see it fit to grant me the privilege to access my raw data.
- dragonwriter 10y ago
  "Walled garden" is more appropriate than "digital prison". No one is being sentenced involuntarily to these enclosures, they are voluntarily choosing to accept them because of what is inside them.
  - Forbo 10y ago
    "Cult compound" is probably how I would describe it. Sure, you can leave, but there is immense social pressure to continue in what has become the norm, despite there clearly being something not okay with what is going on. And good luck convincing others to leave when you do.
    - schlowmo 10y ago
      Never heard "cult compound" in this context so far and by thinking about it I really think it better fits then "walled garden". "Walled garden" sounds like you go there because of its beauty or for getting the best crops while in reality you go there because it's the most crowded place.
      - Karunamon 10y ago
        It's also one hell of a loaded term with things like Heavens Gate and Jim Jones having existed. To my knowledge, Facebook has yet to cause a mass suicide by people worshiping Zuckerberg.
        10y ago
tsunamifury 10y ago
Unfortunately your use case, while valid, is for a very small demographic. In general people want the guaranteed experience that locked in products give them. A lot of people like to sideline complain about that, but tech is no longer its own customer -- there are billions of users who have different preferences than us and they are a lot more lucrative.
- WorldMaker 10y ago
  People opted into several of these services before they were "locked in", many of whom never noticed the switch of XMPP backplanes in Facebook Messages and GTalk. Some of them haven't even seemed to notice the loss of a few technically minded friends from their messenger windows, changes in branding, and or even really changes in apps. The ambivalence is not a preference or a "want" for a locked in experience. There isn't even a preference for a type of experience: the general human thought process is "I want to talk to my friend Jim" never "I want to use [Facebook Messenger/Google Hangouts/SMS/smoke signals] to talk to my friend Jim". I've seen people that ritualistically open certain apps to talk to certain friends and networks of friends, but have no idea what apps they are using beyond the background navigation needs of "the one with the fuzzy green icon on my last page" and "the blue one with the annoying notifications". Locked in platforms are a consequence of network efforts, not a "preference" for some mystical "guaranteed experience": the experience and the platform don't matter if the social interactions aren't there. The diaspora of communications platforms hasn't hit home to the average consumer yet, and it's currently background inconvenience that people are using five to ten different apps to communicate these days in some cases, but that doesn't mean average consumers are entirely ignorant of the situation either. (To some extent that's why OS-level notification systems have become so important to the average consumer; at least when you have a half-dozen messenging apps all the notifications arrive in the same place.)
Arathorn 10y ago
Enabling interoperable chat to non-nerdy friends is basically Matrix's raison d'être. We're not there yet (see https://matrix.org/blog/2016/07/04/the-matrix-summer-special/ https://matrix.org/blog/2016/07/04/the-matrix-summer-special... for the current status), but if we don't provide it we will have failed in the whole mission to defragment these silos, letting users choose which service to trust without losing interoperability. The good news is that the Olm end-to-end cryptographic ratchet that Matrix is in the process of deploying (https://matrix.org/git/olm https://matrix.org/git/olm) is built using the same algorithms as Signal Protocol's ratchet (although it's an independent implementation) - so we're hopeful that at least technically the window is open in future for using Matrix to defragment all the services who have adopted Signal Protocol (WhatsApp, Google Allo, FB Messenger, Signal itself etc) without compromising the E2E privacy. Right now this is total sci-fi, and won't likely happen (whilst preserving E2E crypto) without cooperation from FB, Google etc. However, we hope to get Matrix to the point where they see that the longer term benefits of participating in a healthy open ecosystem outweigh the short term benefits of trying to lock users into a silo - just as email eventually interoperated over the early internet. That's a while off, but this is still the goal. The best way to make sure this happens is to play with Matrix in its current form, and help us write bridges (e.g. https://github.com/matrix-org/matrix-appservice-bridge/blob/master/HOWTO.md https://github.com/matrix-org/matrix-appservice-bridge/blob/...) to interface as many silos as possible into Matrix. The more bridges, the more useful Matrix is, and the higher the chance of building an ecosystem which eventually Google, FB and friends will find attractive.
- arximboldi 10y ago
  Thanks a lot for your work on Matrix. It is definitely one of the projects (like Syncthing, IPFS or GNU Social) that gives me enough hope to not run to the caves so early :)
- mafuy 10y ago
  Sorry if this is a stupid question, can I store chat logs of all (even encrypted) conversations locally?
  - 10y ago
free2rhyme214 10y ago
Have you used Signal before? You don't have to use Whatsapp, Allo, or FB Messenger. It's just a pain to get people to download it.

captainmuon 10y ago

> No secure way to verify code or store keys without routing through mobile. Weeeeeeell, not quite. Every device and browser the user uses can get it's own private key, and then you use Facebook's central servers and SSL to exchange keys. If I don't trust Facebook for key exchange, then I can't trust them with their app. Any encryption they implement, they can trivially circumvent by putting a backdoor in their app. But if I trust their (closed source, frequently updated) app at all, then I can trust them to relay people my public keys. Especially since MITM can be discovered by comparing hashes over a hard to manipulate channel (telefone, video, or IRL). And if you're really paranoid, you could think about using an open-source app and letting a trusted third party handle the keys.

egeozcan 10y ago
Yes I completely agree. Actually, what is the difference in security between an app that generates a key pair on first use and exchanges the public key via a 3rd party servers and a web application doing exactly that. As long as the connection is secure and you trust the 3rd party for not having you send the private key to them, the model seems reasonably secure for both scenarios. Though public key exchange can be improved on mobile by better direct communication capabilities like barcode scanning, rfid, bluetooth etc. Am I missing something or is this more of a "JS is not reliably fast on all devices so we rather don't" kind of thing?
- WorldMaker 10y ago
  I assume the issue is more to do with private key storage on the device. JS provides several local storage mechanisms, but none of them have cryptographic guarantees and all are potentially vulnerable to attacks like XSS and "attacks" like development console disclosure. There's been calls for the Web Application Platform to standardize on an HTML5 "Key Store" for cryptography, but thus far it doesn't sound like any consensus has been managed to be reached on how that key store would operate. Certainly, there are mitigations such as very short lived private keys and relying on existing sandboxing and XSS protections browsers already have to do for JS local storages, but it's easy to understand how from a paranoia standpoint there's no guaranteed safe key store just yet in a browser, especially not one backed up by OS-level security guarantees as one would be able to use on mobile devices.

Spooky23 10y ago

> "We don't want to disrupt people's current experience." Hahaha. Sounded plausible until I saw that line. When did FB suddenly start caring about that?

exolymph 10y ago
Doesn't ring true after how they ripped all messaging functions out of the main Facebook app and forced me to download Messenger.
- ulber 10y ago
  The fact that "We don't want to disrupt people's current experience." did not previously outweigh other considerations does not mean it is not a consideration. It does imply an upper bound on the weight though.

mtgx 10y ago

That's all fine, but why isn't there a setting somewhere, where I can just knowingly choose "always use end-to-end encryption" at least? The way it's implemented now still makes it a pain/inconvenient thing to do when you want private conversations. So let's face it. Facebook just wants to get away with the minimum necessary to convey that it cares about privacy, while knowing that only 0.1% of the conversations will ever be encrypted this way.

moxie 10y ago

Signal Protocol already supports multi-device. We've encouraged them to enable that for Secret Conversations. Voice/video etc are obviously straightforward; hopefully they'll continue to iterate towards support for e2e by default.

wmccullough 10y ago
"Signal Protocol already supports multi-device" This is what I thought. If one were starting a new messaging platform, how would you implement the Signal protocol from scratch I wonder? I'm assuming for people who don't have strong security backgrounds, this means dissecting the Signal source code from Github.
- niftich 10y ago
  > I'm assuming for people who don't have strong security backgrounds That's already a bad start. You mean inventing Signal from scratch (which is rough) or incorporating the libsignal protocol into a new messaging app? All of the libsignal repos have a good readme that explains init [1][2] , so you can start there. Browsing Signal source is helpful not so much to understand the protocol, but to see if any special precautions were taken against side-channel and other implementation pitfalls. I mean, you could contract moxie (hey moxie, what's your price?) EDIT: there's also this [3] independent implementation of libsignal in golang that tries to make some targeted modifications to fit their need. Can't vouch for its quality, but it's an interesting effort nonetheless. [1] https://github.com/WhisperSystems/libsignal-protocol-java https://github.com/WhisperSystems/libsignal-protocol-java [2] https://github.com/WhisperSystems/libsignal-service-java https://github.com/WhisperSystems/libsignal-service-java [3] https://github.com/OpenBazaar/libsignal https://github.com/OpenBazaar/libsignal
  - wmccullough 10y ago
    It may be a bad start, but if we want to see this implemented in many products at a large scale, you'll have to expect that not everyone is a security expert. I swear HN has become riddled with people who want to be contrarian for the sake of being so.

mtgx 10y ago

> "We don't want to disrupt people's current experience." You don't say? (not you, Facebook) How about the dozens of times Facebook disrupted the user experience of the service for its own benefit? How about the dozen+ times it changed people's settings from private to public, after people previously manually enabled a certain setting to be private, or after having a setting by default as private initially and letting people believe that such action is private? Wasn't THAT disrupting to users' experience? Of course it was. But it benefited Facebook, and that's the difference here. They just don't want to "disrupt" the experience in a way that also hurts the company's bottom line, even if it's better for users. In other words, it's just a weak excuse for not doing it by default, or at least allowing people to always set it as default (although knowing Facebook, I'd probably worry that they'd revert it back to non-E2E without even making it obvious that it did that. Announcing a new privacy policy change doesn't really count).

Siimteller 10y ago

Alex Stamos should check out https://wire.com https://wire.com (full disclosure: I work there) • E2EE by default, in groups too • Has solved the multi device, sync problem • Has webapp • Fingerprinting of all devices • Does not sacrifice features for security - voice, video, media • Crypto and comms protocols open source https://github.com/wireapp https://github.com/wireapp • Privacy and security whitepaper https://wire.com/privacy https://wire.com/privacy

newscracker 10y ago
I recently started using Wire and liked the richer feature set. But I'd say it still has some way to go on usability, features and speed. I hope you look at Telegram as an inspiration on those (not on crypto though, where you seem to have the one commonly accepted as the best).