I'm feeling dirty, because I don't like to be that negative, especially if we're talking open-source software. And I feel that I kinda hold this project to higher standards: If I compare this to WhatsApp/Telegram/Threema/Whatever, I inheritently, somewhat subconciously expect more from Signal.
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.
If we were going to rank our priorities, they would be in this order:
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.
Thank you for your reply. I really appreciate it. As I stated earlier, I feel bad about 'expecting more' here - I certainly see the appeal of a popular ~decent~ option. Without trying to derail this further, let me look at those points:
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.
If we ever meet I'll buy you a beer for the year of the Linux desktop line.
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. :)
This is my question exactly. What features does Chrome have that are worth making the app completely incompatible with other browsers? Why is it not just a "Web app" and it's a "Chrome app" instead?
Similar to Firefox extensions, Chrome has "apps" and "extensions". Both are locally-saved packages of locally-run JS/HTML/CSS, differing in what capabilities they have w.r.t. chrome api access.
Perhaps Signal just isn't for you. No one who I've introduced signal to has ever had a problem with it. Now if you add a randomly generated 128 bit account identifier, then people WILL have problems with it. Not with you, but with your mum/grandma.
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.
Non-technical people I've introduced to Signal on iOS stop at the "upload your contacts" stage and go "I don't want this random little company to have access to my contacts". These are non-technical people who understand the importance of keeping their contact list private, and there are a lot of them.
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.
> These are non-technical people who understand the importance of keeping their contact list private
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?
The last person I'm recalling this conversation with actually blocks Whatsapp / Facebook from getting her contact list, but trusts Microsoft and Google. I'm not sure how representative that is, but I wouldn't be surprised if people trust big companies with big brands over relatively no-name startups in this regard.
See, that identifier might be an option. Or .. it might not be necessary. If that identifier would be the core 'me' on Signal, why wouldn't you be able to add me by phone number - if I gave Signal one to share/associate with? Mum and Grandma would see no change. People like me could run around without a phone number.
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. foo@example.com -> 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 ;-)
If that identifier was linked to my Keybase.io account, that would be really cool. Or linked to Namecoin. Using methods like that to find my contacts would be great.
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!
> 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.
Chrome is not any better at all. Speedwise they're about the same, but Chrome has better separation between tabs. However it allocates ram like there is an infinite supply of it, and it absolutely kills the battery on my computer. This is with the same extensions installed in both browsers, uBlock Origin, Privacy Badger, No Script, Last Pass, and Wunderlist.
I'm aware of that. I used to run an xmpp server and recently switched to Telegram for inter-family conversations (wife, brother, intimate friends) because the xmpp UX story is unfortunately not perfect (you need message carbons, you need stream management and you probably want MAM to have a usable system that can be used on mobiles as well).
This is great news! Such a big fan of the work you guys are doing at Whisper Systems. We are in the middle of an update to Umbrella App (which contains lessons on digital and physical), so will add the latest Signal changes to it in the next few days.
The problem of course being that those users that use the closed source Google browser and iOS won't care much about what Signal is offering either. They're already using Hangouts, iMessage and Signal is pretty much a downgrade from those.
I don't really know anybody who uses "Chrome apps", technical or non-technical. I agree that was an odd choice, and will probably exclude a lot of people.
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.
First, congratulations on shipping. Usable E2E encryption is something I care deeply about and Signal is the best Ive ever used. Completely agree fighting mass surveillance for avg users is highest priority.
What do you mean by "the velocity of the ecosystem is unlikely to make distributed communication mechanisms possible for some time"?
Ecosystem - tools and services with network effects, like Google Cloud Messaging.
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.
"most people" in "the world we live in" are completely hopeless. You won't get to them until you sink completely to the level of the services you are trying to replace. So you won't help people who can be helped because you're trying so hard to get to the people who just can't be.
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 would argue that the removal of SMS encryption is a worse failing. Accepting all key changes without question renders you vulnerable to active attacks, but you remain safe from mere passive collection (the most common case). On the other hand, whatever Whisper Systems would have you believe, people really do still use SMS. A lot.
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.
Why do your friends care about the underlying transport?
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 am farting in a thunderstorm, since this argument has been had a million times. Nevertheless, i will explain why i personally worry about the transport. Perhaps the other commenter has different reasons, i don't know.
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?
Because most people I know keep their data switched off most of the time, which will always be the case as long as apps are abusive about phoning home.
I like the fact that Signal makes good cryptography available to the masses. But I also share the OP concern about Chromium (and about a central server, but this is technically much harder to fix).
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).
The main thing I have against webapps is that from a technological point of view they aren't meant for the use we go today.
Obviously the privacy thing is another big issue, but this leads me to point 2;
I can protect my privacy: I just need to switch off my router, throw away my phone and say good bye to the grid, but that is the 2015 way of being an heremit and honestly, is something I don't want.
So I came up with this solution: carefully try to not divulge sensible data and, if I need to, split that over many possible unrelated services.
We're not going to win, but at least I try to defend myself
Please make it possible to use public keys as identifiers somehow, maybe linked via for example keybase.io to provide simplicity in lookups and tracking usernames.
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.
Signal combines a competent and relatable user experience with a reliable security model. The latter is required to make a few people install it, the former is required to make their acquaintances install it, too.
Moxie, you really think crypto nerds are being attacked? They're not the ones with Keys to the Castle. Sysadmins have the keys! In fact, the NSA has been targeting sysadmins for a while. Sysadmins make great targets. Forget about their inability to implement a real security program, a sysadmin can barely get a security compliance regimen off the ground. Here's an article from Glen Greenwald's TheIntercept that details why Sysadmins are sitting ducks against both the NSA and Nation States: https://theintercept.com/2014/03/20/inside-nsa-secret-effort...
It's Sysadmins who make for a delicious muskrat lunch, not the crypto nerds.
There is a bunch of overlap between those groups (though too many sysadmins indeed don't grasp the threats that face them, or don't take them seriously).
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.
Regarding #2, since it's worded somewhat ambiguously, should we read that as wanting to stop targeted attacks in general (I'm thinking specifically of criminal suspects/etc. when a valid warrant exists) or targeted attacks against specific targets (i.e. people being illegitimately targeted like crypto nerds)? As a follow-up, are there any situations in which you think it would be appropriate to give information or the plaintext content of encrypted messages for a specific user to a law enforcement agency?
#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.
Could you tell me more about gcm core? I've removed play services from my phone and for the moment accept that this means some apps dont work. I'd love a substitute, but a quick search for 'gcm core' didn't give useful results.
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.
> Will the US government really just let you do it? Have they not interfered yet?
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.
The central server in Signal does not have the same role as the Telegram's.
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.
I've been actively using PGP for about 2 years with a few friends that all use keybase, but I still don't feel like I really know what I'm doing, or if I'm really doing the right thing. A lot of the terminology and best practices I learned while first setting it up are lost on me now. It still works though! Well, somewhat... since I switched to KDE thunderbird no longer remembers my pgp password. I miss the gnome keyring.
70% of the UX complaints people have about PGP stem from the huge number of options it has and the lack of guidance it gives you for which options matter.
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.
In fact, he may have even said it on Cryptocat; Poitras and Greenwald used it to collaborate with him. Snowden also used Lavabit to send email. Why? Because Lavabit had superior UX to his other options --- because Lavabit handled all the crypto serverside. NSA has presumably read everything he sent on both of those systems. Despite the extreme ease of use both systems boasted, they were both so badly designed that they enabled retroactive decryption.
So I think, if that was an attempt at a rebuttal, it was not a very effective one.
Secure messaging products with good UX and bad security should wait to launch until they can have good security; the alternative puts people at risk, as it did to Snowden.
They should but they don't. That's why have competitive UX is important for the good tools or people won't even consider using them. We have seen that happen countless times.
* 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.
What do you mean it's a point-to-point mapping? Genuinely curious.
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.)
It's one device to one device (as stated elsewhere in this thread. Apparently, only Android+Chrome combo is supported for multi-device).
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).
Oh I see. That is indeed annoying. So I guess this bit from the desktop announcement is a stretch: "....all incoming and outgoing messages are displayed consistently on all your devices." I mean I guess if you ONLY have one phone and a desktop that would be true? And I guess if Signal only allows you to register those two things, it is TECHNICALLY true, in the sense that "all" <= 2
I do have an "invite" prompt on my SMS contacts that don't yet have Signal: "Invite to Signal: Take your conversation with %s to the next level.". Perhaps it's a function in the beta version that isn't in the live version yet?
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).
With no knowledge of how signal's servers actually implement this, I would like to ask you... how long should the central server hold on to the (encrypted) message that Alice sends to Bob if Bob never becomes available again?
I haven't thought about what's reasonable (an hour? a week?) but it still shouldn't be dropped but bounced back to the sender with an undelivered message. At last that's how email solved it some thirty years ago.
(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.
This reply is mainly intended for Moxie and the team developing Signal as feedback (which they probably have received from others). I'm not going to focus on security, because Signal is likely the best on that front from whatever I have read.
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.
I'm curious about this response. Could you please explain or point to something that explains, for a common person who doesn't code or cannot build code or cannot maintain servers, how Signal would provide more control and avoid being locked to a single vendor when compared to Telegram?
It does not. In practice both are equivalent in that regard. I guess tptacek meant that Signal might have less control over you than Telegram, but that's a different issue from what I was thinking of.
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.
There was talk some time ago now about Signal server federation. I was under the impression that it was planned and either dropped or de-prioritised for now.
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.
They don't like to admit it, but Signal has a metadata problem. It's fine if that's not their threat model, but I wish they would be more clear about it, especially when other chat systems get criticism more often for precisely that aspect.
Edit:
"As far as we can determine, practical privacy preserving contact discovery remains an unsolved problem." -03 Jan 2014
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.
They don't like to admit it, that is why the write a whole blog post about it? The app tells you when registering that is is about to send some contact information to the server and that it will not be stored.
Your criticism would be stronger with a list of examples and evidence they are unfixed for at least 6 months.
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.
> "As far as we can determine, practical privacy preserving contact discovery remains an unsolved problem."
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"
You don't even need a central server for that. Just set up a p2p network and have all peers broadcast their messages (¶) to everyone they're connected to. Those peers in turn forward everything they receive to everyone they are connected to and so on. (And, of course, they try to decrypt everything in the meantime to see if any message is meant for them.)
(¶) 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.)
>broadcast their messages (¶) to everyone they're connected to. Those peers in turn forward everything they receive to everyone they are connected to and so on.
That sounds like a great way to DDoS everyone using it and every network in between.
Well, there're obviously a lot of things you could improve to lower the chances of a DDoS. (E.g. introducing a TTL / maximum number of hops for a message or forwarding some messages only to some peers, thereby influencing the exact way messages are routed through the network.) But I agree it doesn't look like the most viable idea for a medium for mass communication, not even if it's just for high-latency messages. Yet, people are working on it.
I'm currently working on a decentralized instant messenger Ensichat [1] which does exactly that. Right now, it only works over Bluetooth, but internet support will be coming very soon!
/dev/random has a nonzero chance of emitting a valid GPG public-key-encrypted message. How does the server tell the two apart? How do you make sure that an external watcher can't tell them apart?
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?).
NSA only knows then that somebody with that phone number is using Signal ... so what?
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.
I feel the same but in a bit other way. They tied up everything very closely to google services and they tell me "we really care about your privacy so use our app that requires google play frameworks on your android device". Those are two completely different things, use gapps or opensystem apps? It's 100% no-go for me and the whole idea seems to be a bit sarcastic for me. It hurt me when they removed content encryption from TextSecure because "NSA cares about metadata not content", yea, but European agencies like GCHQ care about content not meta-data.
I just found it unreliably slow. Principles are all good, but if I message my gf saying "see you at the bus stop in 20 minutes" and she doesn't receive the message for 2 hours, that's majorly annoying and it happened so often I had to leave it. The basic functionality isn't fit for purpose, for me.
Do you have IPv6 in your home network ? Many devices (such as all the Samsung one) stop responding to ICMPv6 packets when in sleep mode (which completely breaks long-running TCP connections over v6), supposedly to save power.
This breaks push notifications of every apps using GCM, but there is no way to disable IPv6 without root, and no way to only use GCM over IPv4.
I find it mind-blowing that this issue has been known for 3 years and nothing has been done to fix it...
are you sure it's Signal? cause i have this problem with my husband too, but it happens with Hangouts as well as with Signal. my best guess is that his android phone, a cheaper LG model, has limited resources and puts some services to sleep...
Yes, because it happens on recent hardware (a 6s) and other messaging systems don't seem to have this issue at all under the same conditions.
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.
> 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.
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.
Approximately zero is the number of software security experts that would agree with that assessment of Android's security versus that of iOS.
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.
Do you happen to have a reference to any kind of freely available technical publication (blog post, etc) that goes through some core points to reach this conclusion? I read many things around for years and I agree with the general statement, but I failed to find a recap that can be used to explain the core points of differences to people not familiar with the matter.
Huh? Apple and MS have a record of communicating in sharing data with US government - plus as companies providing closed source software they are likely to introduce backdoors ... also something you might have heard of since Snowden.
Engineering and corporate behavior aren't really orthogonal topics, are they, when the actual engineering you want to inspect is unavailable (closed source) and you have to rely on observed behavior and trust?
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.)
I think Apple has gone through a lot of trouble to avoid being forced to compromise iMessage, but I am not recommending iMessage. iMessage is orthogonal to Apple's platform security, which is simply better than Android's.
Closed source it may be but what's stopping you from reverse assembly? After all even in 'open source' you still don't know what you run unless you built it yourself. And even then you have to trust your toolchain.
And the Android build shipped with your phone is provided by your telecom provider, which presumably cooperates with your favorite Three Letter Agency.
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).
To me, this announcement feels pre-mature, the software doesn't seem ready until it integrates with other clients. But I think, giving time, your concerns could be addressed:
-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!
Isn't Chrome app a standalone app which doesn't run inside Chrome browser, but instead only uses its engine? I don't know anything about security or privacy implications of using this tech though, anyone care to comment?
That surprises me. I don't trust Chrome for confidentiality; I assume it collects data for Google and I don't know that it protects my data from others.
If Chrome isn't trustworthy for confidentiality, it would seem to fatally cripple the security of Signal Desktop. However, I believe the people at Whisper Systems would see that obvious flaw so I suspect that I'm misunderstanding something - what is it?
Whisper Systems has a track record of prioritizing 'good enough' ease-of-use ahead of 'perfect' security as a practical way of expanding its user base.
Edit: Tried to word the above most neutrally; I believe this approach has both pros and cons.
> Whisper Systems has a track record of prioritizing 'good enough' ease-of-use ahead of 'perfect' security
Why is Telegram always under for their flawed security challenge despite the good-enough track record then? They also have perfect usability, native apps, 3rd party clients, etc. If the security is not the first priority then Signal isn't very attractive compared to the competition I think.
Signal's objective is to make mass surveillance impossible. Telegram stores the entire plaintext transcript of every user's entire conversation history server side by default, so if that's the objective, Telegram is definitely not "good enough." Just the opposite, there's nothing worse.
I'm not drawing an equivalence at all (not saying that Telegram and Signal are equivalently insecure or flawed, etc.) -- I was only asking why would Signal make any compromise on security if that is their main selling point (and probably the only one). I don't think that releasing a Chrome app is a good strategy considering the audience (but I don't know for sure, they probably have a better overview of their user base).
I could have compared it to Threema as well, actually.
I don't concede that Signal has made any security compromises. That was someone else.
If you care about security, use Signal. If you care about UX, and Threema has a better UX, use Threema. Threema is a closed-source system that apparently relies on Nacl. That is a much better answer than the one Telegram can give, but it still leaves a whole lot of questions unanswered. There's a lot that can go wrong in the layers above Nacl.
F-droid builds those parts separately from source.
> The official source code of the app contains binary blobs, so this tracks a fork which builds those from source. Hence, versions might become available with a certain lag.
moxie has stated previously someplace that the goals are
1. Simple encryption for everyone to prevent mass data collection
2. Prevent targeted collection for the crypto enthusiasts
The main focus is on step 1. now and they are doing a great job at it. It's slow like anything new, but I managed to convince my parents to switch so that means it's working!
> 1. Simple encryption for everyone to prevent mass data collection
Google might be the second biggest mass data collector, after the U.S. government. Using Chrome, one of Google's tools of collection (if I understand correctly), wouldn't seem to further that goal.
The threat is that Google (perhaps forced by the NSA, perhaps only for some users) modifies Chrome to include code that logs all keystrokes or specifically detects the Signal extension (or standalone app if Chrome is also installed) and uploads the plaintext of all messages to Google or to the NSA.
In other words, you have to trust Google to not insert such a trojan by itself and to not bow down to the U.S. government should it try to secretly force Google to do so.
You also have to trust that their security is good enough to prevent third parties from covertly performing such a feat.
That's not say that Google should not be trusted or should be trusted less than other parties, but that's the threat.
Google adds Google Analytics to their browser, to automatically report what a user does in Chrome apps, and "accidentally" your whole chat history ends up on Google’s servers?
"Accidentally" logging keys is possible, as Google can modify the content of the JS on request – for example, in case of being served an NSL, Google can be forced to modify the JS to log that.
The android app already requires Google content manager to be installed, which is probably why the beta is android only. so its no different from the mobile app really.
I think more accurately, it's a standalone app that runs on the chrome runtime. You get windows, osx, linux & chrome os all at once. The chromebook is touted as the secure desktop for the non-technical user.
You can take the app and make your own standalone runtime version if you want and audit / test your standalone version to make sure it's only communicating with open whisper systems.
Loving moxie's namedropping of oldschool revolutionaries:
Maria (Masha) Alexandrovna Kolenkina was a Russian socialist revolutionary from a merchant family in Temzhuk, a small town on the Sea of Azov. (1850-1926)
Vera Ivanovna Zasulich was a Russian Menshevik writer and revolutionary. (1849-1919)
Nestor Ivanovych Makhno or Bat'ko Makhno was a Ukrainian anarcho-communist revolutionary and the commander of an independent anarchist army in Ukraine during the Russian Civil War of 1917–1922. (1888-1934)
(all above from Wikipedia)
Oldschool Communist revolutionaries, to be exact. Yeah, it's no mystery where Moxie's politics lie given those allusions and the not-a-company company, eat together, do push ups together, open salary policies.
I'm sure most people wouldn't use software created by Nazis. Considering Communism has arguably worse track record, I would definitely avoid any software created by its proponents if it's at all possible.
I don't understand why it prompts me to invite other people after putting me in line. Why would I email/tweet my friends to join this service if it isn't even ready for me? Seems rude to bother a friend with joining an internet line just so that I can get a better position in the line.
I love signal on android and have been looking forward to this, kind of rubs me the wrong way when I'm put in "line"
I think it might be related to a restriction google groups has (https://twitter.com/liliakai/status/672219521654980608)
"Waiting for Signal Desktop beta access? Know any googlers who can lift the 100-person daily limit on google group invites?"
I don't feel strongly about the practice either way, but you're also indirectly prioritizing users who are most willing to share the product. So they're hoping their early users are also those most willing to spread. The "connectors" of the products ecosystem.
You're prioritizing users who are willing to spam their friends about a product they can't even use.
I would be _far_ more likely to tell my friends about the product if I could actually use it and be able to vouch for it (as I have with the mobile version of TextSecure/Signal).
Forcing me to get my friends to visit a page where they will find out about an application they can't even use is just annoying.
Why incentivize spamming my friends with links before I've even seen the app, only to refer them to a waiting line? Sure, launch day momentum and all that, but I wish that as an entity that wants to be "the good guys", they can find a way to gain a broader audience for their app based on the app itself, not the buzz around it.
The buzz about a chat app is more important than the app itself. The usefulness of the app is proportional to the size of the social network. The most difficult thing to build and the most valuable part of a chat app is the social network. WhatsApp wasn't worth $19 billion because of the quality of the software.
Buzz, marketing, promotion, virality, user aquisition in general, are the most important thing for Signal to be working on.
I mention it because downloading one file (a nw.js / electron build) is a lot less friction filled than (in some cases) downloading an entire browser just to use one app. There's still people out there who still use Firefox or whatever default browser their OS comes with. Instead of downloading one file, you're now forced to download two.
These aren't specifically about Qt or GTK applications (except maybe the Ubuntu phone app), but here are some other projects that are shooting for compatibility:
FWIW someone is trying to create a Signal/Textsecure client for Ubuntu phone[1][2], using web-sockets, with (I think) a QML-interface and a go back-end, so once it's ready it should hopefully be relatively easily portable to desktop Linux (and if/when Ubuntu convergence becomes more than a pipe dream it should work even without porting...)
I haven't actually used it or looked at the code, so I can't comment on the usability of the interface or the security of the implementation.
Slack and several other chat apps are web based. You don't really need it. Dev time and cross platform compatibility would be worse. With this they get at least 4 platforms.
A native app would certainly have its advantages, although it would require putting pre-compiled binaries up for Windows, OSX, and various Linux distros.
By contrast, making it a Chrome app allows it to run on any OS that supports Chrome, including Chromebooks. So I understand the decision. But I'm primarily a Firefox user, so a native app or at least an FF add-on would personally be preferable to me.
True. Although, I don't understand why it has to be a Chrome app. Why not just a NW.js app? Maybe for the whole "connect with your phone" functionality?
My guess is it uses Chrome's Native Client [1] for crypto. It's understandable why they might want to do this at this point in time, because the only other way to use native code for crypto in the browser is through the the Web Crypto API [2], which is still very young and implementations aren't very consistent across browsers yet anyways.
As much as I agree with your overall sentiment, the sad truth is that centralized architectures enable many of the UX affordances that users take for granted today in a modern chat app, many of which are much more difficult, sometimes simply impossible, to implement in a decentralized architecture (think features like automatic contact discovery, offline messaging, etc). Without some of these affordances, a chat app has simply has no chance of gaining widespread adoption in such a competitive landscape. This is why it is very difficult to justify pouring any significant resources into building a decentralized chat app, because too few people will ever end up using it to justify the investment.
For what it's worth, I am the author of a decentralized messaging app myself [1], and have spent a lot of time thinking about stuff like this, and eventually reached this unfortunate conclusion and decided to leave the project at the prototype stage.
Impossible is a strong word - one prefers to reserve that for provably doomed problems like DRM - but several common, simple paradigms do present an unexpected technical challenge, or even an open research problem, or need to be expressed slightly differently to be practical, in a distributed, privacy-preserving, untrusted-server kind of model.
For example, paraphrasing quite a lot - uniqueness of names requires ordering; ordering probably requires consensus; consensus has a Sybil problem for which some kind of countermeasure is needed. So a namespacing problem that seems simple, and is simple in a centralised/trusted context, may only be practical to solve with a blockchain-like structure with a computationally-heavy proof-of-work in a distributed trust architecture. Even that may still be vulnerable to attacks from someone who can outcompute the rest of the network: and a Nation State Adversary (as a friend snarkily puts it) may actually have enough budget to try that. There may be another way, but maybe not another way that satisfies all the security requirements or that would survive an attack. And there are still other niches you need to worry about, like homoglyph attacks.
That's a long way to go just to make sure that there aren't two ~bobs! So you end up thinking, maybe it's better to find another way that ~alice knows she's talking to the right ~bob? Then you have rephrased your security problem as more of a UX problem: how do I try to avoid impersonation? - which is perhaps more practical to solve another way. [Edit: Also, now your users won't have to fight over who gets to take ~bob first. This may or may not be an advantage, depending on how you feel about username exclusivity.]
It's going to require a lot of hard work to solve this type of problem comprehensively; in the meantime, Signal does more or less the best we can do practically right now, and there's a lot of value in a practical solution that's best-in-class, works and millions of people can just pick up and use now.
The two features I mentioned, automatic contact discovery and robust offline messaging, are examples of features that I have concluded to be impossible to build without some degree of centralization (there are probably more, but those two were the only ones I could recall off the top of my head). Though it is certainly possible that I simply haven't put enough thought into it.
Toc's original goal was to be a decentralized messaging app that makes no compromises in terms of UX compared to a centralized messaging app. Toc managed to tackle decentralized cross platform sync, but to this day I still have no idea how to approach automatic contact discovery and robust offline messaging.
Automatic contact discovery is tricky, but the beginnings of one potential solution is I think explored in agl's Pond, using pairings on BN curves?: https://pond.imperialviolet.org/
To a point, so is offline messaging. Distributed datastores in general do that kind of thing - there are old implementations over Freenet in particular, and GNUnet as well and other things I think. The robust part is harder: if the client is offline, where's the disk space coming from? Volunteers' (nodes') cache? That needs to be opaque, and so do lookups. What's to stop spammers flooding the network? (Spam, and denial-of-service in general, is a Hard problem to deal with in general even in distributed systems.)
They're not among the hardest problems. Pseudonymity is a huge challenge as the latency gets lower against traffic correlation attacks, and a secure messenger is most definitely up against the kind of threat model that can and will try to pull those off in the wild. Perhaps mixing high and low-latency traffic may help, although it's going to need to be very carefully analysed how much (I believe I2P's design can do that, although I'm not sure if jrand0m ever implemented it in the router).
Yes those are definitely not the hardest problems in this space. I was only referring to UX-related features in my original post (i.e. rather than the much more tricky privacy and security related ones), ones that I couldn't figure out how to actually implement in the context of a client-side web app. Impossible was probably too strong of a word to express that.
Thank you for all the interesting ideas and resources though! They'll definitely come in handy when I eventually revisit this space when I have more time later on.
Maybe because an excellent centralized encrypted chat doesn't exist yet. All options, including Signal, have lots of problems. Some chat apps are great, but really questionable security. Other apps have seemingly great security, but really questionable chat experience. After this duo problem of chat+encryption has been done well, we can start looking into adding additional problems like centralization.
> Tor Messenger builds on the networks you are familiar with, so that you can continue communicating in a way your contacts are willing and able to do. This has traditionally been in a client-server model, meaning that your metadata (specifically the relationships between contacts) can be logged by the server. However, your route to the server will be hidden because you are communicating over Tor.
That is essentially what happens with Signal and every other service as well.
No metadata, truly anonymous communication between trusted parties is an unsolved research problem.
I'm currently working on a decentralized instant messenger Ensichat [1] which does exactly that. Right now, it only works over Bluetooth, but internet support will be coming very soon!
But as others have mentioned, many problems become really difficult in a decentralized application, most importantly offline messaging.
It's easier to build Chrome apps, and they are also more secure. It's one of the reasons Mozilla is trying to move away from the add-on model and adopt WebExtensions. When it does that we should start seeing Chrome/Firefox apps appear likely at the same time. It's why I hope Mozilla dismisses the backlash against the switch because some people can't live without their "deep" themes.
>Don't leave your friends behind, invite them to signup with this unique link. The more friends that join, the further you will advance in line for the beta.
Even more annoying is that it tells you how many people are ahead of you in line, so you get to watch that number grow as you move further down the list...
I was pretty excited about this when I saw the title, now I'm just annoyed.
Yeah, I was disappointed to discover this a while back when I tried to provision an iPad to use the same account as the iPhone.
The failure mode is horrible too, in that messages will just go into the ether. I apparently missed a whole bunch of messages until I deleted Signal off the iPad and reinstalled on the iPhone.
I found myself thinking "WFT - this is Chrome, not desktop and with an Android dependency at that !" and then realizing that it may be time to question my assumptions about "desktop" meaning Linux/Windows/Macintosh
Also note that the multi device support only supports multiple desktop clients and not multi-mobile. If you have multiple phones or a tablet you're out of luck.
Sadly, as much as I'd like to use Telegram or Signal rather than the usual suspects (sms, whatsapp, facebook messenger), it would require someone on the other end to receive my messages.
The likelihood of convincing my friends/family to use a messaging app that isn't any of the usual suspects is low to none. And none of my bleating about privacy issues will convince them otherwise ("I've got nothing to hide, doesn't bother me").
I agree with some of the folks here. I have the utmost respect for Signal and Marlinspike but this seems like a weird direction for this to go in. A Chrome app? Tying it to the Chrome App Store? Requiring a Google email for the beta group? Just seems out of place for Signal.
"Make sense since that's how you sign into the Chrome app store to download the app."
I don't think it makes any sense at all.
Even if you do use gmail/google in some places (I don't) it's not a given that you want to tie that identity to this app or these activities.
A throwaway google account is getting very difficult since google automatically flags an account with no mobile phone number attached to it as a "suspicious activity" account, immediately forcing you to add a mobile number.
Google is not the Internet. Their app store is not the Internet. I can't believe that the people I know to be behind this project have tied it to google in such a necessary and intimate way.
Really, they do that now!? No way am I giving Google my phone number, goddamn. I have gradually drifted away from using any Google services - I guess I won't be creating any new Google accounts in the future, then.
How much money do you need to develop and maintain a Firefox version? Can I donate? I don't want to help to enforce this idea that Chrom* is the only browser that can run certain things, is against my believes.
Yeah, this makes Signal a total non-starter for me. It is doing the same thing WhatsApp does: you need a smartphone to use it. Even the desktop version requires a smartphone to create an account.
If privacy is so important for Signal, why forbid using it without a phone number? It makes no sense.
This is slightly off topic but am I the only one surprised at the litany of permissions they require for the android app? Some make sense (like SMS or camera) but device & app history/location/identity/device ID & call info/contacts/calendar/microphone/phone seems like a smash and grab. I saw moxie speak at a conference once and he specifically called out the device id/call information permission as evidence that google doesn't care about your privacy, so why is his privacy-enabling app requiring it?? I thought these were supposed to be the good guys (and girls)? The good guys (and girls) don't do 'collect it all.'
I love Signal and advocate it wherever possible. After following along on the GitHub tickets for this project, I'm happy to say thank you and congratulations on the beta release folks!
I'm probably about to ask this on the mailing list soon anyway, but in case there is any hidden knowledge here:
1. There was talk of server federation long ago. Is this still part of the long term plan?
2. There was talk of not using a phone number as a required identifier. Is this still part of the long term plan?
I got excited about signal after watching this video, which explains pretty well the challenges of encrypted communication and how Signal addresses them (it might be basic stuff for people super familiar with the topic though):
https://www.youtube.com/watch?v=tOMiAeRwpPA
Why tie it to a phone at all? Why not have this Chrome app work standalone? Apple's messaging app uses end-to-end encryption and it can be routed to multiple devices. I would expect Signal to strive to attain parity with Apple's offerings.
Also, the naming of this app is pretty disingenuous. This app should be called "Signal Remote", since it's not running the actual Signal comms on my desktop, it's remotely controlling Signal on my phone.
And actually, earlier this year, WhatsApp started using the encrpytion protocol developed by the signal folks (Axolotl) to encrypt message data, Which is super cool. (I think group chats and images are still not encrypted, or something) I wonder if in the future Signal will focus on integrating their encryption into other existing chat systems like Facebook messenger, and put the Signal apps on the backburner.
The problem I have is when these systems don't indicate whether their session or secure or not. Last time I checked, WhatsApp still didn't have it. This is especially problematic when the system has exceptions like the ones you've described. (Group chats, images, etc.)
Services like LINE also bragged about their secure chat feature, too [0] but honestly, without an active indication of whether their session is secured or not, it's fairly useless and I don't really like this "hide the complicated stuff" attitude that those services seems to be going toward...
I heard somewhere on the internet (actually /r/crypto) that after being bought by Facebook, they are cancelling or backdooring it. Sounds like conspiracy to me but then again it's Facebook...
> Signal Desktop is a Chrome app which links with your [Android] phone,[...]
Unless your "adversary" is not the NSA, I wonder what's the point of encrypting your communications when those coms are taking place on technologies (iOS, Android, Chrome) from companies that are members of the Prism program.
1. Billions of people live in countries which do not have jurisdiction over Apple, Google, etc.
2. You should learn more about PRISM before spreading FUD about its victims. I'm strongly critical of the NSA's actions but for all of their abuse, PRISM is not the bogeyman you're making it out to be:
“The PRISM program collects stored internet communications based on demands made to internet companies such as Google Inc. under Section 702 of the FISA Amendments Act of 2008 to turn over any data that match court-approved search terms”
Remember, this a secret court, whose judges are likely highly biased in favor the government, with secret proceedings where only the NSA gets to make a case. Not exactly a legitimate safeguard.
I also have reservations about the grandparent comment, but PRISM is still pretty awful.
Again, I'm not defending them in any way but all we know about the program is that it allows the kangaroo courts to order searches of information stored on those servers. We have no reason to believe it includes the ability to e.g. compel Google to ship a compromised version of Chrome to a specific user and the fact that the NSA has an entire program to develop and deploy rookits supports that interpretation since it's far more expensive than just asking the company to do it for you.
> 1. Billions of people live in countries which do not have jurisdiction over Apple, Google, etc.
Alternatively, you could say that billions of people live in countries with no restrictions on espionage of these companies, and with no recourse. Has NK faced justice for the Sony hack? Has the US faced justice for taps of overseas cables? No on both counts. If anything, having your country be a member of PRISM grants you as a citizen greater protection over how that data is used against you by that government.
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.