So it can't be used without a phone and phone number? Like most people I have those items - but only one of each. Good enough for standard chats with family and friends (which I currently use iMessage for), but on occasion I'd rather be pseudonymous, and it's precisely then that I need secure communications the most. Right now I have no idea what instant messaging software to trust, so I was hoping I could use Signal over Tor for this purpose, but I guess not.
* Signal's primary audience is non-technical users. The big goal of Signal is to thwart passive, dragnet surveillance of people's text and voice messaging.
* AFAIK, Signal's use of GCM makes it more difficult for an adversary to perform traffic analysis to determine with whom a Signal user is speaking, but not impossible.
* If you don't trust Open Whisper Systems to treat the phone number that you give them as sensitive and confidential, you really can't trust their messaging software, either. :)
I do trust OWS (although I'd like if they made the Signal iOS app build reproducible - there's an issue report about it). But I don't trust the people I'm conversing with, and they need my phone number to reach me on Signal. I guess I could use Google Voice or another service to register an anonymous phone number, but that's not a great UX, especially if I'm recommending the same procedure to the person I'm conversing with. (Oh, and the app doesn't seem to support multiple identities... I really should just look elsewhere, I suppose. It's just that I have a lot more faith in OWS's ability to deliver properly engineered systems than, well, anyone else's.)
Imho, the big thing is that I have to give people my phone number to communicate via Signal. For contrast, Threema only requires you to share an ID like K48FEHZD.
It seems like a well thought compromise, but it doesn't work for many users. Moxie must have plans to support certificate-based identification/authentication in order to remove the number requirement. There's no reason you need a SIM card to make voice calls, video calls and text chat.
I heard a long time ago that the dependency on phone-number-as-username is something that they want to get rid of. However, I'm pretty sure they've been busy with the WhatsApp work and doing general work on the existing clients, so I don't know the timeframe for such a change.
This is finally what allowed me to get rid of Telegram/Whatsapp. The lack of desktop integration is what held me back from using and recommending Signal with most of my friends. It's nice being able to use the same app for SMS, IM, and now desktop IM.
We've been using it for the last week and I've personally found it pretty flawless so far.
The only complaint I've heard from other people is that they couldn't sign-up when their phone was offline. But not a big deal given the security advantage of routing through a local device.
That is Telegram's biggest security/UX compromise which I hope they address, since I'm sure 90% of people using Telegram aren't really using E2E encryption the majority of the time - due to the fact encryption is not enabled by default in the UI, the lack of syncing conversations between devices for "secret" chats, and the fact a few official Telegram desktop GUI clients don't even support secret chats at all (including on Linux).
A big problem with some E2E messaging systems is that your conversations aren't synced across devices. By routing messages through your phone, the way WhatsApp does in their desktop app, you can have the same conversation synced across both devices. (EDIT: additionally a server in between could sync the various client conversations as it seems Signal is doing).
Otherwise you end up with a situation, such as with Telegram secret chats, where encrypted chats are initiated on your phone<>friend, then you switch to your desktop and create a second secret chat channel with the same friend. You could then potentially miss messages that are still going to your phones secret channel - as your friend won't be able to know which secret chat is mobile/desktop or the "right" one to use at that moment. You'd have to close the existing secret chat on your phone when switching machines, which we often forgot to do in practice.
Signal Desktop messages aren't routed through your mobile device, so it's the best of both worlds. Once you've installed Signal Desktop, you can use it when your mobile device is turned off, and vice versa.
I'd love to see Keybase support for contact management and addressing, perhaps by hooking into OpenKeychain that's already got it integrated (OpenKeychain has an API)
You should update your knowlage of keybase. They are more then just a GPG public directory. They try to have multi device end to end encryption capability distributed by a smart system of public key infrastruture. This gives them the basis to have multi client archtecture for messanging and file sharing. It is very cool because it allows you to revoke individual devices and thus also 'solves' the GPG problem of having one 'holy' key.
So does the Desktop client have its own set of keys? Do you encrypt every message for each device registered? Can I somehow revoke a device when I lose my phone/laptop?
Are you considering something like the Keybase Device registry? It would be fantastic if I could somehow add my phone number to keybase and integrate with Keybase. It would be a total hit, Keybase providing filesharing while Signal adds the messenging part, all backed up by a clever PKI that works for the online world.
I saw the desktop client mentioning something about generating keys after scanning the QR code. Afaik it works similarly to group chat[0], but instead of clients with their own keys belonging to different accounts they belong to the same one.
Open Settings > Linked devices and tap an a device to unlink on Android. Seems there's no way to revoke (yet) in the Chrome app.
Not Moxie, but the desktop beta announcement[0] carried a link to a donations and grants page[1] and a link to their Github org[2] for anyone to verify their code and implementation, but not any request for or details about code submissions.
I'm assuming the SMS integration is only for Android... But, yeah, this is great! I love Signal. Now I need to get more people I know to care enough to use it and not FB Messenger.
Oh very much so. What's been done with textsecure/signal is amazing.
I'm far more held back by not being able to get friends to switch from just chatting with Facebook app / Kik / Whatsapp etc than it being a browser app. I know I'm the outlier here. :)
Honestly, I don't know. I don't have one. But, for the price, I can see a lot of cool circumstances where a ChromeBook (or maybe Chromebox) could be very useful.
I'll be waiting eagerly for those native desktop clients too (especially something also including desktop voice communication), but this looks promising enough that maybe I can seriously start pulling people to Signal for things like coordination of groups, which as things stand often happens in Facebook or things almost as revolting.
So I think this is a big thing.
Haven't tested it yet and probably won't get time to today, but I'm really excited to see if it lives up to expectations.
I agree. Last time I looked at why they were designing it be Chrome-only, it appeared to be due to a reliance on Google Cloud Messaging (GCM, [1]). This could be due to one or both of the following factors:
a) they wanted to re-use as easily as possible their existing back-end infrastructure which already uses GCM for the Android app.
b) they are using GCM to ensure that their desktops users are also "screened" by Google's existing authentication/security infrastructure - which ties a user down to a phone number among other things.
We've never used GCM in conjunction with the desktop app, so I'm not sure where you were looking. Writing and maintaining three different fully native apps for Windows, OSX, and Linux is a non-starter for most organizations these days, but it's particularly true for a small open source project like us.
We developed it as a chrome packaged app because it provides the same experience as a native app (appears fully stand alone, integrates with your native OS launcher, etc), and because that's where the people are in the world we live in today.
Eventually we might consider wrapping it in electron or equivalent, but that's just a question of packaging.
Picking up on the maintenance burden here: Is there library support (or documentation) for the underlying stuff?
Say, is there a way to go to your Github page [1] and grab a project that allows me to a) build a client (I think that's possible) and b) link clients just like the browser?
Could I create the world's ugliest native client, connecting to the Signal network using my (phone's .. hrm..) identity? Is that a scenario you support (in general, not with office hours..) or would consider if it isn't possible today?
You can get the chrome client from Github. That enabled one to circumvent the private beta until this announcement. There are no proprietary parts in the app store version.
Thus you should be able to make a native client just as well.
Any reason you didn't just go with Java? Java isn't my favorite, but shipping "apps" as entire web browsers under some handwaving is a dependency mess and massive bloatware. Too late now of course, but curious if there is some big advantage over the more obvious options that I'm not appreciating.
Not parent, just my own negative views on electron:
1. Massive download for a simple app. 37M is a lot of data.
2. Massive download for every simple app. It would go a long way if every electron app didn't have pull in a full 37M, and could share a set of common libraries. n*37M is a lot of data, and this is one strong reason I like this Signal Desktop release.
3. Battery unfriendliness. Even when idle, every Electron app does a lot under the hood that isn't even related to the app itself. This is the cruft of having a full web browser and an advanced JS VM, but it is a cruft regardless, and it is very disheartening when reduces a ten hour battery life to six hours.
Java comes with adware on the platform with the worst java installer. It's slow to install and forces you to actively deselect adware, but there's a Windows tool that can do that for you and there are package managers and app setup bundles. Installing Java on Linux and FreeBSD is very simple and fast.
Qt these days needs at minimum 30MB for a simple window and that's a huge overhead for basically a hello-qt app.
But Qt isn't as bloated as carrying around another browser.
Slack is a web app too, it doesn't hold it back at all.
Chat apps really don't need that much and the cross platform benefits of making a standalone webapp is numerous. Also being a chrome app means it can run on a chromebook, one of the most secure desktops out there.
And it being open source makes it you probably could make your own native clone implementation if you were really so inclined.
I _think_ (correct me) you might think of the Android app's dependency on the proprietary Google services.
As far as I'm aware, Signal doesn't run without GApps on Android by default, exactly because of the GCM dependency (but you seem to be able to dodge that with the help of the microG project).
Plus one for a desktop client. I do get the idea of a chrome app (firefox would be better imo) though as it gives you windows/mac/linux coverage in one shot.
When it was at an earlier stage of development, I tried out porting the Chome App over to NW.js (formerly node-webkit). It was easy enough and the result worked fine. I'll have to see if this is still the case.
Why doesn't the title of the announcement indicate "for Chrome? Is there a reason not to mention the release of such an application for other Web browsers, like Firefox?
It's a Chrome packaged app, not an extension. It integrates with your OS to function just like any other stand alone application (visible in your native launcher, etc).
For a moment I thought you meant that this is similar to say Atom: It's an application that just happens to run in a browser engine.
The link in the article points to [1], the Chrome App Store.
That in turn presents me a button 'Available on Chrome' and wants me to download that dreaded thing (the browser itself, not some Signal-Using-Chrome-As-Shell bundle) [2].
I admit I don't understand what a Chrome packaged app is, but it seems to require a normal installation of Chrome, going to the 'Chrome App Store' to finally install Signal.
That's probably what the OP (and others here) try to say: This isn't a desktop app, it requires an installation of Chrome and then might act like a desktop app if you install it that way, right?
Correct, you need to have Chrome or Chromium (if you want something fully OSS) installed. Once you do, it functions like a native app (integrates directly with your OS's launcher), rather than like an extension (something attached to a browser window).
We might consider distributing it via something like electron in the future, but that's just a matter of packaging.
The Chrom(e|ium) name is tainted for me and while Electron is Chrome I'd be less hesitant to install an 'application' than something that might want to be the default browser or end up being launched by guests / my family.
You explained at length on HN that the target demographic doesn't include the random nutjob like me, and I understand that the average person doesn't care (or runs Chrome anyway already): I'm not trying to say that this release, this work is bad - I'm just trying to explain why I'm not putting on my party hat just yet.
Retroshare is desktop only, Signal is mobile first.
If you posted a Retroshare thread, I might say "Not worth the time. Use OTR instead."
Signal is also significantly easier to use, and to the novice appears to be any other text messaging application. This makes it much easier for non-technical people to adopt.
If you install signal on your phone without google play it will magically stop working with no warning after some delay (6 months?) leaving you without communications ability. It was especially irritating when it cut out mid-conversation leaving me unable to tell the far end why I was unable to respond further, or get help getting a new package built.
Pretty lame. I wonder if the desktop software also has this kind of logic bomb anti-feature?
Do you mean integration where Signal could integrate the SMS messaging (or similar functions)? Just taking a stab in the dark, but that's not (afaik) something iOS allows.
Edit: Duh, you mean to pair it with like you do now via QR code from an Android device. Sorry, gotcha.
Chrome is just the framework. Would an application written in Qt or .NET count as a "desktop application" by your definition? Chrome seems like a pretty sensible choice for a team with limited resources considering its portability and large existing install base.
I've recently been coming across some strange message sync issues with using the desktop client on two different computers. It seems like they'll go out of sync, and not all received messages will arrive. Sending works sometimes, but I won't see the "received" checkmark. Re-pairing isn't enough to fix it, I need to delete the Chrome app to clear the history and re-pair. Anyone else coming across this issue?
I don't use a smartphone, but I think there's an old android phone lying around my apartment. Could I use that to set up this desktop version and then never need to bother with the smartphone again? Or would you need to use the phone pretty regularly?
It sounded like robto uses a "dumb phone" or has some other method of accessing the PSTN (land line?). You don't need your smart phone to receive the verification directly, you just need to be able to get the verification to your smartphone
Is there a way to start Signal directly without starting Chrome/Chromium beforehand? I have Chrome/Chromium installed, but do not use it. I want to use only the Signal desktop webapp.
Why all the negative responses here about it being a Chrome app? If you're paranoid about reliance on the product of a PRISM partner, I understand. But in that case, just quietly don't use it. Why shit on work done by Moxie and his team that is helping to mitigate dragnet surveillance?
The desktop app doesn't show a lock key icon in the message bubbles, while the Android app does. I never quite understood why the Android app clutters the interface with that icon since, I assume, _all_ messages are end-to-end encrypted anyway.
The Android app also supports standard SMS with non-Signal users. Those messages are not encrypted, so they show the lock to indicate whether the message was sent via Signal or SMS.
NSA sends drone strikes on people and villages based on metadata. How do I use Signal without exposing metadata to Google? It's metadata what counts, not content. So why hide context and purposely expose all metadata to Google and NSA?
Nobody figured out how to hide meta data yet given the requirements.
P2P is not practical on mobile, because it eats your battery and data plan. Thus, client-server is a requirement. Federation is a problem for non-technical users, because it makes the app more complicated.
Also, I want to see proof that federation is a problem for users, because most people seem to handle email addresses just fine. The resistance to federation is primarily from users, it's from business that want to control a protocol as middle-men.
> it makes the app more complicated
So? Federation is necessary. Leaving it out simply creates yet another centralized solution that can be targeted by businesses and/or governments. Saying "Security and freedom are complicated, so we left that feature out" is not a solution.
Teaching people is incredibly hard and usually does not work. For years and years we have tried teaching people about gpg and it has done nothing.
Its also incredibly difficult to make federation work, amd even harder when you want to hidemeta data. I am sure OWS would love to develop solutions for all of those, but they simply do not have time for it, not because the want to protect their costumers.
Its opensource, and you can send them a pull request where you solve federation. Currently you sound like an intiteled brat who does not understand the concept of time constraints.
You're moving the goalposts. Teaching people that their chat address has a @hostname component just like their email is easy.
(and gpg just needs a nice GUI front-end that makes the common cases trivial)
> [it's hard]
Yes it is. What you don't seem to understand is that this isn't a reason to create yet another centralized solution that promises more than it can deliver. So far every centralized communication service with true privacy has ended up either exploiting their users privacy, sold to people who don't care about privacy, or strong-armed by various powers. If you don't build in mitigation to this problem from the beginning, it will never happen.
> incredibly difficult to make federation work
This is complete nonsense. It's another feature that has to be taken into account, but it isn't harder than any other feature. (I would rate the crypto ratcheting protocols as "incredibly difficult" to get right, not federation)
Again, if this isn't built in from the beginning, it will never happen.
> Currently you sound like an intiteled[sic] brat
Insults are rarely effective rhetoric.
> who does not understand the concept of time constraints.
I've been designing and implementing network protocols for about two decades, so I'm very aware of what's involved. I'm suggesting that protocols are hard to change once implemented. If federation isn't designed in from the beginning, then this is just another centralized system that is destined to fail. Pursuing the wrong goal is not a good use of time.
I don't just mean in getting federation to work. I mean building a good network that is response to updates and adding features. A network that does not make further devlopment almsot impossible.
> If you don't build in mitigation to this problem from the beginning, it will never happen.
I would disgree about that. I think an incremental approche can work. I guess we will see about that.
Ideally everybody would have home servers. My server would be what my phone connects through for everything, and the server would deal with anonymization over P2P networks when necessary.
Depends on what you mean by 'ideally'. That approch would not be ideal in terms of resources and time wasted. It would also not be ideal in terms of how well such a system would work.
One could also go one step further and require everybody to host a tor hidden service.
I think federation with advanced metadata hidding would be great and that should be the goal, but the idea that everybody runs a server would not be part of my goal.
Well, it all sounds nice in theory, but nothing is that easy in practice. People don't have computer that are always one. Do you want to run it on peoples routers? That will be hard/impossible.
Even if you imagen that everbody has their own server, they would not have very good uptime. What do you do with the messages? Updating potentially millions of server to new version of protocol is hard. Devloping a protocol that is both backwards compatible and secure is very hard.
Just look at Bitcoin for all the problem peer-to-peer networks have. Something as simpel as chinas firewall causes a hole lot of problems.
I would really like to see federation, but even then I don't think 99% of users should run their own servers.
Multiserver federation? The user's own server is the primary one, with a 3rd party one used as a backup. Much of this can be solved with delegation of tasks.
I just dont see any reason why every user should run their own server. Is a waste of resources and time. It makes everything harder without all that much gain.
Do you have your (physical) mail sent "general delivery"? Or do you have it sent to personal mailbox a specific address?
It doesn't how much it costs[1] in resources. It is important that people have their own place that they control on the internet. You are insisting that everyone stay subservient to a central authority. This means they need an imprimatur[2] to communicate.
This centralization has happened because NAT is a "party line". The lack of addresses has removed the most important feature of the internet: every host is equal in the protocol. If you have an internet address, you can publish without the permission of a third party. I'm not saying it is easy, but the power of the internet is that publishing just takes a bit of learning and effort, not the permission of a central authority or other gatekeeper.
You seem to be focusing only on various technical features in your analysis, which don't actually matter. This isn't about efficiency or ease of development. This is a question of freedom: is a technology giving people more freedom, independence, and power? Or does it create another layer of middlemen with power over a fundamental feature of society?
You need to decide which side you're on in that fight, because there is "no neutral ground in a burning world"[3].
[1] It isn't going to cost much; small serves are cheap and getting cheaper all the time. By definition we're talking about something that would have the benefits of mass-production.
All mailbixes are actually grouped together. I have rented my apparment and i have very little control over the mail box. Its much more like federation then it is like peer-to-peer.
In the modern world you have control of almost nothing. You always rely on a huge number of profiders. The importent thing is that their is competition and that if you are unhappy, you can do it yourself. Thats federation, a model that scales and has at least the potential to compete with centralised systems.
Peer to peer is incredibly hard. I would love to live in your fantasyland, where NAT does not exists, everybody runs cheap linux servers that are always up to date and reachable, even of they are behind shitty ISP provided routers. If you want to spend your effort on solving these problems, more power to you. People like Gnunet are doing a fantasic job at proiding a basis for a truly peer to peer system that is secure.
I prefer to deal with the reality and advocate solutions that have at least some chance of actually working. I am happy to host a number of services for my friends and familly, and I happly federate with others. I will hover defently not go out and tell my parents that they should go out and buy and run a freedom box.
Happy that it's public now, I'm a regular Android Signal user and was waiting for this. It seems to work fine, my desktop and phone messages are in sync.
Are there 3rd-party implementations of OpenWhisper or a complete and detailed spec, so that others can build clients more fitting their (integration) needs?
1- it's beta
2- it's built as a chrome packaged app, which means it runs on all platforms regardless of what smartphone OS you use.
3- it's beta
4- it's okay.
