Signal Desktop beta now publicly available
whispersystems.org
whispersystems.org
* You can use Signal with any phone number that can receive voice calls: http://support.whispersystems.org/hc/en-us/articles/21319067...
* 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. :)
Agreed. It was even point number one in my list of commentary:
> * You can use Signal with any phone number that can receive voice calls: http://support.whispersystems.org/hc/en-us/articles/21319067... [0]
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.
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).
To me, it's the opposite, and makes Signal less secure.
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.
The messages are being synced automatically between chrome client <> mobile clients, which is the key feature.
[0]: https://www.whispersystems.org/blog/signal-desktop/
[1]: https://freedom.press/bundle/encryption-tools-journalists
See:
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.
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.
Moxie has already given me secure communications and free text, media and voice messaging the world over so I can't complain too much.
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. :)
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.
[1] https://developers.google.com/cloud-messaging/
Edit: clarity, typos
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.
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?
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.
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.
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.
A typical native IM app can add an icon to the system tray, allows opening each conversation in a separate window and supports flashing said windows.
Do consider writing it in Qt 5.
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).
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.
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.
Not worth the time. Use Retroshare instead.
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?
1: https://chrome.google.com/webstore/detail/signal-private-mes...
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.
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.
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.
Edit: To clarify. It can't be paired with an iOS device yet.
Do you mean OSX? If you really meant iOS, the Signal app has been available for iOS[0] since July 2014[1].
[0] https://itunes.apple.com/us/app/signal-private-messenger/id8...
[1] http://www.techrepublic.com/article/new-signal-ios-app-allow...
edit: spelling
The perfect is the enemy of the good.
Think Apple Messages blue versus green.
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.
Then teach them so it isn't a problem.
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.
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.
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.
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.
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.
[2] https://www.fourmilab.ch/documents/digital-imprimatur/
[3] https://media.ccc.de/v/30C3_-_5491_-_en_-_saal_1_-_201312272... http://opentranscripts.org/transcript/no-neutral-ground-burn...
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.
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.
> you can send them a pull request
I still might.
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.
That just seems rushed and lame.
It requires that you install the android app first.
The just say (android only currently) - don't advertise it as a "desktop" app BEFORE disclosing this piece of info.