1) Make mass surveillance impossible.
2) Stop targeted attacks against crypto nerds.
It's not that we don't find #2 laudable, but optimizing for #1 takes precedence when we're making decisions.
If you don't want to use your phone number, don't use it. You can register with any GV, Twilio, Voicepulse, or other throwaway VoIP number.
If you don't want to run Chrome, use Chromium instead.
If you don't want to use Google Play Services, use GcmCore.
The world you want this software for is not the world that everyone else lives in. You can certainly make it work in that world with a little effort, but because of how we've prioritized our objectives, that's not the default experience.
If I use throwaway numbers: What happens if I lose access? Do I _need_ the number for anything in the future (say, device died)? Can someone else mess with me if they get access to this number, if the number gets reassigned? Searching for this kind of information is hard, because 'Signal' isn't exactly a word that search engines understand in context.
Chromium and Chrome are the same thing for me: A browser I don't care for and only install on a dev machine for some tests. I wouldn't install either on my personal rig, ignoring the suffixes. And certainly not for an 'app'. It's both 'Not liking Google' and 'No general web browser to run an IM client'. The latter isn't solved by Chromium.
As far as I'm aware there are no Google Play Services for FxOS (looking at this Flame right here) and I expect that there's no easy solution for SailfishOS either.
I understand that I'm not the target audience. Please believe me when I say that I don't feel that I can (as in, it suits me/feels okay to do so) use Signal right now. I'm writing these messages here not to hit on your work, but to express that there is an audience with other preferences/goals. It's Christmas soon, after all - consider this my public, unrealistic, idealistic wishlist.
(Edit: And I apologize that my critical comment ranks rather high right now. I might believe that I'm not completely bonkers and there are other people that feel the same way, but it still sucks to see this kind of feedback on an announcement post)
This is the world we live in: people do most of their communication on mobile devices running iOS or Android, use Chrome on the desktop, and expect contact discovery to be automatic in their social apps. The browser has won the desktop, iOS and Android have won mobile, and the velocity of the ecosystem is unlikely to make "distributed" communication mechanisms possible for some time.
We're trying to make mass surveillance impossible within this world of ours. We want to produce technology that is privacy preserving but feels just like everything else people already use, not somehow convince everyone to fundamentally change their workflow and their expectations.
It'd be sweet if we lived in an alternate reality where everyone ran SailfishOS or something (and maybe this year will be the year of Linux on the desktop!), but we can't just pretend that's already the case.
But honestly: I understand mobile support for iOS/Android only. I don't understand Chrome as a platform (FF isn't dead. And the biggest reason for that is that I fail to understand why that client needs to be 'web based' and then again not. A web app in a silo)
Mobile numbers.. Why? I mean, if 90% of the population WANT mum to see that they use a service and when they're online (or whatever metadata you want to exchange for contacts), just because they happen to know the phone number: Fine. But why isn't it possible to sign up, hit a box that says 'no phone number associated' and .. add contacts manually? I don't want the 99.999% to change, to make it harder for them. I just wish that Christmas brings an option that lets me opt-out of that. Chat contacts don't need my phone number. People that know my phone number are not chat contacts.
I'll get back pretending that Linux has won and will try to surf the web in FxOS for 30min just .. to prove you wrong. :)
I really think Signal might not be for you. Signal is not about building the most secure or private system, it's about building the first mass-market encrypted that that's Good Enough. Signal is a infinite percent improvement over plaintext/https. It's not supposed to be as good as OTR.
Making it a de facto requirement that users on your network be personally identified via a phone number ("get a burner number"? really?) and that you have a copy of their contact list and phone calls, all within US jurisdiction, means mass metadata surveillance a single judicial order away (as it is now with the telecoms).
Unlike POTS, Signal prevents phone taps, yes, but it does not hide your social network, and so does little to provide you with the ability to associate with someone anonymously.
Do you take this opportunity to point out to them that they do away with this privacy every time they install whatsapp / fb messenger / hangouts / skype / practically anything that asks for contacts permissions?
It's not as if that hasn't been done. twitter.com/darklajid is me (not worth checking it out). See? A name, tied to an identity. Same here. I used to have a FB account and even _there_ you can have a profile name that is unique and shareable. I really think you conflate things here: I DO NOT want to make life harder for mum/granny/the average WhatsApp fan. If you love that random people show up in your roster because you store their number (or vice versa: You show up on your Ex's roster because she didn't delete you yet) that's fine. And could continue to work like that.
I really have a hard time understanding why it isn't impossible to opt out. If I have a key, registered with Signal - why would I need a number on top? _Especially_ given that there's no federation to speak of, so I assume they don't need to 'shard' base on the identifier. [email protected] -> talk to example.com? That's not happening here. And I don't see why/how they'd shard on numbers? +49 -> route to a German server?
Why is a phone number (and all the things that come with it: Discoverability for example) a requirement? You didn't answer that.
Yes, Signal might not be for me. I'm reasonably sure that I mentioned that before in this thread ;-)
Hey, please consider finding a better way to say "the average person" than calling out women and old people as being groups you think of as non-technical. Thanks!
That said there's a lot of potential as the crypto libraries are known to be top notch and reviewed. I hope they progressively address these issues.
From http://www.computerworld.com/article/2893514/an-incredibly-s...:
> In the last 12 months, Firefox's user share -- an estimate of the portion of all those who reach the Internet via a desktop browser -- has plummeted by 34%. Since Firefox crested at 25.1% in April 2010, Firefox has lost 13.5 percentage points, or 54% of its peak share.
I love Firefox, but having used FxOS and mobile versions of Mobile Firefox, the Mozilla Foundations new products feel like the Netscape 6 / Mozilla Browser Firefox was created to replace, rather than the lightweight, user focused alternative.
> Mobile numbers.. Why?
Pidgin + OTR works on Linux, and doesn't relate to mobile numbers or Chrome at all. This might be a better fit for you.
If anyone is interested in taking a look (free, open source, code reviewed, Android) please feel free: https://play.google.com/store/apps/details?id=org.secfirst.u...
It's also odd to me that privacy advocates would push people to Google's ecosystem.
I hope one day there will be Windows and Mac apps. And that instead of phone numbers, we can use email addresses.
What do you mean by "the velocity of the ecosystem is unlikely to make distributed communication mechanisms possible for some time"?
Lots of phone carriers whitelist that server of theirs to allow it to wake up phone unprompted from idle while typically only allowing phone-initiated connection to stay active, and they also tend to block most incoming connections once the phone has been inactive for a while.
While it isn't technically hard to make something distributed, to also make it work well can be troublesome...
Yet another reason I want home servers to become common, as your phone could automatically request that your carrier whitelist your chosen trusted nodes such as your home server.
By the way - the biggest problem with textsecure^Wsignal right now is the lack of encrypted export and import of the private key. Forget the issue about message history, the freaking private key is the most important thing. All the dumb users you may manage to reach with your current integrations and conveniences are just accepting a changed key for their contacts at any time, and now also smart and diligent people are doing the same thing because you can't keep private key continuity unless you root your android phone and use a root backup app. It's a basic core failing.
I will never convince my friends to use an internet-based messenger - I might as well try and get them to use Pidgin+OTR if that's the ball game. I have, however, switched a few of them over to SMSSecure, the SMS-only TextSecure fork, which is a perfectly serviceable SMS client.
I too think SMS transport should have been maintained, but I believe it only really matters when you're stuck without mobile data access (for example, when I was on a cruise ship earlier this year I had roaming SMS/voice but not data).
As long as you _do_ have mobile data access at both ends, then a message to another TextSecure user will be sent encrypted over the data connection; and a message to a non-TextSecure user wouldn't have been encrypted anyhow.
I currently pay €2 per month for my mobile bill. That is very little money. Notably, that includes no internet/data, but it does include unlimited text messages. Can you see why SMSSecure is something i would want?
Perhaps it would be possible to have a simple CLI app that is free from these dependencies (which should also be quite simple to develop).
We're not going to win, but at least I try to defend myself
It would also be much easier to allow federation with that mechanism, as your keybase.io account even could point to your chosen server together with the public key.
A worthy goal. But let's be real; to stop mass surveillance by writing a new chat program, you need mass adoption of your new program, and that means you need truly amazing UX.
If you write something which is technically perfect and would work if it was widely used, but nobody uses it because Telegram is just a little bit easier to get started with, and has nice cartoon drawings to explain their features (or whatever), then you've completely failed.
It's Sysadmins who make for a delicious muskrat lunch, not the crypto nerds.
I'm saying this as a sysadmin and crypto nerd who really wishes we had a secure messaging system that achieved both of Moxie's stated goals. Unfortunately, I don't want to use it in its current state for largely the same reasons as laid out by 'darklajid.
Both goals are important and feed into each other. If we don't have #2, it's easy for NSA and friends to backdoor the software or services for #1, for example like they did with their trusting-trust trojaned XCode.
Does anyone really believe these agencies will not react as we deploy "mass-surveillance-proof" software? What will be their next move to collect the data that they want? All of these attacks that people now write off as "crypto-nerd paranoia" will just become the new normal.
It seems to me, at least, it might be possible to do so if the API was consistently exposed and versioned.
#1 is essential, but you really need to cater to #2 as well because "crypto nerds" are likely those who will eagerly adopt the software and advertise and praise it to others.
Here is a simple non-exhaustive list of changes to better achieve #2:
1. If the phone number starts with +xx where xx is a reserved/invalid country code, the rest is the client's base10 public key. Verification happens by signing a challenge or simply successfully performing a DH handshake instead of by SMS.
2. Provide a "pull" notification socket in the Signal server, use it if GCM is not available
3. Package the mobile-sync Chrome app with node-webkit or simply as a standalone server that auto-opens your browser to localhost:port
4. Use libtextsecure-java to make a simple standalone desktop client that could either have a command line interface or a localhost web interface (please don't use the C library, since C is not suitable for secure software)
Obviously these changes could be done by third parties, not necessarily by Open Whisper Systems.
Moxie is probably going to hate you for it, but it works very well and doesn't require Google Services or anything else.
Overly dramatic...
I live between two countries, and have two phone numbers - friends and family in one country have the one, in the other have another.
In places like Myanmar, people regularly have several SIMs with several numbers due to poor connectivity.
Also can we please stop calling this a Desktop app? It requires Chrome to run, so it's neither Desktop nor Web app.
That's an extremely noble goal, and it seems you've made great progress towards it, but..
Will the US government really just let you do it? Have they not interfered yet? It seems highly unlikely that they wouldn't somehow neutralize the threat your work represents, so I'm just.. cautiously optimistic instead of really excited.
Of course they did: the recent propaganda wave against "encryption" is all about preventing the next wave of privacy-conscious communication tools, to which Signal belongs.
Smart governments don't have to "interfere": they just have to pass laws.
If you care first and foremost about UX, use Telegram. If you care first and foremost about the security of your communications, use Signal; go out of your way to use Signal.
With that mindset we will never get secure communications to the masses but will repeat the PGP dilemma again and again. UX is of utmost importance.
We would still be on 99.99% HTTP websites if HTTPS required going out of one's way.
The GP was comparing two apps that are actually both very easy to use, one maybe slightly moreso.
(That said, PGP isn't THAT hard either.)
Which is a shame, because none of the options actually matter.
If you're encrypting messages to a public key, and not with a passphrase, and you're signing the messages you encrypt, you're getting 98% of the value PGP has to offer.
If you want to do things more advanced than that, you probably shouldn't use PGP. PGP has lots of advanced options, but it lacks a lot of fundamental features you'd want from a secure messaging system.
But for the basic use case it supports without options, PGP is just fine.
So I think, if that was an attempt at a rebuttal, it was not a very effective one.
Is Telegram just better on iOS or am I missing something when you say it has better UX?
For example:
* Does not make it clear it's a point to point mapping (on iOS) right now. I discovered this the hard way.
* Unclear failure modes (see above). It's entirely possible to have messages be silently dropped.
* Texting vs. call methods unclear. I.e. there's a phone icon but no text icon (select name instead).
* Contacts list has some text only, some phone only, some both.
* The whole contacts list arguably needs to be rethought. It only shows others that have installed Signal/RedPhone/Textsecure. There is no easy way to see if someone does NOT have Signal installed and have the functionality to send a link to invite other person to add the app. I think this would help tremendously in the virality of the app.
* There used to be easy ways to invite people to the app within the app, seems to have gone away with only a tweet an invite to app store function remaining.
* There have been several instances when I can't see someone after they install Signal. They have to initiate a message to me in order for the contact to show up in the list.
* Signal has poor handling for contacts with multiple numbers. It's not clear which number is being used and you can't switch selection of numbers.
So what I'm saying is don't necessarily ape what Telegram/WhatsApp etc. is doing but I think Signal would do well to study hard the onboarding workflows of those apps.
You mean that there is no server to buffer failed delivery attempts if one of the devices is off or disconnected?
(Side note, I've hit that the same bug where the other person has to contact me first because they don't show up in my contacts, even though they should.)
Put differently, I can't register the same number to an iPad and iPhone simultaneously at this time and hope to communicate with someone. It apparently gets things all confused.
I was doing some more testing and it also appears that I'm unable to call someone with a greyed out name but with available phone icon. Once again, no clear indication if this is a bug (not supposed to happen) or a feature (can call but not text).
Since I'm not an Android user, I'm unable to confirm all > 2 scenarios. Someone should try and report back.
It's all very fast and working quite well.
I haven't seen a message with a double-tick that's been dropped yet, at least not on a recent version. It can sometimes behave poorly with Android battery-saving mode - however, so does plain SMS. Turning off sync is part of the actual point of battery-saving, but conversely, I never want to not get messages. That's arguably Android's problem, not Signal's. Still, it uses GCM, so at least there's hope for the deep sleep (which I haven't tried yet).
(But perhaps a new protocol could take the opportunity to improve things further and offer on-line delivery status notifications throughout the process.)
No matter what, messages should never be silently dropped.
At least that how it seems iMessage seems to work. I have no idea how long iMessage holds on the queue but it seems no more than a few days.
Not sure what kind of attack vector a public TTL would constitute.
I really want Signal to be my only app for chats and I do try Signal once in a while, but I always go back to Telegram for a few reasons. Telegram is very fast in delivering messages, just like it claims. Signal, on the other hand, has been and continues to be slow. Messages could sometimes take anywhere from 10 seconds to even a minute or several minutes to get delivered. That's not really a good UX for chats when you can't say whether your message would get delivered or not. If I wanted to send a slightly urgent message (urgent enough to be a message but not urgent enough to be a call), I wouldn't rely on the current implementation of Signal. Back and forth communication also becomes very odd and frustrating if the messages don't get delivered within a few seconds. Even SMS seems better when compared to Signal's speed of message delivery.
Next is the multi-device availability and syncing of conversations in Telegram. Once you get used to having Telegram on the desktop/laptop and phone (and perhaps a tablet), it fits in so well with the physical location someone is in, what the person is doing and which device the person feels comfortable with. There are many people who have deep and heavy conversations on these chat apps, and doing that on a small screen's touch keyboard is a big hindrance. Being able to do that with a laptop or a desktop makes it so superior an experience that it's difficult to give that up.
People that I chat with either don't know much about encryption and privacy or don't care much about those. Getting some of them to use Telegram instead of WhatsApp was difficult, but they're now big fans of Telegram because of how it works and what it provides. But getting them to move to Signal? I can't imagine doing that with the current state of affairs with Signal.
While Signal may be a very secure chat app, not focusing on the things that help increase UX (and in turn, market share) will not help in the long run.
My hope and wish is that Signal development would accelerate faster and provide quicker releases that solve what I see as fundamental issues. This would benefit everyone and make our world a much better place.
Both Telegram, Signal¹ rely on a central server to which all users connect. If that server goes up in flames then nothing will work for anyone. Or if those who run it turn out to be evil or otherwise doing bad things then there is nowhere you can go without losing all your contacts.
But in a system that has multiple servers that talk to each other, like email and Jabber/XMPP, you have a choice in who provides the server while still being able to talk to everyone on the network. So then it is at least possible to switch to another server or provider and still be able to reach your contacts. It is also possible to run your own server, or convince your more technical friend to run one for you. This model is called a federated client-server model.
A true serverless peer-to-peer system would in theory be even better, but in practice it is much harder to build and maintain, especially on mobile where devices may lose coverage at any time. So for example Skype (before Microsoft bought them) would promote some clients to "super nodes" which other clients would use to communicate ... kinda like having servers but with less control over who they are.
(Note, I work on XMPP software so I'm kinda biased)
¹ There appears to exist server software but it is unsupported and might not be useful for more than talking to yourself.
Certainly, it seems that while running your own server might not be actively discouraged, it isn't supported by the Open Whisper Systems team at the moment.
Edit: "As far as we can determine, practical privacy preserving contact discovery remains an unsolved problem." -03 Jan 2014
[0] https://whispersystems.org/blog/contact-discovery/
The kind of data they hold is legally within the reach of authorities and would allow metadata analysis similar to the NSA's former phone metadata program.
EDIT:
That metadata problem is essentially unsolved and unsolvable. No system is immune to metadata contact discovery at present.
For instance, https://ricochet.im/, is attempting to solve that problem by relying on the user to make the initial exchange securely. However, in reality, any method of relaying that to their contact point is vulnerable to discovery of that kind of metadata.
https://github.com/SilentCircle/contact-discovery
I suggested this to Moxie, he said "it's not meaningfully privacy preserving", but there wasn't any more detail.
This reminds me of an idea I had which I would love for people to tear apart (I know that the obvious bandwidth problem makes it completely impractical, but I wonder if there are theoretical flaws):
Have a central server which everybody connects to. All clients send a constant stream of data, 24/7 - if they don't have anything useful to send, they send /dev/random. When they do have something to send, they send a GPG public-key-encrypted message. Every client then receives the entire stream of data, handles the data which it can decrypt using its private key, and discards the rest.
- Your contacts list is a GPG keyring - The server knows nothing - Anyone intercepting your internet traffic can't tell where your packets are destined for - You can't even look at two people's traffic patterns and say "these two people were active at the same time, they must be talking to each other"
(¶) I think you could do without sending random data unless network consists of only two active peers and your adversary taps every single internet link. (As in, even the cable underneath the street in front of your house.) If he doesn't, broadcasting your message to your (physical) neighbors would likely be enough to obfuscate the message's origin.
Anyway, the idea of broadcasting / flooding to protect metadata is not new. See, for instance, Bitmessage and Ethereum Whisper. If you ask me, though, (and you mentioned that, too) the traffic and performance issues originating from broadcasting and brute-force decryption make this approach rather impractical to pretty much impossible – at least if you want this to work for the masses. (Even if it's just for text messages, not cat pics or anything.)
That sounds like a great way to DDoS everyone using it and every network in between.
Is this something that is going to require a Tor-like approach to even have a chance of fixing?
The first case is about finding out who of your contacts uses Signal, too. The way it's done in Signal right now is described here: https://whispersystems.org/blog/contact-discovery/.
The second problem is about whether anyone gets to see who is sending messages to whom, e.g. by tapping the wires or running the central server all messages are being routed through (for instance, Signal uses such a server).
In both cases, your social network might get get exposed depending on what data is exposed exactly (IP addresses, pseudonyms, …) and what the attacker can infer from it (your name / home address?).
Let me know if that helps.
They would find out anyway b/c your packets are sniffed on a regular basis and so they know your phone is communicating with the Signal server and maybe the packets itself are characteristic.
So in my humble opinion this criticism is irrelevant.
An inside man is much easier for NSA than all that expensive world wide data collection. (Of course, in reality surely they do both.)
Issue from 2012: https://code.google.com/p/android/issues/detail?id=32662
Thread starting in 2013 on Samsung dev board: http://developer.samsung.com/forum/board/thread/view.do?boar...
Sigh.
Most of the time it would work fine, but quite frequently messages would be sent (have left my device) but not appear on the receiving device for ages, so i can only assume that sometimes the infra couldn't keep up.
Your phone number is not your identity in Signal. If you change SIM cards then your friends won't notice and the app works as before.
Signal is based on asym encryption - your private key effectively encodes your identity in combination with your public key.
> And only if the first client is Android?
There is no point in dwelling on that. Android and its syblings are the only potentially secure popular smartphone OSs. Apple and Microsoft OSs are fundamentally flawed in that regard.
There are a lot of totally fine reasons (shakes fist) that OWS would start with Android; they might all have Android phones, they might have ideological problems with app store review, it might have just been an easier platform to build for. But yours isn't one of the valid reasons.
If Apple actually did have a history of, say, pushing customized "iOS update" binary blobs at USG targets that undermined all the security features they describe in their white papers and in their (other) marketing, that would actually be entirely relevant to claims about the security of iOS, would it not? Even without such on-device updates, a system like iMessage can potentially be thwarted if Apple itself decides to cooperate with MiTMing, at least in certain scenarios.
(Btw I'm not actually endorsing OPs point that Apple is too close with the U.S. government. That does not seem accurate given the public heat brought down on Apple by entities like the FBI recently. But if it were Microsoft, there would be a point there.)
That's all I'm saying.
So, you flash the phone with your own build? Most phones on the market rely on proprietary drivers only available as binary blobs. Even if you find a phone that has all Free drivers, can you replace the bootloader with your own trusted binary? Even the bootloader isn't nearly as dangerous as the baseband processor, and I don't know of a single phone with a Free baseband OS.
Sorry, as much of a fan as FOSS as I am, with your threat model, every phone on the market is equally bad. This might change once we're able to eliminate baseband processors from smart phones, but even then I wouldn't hold my breath.
If the phone number isn't my identity - what is the phone number for? I don't need a phone number to generate my key, do I? It seems, as far as I can follow from the outside, that phone numbers are used as namespace. Maybe 'identity' goes too far, but so far I understand that the number you register with is your - erm - user id?
Help me out. If that's totally wrong, if I "didn't get it", I'd be glad to learn more. But .. then again: Why require a phone number (-> No standalone client on the desktop)?
Thomas basically destroyed that security argument already, and I'd actually prefer a niche OS (FxOS, but I'm getting more and more into SailfishOS demos atm).
-Integration with other devices, backing up and importing your back up between devices, are features that will come, eventually.
-There are several 3rd party standalone desktop apps being developed for Signal.
-You could maybe build a Textsecure server, and in the future, who knows, there may be documentation for doing so.
Maybe Signal isn't ready for you right now now but I wouldn't count it out!
1. It's early days yet -- let's give them some time to work out the bugs and build out more diverse platform support.
2. The code is open source. If we (or anybody else) gets motivated enough, we can add support for other browsers or build a "real" standalone app.
[0]: http://electron.atom.io/ [1]: https://developer.chrome.com/apps/about_apps
And I'm disappointed. I tend to repeat the 'central server' and 'a phone number is not an address and not public information, it certainly is no identity' criticism.
When I read the headline/title, I thought 'Now maybe that would be enough to be ~good enough~ to ditch Telegram' in spite of these problems (which Telegram has as well, ofc). But really. A Chrome app. And works only (yeah, I think I said it before: Phone numbers suck) as a secondary client. And only if the first client is Android?
I seriously don't get it. And it certainly is not for me: I don't like that browser (I do have it installed for testing and to follow it at times, but there's no 'app' I'd run in Chrome). I don't want to tie something to my phone and I don't think that it should matter what platform my handset runs on - SailfishOS looks nice, FxOS progresses slow but ticks a good number of boxes for me.
Full circle to the first line: I don't _like_ to be negative and the headline gave me hope for a couple seconds. Unfortunately this release just deepened my belief that Signal wasn't meant to be for me.