Why I won't recommend Signal anymore(sandervenema.ch)
sandervenema.ch
Why I won't recommend Signal anymore
https://sandervenema.ch/2016/11/why-i-wont-recommend-signal-anymore/
349 comments
I agree overwhelmingly with what you wrote, except that I want to point out that this isn't "crypto-puritanism". It's just hipsterism. The author isn't a cryptographer, and if you asked a panel of 10 cryptographic engineers what messaging system they'd recommend, 9 of them would say "Signal".
The 10th wants you to use something else because they're working on an attack for that "something else", and want their paper to be splashier when it's released. :)
When reading critiques of messaging software, keep in mind that messaging is a fucking midnight back-alley knife fight of a market. For whatever reason --- I think because (a) basic chat software is pretty easy to write, with a near- hello- world payoff similar to, say, blog software for Ruby on Rails and (b) because there have been multi-billion-dollar acquisitions of messaging tools --- there are a lot of different messaging products. Messaging is a network-effect market, so all the different vendors are fighting for users.
I don't think Signal has sockpuppets (it's just not their style), but I know several other "secure" messaging applications do.
The 10th wants you to use something else because they're working on an attack for that "something else", and want their paper to be splashier when it's released. :)
When reading critiques of messaging software, keep in mind that messaging is a fucking midnight back-alley knife fight of a market. For whatever reason --- I think because (a) basic chat software is pretty easy to write, with a near- hello- world payoff similar to, say, blog software for Ruby on Rails and (b) because there have been multi-billion-dollar acquisitions of messaging tools --- there are a lot of different messaging products. Messaging is a network-effect market, so all the different vendors are fighting for users.
I don't think Signal has sockpuppets (it's just not their style), but I know several other "secure" messaging applications do.
I think these types of posts are also the inevitable result of people overestimating our organizational capacity based on whatever limited success Signal and Signal Protocol have had. It could be that the author imagines me sitting in a glass skyscraper all day, drinking out of champagne flutes, watching over an enormous engineering team as they add support for animated GIF search as an explicit fuck you to people with serious needs.
I invite those who have opinions about Signal to start by getting involved in the project. To my knowledge the author of this blog post has never submitted a PR, issue, or discussion post to any of our repositories or forums. Many of these points are things that we would like to address, and we could use the help. The day to day reality of developing apps like these is a lot of work.
To provide some color on a few of these:
> Dependency on Google Cloud Messaging
To clarify this for casual readers, no data at all is transmitted over GCM. GCM is only used as a push event to tell the Signal Android client to wake up and connect to the Signal server to retrieve messages from the queue if the app isn't in the foreground.
This is pretty fundamentally just how Android works. However, people who want to use Google's OS without any Google services flash custom ROMs onto their devices that are missing this dependency.
I have said many times that I have no problem with supporting these custom ROMs. But I would like someone from that community to submit the PR: "I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services."
Nobody has done it.
> Your contact list is not private
First, on Android 6+ you can just disable the contacts permission and everything works (although you obviously won't see your contact names).
However, we also spend a lot of time thinking about this class of problems, as well as metadata in general. Right now things are playing out alright for one specific class of attack:
https://whispersystems.org/bigbrother/eastern-virginia-grand...
We'd obviously like to do even better. The nice thing about having a centralized service is that we can eventually take steps in this direction. People seem to equate federation with meta-data hiding for reasons I've never totally understood, but I think serious metadata protection is going to require new protocols and new techniques, so we're much more likely to see major progress in centralized rather than distributed environments (in the same way that Signal Protocol is now on over two billion devices, but we're unlikely to ever see even basic large scale email end to end encryption).
> Lack of federation
I've tried to write about why I don't feel like this is going to be a part of our future here: https://whispersystems.org/blog/the-ecosystem-is-moving/
However, I would love it if someone proved me wrong. The Signal clients and server already support federation, so there shouldn't be any technical hurdles stopping the people who are really into federation from using our software to start their own federated network that demonstrates the viability of their ideas.
If anyone needs help doing that, let me know. I'd be happy to help.
I invite those who have opinions about Signal to start by getting involved in the project. To my knowledge the author of this blog post has never submitted a PR, issue, or discussion post to any of our repositories or forums. Many of these points are things that we would like to address, and we could use the help. The day to day reality of developing apps like these is a lot of work.
To provide some color on a few of these:
> Dependency on Google Cloud Messaging
To clarify this for casual readers, no data at all is transmitted over GCM. GCM is only used as a push event to tell the Signal Android client to wake up and connect to the Signal server to retrieve messages from the queue if the app isn't in the foreground.
This is pretty fundamentally just how Android works. However, people who want to use Google's OS without any Google services flash custom ROMs onto their devices that are missing this dependency.
I have said many times that I have no problem with supporting these custom ROMs. But I would like someone from that community to submit the PR: "I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services."
Nobody has done it.
> Your contact list is not private
First, on Android 6+ you can just disable the contacts permission and everything works (although you obviously won't see your contact names).
However, we also spend a lot of time thinking about this class of problems, as well as metadata in general. Right now things are playing out alright for one specific class of attack:
https://whispersystems.org/bigbrother/eastern-virginia-grand...
We'd obviously like to do even better. The nice thing about having a centralized service is that we can eventually take steps in this direction. People seem to equate federation with meta-data hiding for reasons I've never totally understood, but I think serious metadata protection is going to require new protocols and new techniques, so we're much more likely to see major progress in centralized rather than distributed environments (in the same way that Signal Protocol is now on over two billion devices, but we're unlikely to ever see even basic large scale email end to end encryption).
> Lack of federation
I've tried to write about why I don't feel like this is going to be a part of our future here: https://whispersystems.org/blog/the-ecosystem-is-moving/
However, I would love it if someone proved me wrong. The Signal clients and server already support federation, so there shouldn't be any technical hurdles stopping the people who are really into federation from using our software to start their own federated network that demonstrates the viability of their ideas.
If anyone needs help doing that, let me know. I'd be happy to help.
> However, I would love it if someone proved me wrong. The Signal clients and server already support federation, so there shouldn't be any technical hurdles stopping the people who are really into federation from using our software to start their own federated network that demonstrates the viability of their ideas.
> If anyone needs help doing that, let me know. I'd be happy to help.
I appreciate that you would say this. I suspected that you actually felt this way despite your pragmatic approach outlined in that blog post. I'm a fan of federation, but I think the developers of federated systems have to take the problems outlined in your blog post very seriously and not defensively.
> If anyone needs help doing that, let me know. I'd be happy to help.
I appreciate that you would say this. I suspected that you actually felt this way despite your pragmatic approach outlined in that blog post. I'm a fan of federation, but I think the developers of federated systems have to take the problems outlined in your blog post very seriously and not defensively.
Push notifications without GCM can be done without losing reliability or ruining battery life, but it's difficult. There are a few apps like Conversations doing it well but it's quite rare. GCM is still technically more efficient since it's reused across multiple apps, but it doesn't really matter especially without a large number of apps doing this.
There's already a built-in warning on modern Android because apps need to request a battery optimization exception just as they would one of the dangerous permissions. Otherwise, GCM is the only way they be woken during Doze / App Standby for push notifications. Apps can't simply poll anymore. It's unfortunate that even an app doing a great job like Conversations gets a warning / prompt about this but there's little that can be done about that beyond the OS whitelisting the keys for known good apps.
Conversations is pretty much the only viable option without GCM. It uses a take on the Signal protocol via XMPP (when supported by the other contact) so you helped to make that happen anyway.
There's already a built-in warning on modern Android because apps need to request a battery optimization exception just as they would one of the dangerous permissions. Otherwise, GCM is the only way they be woken during Doze / App Standby for push notifications. Apps can't simply poll anymore. It's unfortunate that even an app doing a great job like Conversations gets a warning / prompt about this but there's little that can be done about that beyond the OS whitelisting the keys for known good apps.
Conversations is pretty much the only viable option without GCM. It uses a take on the Signal protocol via XMPP (when supported by the other contact) so you helped to make that happen anyway.
Thanks for the clarifications.
> First, on Android 6+ you can just disable the contacts permission and everything works (although you obviously won't see your contact names).
This is very good.
> However, we also spend a lot of time thinking about this class of problems, as well as metadata in general. Right now things are playing out alright for one specific class of attack: [federal subpoena]
Good, so Open Whisper Systems has no metadata. Do any third parties retain metadata about Signal messages?
There's also the issue of mobile numbers. I get that more-or-less anonymous numbers are doable. But arguably, most Signal users don't have anonymous numbers. However, maybe this is a non-issue, if the only data available are "the date and time a user registered with Signal and the last date of a user's connectivity to the Signal service". Is that it?
> First, on Android 6+ you can just disable the contacts permission and everything works (although you obviously won't see your contact names).
This is very good.
> However, we also spend a lot of time thinking about this class of problems, as well as metadata in general. Right now things are playing out alright for one specific class of attack: [federal subpoena]
Good, so Open Whisper Systems has no metadata. Do any third parties retain metadata about Signal messages?
There's also the issue of mobile numbers. I get that more-or-less anonymous numbers are doable. But arguably, most Signal users don't have anonymous numbers. However, maybe this is a non-issue, if the only data available are "the date and time a user registered with Signal and the last date of a user's connectivity to the Signal service". Is that it?
> Good, so Open Whisper Systems has no metadata. Do any third parties retain metadata about Signal messages?
I'll try to answer to the best of my knowledge (I'm not associated with project, I'm just a happy customer).
Does your ISP know that you are communicating with Signal servers? Yes, IP addresses.
Does it know to whom you are sending messages? No.
Does Google know you are using Signal? Yes.
Does it know whom of your contacts use Signal? Yes, because they have a full list of your contacts and they know if someone has installed Signal.
Does Google know you've sent a message? No.
Does Google know that you are receiving a message? Sometimes, because Signal servers ping your device via GCM with "wake up".
Does Google knows who from your contact list send this message? No, unless you have only one contact who uses Signal.
Can Google infer from pings who is communicating with whom? Yes, although pings are needed only if app has disconnected from server, and this severely limits usefulness of this technique.
Where else may any metadata coming from usage of Signal be? Nowhere.
As for Google having your contact list... Take a look into Flock.
I'll try to answer to the best of my knowledge (I'm not associated with project, I'm just a happy customer).
Does your ISP know that you are communicating with Signal servers? Yes, IP addresses.
Does it know to whom you are sending messages? No.
Does Google know you are using Signal? Yes.
Does it know whom of your contacts use Signal? Yes, because they have a full list of your contacts and they know if someone has installed Signal.
Does Google know you've sent a message? No.
Does Google know that you are receiving a message? Sometimes, because Signal servers ping your device via GCM with "wake up".
Does Google knows who from your contact list send this message? No, unless you have only one contact who uses Signal.
Can Google infer from pings who is communicating with whom? Yes, although pings are needed only if app has disconnected from server, and this severely limits usefulness of this technique.
Where else may any metadata coming from usage of Signal be? Nowhere.
As for Google having your contact list... Take a look into Flock.
Thanks :)
I get that Signal is probably the best option for smartphones. And that maybe its vulnerabilities are only relevant for "TAO targets". But the problem is that "TAO targets" is in rapid flux, given developments in automation and AI. So arguably, more and more journalists and dissidents are becoming vulnerable.
And there's the fundamental insecurity of devices with cellular-radio connectivity, and operating systems that users can't control and lock down. Signal can do nothing about that. Even something as simple as reliably obscuring identity in connections to Signal servers is nontrivial.
I get that Signal is probably the best option for smartphones. And that maybe its vulnerabilities are only relevant for "TAO targets". But the problem is that "TAO targets" is in rapid flux, given developments in automation and AI. So arguably, more and more journalists and dissidents are becoming vulnerable.
And there's the fundamental insecurity of devices with cellular-radio connectivity, and operating systems that users can't control and lock down. Signal can do nothing about that. Even something as simple as reliably obscuring identity in connections to Signal servers is nontrivial.
> But the problem is that "TAO targets" is in rapid flux, given developments in automation and AI.
You are implying that cost of TAO consists mostly of labor costs. Which is false. NSA and friends are not really limited by money. They are limited by amount of unpatched software vulnerabilities. Every use of vulnerability in the wild is a chance of revealing it to world and losing it. Snowden docs reveal the existence of automated software which evaluates chance of vulnerability being revealed by attack. XKeyScore or one of related pieces, AFAIR.
You are implying that cost of TAO consists mostly of labor costs. Which is false. NSA and friends are not really limited by money. They are limited by amount of unpatched software vulnerabilities. Every use of vulnerability in the wild is a chance of revealing it to world and losing it. Snowden docs reveal the existence of automated software which evaluates chance of vulnerability being revealed by attack. XKeyScore or one of related pieces, AFAIR.
Does Google know you are using Signal?
Does it know whom of your contacts use Signal?
Does Google know you've sent a message?
Does Google know that you are receiving a message?
Does Google knows who from your contact list send this message?
Can Google infer from pings who is communicating with whom?
Yes to all of those, because they have root on your phone.
Does it know whom of your contacts use Signal?
Does Google know you've sent a message?
Does Google know that you are receiving a message?
Does Google knows who from your contact list send this message?
Can Google infer from pings who is communicating with whom?
Yes to all of those, because they have root on your phone.
You are assuming that Android reports on every step you take. Do you have sources backing this claim?
It's nearly impossible to find out. But if I trust corporations like Google not to exploit the possibilities, I wouldn't be looking for an open-source alternative to WhatsApp in the first place.
Signal is not positioned as a tool for possible TAO targets. Never was, and never will be. Don't use it and please stop spreading the FUD.
> Signal is not positioned as a tool for possible TAO targets. Never was, and never will be.
Eh, that’s exactly what it is currently advertised as.
A tool, supported by Snowden, to be used by journalists who are at risk of being under active surveillance by state actors.
That is the very definition of a TAO target.
Eh, that’s exactly what it is currently advertised as.
A tool, supported by Snowden, to be used by journalists who are at risk of being under active surveillance by state actors.
That is the very definition of a TAO target.
You shouldn't use a smartphone if you expect to be TAO. Even the hardware could be compromised. Use a laptop with Linux for anything anyone might want to track...
Then why is Moxie advertising with Snowden the Signal app as communication for TAO targets?
And for non-TAO targets, WhatsApp is just as good as Signal – the users won’t read the source code anyway, and in both cases President Trump gets your social graph.
And for non-TAO targets, WhatsApp is just as good as Signal – the users won’t read the source code anyway, and in both cases President Trump gets your social graph.
What exactly is a TAO target?
https://en.m.wikipedia.org/wiki/Tailored_Access_Operations
Aka NSA's "we really need to get access to this device and will fund diverting backbone traffic / writing firmware malware / whatever else we need to in order to get it" team(s).
Aka NSA's "we really need to get access to this device and will fund diverting backbone traffic / writing firmware malware / whatever else we need to in order to get it" team(s).
Tailored Access Operations from the NSA
terrible acronym obviously
Google has root on your phone. Even if they aren't "for now", good security sense says that we should assume that are.
It did formerly via Carrier IQ, which was widely reported in the press. So that's not unprecedented.
> I invite those who have opinions about Signal to start by getting involved in the project.
Yeah we've been there. Do you remember someone on Github complaining about the Google dependency? You closed that issue as a wontfix. Or LibreSignal? I read the post where you basically told them to go away on Github too.
That's why I haven't recommended Signal ever since trying it myself a year or two ago.
Yeah we've been there. Do you remember someone on Github complaining about the Google dependency? You closed that issue as a wontfix. Or LibreSignal? I read the post where you basically told them to go away on Github too.
That's why I haven't recommended Signal ever since trying it myself a year or two ago.
Downvotes but no comments. What is wrong with what I said?
> You closed that issue as a wontfix
Not sure what you're talking about, because the issues in question, #127 and #1000, are open.
> you basically told them to go away on Github
Quite the opposite [1]:
"I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services."
[1] https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
Not sure what you're talking about, because the issues in question, #127 and #1000, are open.
> you basically told them to go away on Github
Quite the opposite [1]:
"I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services."
[1] https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
Plus the complaint about giphy seems to completely miss the point that the more 'random messaging users' Signal attracts the better from a POV of deniability/etc.
Although the masking effect may be useful, my immediate thought was how much extra code and buffer overflows had been added to the client. Android doesn't have any sandbox mechanism like pnacl to contain such code.
The code in question is written in Java, so the type of memory corruption vulnerabilities you're thinking about are not a possibility: https://github.com/WhisperSystems/Signal-Android/tree/master...
In addition to Moxie's comment about using Java, you're more broadly confused, I think.
Pnacl provides sandboxing, but it doesn't seem to provide any protection against buffer overflows. Android apps are also sandboxed, so I'm not sure what your point was.
Android (at least recent versions) has both NX pages and ASLR, both of which are specifically designed for these kinds of attacks. Sandboxing isn't, really, especially if your sensitive content (messages!) are inside the sandbox, obviously.
Pnacl provides sandboxing, but it doesn't seem to provide any protection against buffer overflows. Android apps are also sandboxed, so I'm not sure what your point was.
Android (at least recent versions) has both NX pages and ASLR, both of which are specifically designed for these kinds of attacks. Sandboxing isn't, really, especially if your sensitive content (messages!) are inside the sandbox, obviously.
Perhaps I did not isolate my concerns in sufficiently deliberate language.
You may be aware that of late there have been numerous buffer overflows (or other parsing problems) in standard image parsing libraries. Where these are implemented in Java that may be less of a concern, but this type of task is often handled by native code. And while more Java exploits are via breaking the verification in clever ways, via reflection or priviledged calls or pickling, that does not rule out that processing external data can lead to an inconsistent state. It might not be a problem with gifs, if they are small, but animated gifs can be large. Or maybe java See this discussion on Android image processing: https://code.facebook.com/posts/366199913563917/introducing-...
The point of PNaCL is that you can use it to sandbox components within the same process/permission set, you don't have to rely on the OS. It has a much smaller attack surface than Java.
You talk about NX and ASLR being useful in the same post as you say buffer overflows can't happen. In any case, while they may be designed to restrict attackers, they are by no means sufficient. There are Java ROP gadget chain builders! JVMs use JIT, which inherently means they are creating new code. Eg. see jit spraying.
You may be aware that of late there have been numerous buffer overflows (or other parsing problems) in standard image parsing libraries. Where these are implemented in Java that may be less of a concern, but this type of task is often handled by native code. And while more Java exploits are via breaking the verification in clever ways, via reflection or priviledged calls or pickling, that does not rule out that processing external data can lead to an inconsistent state. It might not be a problem with gifs, if they are small, but animated gifs can be large. Or maybe java See this discussion on Android image processing: https://code.facebook.com/posts/366199913563917/introducing-...
The point of PNaCL is that you can use it to sandbox components within the same process/permission set, you don't have to rely on the OS. It has a much smaller attack surface than Java.
You talk about NX and ASLR being useful in the same post as you say buffer overflows can't happen. In any case, while they may be designed to restrict attackers, they are by no means sufficient. There are Java ROP gadget chain builders! JVMs use JIT, which inherently means they are creating new code. Eg. see jit spraying.
are you part of that knife fight? calling the article writer a hipster in this comment, and what seems to amount to "It's not wrong to criticize Signal. but don't because telegram is worse and more likely to win" in your other comment (since they arn't asking for libresignal to take over, just for a decent alternative to exist which currently probably does not)
It seems a really strong and a bit aggressive of an attitude to have against a person's opinions
It seems a really strong and a bit aggressive of an attitude to have against a person's opinions
No, because I'm not affiliated with any messaging applications. Nor, by the way, am I saying that the author is --- I don't know them. I'm saying it's a good thing to know about the conversation.
Rereading my post here, I can see why a reader would infer from it the idea that the author might be a sockpuppet. I don't believe that! I was thinking more about the kinds of comments on message boards that say Signal is a "honey pot". I could have written that more carefully, so, sorry about that.
Rereading my post here, I can see why a reader would infer from it the idea that the author might be a sockpuppet. I don't believe that! I was thinking more about the kinds of comments on message boards that say Signal is a "honey pot". I could have written that more carefully, so, sorry about that.
I think the author is mostly right.
While Signal might have an excellent protocol, also well audited all this comes with some bad compromises.
E.g. you are forced to run GCM, or you share your address book. Both are unacceptable to many people that really need secure end-to-end encryption.
While Signal might have an excellent protocol, also well audited all this comes with some bad compromises.
E.g. you are forced to run GCM, or you share your address book. Both are unacceptable to many people that really need secure end-to-end encryption.
GCM has practically nothing to do with the security/privacy of Signal, but it is the #1 "concern" that people who don't understand cryptographic messaging security feel they must relate about Signal.
My main concern with GCM is that it's unavailable on fully open OS builds, so requiring it compromises the security of the device as a whole, rather than Signal in particular.
That's one of several things that are reasonable not to love about Signal. Criticism intended to urge Open Whisper Systems into changing their Signal policies are reasonable. A statement that someone would recommend less secure messaging solutions to investigative journalists is another --- something I find much harder to be supportive of.
There are alternatives with comparable or better security, but they tend to have other flaws. Most of the alternatives including Wire and Riot ALSO depend on GCM, otherwise they either lack push or force ridiculously bad battery life. They also have bad UX since they don't ask the user for a battery optimization exception permission, so the user would have to somehow know it's required or they'll break after a while in the background.
Conversations / OMEMO is a great Android messaging client, but it's ONLY available for Android and a desktop client (Gajim OMEMO plugin). It can use OTR (which it marks as less secure) but there isn't even a decent iOS OTR client anyway. ChatSecure iOS will probably get OMEMO and push support along with becoming a more decent client but it's going slowly. Until that happens, Conversations is problematic because there isn't a decent way to talk to iOS users.
Conversations / OMEMO is a great Android messaging client, but it's ONLY available for Android and a desktop client (Gajim OMEMO plugin). It can use OTR (which it marks as less secure) but there isn't even a decent iOS OTR client anyway. ChatSecure iOS will probably get OMEMO and push support along with becoming a more decent client but it's going slowly. Until that happens, Conversations is problematic because there isn't a decent way to talk to iOS users.
Nobody is saying Signal has less secure cryptography than others. But being able to run it in CopperheadOS without loading microg would make the whole setup much more secure. And one cannot dissociate both things.
What confuses me about the post is that the author does not make it clear if he recommends that journalists run CopperheadOS. It sounds like he does not recommend this, but rather opposes Signal's dependency on Play on general principals.
But if his journalists are using Android or iOS anyway, there's no practical advantage in Signal not depending on GCM or the Play Store, and some real disadvantages (like less secure updates). So the whole complaint seems like rather contrived to me.
(I would contest the claim that running a massive, not-practically-auditable open source OS is actually any more secure than running iOS or Android+Play Services, but whatever.)
But if his journalists are using Android or iOS anyway, there's no practical advantage in Signal not depending on GCM or the Play Store, and some real disadvantages (like less secure updates). So the whole complaint seems like rather contrived to me.
(I would contest the claim that running a massive, not-practically-auditable open source OS is actually any more secure than running iOS or Android+Play Services, but whatever.)
The point of CopperheadOS is not that it lacks Play Services... and Play does not provide more secure updates than an app store like F-Droid. In fact, Play abuses system privileges to bypass the signature system used by Android. It will happily clobber an app with another with a different signature. It moves all the security checks for that into the cloud... completely bypassing the standard trust-on-first-use signature system. Official builds of Signal could be hosted via an F-Droid repository, although there's no point when it depends on Play.
My point was that there's no real merit to the complaint that Signal requires Play Services if you're going to use an OS with Play Services installed anyway. One can reasonably argue that Signal should work on non-Play Androids, but since his target audience is non-technical users, it seems likely that they are all using (and are more secure using!) off-the-shelf iOS or Android phones, which implies a significant reliance on your vendor anyway.
Do you have any pointers on how Play bypasses local signature verification? I'm surprised about that.
Do you have any pointers on how Play bypasses local signature verification? I'm surprised about that.
> it seems likely that they are all using (and are more secure using!) off-the-shelf iOS or Android phones
In what sense are they more secure using stock Android than CopperheadOS? They wouldn't be installing it themselves either way. It's a product available for purchase too... have you done any research into what it is before making claims about it?
> Do you have any pointers on how Play bypasses local signature verification? I'm surprised about that.
Play contains a bunch of privileged / platform signature apps. They don't follow the regular permission rules. An unprivileged app not signed with the platform key cannot do automatic upgrades and counts as an unknown source. The Play Store chooses to bypass the trust-on-first-use signature checks of the package manager too. Upgrading apps via F-Droid or manually will perform the signature checks, but the Play Store does not. Try installing an app from F-Droid on a phone with Play, and note how Play will happily clobber it with an update signed with a different key. On the other hand, F-Droid won't do that even if you sign it with the platform key as CopperheadOS does to mark it as a unknown party source.
In what sense are they more secure using stock Android than CopperheadOS? They wouldn't be installing it themselves either way. It's a product available for purchase too... have you done any research into what it is before making claims about it?
> Do you have any pointers on how Play bypasses local signature verification? I'm surprised about that.
Play contains a bunch of privileged / platform signature apps. They don't follow the regular permission rules. An unprivileged app not signed with the platform key cannot do automatic upgrades and counts as an unknown source. The Play Store chooses to bypass the trust-on-first-use signature checks of the package manager too. Upgrading apps via F-Droid or manually will perform the signature checks, but the Play Store does not. Try installing an app from F-Droid on a phone with Play, and note how Play will happily clobber it with an update signed with a different key. On the other hand, F-Droid won't do that even if you sign it with the platform key as CopperheadOS does to mark it as a unknown party source.
GCM is available on fully open OS builds. The microG project implements a fully open stand-in for GCM.
There are no fully open OS builds that are Android.
Osomocombb is the closest we've ever gotten.
Osomocombb is the closest we've ever gotten.
Use iOS
Parent is concerned about one part of their OS not being open-source. iOS is closed-source.
Couldn't attacker (NSA) infer times of phonecalls/messages from GCM? This might not seem like much, but it is another piece of metadata...
</armchair>
What's the threat? An attacker who can observe only traffic on the wire (e.g. an ISP) probably gains nothing from observing GCM, since a) it's probably hard to distinguish different types of GCM messages and b) the attacker can just observe traffic to the Signal servers directly.
An attacker who cannot generally passively intercept (but not decrpyt) traffic on the wire but can passively intercept traffic to/from the GCM servers would be foiled by not using GCM, but that's a very narrow case.
An attacker who cannot generally passively intercept (but not decrpyt) traffic on the wire but can passively intercept traffic to/from the GCM servers would be foiled by not using GCM, but that's a very narrow case.
Hipsterism? That's horseshit. TFA is completely reasonable. At least 3 of these issues have prevented my privacy conscious friends from using it.
Especially the phone number thing. Phone numbers are quite sensitive. In some cases, the USG uses phone numbers alone for targeting drone strikes. They're enough to pull your credit report.
Especially the phone number thing. Phone numbers are quite sensitive. In some cases, the USG uses phone numbers alone for targeting drone strikes. They're enough to pull your credit report.
> I don't think Signal has sockpuppets (it's just not their style), but I know several other "secure" messaging applications do.
Could you provide details/sources? This seems like a good opportunity for some public shaming.
Could you provide details/sources? This seems like a good opportunity for some public shaming.
Good points. Perhaps crypto-hipsterism, then: crypterism.
[deleted]
Cryppled-ism
As an aside, I like "crypsterism" as a portmanteau for people who advocate hipster cryptography/security policy.
I'm not a cryptographer. I .. am reasonably sure that no one would take me for a hipster.
But two issues - or call it 'differences in opinion' - in that article are relevant for me: The inability to use the service without a mobile number and federation.
I understand the rationale behind the former ("It's easier"), but I don't understand why it is mandatory. I could've been 1283783127356128531312 on Signal and optionally add my phone number to that identity for others to find me (and optionally let Signal use my contacts to search for someone). That could even be the default, opt-out during registration. But right now, I'm basically using my phone number, which I really hate to do.
Federation is probably hard to get right, and looking at Eric Lippert's "Every feature idea starts with -100 points" rationale I guess it is understandable that this isn't a thing. But I don't want to join another silo, even if it's the best of the crop so far.
For users like me, Signal, WhatsApp and yes, Telegram are basically the same thing, come with the same set of limitations and I feel that it is worth pointing them out from time to time. Just as the article did (I'm not agreeing with everything in there btw.)
People jump in to defend Signal whenever this comes up, but maybe that isn't necessary. Signal is a great project and most criticism I've seen here so far is not 'Signal sucks', it is usually more a long the line of 'Signal is not for me' and I have a hard time understanding why that is debatable or why this shouldn't be a valid position.
But two issues - or call it 'differences in opinion' - in that article are relevant for me: The inability to use the service without a mobile number and federation.
I understand the rationale behind the former ("It's easier"), but I don't understand why it is mandatory. I could've been 1283783127356128531312 on Signal and optionally add my phone number to that identity for others to find me (and optionally let Signal use my contacts to search for someone). That could even be the default, opt-out during registration. But right now, I'm basically using my phone number, which I really hate to do.
Federation is probably hard to get right, and looking at Eric Lippert's "Every feature idea starts with -100 points" rationale I guess it is understandable that this isn't a thing. But I don't want to join another silo, even if it's the best of the crop so far.
For users like me, Signal, WhatsApp and yes, Telegram are basically the same thing, come with the same set of limitations and I feel that it is worth pointing them out from time to time. Just as the article did (I'm not agreeing with everything in there btw.)
People jump in to defend Signal whenever this comes up, but maybe that isn't necessary. Signal is a great project and most criticism I've seen here so far is not 'Signal sucks', it is usually more a long the line of 'Signal is not for me' and I have a hard time understanding why that is debatable or why this shouldn't be a valid position.
Signal and Telegram are not the same thing. Telegram has, according to Reuters, been actively compromised by people working for oppressive regimes (Iran, in particular).
If you're just using a secure messenger on general principles, it doesn't matter much which one you use. Probably WhatsApp is your best choice.
But if you actually need secure messaging, you should be using the safest secure messenger. Since we don't know who's reading these recommendations and what they're doing with them, we should employ the precautionary principle, and be clear with people that systems like Telegram, while probably fine for keeping messages out of the hands of jealous ex-partners, are simply not up to the task of protecting messages from serious, well-funded adversaries.
If you're just using a secure messenger on general principles, it doesn't matter much which one you use. Probably WhatsApp is your best choice.
But if you actually need secure messaging, you should be using the safest secure messenger. Since we don't know who's reading these recommendations and what they're doing with them, we should employ the precautionary principle, and be clear with people that systems like Telegram, while probably fine for keeping messages out of the hands of jealous ex-partners, are simply not up to the task of protecting messages from serious, well-funded adversaries.
I don't think we disagree. If you need secure messaging, go with Signal. I'd agree (with less credentials to back it up compared to people that work in that industry cough).
I said that for me they are basically equivalent. And for now I pick Telegram as the best compromise I'm going to get (still using my mobile number, still a silo, crappy encryption vs usability and cross-platform/multi-device support).
You seem to say that people should cheer for Signal so that people that NEED the secure messaging features aren't lured into the wrong direction. That makes sense. But if someone reads HN for secure messaging recommendations .. I kinda expect them to read more than a single comment and do a bit of research.
People are pointing out that Signal doesn't satisfy some requirements for their individual needs. It's not a "You shouldn't use Signal" (which would be bad), it's a "You might not like Signal, if .. " listing reasons like federation and identity. In this setting here I think that's fair and reasonable. No harm done, no danger for a random person stumbling upon these discussions and dismissing Signal because a random person online said that it doesn't support federation.
Signal is a nice project, I'd recommend it for everyone that has hard requirements for their secure messaging solution. I still don't want to use it myself and feel that it's fair to point out why Signal cannot cater to everyone. That doesn't harm Signal or its global perception, I think.
I said that for me they are basically equivalent. And for now I pick Telegram as the best compromise I'm going to get (still using my mobile number, still a silo, crappy encryption vs usability and cross-platform/multi-device support).
You seem to say that people should cheer for Signal so that people that NEED the secure messaging features aren't lured into the wrong direction. That makes sense. But if someone reads HN for secure messaging recommendations .. I kinda expect them to read more than a single comment and do a bit of research.
People are pointing out that Signal doesn't satisfy some requirements for their individual needs. It's not a "You shouldn't use Signal" (which would be bad), it's a "You might not like Signal, if .. " listing reasons like federation and identity. In this setting here I think that's fair and reasonable. No harm done, no danger for a random person stumbling upon these discussions and dismissing Signal because a random person online said that it doesn't support federation.
Signal is a nice project, I'd recommend it for everyone that has hard requirements for their secure messaging solution. I still don't want to use it myself and feel that it's fair to point out why Signal cannot cater to everyone. That doesn't harm Signal or its global perception, I think.
Look, that all makes perfect sense, and apart from the fact that I think Telegram is a deeply problematic project, I don't generally care what people use for casual communication. I use Slack, FFS!
But please remember the article we're actually commenting on starts like this:
One of the things I do is cryptography and infosec training for investigative journalists who have a need to keep either their sources and communications confidential so they can more safely do their work in the public interest.
But please remember the article we're actually commenting on starts like this:
One of the things I do is cryptography and infosec training for investigative journalists who have a need to keep either their sources and communications confidential so they can more safely do their work in the public interest.
Right. You got me there. In THAT context I'm completely with you and the recommendation for these people probably should be Signal, keeping the technical/philosophical differences for places like this one here.
Wishing that Signal would do things differently? Fair. Not recommending Signal to these users if it is your job to train them? Not a good idea.
Wishing that Signal would do things differently? Fair. Not recommending Signal to these users if it is your job to train them? Not a good idea.
> If you need secure messaging, go with Signal.
How can Signal be considered secure if Google has the metadata?
How can Signal be considered secure if Google has the metadata?
I am not using Telegram and wouldn't have used it if I was a US journalist working on something potentially dangerous, but I don't think this is a good argument.
As long as Telegram isn't compromised by USA-allied countries (Iran is somewhat allied with Russia), it might be a safer choice than Signal for US journalists. The reason is that USA can easily send a letter to Google that would reveal a lot about that person + they have root on the device.
Just like the safest place for Snowden right now is in Russia.
As long as Telegram isn't compromised by USA-allied countries (Iran is somewhat allied with Russia), it might be a safer choice than Signal for US journalists. The reason is that USA can easily send a letter to Google that would reveal a lot about that person + they have root on the device.
Just like the safest place for Snowden right now is in Russia.
To me, this is madness. I shouldn't have to care what global power my messaging service is aligned with. With Signal, I don't.
With Signal, you clearly do as they send a lot of your information to Google explicitly (like contacts) and Google has root on your phone.
Is that completely accurate? As Moxie explained elsewhere they do sync contacts, but that's optional. I'm not sure there's any other dependency beyond the GCM push, which I don't know is very concerning.
Google definitely has root on your phone, but is that automatically an implication that Signal is compromised?
Google definitely has root on your phone, but is that automatically an implication that Signal is compromised?
[deleted]
> Telegram has, according to Reuters, been actively compromised by people working for oppressive regimes (Iran, in particular).
I just wanted to add some details: someone checked the Iranian phone numbers range at Telegram servers and learned which of them are registred with Telegram. Message contents or contact lists were not obtained.
I guess this attack could be done with other apps that use phone numbers and phone contact lists for identification.
I just wanted to add some details: someone checked the Iranian phone numbers range at Telegram servers and learned which of them are registred with Telegram. Message contents or contact lists were not obtained.
I guess this attack could be done with other apps that use phone numbers and phone contact lists for identification.
I think tptacek was talking about actual takeovers of Telegram accounts. AFAIK there have been documented cases of this in Iran and Russia. See e.g. https://www.fredericjacobs.com/blog/2016/01/14/sms-login/
Nothing in that article proves that the accounts were actually directly hacked or mentions whether they had 2FA enabled or not.
Then it is a serious problem for Telegram and any app that relies on SMS or some phone identity to restore access to an account.
Telegram sends activation code to known devices, no sms (and I don't remember when it happened, maybe 4 years ago, probably for all other competitors). Also creators of telegram told everyone to use secret chats if conversations are secret to ensure p2p and forward secrecy. And to check key fingerprints to identify peers.
As usual, security threads consist of ancient beliefs, non-users and stories of low-conscious people using high-tech software. And there is always someone who mentions whatsapp as an alternative. Things like wickr are not even mentioned here.
As usual, security threads consist of ancient beliefs, non-users and stories of low-conscious people using high-tech software. And there is always someone who mentions whatsapp as an alternative. Things like wickr are not even mentioned here.
Not a problem for Telegram, as you can protect your account with a password.
Private chats and your contact list can't be accessed by accessing your Telegram account though.
Agree. I'm not a cryptographer and never claimed to be either. -- and I think it would be difficult to mistake me for a hipster. For one, I don't have that snazzy majestic beard.. Anyway, on to the point. :)
Yes, the phone number thing is a policy decision by the Signal people. As I write in my article, it's maybe marginally easier to get connected using phone numbers, but I may want to communicate via Signal with someone I don't want to give my phone number to. Handing out personal phone numbers on the willy nilly is not something I'm comfortable with. There's no reason why we couldn't have some other identifier, possibly easy to remember to connect us to via Signal. So this was a policy decision by the Signal people.
Federation is indeed hard to get right, but I think with proper versioning, and various teams keeping their software up-to-date and close to the reference paper/the Signal protocol, I see no reason why it cannot be overcome. For XMPP/Jabber it also works quite well.
Yes, the phone number thing is a policy decision by the Signal people. As I write in my article, it's maybe marginally easier to get connected using phone numbers, but I may want to communicate via Signal with someone I don't want to give my phone number to. Handing out personal phone numbers on the willy nilly is not something I'm comfortable with. There's no reason why we couldn't have some other identifier, possibly easy to remember to connect us to via Signal. So this was a policy decision by the Signal people.
Federation is indeed hard to get right, but I think with proper versioning, and various teams keeping their software up-to-date and close to the reference paper/the Signal protocol, I see no reason why it cannot be overcome. For XMPP/Jabber it also works quite well.
Moxie has written at some length about the problems they've had with federation in the specific case of their experience with Signal and also more generally about federation and its potential impact of the development of network technologies.
Your answer to all that is "I heard it's hard but really, versioning/XMPP and also, it's not hard". How well has 'proper versioning' worked out for SSL/TLS? Federation hasn't really 'worked out' for XMPP. Never mind anything substantial in response to Moxie's writing. People calling your piece 'hipsterism' are being very, very polite.
Your answer to all that is "I heard it's hard but really, versioning/XMPP and also, it's not hard". How well has 'proper versioning' worked out for SSL/TLS? Federation hasn't really 'worked out' for XMPP. Never mind anything substantial in response to Moxie's writing. People calling your piece 'hipsterism' are being very, very polite.
It's unquestionable that federation and decentralisation increase complexity significantly. For context, prior to Matrix the Matrix team used to write commercial comms app silos for telcos - and then we had the epiphany that building silos is harmful to end-users and the industry as a whole, and shifted entirely to the longer-term mission to build an entirely decentralised & open alternative. Despite the fact that we already had an entirely functional centralised implementation, it took about 1.5x longer to create Matrix. And if had been starting from an entirely clean slate, I suspect it'd have been 3-4x longer.
However, we very strongly feel that the resulting freedom and choice from the resulting open ecosystem is worth the additional complexity.
Users can choose any service provider without compromising interoperability. They can run their own servers. They can write their own clients. They can write their own servers. They can choose precisely who they trust with their data. They can contribute to the spec and help define the ecosystem. They aren't forced into trusting a provider who may be trustworthy today, but who knows in future.
I believe Moxie's viewpoint is that privacy is paramount, and any complexity which could introduce bugs which could undermine security/privacy is anathema. From a cryptography dev perspective, this makes perfect sense.
On the other hand, Matrix believes that there is more to life than just privacy, though (as critical as privacy is, of course) - and it is possible to have both privacy and freedom.
Yes, it slows down the rate of development a bit. Yes, it means you have to think much more carefully about layering the protocol to allow the different layers to evolve as independently and efficiently as possible, with the necessary mechanisms (both technical and organisational) to upgrade and lock out obsolete clients and servers. Yes, it means there's more complexity, where bugs could hide. Yes, it means that you may not be able to force the world to upgrade as rapidly as a silo might in the face of a critical security issue.
However, we think it's worth it.
However, we very strongly feel that the resulting freedom and choice from the resulting open ecosystem is worth the additional complexity.
Users can choose any service provider without compromising interoperability. They can run their own servers. They can write their own clients. They can write their own servers. They can choose precisely who they trust with their data. They can contribute to the spec and help define the ecosystem. They aren't forced into trusting a provider who may be trustworthy today, but who knows in future.
I believe Moxie's viewpoint is that privacy is paramount, and any complexity which could introduce bugs which could undermine security/privacy is anathema. From a cryptography dev perspective, this makes perfect sense.
On the other hand, Matrix believes that there is more to life than just privacy, though (as critical as privacy is, of course) - and it is possible to have both privacy and freedom.
Yes, it slows down the rate of development a bit. Yes, it means you have to think much more carefully about layering the protocol to allow the different layers to evolve as independently and efficiently as possible, with the necessary mechanisms (both technical and organisational) to upgrade and lock out obsolete clients and servers. Yes, it means there's more complexity, where bugs could hide. Yes, it means that you may not be able to force the world to upgrade as rapidly as a silo might in the face of a critical security issue.
However, we think it's worth it.
Use Wire then. You can either use you e-mail or phone number. Uses Signal OTR protocol and a single sign in for all your devices. The clients are open source.
IMHO Signal is only usable on smartphones. I don't want to link my desktop client with the phone, so I use Wire on the desktop.
Oh and Wire is a Swiss company. I see you run your blog off the .ch TLD.
IMHO Signal is only usable on smartphones. I don't want to link my desktop client with the phone, so I use Wire on the desktop.
Oh and Wire is a Swiss company. I see you run your blog off the .ch TLD.
That has other issues though. Last I checked you're unable to remove contacts from your contact list. I'm not kidding.
You can 'block' people, but simply removing them? Nope.
Why do I care? Because at one point the 'upload all contacts to Wire to help you find them on Wire' wasn't optional (I understand it is now) and now I'm stuck with entries on my contact list that I just don't care about. Very weird..
You can 'block' people, but simply removing them? Nope.
Why do I care? Because at one point the 'upload all contacts to Wire to help you find them on Wire' wasn't optional (I understand it is now) and now I'm stuck with entries on my contact list that I just don't care about. Very weird..
You are not a cryptographer and not a hipster and apparently never had your life on the line in a way that made it imperative that your communications not be associated with your phone number.
Whether you are a journalist or an abused individual hiding from the ex spouse/parents/whomever that abused you, if your life and/or the lives of other people are on the line, this detail (and perhaps others, as I am not super technically literate) is a serious deal breaker.
It has nothing whatsoever to do with some kind of vague, hand-wavy preference, like preferring red phones over blue ones because you like the color red. It has to do with "If I use this, will I or others end up dead, maimed, in jail for a lot of years or otherwise basically have one's life utterly ruined?" Like that movie scene where they blow up everything "because you made a phone call" (Enemy of the State, IIRC).
Whether you are a journalist or an abused individual hiding from the ex spouse/parents/whomever that abused you, if your life and/or the lives of other people are on the line, this detail (and perhaps others, as I am not super technically literate) is a serious deal breaker.
It has nothing whatsoever to do with some kind of vague, hand-wavy preference, like preferring red phones over blue ones because you like the color red. It has to do with "If I use this, will I or others end up dead, maimed, in jail for a lot of years or otherwise basically have one's life utterly ruined?" Like that movie scene where they blow up everything "because you made a phone call" (Enemy of the State, IIRC).
I'm .. confused. Aren't you basically just confirming my position, with stronger examples? Are we on the same side or do you disagree with my comment?
I mean, I think I wrote[1] that I really dislike the connection between identity and phone numbers. I happen to use Telegram at the moment (I have exactly 5 contacts, one of those is the Telegram 'we updated the software' bot, another one is a random 'Sticker' bot), but I'm an xmpp guy deep down. Matrix looks promising, I just need to find the time/energy to make the switch (and convert the 3 'real' Telegram contacts).
If you look at the thread with tptacek I do have to agree that the safest bet probably is Signal right now - if it leaks the phone number or not. I don't have to like it though...
1: If you look at my comments it seems that I repeat that in every other one, but English isn't my native language. Please blame the language barrier first, then blame the human behind the message.
I mean, I think I wrote[1] that I really dislike the connection between identity and phone numbers. I happen to use Telegram at the moment (I have exactly 5 contacts, one of those is the Telegram 'we updated the software' bot, another one is a random 'Sticker' bot), but I'm an xmpp guy deep down. Matrix looks promising, I just need to find the time/energy to make the switch (and convert the 3 'real' Telegram contacts).
If you look at the thread with tptacek I do have to agree that the safest bet probably is Signal right now - if it leaks the phone number or not. I don't have to like it though...
1: If you look at my comments it seems that I repeat that in every other one, but English isn't my native language. Please blame the language barrier first, then blame the human behind the message.
Signal is a great project and most criticism I've seen here so far is not 'Signal sucks', it is usually more a long the line of 'Signal is not for me' and I have a hard time understanding why that is debatable or why this shouldn't be a valid position.
To me, remarks like this one read as "Eh, if Signal is not to your tastes, no big, but no reason to trash it either." But the article and I and others here are saying, "Yeah, no. This is not the same thing as picking a phone because you like red more than blue. This is more like refusing the blue one because it explodes sometimes when you answer it."
For people for whom lives are on the line, this goes a lot deeper than personal preference.
To me, remarks like this one read as "Eh, if Signal is not to your tastes, no big, but no reason to trash it either." But the article and I and others here are saying, "Yeah, no. This is not the same thing as picking a phone because you like red more than blue. This is more like refusing the blue one because it explodes sometimes when you answer it."
For people for whom lives are on the line, this goes a lot deeper than personal preference.
Okay, I kinda get where you're coming from now. But .. for a good number of 'life is on the line' scenarios leaking a random anonymous phone number (prepaid, whatever) and the arguably best encryption for instant messaging today might be a Good Idea™.
Yes, you (and I, let's not forget that we kinda agree that this is bad design) might not want to share your private phone number just to contact someone via Signal. But I feel you're painting this a bit too black or white.
If lives are at stake or not, Signal might or might not be the right solution. If people feel that their life is at risk, I hope they know how to evaluate the trade-offs - or have someone around that can explain it.
We both don't like Signal. I don't agree that it should be dismissed and emotional appeals are ~questionable~, can probably be turned around (see first paragraph). Individual decisions need to be made and if Signal is a good fit or not for a specific scenario isn't an good indicator about the general fitness of Signal in general imo.
Yes, you (and I, let's not forget that we kinda agree that this is bad design) might not want to share your private phone number just to contact someone via Signal. But I feel you're painting this a bit too black or white.
If lives are at stake or not, Signal might or might not be the right solution. If people feel that their life is at risk, I hope they know how to evaluate the trade-offs - or have someone around that can explain it.
We both don't like Signal. I don't agree that it should be dismissed and emotional appeals are ~questionable~, can probably be turned around (see first paragraph). Individual decisions need to be made and if Signal is a good fit or not for a specific scenario isn't an good indicator about the general fitness of Signal in general imo.
No, I don't have a beef with Signal. I have no familiarity with the product. I am a woman and violence is often directed at women merely because they are women, regardless of what part of the world a woman lives in. I am also someone whose father spent 26.5 years in the Army and he fought in two wars and my ex husband was career military and ...etc. My parents also helped relatives of my mother's escape East Germany during the Cold War.
While you may hope that they know how to evaluate the trade-offs or have someone around that can explain it, many people live life under very risky circumstances and an uninformed choice can be the last choice they make.
No, I am not painting this a bit too black and white. Alive or dead is a pretty black or white thing and many people live lives where death dogs their steps. This is not an appeal to emotion or hyperbole. This is a fact.
If it isn't that big of a deal for you, cool. Glad to hear your life is fairly comfortable. But I do think it matters that informed, knowledgeable people discussing it on a forum with a strong reputation for being a good source of technical information (as well as other kinds of information) is a place where someone needs to make it very clear what the potential consequences are for people who live in dangerous circumstances and don't have the technical background or connections needed to figure this out.
While you may hope that they know how to evaluate the trade-offs or have someone around that can explain it, many people live life under very risky circumstances and an uninformed choice can be the last choice they make.
No, I am not painting this a bit too black and white. Alive or dead is a pretty black or white thing and many people live lives where death dogs their steps. This is not an appeal to emotion or hyperbole. This is a fact.
If it isn't that big of a deal for you, cool. Glad to hear your life is fairly comfortable. But I do think it matters that informed, knowledgeable people discussing it on a forum with a strong reputation for being a good source of technical information (as well as other kinds of information) is a place where someone needs to make it very clear what the potential consequences are for people who live in dangerous circumstances and don't have the technical background or connections needed to figure this out.
.. we still don't disagree, I think?
Yes, I'm living a comfortable life (if we define that as "Not worried about dying"). I seriously cannot imagine what people in those situations might go through.
But regardless of one's technical skills, I believe that someone cautious about giving up their phone number would stop and reconsider when Signal wants you to provide your phone number? I also really hope (for the sake of the people you stand up for) that getting a random / anonymous SIM card, a 'just for close friends and family' phone number is something that is well-known and good practice?
I .. don't want to dismiss your opinion. Honestly, I'm _still_ convinced that we feel the same about Signal. Let's turn this around: What would you _hope_ for here? What do you expect or wish for? What do you criticize exactly?
Yes, I'm living a comfortable life (if we define that as "Not worried about dying"). I seriously cannot imagine what people in those situations might go through.
But regardless of one's technical skills, I believe that someone cautious about giving up their phone number would stop and reconsider when Signal wants you to provide your phone number? I also really hope (for the sake of the people you stand up for) that getting a random / anonymous SIM card, a 'just for close friends and family' phone number is something that is well-known and good practice?
I .. don't want to dismiss your opinion. Honestly, I'm _still_ convinced that we feel the same about Signal. Let's turn this around: What would you _hope_ for here? What do you expect or wish for? What do you criticize exactly?
I don't think we specifically disagree about Signal per se, if that is what you are asking. I just think it is worth making some distinctions here, because not everyone in danger would realize that it is a problem when the app asks for your phone number. Does that make more sense?
I am not trying to argue with you. But I think this is a distinction worth making. We don't know who all is reading. People in real trouble often cannot ask questions. They may only be able to read. In which case, it matters if someone points out such a detail.
Thank you for engaging me.
I am not trying to argue with you. But I think this is a distinction worth making. We don't know who all is reading. People in real trouble often cannot ask questions. They may only be able to read. In which case, it matters if someone points out such a detail.
Thank you for engaging me.
Wire can use e-mails or phone nunbers for IDs, so you can use the same ID on multiple devices. But the mobile UI is worse than Signal's and it's also it's not federated. The source for the clients is on Github. It does have desktop apps for Windiws and Mac and a web app that works in most modern browsers. It's in many ways better than Skype. You don't have to link it to your phone in order to send messages - just use an e-mail account. It's also run by a Swiss company, so the servers might just be outside of the US.
Servers ARE outside of the US. All in EU.
I agree about the user name vs phone number. Federation issue was addressed here[1] for what it's worth.
[1] https://whispersystems.org/blog/the-ecosystem-is-moving/
[1] https://whispersystems.org/blog/the-ecosystem-is-moving/
People need to get the fact that all traffic across the Internet traverses lots of people's systems. There is no difference between it relaying off Google vs Verizon, AT&T, Amazon, OVH, or dozens of other carriers and cloud providers.
Like you say that is the point of end to end crypto.
Like you say that is the point of end to end crypto.
There is a difference, because these people in the middle don't have your contacts and don't have root on your phone.
This is a common problem with nearly all software, especially on phones.
A common problem that is mostly solved by other services (like the black phone).
At some point you have to trust someone unless you refine you own silicon, make your own chips, audit every line of code they run, etc.
> Signal is unusual because it combines cutting edge cryptography with consumer friendliness and is actually successful.
You do realize that since last year WhatsApp actually uses the Signal protocol?
You do realize that since last year WhatsApp actually uses the Signal protocol?
I disagree with your criticisms entirely and I think you are conflating things.
First, ease of use: the distinction you miss is ease of use from a UX point of view. Managing your own security is hard for the vast majority of people. It is an advantage that there is ease of use with respect to the security aspects - no command line commands to generate keys, for example - and ease of use from a UX point of view is completely different. Making a decision to to ease the UX can indeed negatively affect privacy elements, and there is no contradiction there.
Which brings me to the second point, which is that there is no contradiction in the discussion of security. The service could be using insecure protocols or algorithms, but the author says it isn't - from the point of view of cryptography, those choices are said to be sound. On the other hand, having your communication routed through a PRISM partner is a different concern. There is no contradiction in saying that the part of security under their control is sound, but that the part routed through Google may not be.
Cryptography is complex and rigorous. What you call puratinism is actually rigor with respect to sound practices. The points the article makes are, in fact, coherent; where you call puratinism and hipsterism on the article, I call cynicism and likely uninformed reasoning on your comment.
First, ease of use: the distinction you miss is ease of use from a UX point of view. Managing your own security is hard for the vast majority of people. It is an advantage that there is ease of use with respect to the security aspects - no command line commands to generate keys, for example - and ease of use from a UX point of view is completely different. Making a decision to to ease the UX can indeed negatively affect privacy elements, and there is no contradiction there.
Which brings me to the second point, which is that there is no contradiction in the discussion of security. The service could be using insecure protocols or algorithms, but the author says it isn't - from the point of view of cryptography, those choices are said to be sound. On the other hand, having your communication routed through a PRISM partner is a different concern. There is no contradiction in saying that the part of security under their control is sound, but that the part routed through Google may not be.
Cryptography is complex and rigorous. What you call puratinism is actually rigor with respect to sound practices. The points the article makes are, in fact, coherent; where you call puratinism and hipsterism on the article, I call cynicism and likely uninformed reasoning on your comment.
There is a coherent argument which you just refuse to see.
Signal was marketed as anti mass surveillance secure messaging system. It is but a mere user friendly email+gpg alternative. It actively avoid anti-mass surveillance methods and does the opposite - encourages centralization and collection of user statistics.
Even Telegram is better, as people arent fooled by what it is.
A better alternative is Ring.cx or Tox.im with for example Antox client.
Signal was marketed as anti mass surveillance secure messaging system. It is but a mere user friendly email+gpg alternative. It actively avoid anti-mass surveillance methods and does the opposite - encourages centralization and collection of user statistics.
Even Telegram is better, as people arent fooled by what it is.
A better alternative is Ring.cx or Tox.im with for example Antox client.
How does it actively avoid anti-mass surveillance methods? There are no metadata obfuscation mechanisms that work at scale against all adversaries. Using GCM is without a doubt a big win for privacy because adversaries that have backbone taps (like your friendly local intelligence agency) just see SSL to google.com which tells them nothing of any use, not even that you use Signal. A big encrypted packet from google.com might be a Signal message or it might be an email or a Play Store update or whatever.
People always overlook the fact that the world is full of adversaries and 99% of them can't get access to Google's datacenters. Those adversaries matter too. Look at Turkey!
People always overlook the fact that the world is full of adversaries and 99% of them can't get access to Google's datacenters. Those adversaries matter too. Look at Turkey!
There are such mechanisms.
Wire for example, doesn't require you to sign up with a phone number. You don't even have to have a phone.
How is it not an obfuscation mechanism that works at scale?
Also, what if google has a rogue employee who works for one of the surveillance agencies?
Trusting all your private data to an advertising company that has root access on your device in an app that is explicitly built around security and privacy is insane.
Wire for example, doesn't require you to sign up with a phone number. You don't even have to have a phone.
How is it not an obfuscation mechanism that works at scale?
Also, what if google has a rogue employee who works for one of the surveillance agencies?
Trusting all your private data to an advertising company that has root access on your device in an app that is explicitly built around security and privacy is insane.
Also, what if google has a rogue employee who works for one of the surveillance agencies?
Trusting all your private data to an advertising company that has root access on your
device in an app that is explicitly built around security and privacy is insane.
it would be much harder to implement such monitoring if they don't have root on your device.
There are degrees of difficulty. If you use Signal, you make it more difficult than if you use whatsapp but easier than if you have a rooted phone with open source software.
Also, you make it easier than it has to be with giving away contacts/phone numbers.
There are degrees of difficulty. If you use Signal, you make it more difficult than if you use whatsapp but easier than if you have a rooted phone with open source software.
Also, you make it easier than it has to be with giving away contacts/phone numbers.
I don't think you can reasonably post a top-level comment on a thread suggesting that Signal is a "honey pot", and then reply to a different comment on the same thread saying its author "refuses to see a coherent argument".
https://news.ycombinator.com/item?id=12881018
https://news.ycombinator.com/item?id=12881018
The author of this post believes that by making a stand over Signal policies he doesn't like (the superficial GCM dep, the OWS-only server policy, the contact list discovery system), something more like LibreSignal will grow to take Signal's place.
The author is wrong. LibreSignal won't replace Signal. Something like Telegram will: an "open source" messaging system with inferior cryptography, "opt-in" end-to-end messaging, a long-term dependency on the telephone system for authentication, and a far "cuddlier" personality with its users and, more importantly, with people from the app development community (like the author). Telegram will continue to gain adoption, because sexy beats sound in every end-user match up. Signal is the closest thing sound cryptography has to a palatable solution for end users.
Iran has already compromised Telegram users, because it systemically trades security off for user adoption. They'll get more of them, and people will hang from cranes as a result.
It's not wrong to criticize Signal. Signal does things I don't love, too! But we should be clear-eyed about the market.
The author is wrong. LibreSignal won't replace Signal. Something like Telegram will: an "open source" messaging system with inferior cryptography, "opt-in" end-to-end messaging, a long-term dependency on the telephone system for authentication, and a far "cuddlier" personality with its users and, more importantly, with people from the app development community (like the author). Telegram will continue to gain adoption, because sexy beats sound in every end-user match up. Signal is the closest thing sound cryptography has to a palatable solution for end users.
Iran has already compromised Telegram users, because it systemically trades security off for user adoption. They'll get more of them, and people will hang from cranes as a result.
It's not wrong to criticize Signal. Signal does things I don't love, too! But we should be clear-eyed about the market.
Hi, author here. I don't think LibreSignal or indeed Signal will ever be the dominant mobile messenger out there. There's simply a lot of inertia to fight against. It's the same reason why it's hard to convince e.g. Facebook friends to move to a different social network, why Google+ failed, etc. Whenever the social aspect gets involved, companies can very easily create lock-in by being early, and then the social aspect will prevent the majority of people from considering changing, because 'it works'.
I never said that LibreSignal will replace Signal, and frankly, LibreSignal itself is not the solution either. But maybe LibreSignal will be the catalyst to a better solution.
We all want to prevent people hanging from cranes, but crypto alone does not equal privacy, does not keep you safe, especially not in those countries, where rubber hose cryptanalysis (https://xkcd.com/538/) is much more common. In those dangerous situations/countries, good operational security practices are better to avoid detection/suspicion than using any 'magic' crypto messaging app.
I never said that LibreSignal will replace Signal, and frankly, LibreSignal itself is not the solution either. But maybe LibreSignal will be the catalyst to a better solution.
We all want to prevent people hanging from cranes, but crypto alone does not equal privacy, does not keep you safe, especially not in those countries, where rubber hose cryptanalysis (https://xkcd.com/538/) is much more common. In those dangerous situations/countries, good operational security practices are better to avoid detection/suspicion than using any 'magic' crypto messaging app.
You don't understand what I'm saying. I agree that crypto alone doesn't equal privacy --- it's table stakes. Clearly: it does not follow from that observation that crypto doesn't matter. If you cannot at least be cryptographically secure, the rest of what you do doesn't matter.
We now have two examples --- CryptoCat and Telegram --- of "secure messaging" systems being used by governments as a way of hunting down activists. Why do we need more? Can't the question be settled now?
As gently as I can, I'm going to push a little further. I poked around your site a little to get a sense of where you're coming from. Your post today opens up like this:
One of the things I do is cryptography and infosec training for investigative journalists who have a need to keep either their sources and communications confidential so they can more safely do their work in the public interest.
Can I ask what your qualifications are in training journalists in keeping their communications secure? Investigative journalists working in hostile regimes, even in smaller countries, are facing adversaries that are better funded than almost any other imaginable threat. Cryptography is incredibly hard. Elsewhere on the thread, you said "I'm not a cryptographer". Neither am I! I've spent the better part of 10 years getting decent at breaking cryptosystems for clients, and I still refuse to do privacy implementation work, because I'm simply not up to the challenge. Are you sure you are?
We now have two examples --- CryptoCat and Telegram --- of "secure messaging" systems being used by governments as a way of hunting down activists. Why do we need more? Can't the question be settled now?
As gently as I can, I'm going to push a little further. I poked around your site a little to get a sense of where you're coming from. Your post today opens up like this:
One of the things I do is cryptography and infosec training for investigative journalists who have a need to keep either their sources and communications confidential so they can more safely do their work in the public interest.
Can I ask what your qualifications are in training journalists in keeping their communications secure? Investigative journalists working in hostile regimes, even in smaller countries, are facing adversaries that are better funded than almost any other imaginable threat. Cryptography is incredibly hard. Elsewhere on the thread, you said "I'm not a cryptographer". Neither am I! I've spent the better part of 10 years getting decent at breaking cryptosystems for clients, and I still refuse to do privacy implementation work, because I'm simply not up to the challenge. Are you sure you are?
Regarding qualifications: I spent years building secure technology (publication platforms, websites) for whistleblowers including Ed Snowden himself (I built his official website (https://edwardsnowden.com) for the Courage Foundation (his official defence fund) plus the tech behind it that supports it. This allows our editors to submit anonymously to the site through the Tor network.
I used cryptographic software as an end-user for many years, like GPG for instance, and agree that it's hard, and we need to train people to use correct security habits (infosec and opsec), to minimise exposure to hostile elements.
I've tought at cryptoparties and other events, I have spoken to many intelligence whistleblowers, some of which I consider to be close friends, and they've told me about some of the techniques used on the national intelligence agency level and how wrong use of crypto and general bad operational security practices can expose you. So while I'm not a trained cryptographer, and do not claim to be, I have extensive experience not only building secure software, but also, thanks to whistleblowers know about some of the ins and outs of the intelligence industry re crypto and surveillance.
I used cryptographic software as an end-user for many years, like GPG for instance, and agree that it's hard, and we need to train people to use correct security habits (infosec and opsec), to minimise exposure to hostile elements.
I've tought at cryptoparties and other events, I have spoken to many intelligence whistleblowers, some of which I consider to be close friends, and they've told me about some of the techniques used on the national intelligence agency level and how wrong use of crypto and general bad operational security practices can expose you. So while I'm not a trained cryptographer, and do not claim to be, I have extensive experience not only building secure software, but also, thanks to whistleblowers know about some of the ins and outs of the intelligence industry re crypto and surveillance.
You really shouldn't have to show credentials. If tpateck had cared, he could easily have looked them up. And besides, arguments should stand on their own without credentials. Our hacker space recently defined a hacker ethos: one of the first things was that credentials or certificates or something don't matter.
One thing I wanted to add, regarding the tech: of course I do that in cooperation with other people some of who are indeed trained cryptographers.
Who are those people? There aren't many of them, in, like, the world.
True, they are rare. On another unrelated project I'm working together with Bill Binney, the cryptographer who wrote ThinThread at NSA. That's all I can currently say about it.
I see I haven't replied yet to your first point: here goes. Of course clearly an alternative has to be at least cryptographically secure. I fully agree with you on that. I'm not recommending something that isn't, and certainly am not recommending Telegram or Cryptocat.
An alternative needs to be as a bare minimum cryptographically secure. And then on top of that it would be very nice if there was federation, not tied to phone numbers and all the components being open source. Those last 3 points is where Signal fails currently. Federation is something that moxie tried, didn't work out, now he's basically not in favour of that, the phone number issue is of course well known, and the redphone server component is not open source.
An alternative needs to be as a bare minimum cryptographically secure. And then on top of that it would be very nice if there was federation, not tied to phone numbers and all the components being open source. Those last 3 points is where Signal fails currently. Federation is something that moxie tried, didn't work out, now he's basically not in favour of that, the phone number issue is of course well known, and the redphone server component is not open source.
Sounds like you're looking for https://matrix.org
Hits all your technical requirements. Setting up your own homeserver is cake. Federation is a key part of the core design. End to end encryption is just about to be finalized. History syncing between multiple clients. Bridges for pulling in other chat systems like slack and IRC. Completely open source. To me, this is the perfect messaging platform. Just needs some UI polish and I could see it really taking off. Had you seen this yet?
Hits all your technical requirements. Setting up your own homeserver is cake. Federation is a key part of the core design. End to end encryption is just about to be finalized. History syncing between multiple clients. Bridges for pulling in other chat systems like slack and IRC. Completely open source. To me, this is the perfect messaging platform. Just needs some UI polish and I could see it really taking off. Had you seen this yet?
But you seem to be hand-waving away the problems Moxie had with federation [1]. Citing xmpp is not a counterexample. Some problems do not have solutions.
[1] https://whispersystems.org/blog/the-ecosystem-is-moving/
[1] https://whispersystems.org/blog/the-ecosystem-is-moving/
Whilst some problems are not solvable, it doesn't mean that they are showstoppers. See https://news.ycombinator.com/item?id=12882181 elsewhere in the thread.
One of the problems I face when somebody comes along and tells me that they're now on Telegram, Cryptocat, Wire, or whathaveyou is that I might recall an issue but there doesn't seem to be a good up-to-date overview that answers the questions (1) should I trust these people (how bad was it; was it in their code or a dependency?) and (2) is it known to be far less secure than it advertises? (still?)
I recall e.g. that Moxie reviewed Telegram's security, found that none of it made any sense and that its authors didn't know what they were doing. https://tobtu.com/decryptocat.php looks like the cryptocat analogue of that. Have the two projects improved somehow? Have some people joined or others left?
Could you please also provide links for the claim that CryptoCat and Telegram are being used by governments to hunt down activists?
I recall e.g. that Moxie reviewed Telegram's security, found that none of it made any sense and that its authors didn't know what they were doing. https://tobtu.com/decryptocat.php looks like the cryptocat analogue of that. Have the two projects improved somehow? Have some people joined or others left?
Could you please also provide links for the claim that CryptoCat and Telegram are being used by governments to hunt down activists?
[deleted]
>We all want to prevent people hanging from cranes, but crypto alone does not equal privacy, does not keep you safe, especially not in those countries, where rubber hose cryptanalysis (https://xkcd.com/538/) is much more common. In those dangerous situations/countries, good operational security practices are better to avoid detection/suspicion than using any 'magic' crypto messaging app.
Then just put a TL;DR at the end of your article and say 'use iMessage/Facetime, it's probably good enough for operating in an unstable region' If it worked for Erdogan it will work for you!
EDIT: (While I intend to come off as cocky, I'm serious:
https://www.apple.com/business/docs/iOS_Security_Guide.pdf page 41
http://www.independent.co.uk/news/world/europe/turkey-coup-e...
)
Then just put a TL;DR at the end of your article and say 'use iMessage/Facetime, it's probably good enough for operating in an unstable region' If it worked for Erdogan it will work for you!
EDIT: (While I intend to come off as cocky, I'm serious:
https://www.apple.com/business/docs/iOS_Security_Guide.pdf page 41
http://www.independent.co.uk/news/world/europe/turkey-coup-e...
)
The author of the post is making the point that Signal's tradeoffs/policies are eroding support from the privacy-conscious end of the user spectrum. Crypto-soundness is excellent but when you staple an infoleak to it (contact list) it's much less compelling. So you can start to make the case to an end user that sharing all your info with Whatsapp or Telegram is a Bad Thing, and here let's install this Signal thing that's much better, except hold on what's this permission list that it requires?
I see Signal as having positioned itself as a compromise that makes nobody happy.
I see Signal as having positioned itself as a compromise that makes nobody happy.
What about all the other alternatives like Wire and Wickr? Wickr went through crypto reviews. Wire is open source.
They don't require using phone numbers so it's not really annoying to sign up without giving away anonymity.
They don't require using phone numbers so it's not really annoying to sign up without giving away anonymity.
Serious question: what does "went through crypto reviews" even mean? One of these messaging systems is designed and implemented by experts; the others, not, but they've gotten 1-2 person/weeks of attention by (one hopes) a crypto experts.
Regarding Wickr:
isec partners spent 9 person-weeks https://www.wickr.com/about-us/blog/2014/08/08/isec-partner-...
this one spent 240 hrs: https://www.wickr.com/about-us/blog/2014/08/05/aspect-securi...
You haven't talked about Wire.
People have to trust someone. If you are not a crypto expert you have to rely on crypto experts to tell you if the protocol/app is sound.
I don't have to be a security expert to know that google can get the phone numbers of all the contacts I talk to on Signal. So the anonymity angle is lost completely.
Regarding privacy, I don't have to be a crypto expert to know that google services are running as root on my phone. They can easily replace the app itself. Avoiding using google proprietary services and still using Signal is a lot of pain.
this one spent 240 hrs: https://www.wickr.com/about-us/blog/2014/08/05/aspect-securi...
You haven't talked about Wire.
People have to trust someone. If you are not a crypto expert you have to rely on crypto experts to tell you if the protocol/app is sound.
I don't have to be a security expert to know that google can get the phone numbers of all the contacts I talk to on Signal. So the anonymity angle is lost completely.
Regarding privacy, I don't have to be a crypto expert to know that google services are running as root on my phone. They can easily replace the app itself. Avoiding using google proprietary services and still using Signal is a lot of pain.
Just a question - is Telegram secret chat after you verify keys still with inferior cryptography? And why?
> a long-term dependency on the telephone system for authentication
You can protect your Telegram account with a password (it's opt-in). Iran couldn't have compromised it then.
You can protect your Telegram account with a password (it's opt-in). Iran couldn't have compromised it then.
Unfortunately, Google has made it (almost) impossible to wake up the phone via some external event without using its proprietary GCM. Even though GCM is not part of AOSP, it has unique status on the platform that can't easily be replicated (without recompiling the kernel, etc like the article mentions).
Before the days of doze mode & other battery optimizations, you could just listen & block on a socket, then let the phone go to sleep. Incoming 3G packets would wake up the phone, you grab a wakelock, then start doing things. From what I remember, at least a while ago Facebook Messenger did this using MQTT. But this is not possible any more.
Before the days of doze mode & other battery optimizations, you could just listen & block on a socket, then let the phone go to sleep. Incoming 3G packets would wake up the phone, you grab a wakelock, then start doing things. From what I remember, at least a while ago Facebook Messenger did this using MQTT. But this is not possible any more.
It works quite well for me with the Conversations Jabber client with no discernible battery usage impact.
Did something change in recent Android versions?
Edit: Apparently Nougat's Doze is the issue. Conversations bug report, you can apparently put it on a whitelist:
https://github.com/siacs/Conversations/issues/1624
Did something change in recent Android versions?
Edit: Apparently Nougat's Doze is the issue. Conversations bug report, you can apparently put it on a whitelist:
https://github.com/siacs/Conversations/issues/1624
Kind of tangential, but GCM is deprecated and you're supposed to use Firebase Cloud Messaging now: https://firebase.google.com/docs/cloud-messaging/
It's still just a JAR (no native components), so AFAICT there's no technical reason someone else couldn't do a similar thing with their own servers.
It's still just a JAR (no native components), so AFAICT there's no technical reason someone else couldn't do a similar thing with their own servers.
> It's just a JAR (no native components)
I’ve reversed it, and rebuilt an alternative
The jar you include actually opens just an IPC channel to the Google Play Services framework, which runs with system permissions, and handles the actual stuff.
You can’t implement your own FCM without having root access on EVERY Android phone out there.
I’ve reversed it, and rebuilt an alternative
The jar you include actually opens just an IPC channel to the Google Play Services framework, which runs with system permissions, and handles the actual stuff.
You can’t implement your own FCM without having root access on EVERY Android phone out there.
Maybe not. Although there's this guy: https://eladnava.com/pushy-a-new-alternative-to-google-cloud..., it seems like his library doesn't work very well after Nougat.
From Android 6 on, Doze just terminates apps running in background after a while. The only network access that is allowed is GCM.
Which causes the entire issue.
I wrote a complaint to the EU privacy official responsible for them and the EU antitrust committee.
Which causes the entire issue.
I wrote a complaint to the EU privacy official responsible for them and the EU antitrust committee.
That's an excellent idea! Do you have a blog or something where you're going to post when (if) you get a response?
> Before the days of doze mode & other battery optimizations, you could just listen & block on a socket, then let the phone go to sleep. Incoming 3G packets would wake up the phone, you grab a wakelock, then start doing things. From what I remember, at least a while ago Facebook Messenger did this using MQTT. But this is not possible any more.
It's not a coincidence that the Facebook app was known for being an absolute battery killer. Go to any android forum post about battery life from a year or more ago and you'll see that the first suggestion is always "have you tried removing Facebook?"
It's not a coincidence that the Facebook app was known for being an absolute battery killer. Go to any android forum post about battery life from a year or more ago and you'll see that the first suggestion is always "have you tried removing Facebook?"
That's very easy to manage.
Every random 15-60 minutes a gcm/firebase message containing an encrypted payload with "you got this mail/no mail for you sir".
So google cant get your frequency of use.
It's my impression that most people use Signal as an SMS app replacement, and in that environment people would not find a random 15-60 minute delay until their phone tells them about an incoming message to be tenable. I certainly wouldn't.
>Unfortunately, Google has made it (almost) impossible to wake up the phone via some external event without using its proprietary GCM
No, fortunately Google has made it impossible for apps to abuse waking up the phone.
No, fortunately Google has made it impossible for apps to abuse waking up the phone.
No. Apps can abuse waking up the phone all they want (and as much as user lets them), as long as they do it via Google's servers. What they can't do is bypass GCM/FCM. Nothing to do with UX.
Any apps that try to abuse it will quickly be flagged by Google for analysis.
I highly recommend Conversations (disclaimer: I've worked on it in the past, although I'm not a project "member" per say): https://conversations.im/
It's open source, uses a federated, open protocol, and can do multiple types of encryption including OTR and OMEMO (an XMPP wire format that uses the Axolotl ratched devised for signal). It does not do VoIP, so it would just be for chat (although there is a large bounty on Jingle-based voip support open). It has also had a public security audit, and is designed to be white labeled so you can tweak a few variables in the source and build your own hardended version or encrypted-only version, etc.
It's open source, uses a federated, open protocol, and can do multiple types of encryption including OTR and OMEMO (an XMPP wire format that uses the Axolotl ratched devised for signal). It does not do VoIP, so it would just be for chat (although there is a large bounty on Jingle-based voip support open). It has also had a public security audit, and is designed to be white labeled so you can tweak a few variables in the source and build your own hardended version or encrypted-only version, etc.
Conversations is great, but there's nothing comparable on iOS except Chatsecure which isn't yet beta quality. Then you need to pair it with a server that actually has all the recent XEP's installed (for push is XEP357, usually missing), see: https://gultsch.de/compliance_ranked.html
My current 'solution' is to use ZNC connected to Bitlbee (supporting OTR). On Bitlbee I use the jabber.fr service. ZNC has a push script for Mutter (great iOS IRC client) that I modified to redact my notification content from Apple's push service. I connect to the ZNC with TLS, so in theory everything should be ok.
NOT USER FRIENDLY but allows me to keep all my chats in one client and not tied to some shitty walled garden. Everyone less savvy I just tell them to use Signal.
My current 'solution' is to use ZNC connected to Bitlbee (supporting OTR). On Bitlbee I use the jabber.fr service. ZNC has a push script for Mutter (great iOS IRC client) that I modified to redact my notification content from Apple's push service. I connect to the ZNC with TLS, so in theory everything should be ok.
NOT USER FRIENDLY but allows me to keep all my chats in one client and not tied to some shitty walled garden. Everyone less savvy I just tell them to use Signal.
That compliance table is the thing really killing XMPP for practical modern usage.
I tried to write an XMPP client about a year ago and found out about that compatibility table the hard way. It's rough -- I had no idea what I was getting into.
Turns out that XMPP, before expansions, has no standard definition of what message IDs are. Which means "good luck, have fun!" is pretty much the best anyone can hope for on synchronizing messages when you have multiple devices or when the network flakes on you. Which in turn means XMPP is basically unusable on multiple devices. If you're lucky, everything supports all the same extensions, and it'll probably work most of the time; but if any piece of software you use is missing one extension, your day is toast. (And even then, frankly, the "carbons" API is wrong-headed and not very capable of recovering from network failures. In no uncertain terms: It's time to move on.)
I wrote about this more previously on HN: https://news.ycombinator.com/item?id=9772968
I tried to write an XMPP client about a year ago and found out about that compatibility table the hard way. It's rough -- I had no idea what I was getting into.
Turns out that XMPP, before expansions, has no standard definition of what message IDs are. Which means "good luck, have fun!" is pretty much the best anyone can hope for on synchronizing messages when you have multiple devices or when the network flakes on you. Which in turn means XMPP is basically unusable on multiple devices. If you're lucky, everything supports all the same extensions, and it'll probably work most of the time; but if any piece of software you use is missing one extension, your day is toast. (And even then, frankly, the "carbons" API is wrong-headed and not very capable of recovering from network failures. In no uncertain terms: It's time to move on.)
I wrote about this more previously on HN: https://news.ycombinator.com/item?id=9772968
I think Conversations is probably getting a lot right, but you also mention its biggest flaw:
> do multiple types of encryption including OTR and OMEMO
Oh and it can also do something else: no encryption at all. That's the problem with XMPP: The user is faced with three different encryption modes, none of them is the default.
There shouldn't be multiple types of optional encryption. There should be one that works and is enabled by default.
> do multiple types of encryption including OTR and OMEMO
Oh and it can also do something else: no encryption at all. That's the problem with XMPP: The user is faced with three different encryption modes, none of them is the default.
There shouldn't be multiple types of optional encryption. There should be one that works and is enabled by default.
The practical problem is that a lot of power-users have strong opinions about which e2e scheme to use in which case. That may include "none". [1] If you enforce a single e2e scheme (no matter which), you will lose a lot of potential power-users, who would double as multipliers to spread your app.
I don't say that Conversations (and the XMPP community at large) couldn't do better, though. For example, there could be a standardized, automated, transparent process for determining which e2e schemes are supported by the clients involved in the conversation.
[1] For example, I skip e2e when talking to my several XMPP bots. They run on the same host as the XMPP server, so e2e won't reduce my attack surface when I already have TLS enforced along the way, but make the bot implementation considerably more complex.
I don't say that Conversations (and the XMPP community at large) couldn't do better, though. For example, there could be a standardized, automated, transparent process for determining which e2e schemes are supported by the clients involved in the conversation.
[1] For example, I skip e2e when talking to my several XMPP bots. They run on the same host as the XMPP server, so e2e won't reduce my attack surface when I already have TLS enforced along the way, but make the bot implementation considerably more complex.
> you will lose a lot of potential power-users, who would double as multipliers to spread your app.
Not really. I consider myself poweruser in many areas, but I would never recommend most of my tools to "ordinary" friends. The tools for them should be easy to use and difficult to misuse.
Not really. I consider myself poweruser in many areas, but I would never recommend most of my tools to "ordinary" friends. The tools for them should be easy to use and difficult to misuse.
In practice you always get TLS. That's really all you need if you trust the server.
Something fairly significant has happened in the world of XMPP recently. You can get real certificates for XMPP servers under your control from letsencrypt. That means that things now work transparently between clients and servers and between servers. As a result, organizations that do things that some governments might not approve of can do transparent encryption simply by setting up a server or servers in places that such governments can not physically get at.
Something fairly significant has happened in the world of XMPP recently. You can get real certificates for XMPP servers under your control from letsencrypt. That means that things now work transparently between clients and servers and between servers. As a result, organizations that do things that some governments might not approve of can do transparent encryption simply by setting up a server or servers in places that such governments can not physically get at.
TLS on the s2s side is unauthenticated. Therefore TLS only protects you in a situation where both users are on the same server and trust it.
Getting a real cert for s2s doesn't really help as long as you have no agreed upon mechanism how they can enforce validation of those certs.
Getting a real cert for s2s doesn't really help as long as you have no agreed upon mechanism how they can enforce validation of those certs.
You need to trust both servers when doing s2s anyway. So you can just turn on certificate validation when depending on just TLS for your security. For Prosody that would be "s2s_secure_auth = true".
Of course an organization using TLS as their only security for XMPP would almost for sure just use one secure server, so I might be being a bit fanciful here. My ultimate point is that because of the way XMPP works, it is possible to make the normal default clients work securely in practice by doing the correct things at the server level.
Of course an organization using TLS as their only security for XMPP would almost for sure just use one secure server, so I might be being a bit fanciful here. My ultimate point is that because of the way XMPP works, it is possible to make the normal default clients work securely in practice by doing the correct things at the server level.
I tried Conversations but I couldn't for the life of me get message history to work. There's just so much stuff you have to do when it comes to XMPP to get things working. Perhaps if I used someone else's server it wouldn't be a problem but I'd prefer not to do that.
I agree that it's a bit hard to get setup if you're dead set on running your own server, but that will be the case with anything (although Prosody and Ejabberd et al could have better defaults for the majority of people who probably just want to throw up a server and be done). The nice thing about XMPP is that if you don't want to run your own server, you're spoiled for choice. The network is significantly bigger than any of the other protocols I know of [citation needed].
> but that will be the case with anything
I mentioned this a bit below but this wasn't the case with Matrix. Setting up a homeserver took me about half an hour and gave me everything out of the box. Setting up Prosody took me days and gave me nothing but trouble.
There are a lot of XMPP servers around but I really want my own so that I can store plaintext chat logs on the server.
I mentioned this a bit below but this wasn't the case with Matrix. Setting up a homeserver took me about half an hour and gave me everything out of the box. Setting up Prosody took me days and gave me nothing but trouble.
There are a lot of XMPP servers around but I really want my own so that I can store plaintext chat logs on the server.
See my comment below. You need a server with the XEP support for it. (XEP-313 I believe)
Yep, I have it. Somehow it was turned off for my account in particular at some point and there's no way I can find to get it back.
If you're using conversations go into the drop down menu, choose Accounts, click on the account you're using and then in its drop down / context menu (what do you call the hamburger menu on Android?) choose "Archiving preferences". Although it's deliberately buried so that you don't mess with it, so I'm not sure how it would have been accidentally turned off, so maybe whatever's happening with your server is unrelated.
Curious for next time I evaluate XMPP is there a list of servers recommended by the Conversations team that people could install themselves? My issue with XMPP is that on the same system I have at DigitalOcean where I could run: an IRC server, a Web Server, and a Mumble Server and extra goodies all together in one box, I couldn't effectively run a XMPP server that would stay up (it would crash). I would of kept at XMPP had I found a decent memory efficient server that didn't merely crash.
THE xmpp server I'd recommend is prosody[1]. Lua based, quite active, very friendly community and easy to set up/configure.
1: http://prosody.im
1: http://prosody.im
I'm a big fan of Prosody (prosody.im); even the nightlies (what I run) are remarkably stable, and the memory footprint is tiny (they have some metrics somewhere if you ask in the chat; I can't find them right away).
I have a virtual server (1 CPU + 1 GiB RAM) running nginx, murmur and Prosody. free(1) reports 80 MiB used memory, thereof 10 MiB for Prosody. (I just have one active account, though: myself.)
So unless you're planning on hosting hundreds or thousands of users, you should be fine IMO.
So unless you're planning on hosting hundreds or thousands of users, you should be fine IMO.
I had not even 3 users... I was running a Java one, looks like Prosody is worth it's salt. Does it support E2E and other features that Conversations supports? :)
Edit:
I was running it on a DigitalOcean box with only 512MB of ram at the time, which I found a bit silly that I would come back and the server was down, but it was a different XMPP server than Prosody.
Edit:
I was running it on a DigitalOcean box with only 512MB of ram at the time, which I found a bit silly that I would come back and the server was down, but it was a different XMPP server than Prosody.
You probably used Openfire, known to be a memory hog and a bit unstable.
Simply go for prosody and you should be fine (ejabberd should also be OK). Some newer XEPs which you may want to have with Conversations are not supported OOTB in prosody (yet) but there are plugins distributed separately [1][2].
[1] https://modules.prosody.im/ [2] https://prosody.im/doc/installing_modules
[1] https://modules.prosody.im/ [2] https://prosody.im/doc/installing_modules
Yes that was the culprit! OpenFire sounds like it... I wanted something simple to setup, without too many terminal incantations. Thanks for the information, it's invaluable.
E2E does not need support from the server. Regarding Conversations, I'm using it with my server and it seems to be working fine, although I have not tested every single XEP supported by Conversations.
This is true, it's kind of easy to forget how E2E works sometimes, thanks!
I use ejabberd for a client. Prosody is also nice.
I never understood properly where Conversations app fit in. Is it a Jabber client to aggregate all the IM clients/accounts or is it also a independent highly secured instant messaging app on its own too?
A very good Jabber/XMPP client for Android. It's GPL and doesn't require Google services.
Essentially this guy is saying, Signal is secure, it's mostly easy to use (with the exception of multiple phone numbers), and the only alternative he mentioned is a half broken clone. Is he seriously going to stop recommending it to people whose lives depend on secure communications because of some abstruse ideological point? In any case, Moxie's position is a reasonable one even though there are some arguments for federation.
While my current phone doesn't support Signal, once I get a new one I will continue to use it.
You might opine that allowing Signal clones would allow me to use the app, but they would almost certainly be maintained by people who aren't really crypto experts, and so it's better to operate as though I am broadcasting in cleartext than to pretend that I'm not and get burned.
While my current phone doesn't support Signal, once I get a new one I will continue to use it.
You might opine that allowing Signal clones would allow me to use the app, but they would almost certainly be maintained by people who aren't really crypto experts, and so it's better to operate as though I am broadcasting in cleartext than to pretend that I'm not and get burned.
The biggest argument is that there is little of a difference between Signal and Telegram or Signal and WhatsApp for the user if they are forced to use the official servers, and those servers get to store their entire social graph.
Here's what Moxie said about this issue: https://whispersystems.org/blog/contact-discovery/
And here's my write-up of how a private set-intersection protocol could be used to enable users to securely swap contacts: https://news.ycombinator.com/item?id=11289223
It's a solved problem, but Signal doesn't implement it.
It's a solved problem, but Signal doesn't implement it.
The protocol you describe is a synchronous online protocol where Alice and Bob have to be online at the same time (and if they're doing this at Charlie's behest, so does Charlie). Signal is designed for asynchronous communication where both participants don't have to be online to discover each other or send each other message.
Also, how does this protocol even help? What's the use case? It allows participants to discover mutual contacts, but what then? Do we use Bob as a web-of-trust style introducer? What if Alice doesn't even want to talk to Charlie? Do we do this for all the friends Alice has in common with Bob? Do we do this for all the friends Alice has in common with everyone? Does Charlie initiate the process, only to have it only work if all three of them are online at the same time? Who kicks it off and why, and what would the user experience be?
You end your last post with "So, problem solved" but I'm not sure this protocol even solves any practical problems for the Signal use case, and seems like a mere first step of solving a much more complicated problem of actually trying to turn this into a useful feature with good UX.
Also, how does this protocol even help? What's the use case? It allows participants to discover mutual contacts, but what then? Do we use Bob as a web-of-trust style introducer? What if Alice doesn't even want to talk to Charlie? Do we do this for all the friends Alice has in common with Bob? Do we do this for all the friends Alice has in common with everyone? Does Charlie initiate the process, only to have it only work if all three of them are online at the same time? Who kicks it off and why, and what would the user experience be?
You end your last post with "So, problem solved" but I'm not sure this protocol even solves any practical problems for the Signal use case, and seems like a mere first step of solving a much more complicated problem of actually trying to turn this into a useful feature with good UX.
> The protocol you describe is a synchronous online protocol where Alice and Bob have to be online at the same time (and if they're doing this at Charlie's behest, so does Charlie).
They don't actually have to be online at the same time (and they don't care about whether Charlie is online or not: it's a pairwise protocol): they just to be able to send and receive one another messages, and to store state. Fortunately the former is some Signal's quite good at, and storing state is something that phone hard drives are quite good at.
> Also, how does this protocol even help? What's the use case? It allows participants to discover mutual contacts, but what then? Do we use Bob as a web-of-trust style introducer? What if Alice doesn't even want to talk to Charlie? Do we do this for all the friends Alice has in common with Bob? Do we do this for all the friends Alice has in common with everyone?
It's the exact same use case as Signal's existing contact-discovery code, only private: it enables Alice & Bob to share information about a mutual acquaintance, e.g. Charlie. This might be used to share Charlie's key ID, in a trust on first use style. Note that this is no less secure than everyone everywhere trusting Open Whisper Systems on first use.
The idea is that when one starts using Signal, one exchanges keys in some out-of-band mechanism (NFC is a likely candidate) with an acquaintance, and then from that person get keys of mutual acquaintances, and from then others, and so on and so forth. Whenever you add a new acquaintance, one can reiterate the same protocol with all previous acquaintances (it's amenable to batching, too, which is nice) in order to propagate that information.
It may have some interesting uses in a certificate transparency sense, but I don't know about that.
> You end your last post with "So, problem solved" but I'm not sure this protocol even solves any practical problems for the Signal use case
It solves the exact same problems the Signal contact-discovery protocol solves, without actually revealing all one's contacts to OWS. That's all. If it did nothing more than that, it would be a good thing.
They don't actually have to be online at the same time (and they don't care about whether Charlie is online or not: it's a pairwise protocol): they just to be able to send and receive one another messages, and to store state. Fortunately the former is some Signal's quite good at, and storing state is something that phone hard drives are quite good at.
> Also, how does this protocol even help? What's the use case? It allows participants to discover mutual contacts, but what then? Do we use Bob as a web-of-trust style introducer? What if Alice doesn't even want to talk to Charlie? Do we do this for all the friends Alice has in common with Bob? Do we do this for all the friends Alice has in common with everyone?
It's the exact same use case as Signal's existing contact-discovery code, only private: it enables Alice & Bob to share information about a mutual acquaintance, e.g. Charlie. This might be used to share Charlie's key ID, in a trust on first use style. Note that this is no less secure than everyone everywhere trusting Open Whisper Systems on first use.
The idea is that when one starts using Signal, one exchanges keys in some out-of-band mechanism (NFC is a likely candidate) with an acquaintance, and then from that person get keys of mutual acquaintances, and from then others, and so on and so forth. Whenever you add a new acquaintance, one can reiterate the same protocol with all previous acquaintances (it's amenable to batching, too, which is nice) in order to propagate that information.
It may have some interesting uses in a certificate transparency sense, but I don't know about that.
> You end your last post with "So, problem solved" but I'm not sure this protocol even solves any practical problems for the Signal use case
It solves the exact same problems the Signal contact-discovery protocol solves, without actually revealing all one's contacts to OWS. That's all. If it did nothing more than that, it would be a good thing.
> It solves the exact same problems the Signal contact-discovery protocol solves, without actually revealing all one's contacts to OWS.
Except it doesn't. If you share your contacts with Signal, it can tell you which ones are on Signal.
If Alice shares her contacts with Bob, she may discover some contacts she has in common with Bob, but not necessarily which ones are Signal users. Perhaps Bob has talked to Charlie some time in the past using Signal, but perhaps not.
So if we run this chatty, online, synchronous protocol with each of your contacts you already know are on Signal who happen to be online at a given time (which will be a subset of all your contacts), you may-or-may-not discover some of your contacts use Signal.
In my previous post I was really asking about the user experience angle, which you didn't respond to at all, so rather than asking a question, let me simply say: I think this feature (at least in as much as I can conceive of it being used) would provide a poor user experience.
Except it doesn't. If you share your contacts with Signal, it can tell you which ones are on Signal.
If Alice shares her contacts with Bob, she may discover some contacts she has in common with Bob, but not necessarily which ones are Signal users. Perhaps Bob has talked to Charlie some time in the past using Signal, but perhaps not.
So if we run this chatty, online, synchronous protocol with each of your contacts you already know are on Signal who happen to be online at a given time (which will be a subset of all your contacts), you may-or-may-not discover some of your contacts use Signal.
In my previous post I was really asking about the user experience angle, which you didn't respond to at all, so rather than asking a question, let me simply say: I think this feature (at least in as much as I can conceive of it being used) would provide a poor user experience.
> If Alice shares her contacts with Bob, she may discover some contacts she has in common with Bob, but not necessarily which ones are Signal users. Perhaps Bob has talked to Charlie some time in the past using Signal, but perhaps not.
The contacts which would be shared would be Signal contacts, identified by some public identifier like their phone number (which is the only public identifier Signal currently supports; it could easily be extended to support other identifiers though).
Yes, it won't reveal to Alice that her friend Etta is also using Signal, if Etta and Alice don't have anyone in common. That's part of the privacy-preserving feature which prevents Signal from knowing who's using it, and whom everyone knows.
Given the small-world phenomenon, the odds are that one will very quickly add most folks one knows about, and the others can be added manually.
> So if we run this chatty, online, synchronous protocol
It's not chatty: the exchanges are large, in order to protect privacy, but they are also rare, and are not ongoing. Whenever you add a new contact, you re-initiate the protocol with your pre-existing contacts, that's all.
It's not online: as I indicated before all that's required is for each party to send & receive messages, and have some state.
It's synchronous, I'll grant, but only in the trivial sense that one party acts, then at some point in the future the other party acts. It certainly doesn't require both parties to be online at any point.
> In my previous post I was really asking about the user experience angle, which you didn't respond to at all, so rather than asking a question, let me simply say: I think this feature (at least in as much as I can conceive of it being used) would provide a poor user experience.
I think that the user experience would be identical to the current Signal UX: from time to time one's phone would buzz and indicate that one of one's friends uses Signal. If one wanted to, one could add a contact in person, e.g. through NFC or QR codes or whatever.
You seem very invested in hating this idea; you might ask why I'm so invested in it. Very simply, Signal is a tool for secure communication, but it requires that end users reveal every person they've ever communicated with to OWS.
The contacts which would be shared would be Signal contacts, identified by some public identifier like their phone number (which is the only public identifier Signal currently supports; it could easily be extended to support other identifiers though).
Yes, it won't reveal to Alice that her friend Etta is also using Signal, if Etta and Alice don't have anyone in common. That's part of the privacy-preserving feature which prevents Signal from knowing who's using it, and whom everyone knows.
Given the small-world phenomenon, the odds are that one will very quickly add most folks one knows about, and the others can be added manually.
> So if we run this chatty, online, synchronous protocol
It's not chatty: the exchanges are large, in order to protect privacy, but they are also rare, and are not ongoing. Whenever you add a new contact, you re-initiate the protocol with your pre-existing contacts, that's all.
It's not online: as I indicated before all that's required is for each party to send & receive messages, and have some state.
It's synchronous, I'll grant, but only in the trivial sense that one party acts, then at some point in the future the other party acts. It certainly doesn't require both parties to be online at any point.
> In my previous post I was really asking about the user experience angle, which you didn't respond to at all, so rather than asking a question, let me simply say: I think this feature (at least in as much as I can conceive of it being used) would provide a poor user experience.
I think that the user experience would be identical to the current Signal UX: from time to time one's phone would buzz and indicate that one of one's friends uses Signal. If one wanted to, one could add a contact in person, e.g. through NFC or QR codes or whatever.
You seem very invested in hating this idea; you might ask why I'm so invested in it. Very simply, Signal is a tool for secure communication, but it requires that end users reveal every person they've ever communicated with to OWS.
I guess you still don't understand where this falls down yet:
> The contacts which would be shared would be Signal contacts, identified by some public identifier like their phone number
If Alice and Bob are just comparing their directories of already-known Signal contacts, there's nothing for a discovery protocol to accomplish: Alice, Bob, and Charlie are already each other's contacts!
So this protocol can only help people discover contacts they are not yet aware are Signal users. That would involve comparing their full set of on-device contacts and sharing mappings of which one of those are within the subset of known Signal contacts.
> You seem very invested in hating this idea
I would continue trying to give you what I thought were constructive technical criticisms, but apparently you interpret that as me being "invested in hating" the idea.
It's more like I'm invested in providing good user experiences for security tools, which often involves starting with the user experience you want to provide and working backward, not starting with a cryptographic algorithm and trying to bolt-on a good user experience.
The latter is how we wound up with a pervasive ecosystem of unusable security tools that Signal is a refreshing departure from.
You are starting with a protocol, not thinking about the user experience, and declaring it a "solved problem". I'm not even convinced this protocol is the right tool for the job.
> The contacts which would be shared would be Signal contacts, identified by some public identifier like their phone number
If Alice and Bob are just comparing their directories of already-known Signal contacts, there's nothing for a discovery protocol to accomplish: Alice, Bob, and Charlie are already each other's contacts!
So this protocol can only help people discover contacts they are not yet aware are Signal users. That would involve comparing their full set of on-device contacts and sharing mappings of which one of those are within the subset of known Signal contacts.
> You seem very invested in hating this idea
I would continue trying to give you what I thought were constructive technical criticisms, but apparently you interpret that as me being "invested in hating" the idea.
It's more like I'm invested in providing good user experiences for security tools, which often involves starting with the user experience you want to provide and working backward, not starting with a cryptographic algorithm and trying to bolt-on a good user experience.
The latter is how we wound up with a pervasive ecosystem of unusable security tools that Signal is a refreshing departure from.
You are starting with a protocol, not thinking about the user experience, and declaring it a "solved problem". I'm not even convinced this protocol is the right tool for the job.
> If Alice and Bob are just comparing their directories of already-known Signal contacts, there's nothing for a discovery protocol to accomplish: Alice, Bob, and Charlie are already each other's contacts!
No, they are sharing (tel:+12025551212 signal:a31d79891919cad24f3264479d76884f581bee32e86778373db3a124de975dd86a40fc7f399b331133b281ab4b11a6ca) pairs. Alice and Bob determine that they both know Charlie; Alice and Bob then — since they both know one another and both know Charlie — feel good about sharing with one another what Charlie's Signal ID is.
> So this protocol can only help people discover contacts they are not yet aware are Signal users.
Which is exactly what Signal's current contact-sharing protocols does, in addition to helping Signal discover all of one's contacts.
> I would continue trying to give you what I thought were constructive technical criticisms, but apparently you interpret that as me being "invested in hating" the idea.
I will give you the benefit of the doubt and assume that your repeated failures to understand the protocol and its requirements are due to by own poor explanations, and further that you actually intend to be constructive.
> It's more like I'm invested in providing good user experiences for security tools, which often involves starting with the user experience you want to provide and working backward, not starting with a cryptographic algorithm and trying to bolt-on a good user experience.
I'm starting with a principle, not a protocol. That principal is that: online service providers must know the absolute minimum amount of information to do their jobs. Ideally, instant messaging would use some form of private information retrieval protocol so that server couldn't know who is talking to whom. Given Signal's current architecture, it must know to whom one is talking; there's no reason for it to also know everyone to whom one could be talking.
> The latter is how we wound up with a pervasive ecosystem of unusable security tools that Signal is a refreshing departure from.
Is it better to be usable but insecure than unusable but secure? I think the answer is mu: a product must be both usable and secure. Granted, security is always in the context of some threat, but it should be possible for users to intuitively grasp the security context.
> You are starting with a protocol, not thinking about the user experience
So, what do you think the user experience of contact discovery should be? I've already demonstrated that my proposal has an identical experience to Signal's, with the exception that one must manually register contacts not know to one of one's contacts. How would you implement contact sharing without giving OWS access to everyone's address book everywhere?
No, they are sharing (tel:+12025551212 signal:a31d79891919cad24f3264479d76884f581bee32e86778373db3a124de975dd86a40fc7f399b331133b281ab4b11a6ca) pairs. Alice and Bob determine that they both know Charlie; Alice and Bob then — since they both know one another and both know Charlie — feel good about sharing with one another what Charlie's Signal ID is.
> So this protocol can only help people discover contacts they are not yet aware are Signal users.
Which is exactly what Signal's current contact-sharing protocols does, in addition to helping Signal discover all of one's contacts.
> I would continue trying to give you what I thought were constructive technical criticisms, but apparently you interpret that as me being "invested in hating" the idea.
I will give you the benefit of the doubt and assume that your repeated failures to understand the protocol and its requirements are due to by own poor explanations, and further that you actually intend to be constructive.
> It's more like I'm invested in providing good user experiences for security tools, which often involves starting with the user experience you want to provide and working backward, not starting with a cryptographic algorithm and trying to bolt-on a good user experience.
I'm starting with a principle, not a protocol. That principal is that: online service providers must know the absolute minimum amount of information to do their jobs. Ideally, instant messaging would use some form of private information retrieval protocol so that server couldn't know who is talking to whom. Given Signal's current architecture, it must know to whom one is talking; there's no reason for it to also know everyone to whom one could be talking.
> The latter is how we wound up with a pervasive ecosystem of unusable security tools that Signal is a refreshing departure from.
Is it better to be usable but insecure than unusable but secure? I think the answer is mu: a product must be both usable and secure. Granted, security is always in the context of some threat, but it should be possible for users to intuitively grasp the security context.
> You are starting with a protocol, not thinking about the user experience
So, what do you think the user experience of contact discovery should be? I've already demonstrated that my proposal has an identical experience to Signal's, with the exception that one must manually register contacts not know to one of one's contacts. How would you implement contact sharing without giving OWS access to everyone's address book everywhere?
That's a terrible argument. What about all the other end-to-end encryption services that have more users and don't require you to give up anonymity?
> and the only alternative he mentioned is a half broken clone.
Sorry but you've got that backwards. He doesn't propose using that, he mentions OpenWhisperSystems banned them from using the service. It's criticism towards Signal, not a product recommendation.
> my current phone doesn't support Signal
I think it's Signal not supporting your phone, not the other way around. The manufacturer probably didn't make a conscious choice to not support Signal, but depending on what the issue is exactly, Signal probably did.
Sorry but you've got that backwards. He doesn't propose using that, he mentions OpenWhisperSystems banned them from using the service. It's criticism towards Signal, not a product recommendation.
> my current phone doesn't support Signal
I think it's Signal not supporting your phone, not the other way around. The manufacturer probably didn't make a conscious choice to not support Signal, but depending on what the issue is exactly, Signal probably did.
> OpenWhisperSystems banned them from using the service
Nobody has been banned from anything. People have been politely asked not to distribute 3rd-party builds of Signal using their name and their servers, and that's it.
Nobody has been banned from anything. People have been politely asked not to distribute 3rd-party builds of Signal using their name and their servers, and that's it.
I think the name is plenty different, nobody will mistake LibreSignal as being the same as Signal. That's as if Microsoft goes LibreOffice and OpenOffice are trademark infringements of Office (insofar as you can trademark the word "office" anyway).
As for the politely asking, yeah that is still banning. If you banish someone from a country, they can still physically walk into the country. They're just not allowed to.
As for the politely asking, yeah that is still banning. If you banish someone from a country, they can still physically walk into the country. They're just not allowed to.
I think you are mistaking my choice of words for a lack of understanding, but I do understand. The author makes no recommendation _outside_ of Signal related products.
Signal may not transmit any payload via Google Cloud Messaging, but Signal's requirement to run Google Play Services compromises the user's privacy in ways that have nothing to do with Signal. If you run Play Services then you have a device which provides your communications metadata, whereabouts, and device usage habits to Google.
I don't trust Google with this information and don't want to carry such a device, but a handful of friends and family use Signal, so I must choose between easy/secure communication with them, and reducing my exposure to corporate surveillance.
Signal may be "pragmatic" among the current choices (just like the project's decision to use GCM is pragmatic), but OpenWhisperSystems absolutely deserves criticism for:
1. Tying secure communication to running what amounts to Google's spyware on your device
2. Offering no alternative for privacy-conscious users
3. Showing hostility to those trying to introduce such an alternative to the project
I think those dismissing these concerns as "crypto-puritanism" will be on the wrong side of history.
I don't trust Google with this information and don't want to carry such a device, but a handful of friends and family use Signal, so I must choose between easy/secure communication with them, and reducing my exposure to corporate surveillance.
Signal may be "pragmatic" among the current choices (just like the project's decision to use GCM is pragmatic), but OpenWhisperSystems absolutely deserves criticism for:
1. Tying secure communication to running what amounts to Google's spyware on your device
2. Offering no alternative for privacy-conscious users
3. Showing hostility to those trying to introduce such an alternative to the project
I think those dismissing these concerns as "crypto-puritanism" will be on the wrong side of history.
> 3. Showing hostility to those trying to introduce such an alternative to the project
Quite the contrary, they're actively asking people to contribute code for an alternative push mechanism [1][2]:
"I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services."
[1] https://github.com/LibreSignal/LibreSignal/issues/37#issueco... [2] https://news.ycombinator.com/item?id=12883410
Quite the contrary, they're actively asking people to contribute code for an alternative push mechanism [1][2]:
"I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services."
[1] https://github.com/LibreSignal/LibreSignal/issues/37#issueco... [2] https://news.ycombinator.com/item?id=12883410
This.
I didn't know much of the insides of Signal. But, When WhatsApp decide to go in bed with FB to share my contacts and usage, one of the alternatives I explored was Signal. Threw it out the moment it asked for ownership of my contacts (no way to opt out). I for one am not going to trust a guy's pinky promise to be good with my contacts and meta-data.
If I'm going to give up the convenience of reaching anybody by WhatsApp, it is going to be at least worth it in the sense of privacy.
Still hoping for a GNU project that garners enough interest to be technically strong, and used universally. One can dream.
If I'm going to give up the convenience of reaching anybody by WhatsApp, it is going to be at least worth it in the sense of privacy.
Still hoping for a GNU project that garners enough interest to be technically strong, and used universally. One can dream.
I doubt you'd want to use it if it didn't use your contacts, though. Not many people are prepared to deal with a whole separate set of contact ids for the sake of a small amount of arguable extra privacy.
It's entirely possible for Signal to work with contacts and yet not transmit address books to OWS. I sketched out a protocol for doing so awhile back: https://news.ycombinator.com/item?id=11289223
So people could use their address books securely if they wanted — if OWS would allow them.
So people could use their address books securely if they wanted — if OWS would allow them.
Discoverability is complicated issue.
If I want someone I don't know yet to reach me, I expect them to Google search my phone number/email to make initial contact.
For those I already established initial contacts with, I'd like an account on a service that knows practically nothing about me other than my username(like coolkid654) and lets me send messages to others(coolkid655).
Given the state of data leaks[data snooping by the Gov or anyone else], and spam, it wouldn't be a terrible idea for someone to have a username that they reveal to only the people they trust(are worth). More like a Blackberry key. If packaged well, and made to look 'cool', it could even catch on and everybody would create one(or many).
If I want someone I don't know yet to reach me, I expect them to Google search my phone number/email to make initial contact.
For those I already established initial contacts with, I'd like an account on a service that knows practically nothing about me other than my username(like coolkid654) and lets me send messages to others(coolkid655).
Given the state of data leaks[data snooping by the Gov or anyone else], and spam, it wouldn't be a terrible idea for someone to have a username that they reveal to only the people they trust(are worth). More like a Blackberry key. If packaged well, and made to look 'cool', it could even catch on and everybody would create one(or many).
Sure, most won't right. But clearly in this thread some people are willing to do that and I'm not convinced that there is a large burden/cost to signal to allow this.
The problem for me is that my contact list of Signal users is quite small (1 or 2 people) and everyone else isn't using it. I don't see the reason to allow Signal access to that list of people "Just in case" they decide to. It's incredibly unlikely bordering on near impossible.
This isn't the golden bullet of reasons that it should be this way, but the fact that in design Signal has made the choice to force access to contacts to me, says one of two things.
1. We haven't thought about cases outside of our own experience and expressly reject those as being outside of the market we're interested in. "You're not the user we're looking for."
2. There is value/commoditisation in that contact list that signal is interested in and this is the price to play in their system.
The problem is that either of these two options run pretty counter to the idea of secure privacy focused messaging client designed to be seperate from the user.
People's value of privacy is nuanced enough that making broad scoped decisions like this can run afoul of their expectations. Considering that Signal is aiming itself at the privacy conscious (Over-conscious in a lot of instances I'm sure), it's very weird that they would forgo this obvious affordance of information.
The problem for me is that my contact list of Signal users is quite small (1 or 2 people) and everyone else isn't using it. I don't see the reason to allow Signal access to that list of people "Just in case" they decide to. It's incredibly unlikely bordering on near impossible.
This isn't the golden bullet of reasons that it should be this way, but the fact that in design Signal has made the choice to force access to contacts to me, says one of two things.
1. We haven't thought about cases outside of our own experience and expressly reject those as being outside of the market we're interested in. "You're not the user we're looking for."
2. There is value/commoditisation in that contact list that signal is interested in and this is the price to play in their system.
The problem is that either of these two options run pretty counter to the idea of secure privacy focused messaging client designed to be seperate from the user.
People's value of privacy is nuanced enough that making broad scoped decisions like this can run afoul of their expectations. Considering that Signal is aiming itself at the privacy conscious (Over-conscious in a lot of instances I'm sure), it's very weird that they would forgo this obvious affordance of information.
There could be two separate versions, one for paranoid users, one for those who don't care. The number of permissions Signal app requires is scary. It gets almost full control over your phone including reading SMS messages.
> The number of permissions Signal app requires is scary.
This is exactly why I'm shying back from recommending Signal to my family. I taught them that the equation "permissions = bad" generally holds, so Signal would look like spyware to them, even if every single permission turns out to be justified for some reason.
This is exactly why I'm shying back from recommending Signal to my family. I taught them that the equation "permissions = bad" generally holds, so Signal would look like spyware to them, even if every single permission turns out to be justified for some reason.
What's wrong with having options ?
Ring looks promising, re GNU projects.
I've personally reached the conclusion that software isn't enough for this, though: it is people who choose to flog your data and it is money that buys it (think FB and WhatsApp). In my view a collectively owned version of something like Signal would offer protection from what is termed corporate surveillance by allowing people with skin in the game to directly influence decisions on things like privacy policies and development roadmaps. I've sketched this in a bit more detail here: https://news.ycombinator.com/item?id=12881917
I've personally reached the conclusion that software isn't enough for this, though: it is people who choose to flog your data and it is money that buys it (think FB and WhatsApp). In my view a collectively owned version of something like Signal would offer protection from what is termed corporate surveillance by allowing people with skin in the game to directly influence decisions on things like privacy policies and development roadmaps. I've sketched this in a bit more detail here: https://news.ycombinator.com/item?id=12881917
"Also, there’s the issue of integrity. Google is still
cooperating with the NSA and other intelligence agencies.
PRISM is also still a thing."
https://googleblog.blogspot.com/2013/06/what.html
Google’s chief legal officer claimed that collection was being done without Google's consent:
http://www.irishtimes.com/news/technology/google-outraged-at...
Evidence leaked by Edward Snowden also points in the direction of illegal infiltration of Google's private network without Google's consent:
https://www.washingtonpost.com/world/national-security/nsa-i...
On this:
https://wikileaks.org/Op-ed-Google-and-the-NSA-Who-s.html
there are links on that page that point out multiple e-mails from the STRATFOR leaks and other files that point to Google being deeply embedded with the U.S. security apparatus.
Also: https://www.theguardian.com/world/2013/aug/23/nsa-prism-cost...
there are links on that page that point out multiple e-mails from the STRATFOR leaks and other files that point to Google being deeply embedded with the U.S. security apparatus.
Also: https://www.theguardian.com/world/2013/aug/23/nsa-prism-cost...
And Google became a PRISM partner in 2009, as the slides here from the Snowden collection prove:
https://search.edwardsnowden.com/docs/PRISMUS-984XNOverview2...
And Google became a PRISM partner in 2009,
as the slides here from the Snowden collection prove
As the previous links from STRATFOR etc. prove, Google is deeply embedded in the security/intelligence apparatus. That part is definitely willing and beneficial to both parties. Of course, they're going to make changes and issue statements to the contrary regarding PRISM, because that would lose them customers.
This is also an interesting read, albeit a bit long: https://wikileaks.org/google-is-not-what-it-seems/
Google continues to coast on the goodwill of its "don't be evil" doublespeak, as Mr. Assange puts it. There's no reason to trust them now.
This is also an interesting read, albeit a bit long: https://wikileaks.org/google-is-not-what-it-seems/
Google continues to coast on the goodwill of its "don't be evil" doublespeak, as Mr. Assange puts it. There's no reason to trust them now.
You've presented no proof whatsoever. All you've done is make unsubstantiated allegations.
Slight correction. Google is a willing* PRISM partner, but they don't use the name PRISM, and PRISM isn't quite what was originally described.
The leaks related to exploitation of Google traffic refer to programs unrelated to PRISM.
*Willing in the sense that they have to respond to FISA orders and NSLs, and they have agreed to do it according to a certain protocol.
The leaks related to exploitation of Google traffic refer to programs unrelated to PRISM.
*Willing in the sense that they have to respond to FISA orders and NSLs, and they have agreed to do it according to a certain protocol.
Any messenger, tied to phone number, is not safe. possible attacks are: 1) create copy of sim-card; 2) force mobile operator to intercept password-code, sent to your number, and "restore" password this way.
It may sound ridiculous for you, but in Russia it's reality (both vectors), it's real cases from life. And when user really need safe messenger, all of them are too careless to implement really safe way of messaging. And if you think these vectors are not possible in your country - be sure, we were thinking the same way.
This is why there is a fingerprint ("Safety Numbers" in Signal), and a warning on every message when that fingerprint changes.
Warning still does not fully prevent the attack. The attacker can still access the account and obtain the data stored at a server (like contact list if it is stored there).
> like contact list if it is stored there
The only thing that we know they store is the creation timestamp and last-seen timestamp for each account: http://arstechnica.com/tech-policy/2016/10/fbi-demands-signa...
Reading over the article again, though, it neither confirms nor denies where these timestamps are the only thing stored about an account. They explain these are the only data matching the concrete subpoena they received.
The only thing that we know they store is the creation timestamp and last-seen timestamp for each account: http://arstechnica.com/tech-policy/2016/10/fbi-demands-signa...
Reading over the article again, though, it neither confirms nor denies where these timestamps are the only thing stored about an account. They explain these are the only data matching the concrete subpoena they received.
[deleted]
Which everyone, including myself, clicks through.
EDIT: this isn't a response to most of the article, but specifically to the "Moving Forward" section, asking about alternative tools.
Come to the matrix!
https://matrix.org/
It's free -- all FOSS, including the entirety of the server -- and yes, all of it: proof by existence: several of my friends run their own.
It federates. I regularly join channels hosted on several different servers, and exchange messages without issue.
It's on every platform. I use it on the desktop, my android (cyanogen, without gapps, none the less!), and my ipad, every day.
It even has voice and video calling built in, using webRTC. This feature has been a little rough while it was in development, but I used it last week in a 1-on-1 call and had an effortless experience. The audio and video quality was on par with Google Hangouts.
Crypto is hard, but it's coming. The Matrix developers have huge respect for the axolotl ratchet design used in Signal. They've worked on making another implementation (in C, for easier linking in various languages, ostensibly) here: https://matrix.org/git/olm/
The deployment of that code to give full End-to-End encryption is a work in progress, but the beta is roughly functional. It includes everything you'd expect: communication works by default, but in an encrypted room, messages are flagged yellow if you haven't explicitly verified the sender's key. There's a key per device; it doesn't leave the device; and as soon as you verify that device/key, messages from it are green, and you're E2E secure.
Disclaimer: I have no direct association -- I became a Matrix convert after trying to write some XMPP client code about a year ago. I'm just really enthusiastic about recommending it because the tech is solid, the sync is good, it solves a problem, and the team hasn't stopped either: they been firing on all cylinders constantly since I started using Matrix.
I love Signal for their dedication to getting encryption right and the security of their users. But yes, I also share a lot of the concerns listed in this article. Most of all, I honestly believe federation is an imperative. So, while acknowledging Signal's history of outstanding security work... Hey, let's celebrate there's more than one game in town working on alternatives.
Come to the matrix!
https://matrix.org/
It's free -- all FOSS, including the entirety of the server -- and yes, all of it: proof by existence: several of my friends run their own.
It federates. I regularly join channels hosted on several different servers, and exchange messages without issue.
It's on every platform. I use it on the desktop, my android (cyanogen, without gapps, none the less!), and my ipad, every day.
It even has voice and video calling built in, using webRTC. This feature has been a little rough while it was in development, but I used it last week in a 1-on-1 call and had an effortless experience. The audio and video quality was on par with Google Hangouts.
Crypto is hard, but it's coming. The Matrix developers have huge respect for the axolotl ratchet design used in Signal. They've worked on making another implementation (in C, for easier linking in various languages, ostensibly) here: https://matrix.org/git/olm/
The deployment of that code to give full End-to-End encryption is a work in progress, but the beta is roughly functional. It includes everything you'd expect: communication works by default, but in an encrypted room, messages are flagged yellow if you haven't explicitly verified the sender's key. There's a key per device; it doesn't leave the device; and as soon as you verify that device/key, messages from it are green, and you're E2E secure.
Disclaimer: I have no direct association -- I became a Matrix convert after trying to write some XMPP client code about a year ago. I'm just really enthusiastic about recommending it because the tech is solid, the sync is good, it solves a problem, and the team hasn't stopped either: they been firing on all cylinders constantly since I started using Matrix.
I love Signal for their dedication to getting encryption right and the security of their users. But yes, I also share a lot of the concerns listed in this article. Most of all, I honestly believe federation is an imperative. So, while acknowledging Signal's history of outstanding security work... Hey, let's celebrate there's more than one game in town working on alternatives.
I'm also a Matrix convert. Tried getting Conversations + Prosody running for me and my wife but just couldn't get it to work properly. XMPP has so many XEPs (like MAM - XEP-0313) that you need to get things working nicely and there are very few clients (Conversations only afaik) that actually support them. We also found that Conversations just wouldn't send/receive messages sometimes and that when there was no connection, it'd pretend everything was fine and dandy but not actually send.
Switched to Matrix and setting up my own homeserver took about half an hour, comes with everything I need (history, "Carbons", notifications, attachments, voice/video) built in. Plus it's federated and has support for bridges so I can interact with pretty much anything else through it if I like.
Switched to Matrix and setting up my own homeserver took about half an hour, comes with everything I need (history, "Carbons", notifications, attachments, voice/video) built in. Plus it's federated and has support for bridges so I can interact with pretty much anything else through it if I like.
I heard from another thread that Matrix is bad a realtime messaging, and quite slow at it. Is this true?
Not even remotely.
It's quite good at realtime, and especially reliable realtime. Compared with protocols like XMPP, Matrix scores way higher on reliability because it has message IDs and message ordering baked into the protocol, so it can actually converge on a correct state after network flakes. (I consider this a pretty big deal because silent message drops were a pretty regular issue for me in XMPP, and we all know about netsplits in IRC. I've simply never had silent message loss in Matrix because the protocol is simply better.)
It's quite good at realtime, and especially reliable realtime. Compared with protocols like XMPP, Matrix scores way higher on reliability because it has message IDs and message ordering baked into the protocol, so it can actually converge on a correct state after network flakes. (I consider this a pretty big deal because silent message drops were a pretty regular issue for me in XMPP, and we all know about netsplits in IRC. I've simply never had silent message loss in Matrix because the protocol is simply better.)
I'm not trying to compare xmpp (which I know a bit) and matrix (which I don't know about, really), but losing messages with xmpp is probably a thing of the past. There were a good number of issues (the protocol originally didn't expect mobile devices that change addresses/connectivity all the time), but with a somewhat recent set of client and server you should be good.
Ah. It was claimed by https://news.ycombinator.com/item?id=12880856, but that was an XMPP developer, so there's a bias.
It's true that it's a big hunk of JSON. And I'll readily concede that when efficiency matters, I'm more partial to binary formats like CBOR. But XMPP is XML, which... isn't exactly lighter.
There's another HN thread where I've talked more about XMPP vs Matrix here: https://news.ycombinator.com/item?id=9772968 -- long story short, I tried to write an XMPP client, and I got grey hairs, fast. The story for consistent delivery is pretty much bananas. (And huh, based on that date, I guess I've been a Matrix convert for almost TWO years now! Time flies.)
I'm not entirely sure what the comment about battery is about either. If anyone has a networking technology that can work without turning on the phone radio, I'm sure we'd all love to hear it...?
Practically speaking, I leave the Matrix Vector app open on my phone constantly. As of this morning, I have half a charge, and three more days of charge to go. I don't have any other apps to provide a good comparison here, but I'll leave this screenshot here for what it's worth: https://matrix.org/_matrix/media/v1/download/matrix.org/IgkU... Looks like my phone has spent about the same order of magnitude of battery on just plain paging the cell towers as I moved around the city. As other comments on this thread cover, if you use proprietary Google stuff, you can wake the phone up slightly more efficiently. But whatever this app is doing works pretty fine for me.
There's another HN thread where I've talked more about XMPP vs Matrix here: https://news.ycombinator.com/item?id=9772968 -- long story short, I tried to write an XMPP client, and I got grey hairs, fast. The story for consistent delivery is pretty much bananas. (And huh, based on that date, I guess I've been a Matrix convert for almost TWO years now! Time flies.)
I'm not entirely sure what the comment about battery is about either. If anyone has a networking technology that can work without turning on the phone radio, I'm sure we'd all love to hear it...?
Practically speaking, I leave the Matrix Vector app open on my phone constantly. As of this morning, I have half a charge, and three more days of charge to go. I don't have any other apps to provide a good comparison here, but I'll leave this screenshot here for what it's worth: https://matrix.org/_matrix/media/v1/download/matrix.org/IgkU... Looks like my phone has spent about the same order of magnitude of battery on just plain paging the cell towers as I moved around the city. As other comments on this thread cover, if you use proprietary Google stuff, you can wake the phone up slightly more efficiently. But whatever this app is doing works pretty fine for me.
XMPP only has to turn the radio on full power mode when it gets a new message or creates a new connection (the tower sends the LTE radio a paging message telling it to wake up, then the long-lived TCP connection can receive data). Matrix has to turn the radio on every single time it wants to check for data, regardless of whether there is data to receive or not. This is the problem with HTTP based protocols; you might have a persistent TCP connection, but it doesn't help you when you have to send a request just to check if there are new messages.
It's not a case of radio off vs on, it's a case of the radio being able to stay in RRC_IDLE mode (which I've probably called "off" more than once, which is where the confusion came from I'm sure, apologies for that) for more of the time, where as with Matrix it almost always has to remain RRC_CONNECTED mode.
It's not a case of radio off vs on, it's a case of the radio being able to stay in RRC_IDLE mode (which I've probably called "off" more than once, which is where the confusion came from I'm sure, apologies for that) for more of the time, where as with Matrix it almost always has to remain RRC_CONNECTED mode.
I don't believe this is true. The long-polling that Matrix does in the baseline impl is just a long-lived HTTP request which blocks until the server has something to send it. Radio-wise this is conceptually the same as an XMPP TCP connection.
The only difference is that (in the baseline impl) you start a new HTTP request after receiving each response - which chews some additional data relative to XMPP. The radio will already be spun up from receiving the previous data, though, so it shouldn't impact significantly on battery consumption.
Also, we put a timeout on the long-lived request (typically 30-60s), to aid recovery in case of the request or connectivity breaking - which could theoretically increase bandwidth and radio battery consumption, but in practice almost all Matrix use cases involve receiving events more frequently than the timeout, so the timeout doesn't actually have much impact on battery.
That said, there is (deliberately) huge scope for improvement with alternative transports - using strict push rather than long-polling; using transports with less overhead; using more efficient encodings, etc.
The only difference is that (in the baseline impl) you start a new HTTP request after receiving each response - which chews some additional data relative to XMPP. The radio will already be spun up from receiving the previous data, though, so it shouldn't impact significantly on battery consumption.
Also, we put a timeout on the long-lived request (typically 30-60s), to aid recovery in case of the request or connectivity breaking - which could theoretically increase bandwidth and radio battery consumption, but in practice almost all Matrix use cases involve receiving events more frequently than the timeout, so the timeout doesn't actually have much impact on battery.
That said, there is (deliberately) huge scope for improvement with alternative transports - using strict push rather than long-polling; using transports with less overhead; using more efficient encodings, etc.
As has been noted upthread, Matrix does allow for alternate transports. So this may not be quite as big an issue.
It has to make an HTTP request every single time it wants to check if there are new messages… I wouldn't call that a good realtime protocol (though in fairness, I'm sure it's good for many other things).
Matrix isn't tied to HTTP - it's just the baseline protocol. The idea is for people to propose whatever custom efficient transports they like, maintaining HTTP as the lowest common denominator. For instance https://github.com/matrix-org/matrix-websockets-proxy is such a WebSocket proposal.
Sure, and that's better, I agree, but XMPP also works the same way, but it's base protocol is much lower layer (a TCP connection instead of a higher layer protocol like HTTP). The point is that the default (which is always what most people will stick with), is too cumbersome and inefficient for realtime applications.
Agreed that XMPP is much lighter in terms of server processing than Matrix (they are doing entirely different things, after all). In terms of transport, yes: Matrix's default HTTP/1+JSON transport is heavier than baseline XMPP.
I haven't checked but my hunch would be that HTTP/2+JSON would be very similar to typical XMPP in terms of bandwidth, if not better, and obviously requires no spec changes; just an HTTP/2 capable client & server/LB.
In terms of what transport people use: well, I assume end-users will use whatever the best performing clients implement. Riot is the flagship client and will obviously do better than HTTP+JSON; meanwhile we've had a lot of pressure from Weechat to start using a better transport (e.g. websockets) for them (https://riot.im/app/#/room/#matrix:matrix.org/$1477998960439... meanwhile Ralith (the author of the NaChat Qt matrix client) has been working himself on a capnproto transport due to wanting something faster & better than the baseline.
So we're not particularly worried that most people will stick with the baseline for daily usage. Instead, it'll act as a really nice and easy on-ramp for new developers, debugging/deving on the API, etc. Anyone serious will end up using a better transport.
Finally: it's worth noting that adding E2E by default into Matrix increases the complexity of clients enormously - so we expect the plain `curl -XPUT /_matrix/client/r0/rooms/.../m.room.message --data { "body": "hello world" }` style APIs to increasingly be just for experimentation, initial dev and prototyping. As soon as you want to start talking E2E folks will reach for a full client SDK, at which point they will get access to both E2E and whatever weird & wonderful transports that SDK happens to provide. So, again, the majority of users won't be on plain ol' HTTP.
I haven't checked but my hunch would be that HTTP/2+JSON would be very similar to typical XMPP in terms of bandwidth, if not better, and obviously requires no spec changes; just an HTTP/2 capable client & server/LB.
In terms of what transport people use: well, I assume end-users will use whatever the best performing clients implement. Riot is the flagship client and will obviously do better than HTTP+JSON; meanwhile we've had a lot of pressure from Weechat to start using a better transport (e.g. websockets) for them (https://riot.im/app/#/room/#matrix:matrix.org/$1477998960439... meanwhile Ralith (the author of the NaChat Qt matrix client) has been working himself on a capnproto transport due to wanting something faster & better than the baseline.
So we're not particularly worried that most people will stick with the baseline for daily usage. Instead, it'll act as a really nice and easy on-ramp for new developers, debugging/deving on the API, etc. Anyone serious will end up using a better transport.
Finally: it's worth noting that adding E2E by default into Matrix increases the complexity of clients enormously - so we expect the plain `curl -XPUT /_matrix/client/r0/rooms/.../m.room.message --data { "body": "hello world" }` style APIs to increasingly be just for experimentation, initial dev and prototyping. As soon as you want to start talking E2E folks will reach for a full client SDK, at which point they will get access to both E2E and whatever weird & wonderful transports that SDK happens to provide. So, again, the majority of users won't be on plain ol' HTTP.
There's a fundamental assumption here: that there is a better way. I'm not saying there isn't, but there's a pretty good existence proof that Signal is the best combination of security & simplicity we can put together.
I would agree with this statement from the article: "there should be a tool that is fully free software (as defined by the GNU GPL), that respects users' freedoms to freely inspect, use, modify the software and distributed modified copies of the software. Also, this tool should not have dependencies on corporate infrastructure like Google’s (basically any partner in PRISM), that allows these parties to control the correct working of the software."
There are such tools. None of them are as easy to use as Signal. So for now, I recommend Signal. I can't, in good conscience, recommend anything else... and given the author doesn't speak to what they recommend, I'm curious about what their recommendation would be.
I would agree with this statement from the article: "there should be a tool that is fully free software (as defined by the GNU GPL), that respects users' freedoms to freely inspect, use, modify the software and distributed modified copies of the software. Also, this tool should not have dependencies on corporate infrastructure like Google’s (basically any partner in PRISM), that allows these parties to control the correct working of the software."
There are such tools. None of them are as easy to use as Signal. So for now, I recommend Signal. I can't, in good conscience, recommend anything else... and given the author doesn't speak to what they recommend, I'm curious about what their recommendation would be.
[deleted]
"Also, there’s the issue of integrity. Google is still cooperating with the NSA and other intelligence agencies. PRISM is also still a thing. I’m pretty sure that Google could serve a specially modified update or version of Signal to specific targets for surveillance, and they would be none the wiser that they installed malware on their phones."
Isn't part of the reason that Moxie went with the Google Store is that he gets to sign the god damned binaries, making it impossible for Google to modify the app.
Isn't part of the reason that Moxie went with the Google Store is that he gets to sign the god damned binaries, making it impossible for Google to modify the app.
Hi, author here. Yes, my point with that sentence was that the average (non-technical) user (to which Signal is marketed btw), is not going to check signatures. Google has root on the phone, the user is using their app store to install the Signal app that comes up in the store, and basically Google has full control over this, and the user would be none the wiser.
Of course, us more technical inclined people could then check the signature, or compare the apk with one built from the official sources, to see the difference and complain about it.
But between those things is a time frame where this is possible.
Of course, us more technical inclined people could then check the signature, or compare the apk with one built from the official sources, to see the difference and complain about it.
But between those things is a time frame where this is possible.
Does it, actually?
I was under the impression that the Play Store doesn't run as root and the package manager API (controlled by the phone manufacturer) is what checks signatures. Can the Play Store override the signature checks on upgrade and if so, what codepaths is it using?
I was under the impression that the Play Store doesn't run as root and the package manager API (controlled by the phone manufacturer) is what checks signatures. Can the Play Store override the signature checks on upgrade and if so, what codepaths is it using?
Just a quick look, but this is the PackageManager.java file:
https://android.googlesource.com/platform/frameworks/base/+/...
for the Android base framework. It has the checkSignatures() abstract definition and some other stuff that seems to be the API you talk about. Now this is all abstract, so some other party (maybe phone manufacturer, possibly others) must implement these methods to conform to the API. Could Google (or some other party) not just override the abstract implementation?
I find it hard to believe this is something only the phone manufacturer would have access to, not Google itself, given that Google has created the entire operating system basically, and is pulling more and more stuff from the AOSP into their proprietary apps (like Play services).
https://android.googlesource.com/platform/frameworks/base/+/...
for the Android base framework. It has the checkSignatures() abstract definition and some other stuff that seems to be the API you talk about. Now this is all abstract, so some other party (maybe phone manufacturer, possibly others) must implement these methods to conform to the API. Could Google (or some other party) not just override the abstract implementation?
I find it hard to believe this is something only the phone manufacturer would have access to, not Google itself, given that Google has created the entire operating system basically, and is pulling more and more stuff from the AOSP into their proprietary apps (like Play services).
The subclass would have to be in the same process as the package manager (the system server) so it being abstract doesn't matter much.
Android doesn't rely so much on root vs non-root: it uses SELinux and lots of capability based security. Root is still there of course but out of the box, even the parts under remote OEM control don't run as root. If the OEM wants to change the basic rules of the system they must push a system update and get the user to agree to it. Of course a firmware update can change anything but outside of that I'm not convinced Google can just replace software at will.
Android doesn't rely so much on root vs non-root: it uses SELinux and lots of capability based security. Root is still there of course but out of the box, even the parts under remote OEM control don't run as root. If the OEM wants to change the basic rules of the system they must push a system update and get the user to agree to it. Of course a firmware update can change anything but outside of that I'm not convinced Google can just replace software at will.
[deleted]
Google has root on your phone. That is enough for them to replace any signatures, steal keys, replace apps without you knowing etc.
This. If Google controlling your phone via a remote backdoor is part of your threat model, you better start shopping for a different operating system anyway. That's not an issue with any particular Android app, it's an issue with Android.
Wire (http://wire.com) has worked well on iOS for encrypted text/files/audio/video. Open-source client, no contact sharing neeeded. No phone number needed, you can register with email by using a desktop browser at http://app.wire.com, then logging into the mobile app. Group chat for text only. Timed/ephemeral messages for 1:1 text/files. Feature matrix, https://wire.com/privacy/. Could use more documentation (e.g. on retention of encrypted data) but a lot of questions are answered on Twitter or Github issues.
> Don't know whether it needs GCM on Android.
The .apk on the site uses websocket, no GCM required.
The .apk on the site uses websocket, no GCM required.
Timed coming to groups in couple of weeks.
Documentation is also getting a refresh in 2 weeks.
Documentation is also getting a refresh in 2 weeks.
From the post:
"The Google Cloud Messaging service basically handles message handling from/to the user’s devices to the Signal servers. The GCM service then handles all the aspects of queueing all messages and delivery from/to users."
This is not true. Messages are delivered via Signal's own servers only. GCM messages are empty; their only purpose is to wake up your device. [1]
"The phone component of Signal is called RedPhone. The server component of this is unfortunately not open source [...] this is also probably the reason why secure encrypted phone calls don’t work in e.g. LibreSignal"
No. The reason for that is that the signaling for RedPhone calls is currently still done via GCM and not via Signal's own message transport.
Regarding microg: I've never heard of the need to re-compile kernels for that. I think most people use it with Xposed (admittedly, a giant hack, but it works).
[1] https://whispersystems.org/blog/goodbye-encrypted-sms/
"The Google Cloud Messaging service basically handles message handling from/to the user’s devices to the Signal servers. The GCM service then handles all the aspects of queueing all messages and delivery from/to users."
This is not true. Messages are delivered via Signal's own servers only. GCM messages are empty; their only purpose is to wake up your device. [1]
"The phone component of Signal is called RedPhone. The server component of this is unfortunately not open source [...] this is also probably the reason why secure encrypted phone calls don’t work in e.g. LibreSignal"
No. The reason for that is that the signaling for RedPhone calls is currently still done via GCM and not via Signal's own message transport.
Regarding microg: I've never heard of the need to re-compile kernels for that. I think most people use it with Xposed (admittedly, a giant hack, but it works).
[1] https://whispersystems.org/blog/goodbye-encrypted-sms/
Hmm. You seem to be right. Article corrected there to reflect that Signal is using empty GCM messages. I must have still had the old situation of TextSecure in my head when I wrote that. Nice to know re the reason Redphone doesn't work, thanks for that insight!
(had suggested the author add an endnote; they did)
Yes, I agree that's more transparent. I've added an endnote, and linked to it from the place where the edit was made.
[deleted]
Can't wait for moxie to jump into the commentary. :)
>Lack of federation
Moxie's pissy because he trusted the kangbangers at Cyanogenmod to to keep in sync with his development. They didn't. Someone will need to volunteer to run their own server that's kept updated, then buy Moxie a Snickers and hope he stops being moody.
>Dependency on Google Cloud Messaging
Fun fact: The iOS client doesn't use GCM, it uses Pushkit. GCM was chosen for Android because what else is as robust and doesn't eat battery? Moxie's voiced support of Websockets if someone implements it correctly and he can merge it as a fallback option when Play Services are missing. If you can't code and want it, contribute to the bounty on it:
https://github.com/LibreSignal/LibreSignal/issues/37
https://github.com/LibreSignal/LibreSignal/issues/43
> Your contact list is not private
https://whispersystems.org/blog/contact-discovery/
TL;DR, it's a tradeoff because nobody has a better idea that works at scale and is usable. Redphone used to have a good way of blindly doing contact discovery but it would require too much data for their current userbase.
>Lack of federation
Moxie's pissy because he trusted the kangbangers at Cyanogenmod to to keep in sync with his development. They didn't. Someone will need to volunteer to run their own server that's kept updated, then buy Moxie a Snickers and hope he stops being moody.
>Dependency on Google Cloud Messaging
Fun fact: The iOS client doesn't use GCM, it uses Pushkit. GCM was chosen for Android because what else is as robust and doesn't eat battery? Moxie's voiced support of Websockets if someone implements it correctly and he can merge it as a fallback option when Play Services are missing. If you can't code and want it, contribute to the bounty on it:
https://github.com/LibreSignal/LibreSignal/issues/37
https://github.com/LibreSignal/LibreSignal/issues/43
> Your contact list is not private
https://whispersystems.org/blog/contact-discovery/
TL;DR, it's a tradeoff because nobody has a better idea that works at scale and is usable. Redphone used to have a good way of blindly doing contact discovery but it would require too much data for their current userbase.
Layoff the personalised attacks on the psychology of someone who has helped increase the security of hundreds of millions of people for free, on basically a shoestring. Making pro/against arguments about Signal is fine but Moxie is genuinely a nice person (as are the rest of the former and current OWS team), so let's keep the argument civil.
I actually insulted the Cyanogenmod team and I think it's funny you missed that.
I don't have an issue with Moxie except that he's been pissy over this and a few other issues. I don't think anyone is going to argue that he isn't. Why not check the first link to the Libresignal thread and read his comments on the topic?
(EDIT: I get the downvotes on this comment, but like Moxie, I too am seriously annoyed that Cyanogenmod dropped the ball so bad with them. Moxie would need to get over it if there's a new solution in the future and HE ALREADY VOICED HIS OPINION THAT FEDERATION IS UNLIKELY. If that's not being pissy, I don't know what else is. I used to run Libresignal on BB10 and now I can't because of this policy of being anti-federation and no work moving forward on websockets fallback. He'll likely say no to approving the fallback on Replicant/Sailfish/BB10 because he doesn't get version reporting through analytics and is concerned about disturbances of the signal server.)
I don't have an issue with Moxie except that he's been pissy over this and a few other issues. I don't think anyone is going to argue that he isn't. Why not check the first link to the Libresignal thread and read his comments on the topic?
(EDIT: I get the downvotes on this comment, but like Moxie, I too am seriously annoyed that Cyanogenmod dropped the ball so bad with them. Moxie would need to get over it if there's a new solution in the future and HE ALREADY VOICED HIS OPINION THAT FEDERATION IS UNLIKELY. If that's not being pissy, I don't know what else is. I used to run Libresignal on BB10 and now I can't because of this policy of being anti-federation and no work moving forward on websockets fallback. He'll likely say no to approving the fallback on Replicant/Sailfish/BB10 because he doesn't get version reporting through analytics and is concerned about disturbances of the signal server.)
[deleted]
Nothing is stopping anyone from running their own servers, changing the username scheme, and implementing the voice signaling. Moxie doesn't complain about such usage. But that's more work than simply complaining and telling OWS what they should do.
As far as usernames go, that would require the signaling key to be remembered by the user. That doesn't work well in practice. As far as contact sync goes, has anyone submitted a patch for the android client to add an advanced option to disable that? On IOS access to the address book is user controlled at runtime. destinations will be validated by the server at compose time. Regarding federation, let's see some code. It's ridiculous to demand the small team that is OWS solve every single problem.
As far as usernames go, that would require the signaling key to be remembered by the user. That doesn't work well in practice. As far as contact sync goes, has anyone submitted a patch for the android client to add an advanced option to disable that? On IOS access to the address book is user controlled at runtime. destinations will be validated by the server at compose time. Regarding federation, let's see some code. It's ridiculous to demand the small team that is OWS solve every single problem.
> Regarding federation, let's see some code. It's ridiculous to demand the small team that is OWS solve every single problem.
Moxie has explicitly rejected federation. Anyone writing such code is wasting their time it won't get accepted.
Moxie has explicitly rejected federation. Anyone writing such code is wasting their time it won't get accepted.
Yep. You can run your own federation though. And maybe if it's really awesome he'll change his mind.
I have started to read about matrix a lot.
- It now supports e2e encryption.
- It has a nice web and mobile client, called riot.im
- I has many other client options
- You don't need to show any phone numbers.
- Federated, you can host your own server
- It now supports e2e encryption.
- It has a nice web and mobile client, called riot.im
- I has many other client options
- You don't need to show any phone numbers.
- Federated, you can host your own server
Animated GIFS were the straw that broke the camels back?
Let's throw the best available solution under the bus.
This post will be my go to example of the myopia of some members of the security community. We have very few examples of well executed, consumer friendly privacy soloutions. Signal is the best for all possible scenarios: Open source, user friendly, buy in from a major Internet service.
I like wickr, but it falls short due to the closed source nature of the project.
Consumer friendly, usable security needs to be the number one priority for security advocates. We need to stop burning down houses because they are short a door or are the wrong color. The foundation is the hard part. Wait till there is a real alternative that can be used by people who are not c.s. majors before you argue that people should stop using the best available solution.
I appreciate the authors perspective and I agree with some of their points. Then they fuck it up by demonstrating purist jackassery. Worth a read as a useful persuasion antipattern.
Let's throw the best available solution under the bus.
This post will be my go to example of the myopia of some members of the security community. We have very few examples of well executed, consumer friendly privacy soloutions. Signal is the best for all possible scenarios: Open source, user friendly, buy in from a major Internet service.
I like wickr, but it falls short due to the closed source nature of the project.
Consumer friendly, usable security needs to be the number one priority for security advocates. We need to stop burning down houses because they are short a door or are the wrong color. The foundation is the hard part. Wait till there is a real alternative that can be used by people who are not c.s. majors before you argue that people should stop using the best available solution.
I appreciate the authors perspective and I agree with some of their points. Then they fuck it up by demonstrating purist jackassery. Worth a read as a useful persuasion antipattern.
I've trained hundreds of human rights defenders and journalists over the last 10 years and I will continue to recommend Signal. For too long the community has placed perfect security over usability - there are slightly more secure ways to communicate than Signal but they are far too disruptive to peoples work flows to actually be implemented.
> this tool should not have dependencies on corporate infrastructure like Google’s (basically any partner in PRISM)
Free yourself from the bonds of corporate infrastructure by installing this tool on your Google Android or Apple iPhone device (Microsoft Windows desktop version coming soon).
Free yourself from the bonds of corporate infrastructure by installing this tool on your Google Android or Apple iPhone device (Microsoft Windows desktop version coming soon).
There are several projects moving toward this. Matrix is probably the most well-known project, but its crypto isn't actually operational yet, AFAIK.
Tox works now, but for all their talk of trying to be user-friendly, asking users to exchange long alphanumeric sequences inherently isn't.
Psyc, maybe?
Tox works now, but for all their talk of trying to be user-friendly, asking users to exchange long alphanumeric sequences inherently isn't.
Psyc, maybe?
E2E Crypto is very nearly operational. It's live (in beta) on the web on https://riot.im/app, and meanwhile the iOS & Android implementation PRs have (almost) landed on the develop branches of matrix-ios-sdk and matrix-android-sdk respectively. Our crypto audit is complete, and we're hoping to unveil it to the world in the next week or two.
Good to hear it!
Matrix's protocol design is terrible for realtime messaging though (I'm sure there are other uses for which it's more adept); it's effectively a giant, inefficient, JSON datastore that syncs data everywhere. It's also pull based so it consumes battery like crazy. If that's what you need, fine, but for realtime messaging I'd argue that it's really unacceptable.
As per elsewhere on this thread, this isn't entirely fair. Matrix uses HTTP+JSON as its lowest common denominator, but the whole idea is for people to use WS+CBOR or capnproto or whatever whenever they need efficiency.
In terms of "syncing data everywhere" being 'terrible for realtime messaging'... i'm not sure that holds water ;)
In terms of "syncing data everywhere" being 'terrible for realtime messaging'... i'm not sure that holds water ;)
Okay. Tox, anybody?
I haven't looked into Tox, but I'd be curious to find out the highlights. Really I've just never understood why people complain about XMPP; yes, it's XML which is ugly, but it's also the right tool for the job (easy to stream, very fast SAX-style parsers, event based, etc.), it certainly has its warts, I won't pretend it's perfect, but for the most part it's been around for 20+ years getting the kinks worked out. If we just keep creating new protocols because it's not perfect, we'll never get a more or less universally federated chat protocol like we have for more long form messages (email). I don't know anyone who would say email was the most wonderful modern thing in the world, but they still use it because it's good enough and was lucky enough to become ubiquitous. Similarly, I feel like people should just use XMPP even if they don't like it for that reason (although I'd still love to find out more about Tox, what it's strengths and weaknesses are, etc.)
Tox is a fully distributed (not federated) p2p system. It supports 2-way messaging, multi-way chatrooms, voice and video calling (using Opus and VP8, respectively), file sharing, and desktop streaming, although not all features are supported by all clients. Although any client can implement any feature they like, so long as they can do it atop the actual network system, sticking to the Tox Client Standard is reccomended for maximum compatability. It implements perfect forward security, and uses libsodium for its crypto. There are a variety of clients, although most seem to use toxcore, the reference protocol implementation, under the hood. However, the spec is readily available, and there are independant implementations.
Tox's goal is essentially to create a user-friendly Skype-like chat application, with not centralized server, and strong security by default.
The downside is that your user ID on tox looks like this:
Tox's goal is essentially to create a user-friendly Skype-like chat application, with not centralized server, and strong security by default.
The downside is that your user ID on tox looks like this:
56A1ADE4B65B86BCD51CC73E2CD4E542179F47959FE3E0E21B4B0ACDADE51855D34D34D37CB5
> Tox is a fully distributed (not federated) p2p system
Ah, see, you lost me there already. I'm sure it's clever and well made and all the rest of it, but fully distributed systems either almost never work, are very difficult to get setup and use properly, or end up just not being fully distributed systems (eg. early Skype and it's "supernodes" or whatever it called them, aka "servers", or Tor [which I love] and it's directory authorities which admittedly are elected, but even so are effectively just "servers", or Bittorrent which has either trackers, aka "servers", or hard-coded DHT bootstrap nodes, aka also "servers").
Distributed systems sound great in theory, but in the real world I just never think they're worth the effort, or you have to compromise them and add some centralized element anyways, at which point you might as well just use a federated system so that people who don't want to deal with all that can use a third party server and people who do want their own specially contained distributed node can just run their own server and client.
Ah, see, you lost me there already. I'm sure it's clever and well made and all the rest of it, but fully distributed systems either almost never work, are very difficult to get setup and use properly, or end up just not being fully distributed systems (eg. early Skype and it's "supernodes" or whatever it called them, aka "servers", or Tor [which I love] and it's directory authorities which admittedly are elected, but even so are effectively just "servers", or Bittorrent which has either trackers, aka "servers", or hard-coded DHT bootstrap nodes, aka also "servers").
Distributed systems sound great in theory, but in the real world I just never think they're worth the effort, or you have to compromise them and add some centralized element anyways, at which point you might as well just use a federated system so that people who don't want to deal with all that can use a third party server and people who do want their own specially contained distributed node can just run their own server and client.
Tox has DHT bootstrap nodes, but they aren't hardcoded.
Who bootstraps the bootstrap nodes?
The bootstrap nodes were probably the first ones on the DHT: hence, no bootstrap needed. If it's a new bootstrap node, it's connected to the old bootstrap nodes, or some other set of nodes in the DHT, just like any other node: distributed, not federated.
But once a node is acutually inside the DHT, it should never need to talk to the bootstrap nodes ever again: that's a pretty major win, in some respects.
But once a node is acutually inside the DHT, it should never need to talk to the bootstrap nodes ever again: that's a pretty major win, in some respects.
Sorry, that was supposed to be a silly joke, but it also made it horribly unclear. I meant: How do you find the nodes to bootstrap yourself into the DHT in the first place? They must be IPs shipped with the client?
Yes, there are. However, they can be replaced with other servers if the user wishes.
I use and love Tox as it got some key fundamentals right.
First, they have full forward secrecy. This is notably unlike Ring, which does not.
Secondly, all communications are end to end encrypted and endpoint-verified, as there's no "legacy SIP support" (eg: SIP) or such nonsense and the DHT addresses your contacts gave you are actual ec25519 public keys.
First, they have full forward secrecy. This is notably unlike Ring, which does not.
Secondly, all communications are end to end encrypted and endpoint-verified, as there's no "legacy SIP support" (eg: SIP) or such nonsense and the DHT addresses your contacts gave you are actual ec25519 public keys.
>the DHT addresses your contacts gave you are actual ec25519 public keys.
For nontechnical users, that's a massive downside. The first tox client to integrate ToxMe into itself will get very popular, very fast, provided it's got the right marketing.
For nontechnical users, that's a massive downside. The first tox client to integrate ToxMe into itself will get very popular, very fast, provided it's got the right marketing.
>The first tox client to integrate ToxMe into itself will get very popular, very fast, provided it's got the right marketing.
Ouch. qTox had it for quite some time already, and given that I didn't observe massive increase in its popularity (there was increase, but ~normal), it's got to be the marketing (or lack of thereof)...
Sadly, I don't know about marketing, and while there were some people who could into marketing, hiring them would require money, which Tox ecosystem doesn't have at all, and if it had, it would be spent on hiring devs part or full time. :|
With that being said, it's quite likely that the UI for the integration in qTox is not the best one, and could use some improvements. If you have any suggestions / ideas how it could be made better, please don't hesitate to make an issue on qTox repo with them: https://github.com/qTox/qTox . Or any other part of qTox.
Anyways, aside from qTox also Antox should have ToxMe integration. I don't know about other clients.
Ouch. qTox had it for quite some time already, and given that I didn't observe massive increase in its popularity (there was increase, but ~normal), it's got to be the marketing (or lack of thereof)...
Sadly, I don't know about marketing, and while there were some people who could into marketing, hiring them would require money, which Tox ecosystem doesn't have at all, and if it had, it would be spent on hiring devs part or full time. :|
With that being said, it's quite likely that the UI for the integration in qTox is not the best one, and could use some improvements. If you have any suggestions / ideas how it could be made better, please don't hesitate to make an issue on qTox repo with them: https://github.com/qTox/qTox . Or any other part of qTox.
Anyways, aside from qTox also Antox should have ToxMe integration. I don't know about other clients.
> For nontechnical users, that's a massive downside.
I disagree entirely. It's an upside. They get to benefit from PKI without even understanding anything. A person's address gets them the actual person.
ToxMe requires trusting the ToxMe identity provider, and is an obvious point of attack. And we'd no doubt see fake addresses that resemble other peoples, and other such nonsense.
There's minimising the inconvenience (with ideas like the QR code feature they have), and there's plain giving up security for minimal gained convenience, which we should just avoid.
I disagree entirely. It's an upside. They get to benefit from PKI without even understanding anything. A person's address gets them the actual person.
ToxMe requires trusting the ToxMe identity provider, and is an obvious point of attack. And we'd no doubt see fake addresses that resemble other peoples, and other such nonsense.
There's minimising the inconvenience (with ideas like the QR code feature they have), and there's plain giving up security for minimal gained convenience, which we should just avoid.
>I disagree entirely. It's an upside. They get to benefit from PKI without even understanding anything. A person's address gets them the actual person.
Yes, but which messaging service will the nontechnical user use? The one where they can exchange usernames, or even phone numbers, and it Just Works? Or the one where they have to give their friends a long alphanumeric sequence of gibberish?
It doesn't benefit them if they don't use the protocol.
>ToxMe requires trusting the ToxMe identity provider, and is an obvious point of attack. And we'd no doubt see fake addresses that resemble other peoples, and other such nonsense.
Obviously. This is why it's a bad thing that nontechs will probably go in that direction, if they use Tox at all.
>(with ideas like the QR code feature they have)
I was hoping somebody had implement QR: that helps a lot, but I'm not sure if it's enough...
Yes, but which messaging service will the nontechnical user use? The one where they can exchange usernames, or even phone numbers, and it Just Works? Or the one where they have to give their friends a long alphanumeric sequence of gibberish?
It doesn't benefit them if they don't use the protocol.
>ToxMe requires trusting the ToxMe identity provider, and is an obvious point of attack. And we'd no doubt see fake addresses that resemble other peoples, and other such nonsense.
Obviously. This is why it's a bad thing that nontechs will probably go in that direction, if they use Tox at all.
>(with ideas like the QR code feature they have)
I was hoping somebody had implement QR: that helps a lot, but I'm not sure if it's enough...
> It doesn't benefit them if they don't use the protocol.
There's no benefit from using the protocol if it gives up security for convenience like the others.
> Obviously. This is why it's a bad thing that nontechs will probably go in that direction, if they use Tox at all.
My point exactly.
There's no benefit from using the protocol if it gives up security for convenience like the others.
> Obviously. This is why it's a bad thing that nontechs will probably go in that direction, if they use Tox at all.
My point exactly.
Matrix actually has e2e crypto working right now. Its in beta but you can active it in the room settings.
Really? Finally. Thank god.
turns out that implementing a new double ratchet implementation from scratch... and then adding in all the additional semantics required for Matrix's history-synced group chats etc... and then getting publicly audited... and getting it running on Web/iOS/Android... not to mention writing a formal spec for everything (both for the crypto, and the Matrix aspects of it), is a significant amount of time & work ;)
I'm not surprised, and I'm grateful for it. But it has been a long time coming, and it's been a major flaw in Matrix's offerings up to this point.
If they are only using GCM as a queue (and the messages are themselves encrypted) I don't understand what the problem is.
They could use anyone for that functionality. Even if the messages are given to an "adversary" what can they really get from that? Your phone app contacted the signal servers. That's really it.
They could use anyone for that functionality. Even if the messages are given to an "adversary" what can they really get from that? Your phone app contacted the signal servers. That's really it.
They're not even using it as a queue, they're queueing and delivering the messages themselves. GCM messages are empty and are only used to wake up your device.
Redphone component.
I don't know why it's closed source. It's been suggested elsewhere in this thread that it was potentially IP issues they kept it closed for. Is it possible loose US CALEA law interpretation influences the reasoning? Or a gag?
I honestly don't know why they chose to do that but I wanted to comment in to see if a lawyer or someone from the project could hint at the reasoning.
I don't know why it's closed source. It's been suggested elsewhere in this thread that it was potentially IP issues they kept it closed for. Is it possible loose US CALEA law interpretation influences the reasoning? Or a gag?
I honestly don't know why they chose to do that but I wanted to comment in to see if a lawyer or someone from the project could hint at the reasoning.
This is the client component. The blog post and your parent were referring to the server component.
I'm working on a completely open secure communications suite based on TweetNaCl. Proof-of-concept prototype is here:
https://github.com/Spark-Innovations/SC4
Working on a better UI at the moment. Could really use help, especially beta testers.
https://github.com/Spark-Innovations/SC4
Working on a better UI at the moment. Could really use help, especially beta testers.
I know the redphone is library is just a binary blob in the github repository:
The server code is up there too - in fact it's all up there. AFAICT, Signal is completely open source.
https://github.com/WhisperSystems/Signal-Android/tree/master/libs/armeabi
https://github.com/WhisperSystems/Signal-Android/tree/master/jni/redphone
The server code is up there too - in fact it's all up there. AFAICT, Signal is completely open source.
[deleted]
I haven't actually worked with GCM so please forgive me if this doesn't make any sense.
I suggest that, instead of routing all messages through GCM, what if Signal could send a "wake up" message via GCM, and then let the app pull the encrypted messages directly out of Signal's servers? A wake up message would only be sent by the server if the message could not be received by the client via normal means (implying that the device is asleep).
An optional user preference could allow some dummy wake up messages to be sent at random moments during the day, to support plausible deniability, at the cost of slightly worse battery life performance. This would all happen silently and the user would only notice a message notification when the app successfully fetches a new incoming message.
An optional user preference could allow some dummy wake up messages to be sent at random moments during the day, to support plausible deniability, at the cost of slightly worse battery life performance. This would all happen silently and the user would only notice a message notification when the app successfully fetches a new incoming message.
> I suggest that, instead of routing all messages through GCM, what if Signal could send a "wake up" message via GCM, and then let the app pull the encrypted messages directly out of Signal's servers?
Yep, that's exactly how Signal has been doing it for >1.5 years now.
Yep, that's exactly how Signal has been doing it for >1.5 years now.
ahh. I just thought otherwise from some of the other comments here. Makes sense. Thank you.
I didn't have to recompile my kernel to use microg...instead I used FakeGApps with Xposed framework. instructions: https://github.com/thermatk/FakeGApps
Signal is to get people from SMS and iMessage -> Signal. This means that cross platform communication becomes secure in transit.
Once Signal and others have really wiped out all the insecure messaging people are doing, then we can start with the identity problem with phone numbers. GCM, Contacts, etc are all related to this "phone number as identity" problem.
RCS is an unfortunate grab in this space, and we need to move fast before RCS is the default, and we're back to insecure messaging.
Email addresses are the best form of "federated identification" but are wildly insecure for communication. Here's to hoping we can get some better ones.
Once Signal and others have really wiped out all the insecure messaging people are doing, then we can start with the identity problem with phone numbers. GCM, Contacts, etc are all related to this "phone number as identity" problem.
RCS is an unfortunate grab in this space, and we need to move fast before RCS is the default, and we're back to insecure messaging.
Email addresses are the best form of "federated identification" but are wildly insecure for communication. Here's to hoping we can get some better ones.
For me I won't recommend it because of the horrible lack of options when you replace your phone (let alone lose it). No encrypted migrate. No backup options. Unencrypted loses content (images).
Plus there's no way to search old messages.
Plus there's no way to search old messages.
I guess these are all features. For example, how are you going to do a backup that restores when you lose the phone (and thus the private key)? In practice, you would encrypt the backup with a passphrase, and the user would choose "123".
Signal aims to be the most usable secure messenger, not the most usable messenger that also happens to be secure.
Signal aims to be the most usable secure messenger, not the most usable messenger that also happens to be secure.
The truth which a lot of Moxie fans don't want to admit is he thinks there is nobody better to be entrusted with this project. I don't think this was ever meant to be a community project -- he just opened some parts so he could pretend it is. Also he is a limelight hogging security diva who always wants to be in the news and have people talk about him. If he allowed others to contribute and be recognised, he worries they might overshadow him.
The author offers no better alternative so I think that means the article speaks for itself: there's not much to do but whine. These are problems, sure, but they're minor when you consider that Signal is the most secure and user-friendly messenger we have on the market right now. If something takes its place, then great. Otherwise, we just will continue to use what is secure and actually works.
- Lack of federation
Use a federated secure protocol. Oh wait, there are none. Because if a problem appears you just can't fix it without breaking all federated clients. And then they will whine.
- Dependency on Google Cloud Messaging
Fair enough
- Your contact list is not private
Fair enough
- The RedPhone server is not open-source
While it would be nice that it was Open sourced I can understand them not releasing it (might be for IP issues)
tl,dr: "Signal does not work the way I wanted"
Use a federated secure protocol. Oh wait, there are none. Because if a problem appears you just can't fix it without breaking all federated clients. And then they will whine.
- Dependency on Google Cloud Messaging
Fair enough
- Your contact list is not private
Fair enough
- The RedPhone server is not open-source
While it would be nice that it was Open sourced I can understand them not releasing it (might be for IP issues)
tl,dr: "Signal does not work the way I wanted"
> Use a federated secure protocol. Oh wait, there are none. Because if a problem appears you just can't fix it without breaking all federated clients. And then they will whine.
That's why you have to design your protocol with backwards compatibility and versioning in mind, ala XMPP. I'm not going to pretend its perfect, but it works pretty well 90% of the time. It does mean clients have to implement versioning and feature negotiation and not just blindly assume everything else supports all the features they do; convincing client authors to do this is the tricky part.
That's why you have to design your protocol with backwards compatibility and versioning in mind, ala XMPP. I'm not going to pretend its perfect, but it works pretty well 90% of the time. It does mean clients have to implement versioning and feature negotiation and not just blindly assume everything else supports all the features they do; convincing client authors to do this is the tricky part.
There are really two federated protocols, xmpp and matrix. Matrix is pretty young but looks good, they just added e2e encryption.
Check out the Riot client, web, android and ios. The apps are even native.
Plus, you don't have to show your phone nr.
Check out the Riot client, web, android and ios. The apps are even native.
Plus, you don't have to show your phone nr.
Umm... Tox?
Tox on mobile? Have you actually tried to use it? It drains your battery like crazy.
He didn't ask about that. He asked about a federated/distributed protocol that actually worked. Tox is one.
> Another issue, and a plus for using usernames, is that you may want to use Signal with people you don’t necessarily want to give your phone number to.
So, how do you know that the Edward.Snowden@signal you're communicating with is the same Ed Snowden that we all know about, and not some TLA stooge?
So, how do you know that the Edward.Snowden@signal you're communicating with is the same Ed Snowden that we all know about, and not some TLA stooge?
You're missing the point. Neither Phone number of Email address/username solve the problem you're proposing. But an email address/username is a lot more transient than a phone number.
I can change emails/usernames very easily and with little effort, and while burner numbers and applications that help that exist, changing phone numbers is not as easy and thus a significant percentage of users are unlikely to do it regularly. So you have a pseudo real ID that to the end user FEELS like it isn't you, but is a very strong (no pun intended) signal that it is to anyone looking in.
The phone number grants no you special verification of identity over an email address that doesn't involve an external verification mechanism (i.e, talking to the identity in person.)
I can change emails/usernames very easily and with little effort, and while burner numbers and applications that help that exist, changing phone numbers is not as easy and thus a significant percentage of users are unlikely to do it regularly. So you have a pseudo real ID that to the end user FEELS like it isn't you, but is a very strong (no pun intended) signal that it is to anyone looking in.
The phone number grants no you special verification of identity over an email address that doesn't involve an external verification mechanism (i.e, talking to the identity in person.)
By making user-names unique...?
funny enough, I was going to try out Signal today but stopped right after seeing the permissions they request: https://pbs.twimg.com/media/CwhFsLzXcAIDcMH.jpg:large
Well, everything is there for a good reason. (Though it escapes me right now why it needs permission to access the calendar.) How are you going to call someone over Signal if Signal can't use the microphone? If in doubt you can always check the source code – it's open source for exactly that reason.
How does Signal compare to Telegram? Would you recommend Telegram as better or worse then Signal.
On Signal, every message uses end-to-end encryption. Signal's servers can't see the messages you are sending, only you and the recipient can read them. Signal's encryption protocol is carefully scrutinized and follows best-practices.
Telegram sends messages in plain-text by default. Telegram servers have access to all plain-text messages that you send.
Telegram's private chats use end-to-end encryption. But they use an encryption protocol that they invented themselves that doesn't follow best-practices. Encryption experts have been critical of Telegram's encryption protocol since it was released. So your private messages might not be so private, either.
If you are doing something sensitive and want to stay out of prison, use Signal.
Telegram sends messages in plain-text by default. Telegram servers have access to all plain-text messages that you send.
Telegram's private chats use end-to-end encryption. But they use an encryption protocol that they invented themselves that doesn't follow best-practices. Encryption experts have been critical of Telegram's encryption protocol since it was released. So your private messages might not be so private, either.
If you are doing something sensitive and want to stay out of prison, use Signal.
Actually, always use Signal unless you have contacts on Telegram that refuse to migrate. Consider all communication via Telegram to be on public record.
> Consider all communication via Telegram to be on public record.
Just because the protocol has flaws, doesn't mean everyone can exploit them.
On the other hand it's possible for Google to read every communication because they have root on your phone. So using Telegram [1] with a custom ROM without Google services (e. g. [2]) will make it harder for Google at least. Not easily possible with Signal.
[1] https://f-droid.org/repository/browse/?fdfilter=telegram&fdi... [2] https://copperhead.co/android/
Just because the protocol has flaws, doesn't mean everyone can exploit them.
On the other hand it's possible for Google to read every communication because they have root on your phone. So using Telegram [1] with a custom ROM without Google services (e. g. [2]) will make it harder for Google at least. Not easily possible with Signal.
[1] https://f-droid.org/repository/browse/?fdfilter=telegram&fdi... [2] https://copperhead.co/android/
> Telegram sends messages in plain-text by default.
This sounds like everyone has access to those messages. Better: Telegram sends messages client-server encrypted by default and since you can't run your own Telegram servers, this is a problem.
This sounds like everyone has access to those messages. Better: Telegram sends messages client-server encrypted by default and since you can't run your own Telegram servers, this is a problem.
Why is the author asking for GPL?
Wouldn't a ISC/BSD-like license be better for the federation aspect?
Wouldn't a ISC/BSD-like license be better for the federation aspect?
If you aren't going to recommend anything else then sit down and shut up frankly. The world is made of compromises and saying I don't like your choices is pointless if it's effectively impossible to choose differently.
I am also very unhappy with the direction Signal has gone, but there's currently no alternative. I'd be interested in contributing to work attempting to replicate it, though.
I have some friends in an encrypted riot room right now. The olm could use a real good audit, but otherwise it is working right now. Federation is working, bridges are working, voice and video are working, it has Android and iOS clients. The only problem is the encryption doesn't apply to the voice / video or shared files yet, but they have made huge progress this last year from basically nothing so far.
+1. I'm super happy with the Matrix / Riot ("riot" is the client) crypto work over the last year.
It's such a relief to have a modern chat system that's FOSS, federates, and offers a liiiiitle more advanced UX than irc...
It's such a relief to have a modern chat system that's FOSS, federates, and offers a liiiiitle more advanced UX than irc...
the Olm audit is done; we're hoping to publish it week of Nov 14 (alongside iOS & Android support).
Encrypted attachments was PRed this week: https://github.com/matrix-org/matrix-react-sdk/pull/533 (for the web; mobile will follow shortly)
Encrypted attachments was PRed this week: https://github.com/matrix-org/matrix-react-sdk/pull/533 (for the web; mobile will follow shortly)
Why isn't there an alternative? Signal uses the Axolotl protocol for encryption. There are already several XMPP clients that support the OMEMO protocol which is based on Axolotl (https://conversations.im/omemo/). And for Matrix (a modern alternative to XMPP) there's Olm which is also based on Axolotl.
At the risk of derailing this slightly, I wouldn't call Matrix a "modern alternative" to XMPP. The use cases are almost entirely different; Matrix isn't really suitable for realtime applications like XMPP is (because Matrix is all pull-based, so you have to query the server constantly to try and get messages in a reasonable time; this also means keeping the phone radio in active, high-battery-drain mode [pretty sure that's the technical term]).
Disclaimer: I do a lot of work on XMPP related things and rather like the protocol, so maybe I'm biased. I'm sure there are things for which Matrix is a better fit that I wouldn't use XMPP for too though.
Disclaimer: I do a lot of work on XMPP related things and rather like the protocol, so maybe I'm biased. I'm sure there are things for which Matrix is a better fit that I wouldn't use XMPP for too though.
Agreed that Matrix isn't a "modern alternative" to XMPP, but for different reasons. At its core, Matrix is a decentralised object database for conversation history (like NNTP). XMPP is a message passing protocol (like SMTP, but extensible).
Matrix is not "all pull-based" - that's just the baseline implementation. Folks have already implemented push-based transports for Matrix - e.g. COAP or WS.
edit: [Disclaimer: i work on Matrix]
Matrix is not "all pull-based" - that's just the baseline implementation. Folks have already implemented push-based transports for Matrix - e.g. COAP or WS.
edit: [Disclaimer: i work on Matrix]
You mean the Signal Protocol. That's its name. Axolotl was a name for a major component of Signal Protocol. Moxie and Trevor Perrin designed the protocol for Signal, and it's under active development. They own the protocol, its direction, and its documentation.
Other projects can adopt parts of the Signal Protocol, and doing that is certainly better than just making stuff up. But Signal owns the protocol, because the experts who own the protocol are attached to Signal.
Other projects can adopt parts of the Signal Protocol, and doing that is certainly better than just making stuff up. But Signal owns the protocol, because the experts who own the protocol are attached to Signal.
Yeah, just to clarify: Olm (matrix.org/git/olm) is an entirely independent implementation of the Double Ratchet algorithm (based on Trevor's original public domain spec sketch, which was originally called 'axolotl').
It's not connected to Signal or Signal Protocol or Open Whisper Systems, and subsequently we've added an entirely different new ratchet (Megolm - https://matrix.org/docs/spec/megolm.html) to handle Matrix's specific requirements for E2E.
It's not connected to Signal or Signal Protocol or Open Whisper Systems, and subsequently we've added an entirely different new ratchet (Megolm - https://matrix.org/docs/spec/megolm.html) to handle Matrix's specific requirements for E2E.
Crypto engineers tend to like the Axolotl design, which is an unusually serious cryptographic design for a messaging protocol (historically, messaging crypto has been cryptographically slapdash, with the exception of OTR).
But the reason crypto people are so positive about Signal Protocol isn't just that they like the ratchet. It's also that they trust the entire design of the system, not just the ratchet but all the rest of the cryptographic details, and also the oversight of the protocol.
It's kind of the same way that crypto engineers like stream ciphers designed as simple hash cores running in counter mode, but really what they like is stuff that Dan Bernstein designs --- they aren't encouraging you to go design your own hash-core based stream cipher!
So: it's good that these other systems adopting "Axolotl" are at least starting from a cryptographically serious place. But it's a bit jarring to see them reference "Axolotl" as if it answered the question of "why should we trust this cryptography".
A better answer would be to provide the bios of the people who designed and implemented the crypto in these systems.
But the reason crypto people are so positive about Signal Protocol isn't just that they like the ratchet. It's also that they trust the entire design of the system, not just the ratchet but all the rest of the cryptographic details, and also the oversight of the protocol.
It's kind of the same way that crypto engineers like stream ciphers designed as simple hash cores running in counter mode, but really what they like is stuff that Dan Bernstein designs --- they aren't encouraging you to go design your own hash-core based stream cipher!
So: it's good that these other systems adopting "Axolotl" are at least starting from a cryptographically serious place. But it's a bit jarring to see them reference "Axolotl" as if it answered the question of "why should we trust this cryptography".
A better answer would be to provide the bios of the people who designed and implemented the crypto in these systems.
Well, I hope on Matrix we've not been blindly namedropping axolotl/double-ratchet: instead we've tried to be as transparent as possible (more-so perhaps than OWS) in terms of speccing what we've been doing (https://matrix.org/docs/spec/olm.html, https://matrix.org/docs/spec/megolm.html, http://matrix.org/docs/olm_signing.html, https://matrix.org/speculator/spec/drafts%2Fe2e/client_serve... etc). Thanks to the Open Tech Fund we also got libolm audited by NCC Group - and we've ensured that the audit report will be publicly released (mid-Nov). Hopefully the audit & the code will speak for itself, and certainly speak stronger than bios.
I started NCC Group Cryptography Services. They're great, but I'm telling you, no: the bios are important. A single point in time audit doesn't make something secure.
Well, thanks for starting NCC Group Crypto then :) One can at least extrapolate from an audit - it surely tells you how competent the code is at a point in time, and how rapidly and competently any issues were resolved, and one can assume the same team will progress similarly.
In terms of bios: the folks working on libolm have 10-15 years each of professionally writing decent security-conscious native code, the vast majority of which (pre-Matrix) has been proprietary, with the exception of occasional contributions to things like Wireshark. I don't think they'd have described themselves as specialising in cryptography before embarking on libolm, but the team's learnt a lot along the way and the label might be more appropriate now. Ooi, what would you consider an appropriate bio? (short of being DJB or Moxie? :)
In terms of bios: the folks working on libolm have 10-15 years each of professionally writing decent security-conscious native code, the vast majority of which (pre-Matrix) has been proprietary, with the exception of occasional contributions to things like Wireshark. I don't think they'd have described themselves as specialising in cryptography before embarking on libolm, but the team's learnt a lot along the way and the label might be more appropriate now. Ooi, what would you consider an appropriate bio? (short of being DJB or Moxie? :)
If wishes were fishes we'd all live by the sea.
Any service that owns valuable user data is going to get compromised eventually, whether they do it themselves, or are the victims of an attack. I feel like the only way to not get swept up in the surveillance state is to never put your data on one of these services at all.
The Signal app is stupid. It doesn't work intuitively as WhatsApp. It's incomprehensible that you need a phone number, it's incomprehensible that you can't compile it yourself.
What are your views about VoIP with ZRTP?
Nobody actually exchanges the initial words to avoid mitm. Hence, zrtp is actually no that secure in practice.
>I’m pretty sure that Google could serve a specially modified update or version of Signal to specific targets for surveillance, and they would be none the wiser that they installed malware on their phones.
I'm not sure he understands how app signing works and why it would be impossible for Google to forge a developer's signature. He also seems to have a problem with GCM and Google in general. Perhaps he should look into writing his own secure chat application.
I'm not sure he understands how app signing works and why it would be impossible for Google to forge a developer's signature. He also seems to have a problem with GCM and Google in general. Perhaps he should look into writing his own secure chat application.
Why would they have to forge it? They can simply install a version that isn't signed on your system via an update.
Then later replace it with a signed version once they have the data they wanted. You would never know what happened.
Then later replace it with a signed version once they have the data they wanted. You would never know what happened.
Hmm... he mentions the Giphy thing at the beginning of the article, then never again.
The Giphy mention seemed really dangerous to me. Now I don't use Signal but I imagine it's 1) optional and 2) requests are proxified/anonimised through an intermediary (the Signal servers in this case). And why is this dangerous? Because this "don't build cool stuff on this serious app" is what makes people not use the app. It's creating boring, dull apps what stops them from becoming mainstream successes. If we are trying to make the public using secure apps because we believe in privacy, we have to make them appealing.
This is similar to the case of how nobody uses PGP because how horribly bad it is, UX-wise.
That said the rest of points he brings up are good. I just didn't like the Giphy mention, especially taking into account he didn't say anything else about it, he just brought it up.
The Giphy mention seemed really dangerous to me. Now I don't use Signal but I imagine it's 1) optional and 2) requests are proxified/anonimised through an intermediary (the Signal servers in this case). And why is this dangerous? Because this "don't build cool stuff on this serious app" is what makes people not use the app. It's creating boring, dull apps what stops them from becoming mainstream successes. If we are trying to make the public using secure apps because we believe in privacy, we have to make them appealing.
This is similar to the case of how nobody uses PGP because how horribly bad it is, UX-wise.
That said the rest of points he brings up are good. I just didn't like the Giphy mention, especially taking into account he didn't say anything else about it, he just brought it up.
Hi there! The Giphy thing is what set me off writing the blog post in the first place. Maybe I should've expanded a bit more on that in the article. As far as I can tell, the idea is that requests to the Giphy API gets proxied through Signal.
I don't see anything in moxie's blog post about whether this is optional. If it isn't and it's sending everything you type to the Giphy API then we have a whole new problem.
In the blogpost by moxie, there's the example of typing "Im excited", which then gets sent in multiple API requests to giphy (basically one of 'I', one of 'Im', one for 'Im+' etc.). Now, if this is an action you don't do explicitly (like pressing a button or something, to search for gifs), then it would basically send everything you type in order to continually search for gifs and then offer suggestions? It's not clear from the blogpost. I hope at least that this is not what moxie had in mind.
I don't see anything in moxie's blog post about whether this is optional. If it isn't and it's sending everything you type to the Giphy API then we have a whole new problem.
In the blogpost by moxie, there's the example of typing "Im excited", which then gets sent in multiple API requests to giphy (basically one of 'I', one of 'Im', one for 'Im+' etc.). Now, if this is an action you don't do explicitly (like pressing a button or something, to search for gifs), then it would basically send everything you type in order to continually search for gifs and then offer suggestions? It's not clear from the blogpost. I hope at least that this is not what moxie had in mind.
Giphy only occurs when you click on a button to add an attachment, and you have to click on Giphy, THEN you search for GIFs.
I promise that nobody is going to force you to use the GIF search. For a demo on how this feature works, check out the short video embedded into the blog post. [1]
I second the parent poster's question: "why is this dangerous?"
[1] https://whispersystems.org/blog/images/giphy.webm
I second the parent poster's question: "why is this dangerous?"
[1] https://whispersystems.org/blog/images/giphy.webm
It's not clear to me, but I assumed that that only happened if you tapped on a "search for gifs" button, which is something that can happen accidentally, but... that's unlikely.
"Otherwise, we’ll be in danger of ending up in an neo-90s Internet, with walled gardens and pay walls all over the place. You already see this trend happening in journalism."
The internet will never be less walled, more free, and more federated than it was in the 90's. With such a poor understanding of the internet and its history, even if he did make a compelling argument (he doesn't), it'd be hard to take seriously.
The internet will never be less walled, more free, and more federated than it was in the 90's. With such a poor understanding of the internet and its history, even if he did make a compelling argument (he doesn't), it'd be hard to take seriously.
You're forgetting about AOL and Compuserve. The Internet itself was federated. Networking really wasn't.
I forgot them on purpose because he's talking about the Internet, not networking, not BBSs (which AOL and Compuserve were just big versions of). AOL and Compuserve eventually made themselves just another part of the Internet, but before that, they were really irrelevant in relation to the Internet's federation. In fact, other than AOL being an ISP and a gateway to the Internet for many, the actual AOL service was completely irrelevant once Internet connections came along.
> The big question now... is what post-Signal tool we want to use. I don’t know the answer to that question yet
Oh.
Oh.
antocv(1)
He says he thinks the protocol is secure, then says he doesn't want it to use GCM because it routes messages via Google who he doesn't trust (fixing that is the point of the encryption) and then talks about an attack that'd apply to any app regardless of whether it used GCM or not.
He finishes with a call to action: "We as a community need to come up with a viable solution and alternative to Signal that is easy to use and that does in fact respect people’s choices ... this tool should not have dependencies on corporate infrastructure"
But like a lot of armchair moralising, he isn't willing to debate the hard choices that go into building successful software. He says it should "respect people's choices" as if Signal is built by people who are disrespectful, he says it should not have dependencies on "corporate infrastructure" as if volunteer run datacenters actually exist, and then says his motivation is avoided paywalls, ignoring that both Signal and WhatsApp are free.
It reads like a collection of talking points rather than a coherent argument.
Signal is unusual because it combines cutting edge cryptography with consumer friendliness and is actually successful. It's pragmatic, not ideological. Crypto-warriors have a long history of producing secure software that nobody uses and then blaming the general public for not getting it; this sort of blog post is just a continuation of this decades long trend.