A non-profit foundation with $50 million in the bank dedicated to providing usable encryption to the general public, with no other agenda other than the public good.
Go read the blog post by Moxie and Brian Acton (who is joining Signal). Very exciting!
I know Moxie's position on federated protocols , but I think we must eventually agree that an open environment with a multitude of providers and implementations is the only way to provide long term privacy - any single provider is vulnerable. It would also be a very useful tool in the context of regulating communication platforms and breaking up monopolies.
Edit: emphasize federated, not open, Signal is indeed an open protocol.
OMEMO in particular uses:
- Personal Eventing Protocol (PEP, XEP-0163) to transport key material; and
- core RFC3920/RFC6120 XMPP protocol to transport encrypted messages.
Both of which are already supported by Openfire [see JM-1122]. So, as far as I can tell, Openfire is fully capable of delivering OMEMO messages right now.
[EDIT] For Adium OMEMO support, have a look at Lurch: https://github.com/shtrom/Lurch4Adium
Obviously this is just one side of the story, but it sounds rather alarming.
> We haven't patented any of the concepts here, and we've done a lot to explain and popularize them. We're happy for people to use these concepts to build their own implementations of similar protocols, but we don't want people slapping things together and calling that Signal Protocol.
That doesn't debunk anything in the blog post - it reinforces the point that moxie doesn't want any third-party implementations of the protocol.
"did", I think. I don't know which distros still run into this, but Debian now ships Firefox (RIP Iceweasel).
It's like bike shedding of security, where Moxi focuses on the things he can do but for the systems where it doesn't matter.
Are you broadening “insecure” to mean “centralized, opinionated security architecture designed for tech-illiterate masses that I don’t like?” Because that isn’t what it means.
I trust my phone a hell of a lot more than any general purpose computing platform, and I’d say the same if I owned any number of a significant collection of Android devices. This isn’t phone vs. phone advocacy, just annoyance at opinions that people disingenuously consider factual, useful observations on security.
Interested to know how that amount compares to other OSes, I really don't know what the going rate is on Windows/Linux.
There are very logical and reasonable reasons for them to advocate publicly. Not everything is a conspiracy.
Like matrix? That uses signals encryption.
"Metadata concern is bogus" yet the linked documentation explicitly says bridges expose metadata, and that home servers expose metadata.
One advantage of Pond-hybrid is "Supports any and all Matrix clients via the existing standard client-server API". This means the issue is desire to remain compatible with insecure clients. This is lack of agility is not needed.
I hope you fix things before it's too late and focus on Pond or other Tor hidden service based communication.
* A server-based system gives you a well-defined secure place to keep an always-on copy of your data, with whatever physical/geographic/network security model you prefer... rather than smearing it across a bunch of handsets or laptops which could get lost/stolen/run-out-of-storage etc.
* Thin-client protocols like Matrix or XMPP are going to typically use way less battery and bandwidth than maintaining a full p2p mesh on a mobile device, which is generally desirable. The way to fix that in p2p is to introduce master nodes of some flavour... at which point you're back in a hybrid p2p/federated architecture again.
* A thin-client-first approach also means that you can easily support different clients (and bots/bridges etc) rather than the client being tightly coupled to a complicated p2p protocol.
To repeat: i'm advocating a hybrid p2p/decentralised approach - not religiously pure decentralisation, nor religiously pure p2p either.
> "Metadata concern is bogus" yet the linked documentation explicitly says bridges expose metadata, and that home servers expose metadata.
My point was that in the medium/long term we have a clear route to avoid having to expose metadata on servers.
> One advantage of Pond-hybrid is "Supports any and all Matrix clients via the existing standard client-server API". This means the issue is desire to remain compatible with insecure clients. This is lack of agility is not needed.
You're missing the point. There's nothing insecure about the clients. The whole idea of the PDF is to spell out that you could swap out a federated server for a local p2p-based server (perhaps even running in the client) whilst reusing all the same clients... which now magically become p2p (if desired). This agility is very desirable indeed, given the huge amount of effort which has now gone into writing good Matrix clients like Riot, nheko, Quaternion etc.
Yes. It's hard to get too excited for the 'expansion' of Yet Another Walled Garden. I say this as a long time user of Signal. It's currently the lesser of most evils, but it still has a lot of room for improvement.
However, there are issues with federated protocols beyond the velocity issue that Moxie mentions. Some of them are technical and some of them are not (see conversations.im comment on doing xmpp notifications on iOS for example), but they do exist.
The Signal protocol is public, but not open. It is a proprietary protocol which is controlled entirely by the company behind Signal.
See also: Adoption failure of Google Talk XMPP, massive adoption of Facebook Messenger and Whatsapp, and AIM before it.
I wish it were different, too.
You might say it is fundamentally easier to build closed systems and entice users to adopt them, but that's a business aspect not a user preference. Exactly the type of business that's of interest to regulators.
Do people want federation enough to have to take a principled stance in order to force change? Heck no. And that's the problem: there's no reasonable way for their desire to impact the producer side of the market. Can't vote with your wallet since public IM service is universally free, plus network effects are strong.
Users are being worn down, too. I remember when Pidgin, Adium, Trillian, etc were rather popular. Now most people don't even use those kinds of consolidation apps either, and resign themselves to literally running many separate apps.
This is a crazy mess we got ourselves in, and there is no easy fix. Time machine to 1980 to get a standard out before ICQ, maybe.
IMO that is really one personal hell for me. I blame android and apple for this. I was happy with my N900 where you got one chat application that supported SMS, Skype, XMPP, AIM, ICQ, whatever. The world was so simple back then.
Now everything has to be a separate "app", where previous there where just plugins. Such a decline in usability.
Some of these protocols are open, some are reverse engineered. Problem with the current generation is that they're focussed much more on security features such as E2EE. Although before GAIM, we had other applications which did multiple protocols we also had loads of single purpose applications for all these protocols you mentioned and a whole lot more. Back in the end of '90s if you wanted to run MSN and ICQ and AIM on Windows, you had to use a client for each of these. Its basically a cat and mouse game. Look at the history of the Skype support for an example of that.
Except that they don't; they mostly use Facebook Messenger, iMessage, and Whatsapp. Those that do use email use gmail, which barely federates (most gmail users never see messages from my personal email address, because google routes them to spam despite my IP never having spammed).
If your choice as a user is to buy an iPhone that can communicate with your Apple friends over imessage and Android friends over hangouts, or buy an android phone and not access anyone through imessage, there's an advantage to Apple there. Google just decided to level the playing field (if slightly) by privatizing the hangouts protocol, and we all lost out a bit because of it.
Federation isn't something most people even experienced throughout all that, so it's hard to think it was factored in, even a few times removed, from their decision.
We haven't seen users forced to do much of anything. In general, there's multiple ways of achieving their goals. They almost always pick either a proprietary company that likes lock-in or a free, ad-driven solution that sells them out. They neither take time to understand the consequences of that ahead of time nor cared enough to switch in the years I've explained it to hundreds (thousands?) of them. Very, very few would switch. And for social media, it's usually a network effect they're joining where stadiums worth of people would have to switch at once or close together to avoid chicken-and-egg problem. They could collectively use open standards to communicate like open-source IM and buddy lists but most don't given they'll sacrifice control of their data and privacy for convenience.
There is a market effect like you describe where the suppliers benefit from lock-in. That's been steady a long time with even the open standards often intended to catch new customers in lock-in in other ways. On the demand side, though, the masses haven't used open-source as a factor in their purchasing much at all. So, it's not even a differentiator on their end for most suppliers to target. The market didn't even adjust: it defaulted on lock-in strategies for owners' benefit with companies occasionally experimenting with other methods they sometimes reversed.
Well, it depends on how you want to interpret forced. Sure, they aren't required to use a product, but if you've been using Gtalk for years, and that's how everyone knows to get hold of you and how you get hold of people, and it's an open protocol (XMPP) which you can and do use through a third party client (e.g. Pidgin), when they switch to Hangouts you are forced to use their proprietary client and protocol if you want to keep the same contact list without making everyone switch. It's not strictly "forcing", but Google is exerting force to drive customers to a different usage.
I'm not sure any centralized IM service that expected to compete would have done different and survived with any appreciable market share, but that the ones that existed switched is notable.
> On the demand side, though, the masses haven't used open-source as a factor in their purchasing much at all.
The benefits of an open system aren't readily apparent to many people until they start experiencing the problems of a closed system. Closed systems have numerous benefits at the starting stage the open systems don't (for example, a clear way to monetize that works in line with people's expectations and human nature). We were lucky with the internet because it was federated by design (and necessity, pretty much), and grew to the point that it would be too costly to close the protocol before gaining too much popularity. Even so, we're seeing pushes to in that direction. Maybe when the problems of the closed IM systems become apparent enough, we'll actually have some more widespread adoption of open systems. WRT human nature and systems such as these, I'm not sure we've even seen full cycles of how people perceive and deal with the systems (we're only now really having a sizable group of adults that have always had the internet WRT the population as a whole), so a lot of how people deal with open/closed systems over time is still in flux.
P.S. Long time no see/read. Nice to have a conversation with you again. :)
There's the problem right there. They created a dependency on a single provider that could turn on them at any time. Many providers have gone out of business or done unscrupulous things. One should always have alternatives if anything is really important. In this case, they usually solely rely on one provider for convenience when not also cost (sometimes trivial cost). Still true for things like Facebook.
They walked right into a big problem because convenience or apathy about risks trumped everything. From there, they can be forced in the way you describe to go along with what vendor wants. At that point, they might also start switching and/or avoid doing that sort of thing in the future. In many cases, they avoid the switching cost and do the same kinds of things in other services. Their very nature is to willingly create opportunities for suppliers to cause them problems.
Even as they do this, there's a small subset of the market doing either the opposite or taking steps to limit the damage which make me think this is more willing than forced. If anything, history has shown we have to use things like regulations to force market participants to behave more safely on average. They usually don't do it on their own because they don't want to or don't care. Seatbelts when driving are the classic example.
"The benefits of an open system aren't readily apparent to many people until they start experiencing the problems of a closed system."
I agree. We probably need a way to quickly present that when they make these choices. Enough of the market making an informed choice might sustain more alternatives that are better. This already happens with at least some of the FOSS market where the buyers specifically liked the benefits of open source. The wider, long-term effects you describe will also be interesting to watch. We might see some of the FOSS-friendly decisions on consumer side as they see the benefits or experience the detriments.
"Long time no see/read. Nice to have a conversation with you again. :)"
Likewise, buddy. Although I comment less, I've read plenty of yours. Usually insightful and enjoyable. :)
Well, or just lack of knowledge, and lack of knowledge about lack of knowledge. I think from our positions it's easy to overlook that. Sure, it seems like people are becoming more technically literate, and they are, but I think when it comes to knowing what you can do, and knowing what you should do, the latter comes well after the forming in almost all exploratory loarning (which internet usage mostly is). We've heard the historical stories (myths), that impart this knowledge. Usually we've lived a few cases of it as well. Even then, it doesn't always take right away, or we get caught out not heeding our own advice. I can't fault a largely novice internet populace for not having had the same conditioning we have.
That doesn't mean they are off the hook though. You're right, there's a shitload of ignoring the signs in favor of convenience and general apathy, it's just not the entire story.
> If anything, history has shown we have to use things like regulations to force market participants to behave more safely on average.
I agree with regulations. I just vastly prefer them to target the specific problems and not try to get too complex with mechanics. Sometimes that requires really looking into the problem, and it can be a hard sell if the general audience for choosing/voting the implementation doesn't have enough knowledge. In this case, I think a lot of the problem all stems from using personal information as currency. Strong regulations on the collection, notification, maintenance, and ability to force removal of personal information by remote entities would make what the real cost is of the systems obvious (you know what they collect and how it's used, or in some cases you know what actual money you pay since that will become a much more viable model again). Open source cometes well in that market, because the actual costs are all apparent instead of hidden.
> We probably need a way to quickly present that when they make these choices.
I have hope this is a problem that will be mostly solved through the normal way societal best practices are passed down, from mentors (parents, teachers, trusted authorities). We just need to get to a point where the mentors actually know this stuff, which requires time and them being bitten by it and learning the hard way, or reading about those stories, or eventually learning it from their mentors. When your Mom or Dad is usually the one that cautions you at an early age to beware any free service that might be trading on your personal info, we've reached a good equilibrium (but we'll still have issues with those that don't have as much access to mentors, which is a constant societal problem).
This is off topic but very briefly: implement SPF and DKIM and get a number of Gmail users (I'm not sure what this number is, but it is order of magnitude 10) to mark your emails as "Not Spam". Eventually Gmail will come to accept emails from your self-hosted server.
Two channels which have become saturated with spam and junk once the federated network starts to include players who are willing to permit bad actors to access the network in exchange for money.
People enjoy federated networks of regulated, good faith players; wide open federated networks tend towards anarchy.
Like... email and the phone system? both of those have huge amounts of bad actors and spam, and people still use them as primary means of communication. Email and phone are generally expected to be more reliable, I think, than any of the walled garden communication protocols.
(Speaking of, if you have ideas about curbing phone spam other than keeping the number secret, do let me know.)
Really? Even internal company phone systems have largely switched over to walled garden voip or videocalling systems in most places I've seen. Nobody calls anybody any more - the only use of phones I see is for dialling in to conference bridges. Email is used internally within businesses.
What do people really still use public phones and email for?
It's interesting, because I always felt that a SMS was way more 'urgent' than an instant message over AIM, but... most of the adults in my social circle, even those I knew from back when we all used AIM, no longer are on any instant messenger services. They have sms (often, but not always through imessage) and they have email. Then they are on their various social networks, but everyone I know checks email more often than their social network accounts.
My impression is that inter-company communications all go over email and public phone. Intra-company,of course, you use the company's walled garden, if the company is large enough to dream of forcing the world into their garden (as most of the companies I've worked for lately have been.) but even so, interviewing is conducted through public phone systems. In fact, even when I'm interviewing a candidate on behalf of my current employer, half the time the connection between the internal walled garden voice system and POTS is so bad I end up using my personal cellphone. Silicon valley companies are serious about 'dogfooding' to the point where actually doing your job sometimes feels like a secondary concern. Smaller players tend to use existing technologies, and so more often use federated systems.
I have worked at smaller places, earlier in my career; I've even setup VOIP for one of those places, but it was still terminated to a POTS T1; it just used SIP lines and asterisk rather than a wired PBX, and they mostly used public email (I mean, their own email server, but it was federated email) - those are still federated systems.
I'm currently considering going to college; today, I scheduled a bunch of academic stuff, using the phone and email. If I end up locking myself into an institution, of course, then we will probably switch to using their walled garden, because they will have the power to force me to do so, but until that happens? we're communicating via federated systems.
Whenever I'm scheduling a medical appointment outside of my primary hmo? I use the phone.
My impression is that the walled gardens are mostly used in places where the relationship has been established, and one party is big enough to have built a walled garden system, and important enough to force the other party to eat the dogfood in question. Within my primary HMO, I use the proprietary 'secure messaging' application to communicate with my doctor. Within the company, I use the company's messaging system and screen sharing system.
My own conclusion is that forcing you to login and use my communications system is a power move; everyone is still dreaming of replacing email with something more profitable.
Android actually does provide some amount of filtering, but if someone, say, spoofs a seemingly legitimate number, it will come through fine.
Users don't want federation in a sense that they don't _care_ if it's federated or not. Not that they actively decide against it.
They only care if they can start chatting with people from their address book right after installing a chat app.
I don't care what users want. I want it!
That is the beauty in narcissism: You can use the best technology to chat with yourself. :)
Apparently WhatsApp still use xmpp, but afaik also never supported federation.
Aim didn't allow federation.
So I'm not sure what you're trying to say?
You could claim the rotting corpse of duckduckgo's xmpp service is evidence that users don't want federation - but I thinks more just an example of a mis-managed service.
[ed: the other two obvious examples of users do seem to want federation is the rise of irc despite many architectural flaws, and the continued popularity of email.]
Unfortunately they were the only major service provider to do so, and the capability was later discontinued.
"However, since the Google Talk Service does not support server-to-server encryption via TLS (something that was required by RFC 3920 in 2004), a number of servers (including jabber.org) refuse to establish a connection since May 2014."
I recall there were issues...]
Wait, what? You could chat from firstname.lastname@example.org on your bespoke xmpp server and send messages to user@gmail without needing a Google account and vice-versa?
Was Google talk really so unpopular that I didn't seriously try to use it until it became the walled garden that didn't support server federation?
For some glorious years between 2006 and 2013 (Hangouts), this was indeed possible. I run my own XMPP server and I used to chat with GTalk users all the time. For literally years.
> They didn't really support federation in a standards compliant way
It was standards compliant enough. In the original RFC, server-to-server TLS was mandatory to implement but not mandatory to enable/deploy. The XMPP community later moved towards enforced server-to-server encryption, but this was many years later and had little impact on GTalk federation during the time that it was supported.
Now I see that Ms allows federation for on-premise lync - but not for office 365. :-(
Everyone wants their own silo, and force their multitude of awful clients on people.
running your own smtp server these days is painful.
Email is obsolete.
I wonder if they're in contact or work with each other.
However they could go into more of a social network direction, the features are basically there.
The downsides are that it has a very cartoony 'silicon valley' type feel which is great for early adopters, but will be a significant barrier to enterprise and government customers who would otherwise be an absolute prime market for easy-to-implement, easy-to-administrate PKI.
It also has a very start-up oriented world view in terms of 'teams'. There would be great call for generic group management. I would love to have some stakeholder management across some projects where we could have a shared space, but also have separate areas for client, supplier and subcontractors. Keybase kind of doesn't quite fit the need for privacy there, although it is so close to being exactly what is needed.
Bringing it back round to the social networking thing though - it feels kind of like it was inspired a lot by social networking. This would be a boon if it were to become a social network. It is absolutely a downside if they're looking for a wider remit.
(Current version in repo doesn't automatically encrypt, but tests show it's straight forward).
I think that's the real power, the centralized authority of "you are X, with public key Y"
Using public social media accounts to help prove identity is a good idea - it's a solution to the main problem that PGP had.
I think Facebook could have done something similar by generating key pairs for all users and then allowing third part access to the public keys (basically a huge public key server). For users that wanted their own private key off of Facebook they could upload their own public key. It's probably better with the keybase model though and using multiple social media accounts.
I feel like once they want to role it out to companies its frailly easy to change these things.
> There would be great call for generic group management.
They have subgroups, so that's something.
Signal in comparison is very clear about their goals, management and business model, and I believe are 100% open-source. That gives me confidence to adopt it now, even though it's a less feature-rich product.
I would love to see Signal adopt the Keybase identity-by-proof model, I think it's very clever and pragmatic.
Sigh, trust is hard after the crypto wars.
As a heavy Signal user, from where I sit I personally see the following clear needs:
-Better group support. Right now, to do a group in Signal you have to name the group, which makes it kind of a pain to create ad hoc quick groups. I'm forever naming them "John Sue Bill" or "Jane Roger Amanda". iMessage, by contrast, just automatically makes a group without a name. You get a thread for that group, so you can follow the discussion clearly, and you can leave the group, but it hides the nuts and bolts of the fact that a group has been formed. Also, Signal has no per-group notification settings, so if you're in a "noisy" group your only option is to turn off notifications universally (including one-on-one messages and other groups) or live with it. Lastly, you cannot form a group from Signal Desktop.
-Better support for long messages (or a new product using the same network and security). Signal was clearly designed for short session lengths — brief messages that are composed quickly. But as it has become the catch-all app for encrypted comms — "just use Signal! PGP email sucks!" — many people, at least that I deal with, are trying to use it for email-type purposes. Long messages with arbitrary attachments. It would be nice if, like, putting a line break in a long message didn't mean hitting Control-Enter or Command-Enter. It might even be nice if you could have multiple threads with the same recipient. You know, like email. I am not holding my breath on this one. But if people could email as securely as they chat, using Signal protocol, it would be a huge leap forward in keeping the NSA out of our business. Not to mention Google/Gmail's ad clients etc.
-Ability to search. I can't full-text search my messages, even within Signal. As I use it more and more, this is a hindrance.
-Group video chat. This is very pie in the sky. But a lot of sensitive comms involve groups — think of people organizing a protest, or a corporate takeover, etc. And right now there are few private options.
- Real multi device support. I want my messages on all my devices, without having to have my phone on.
- An iPad app.
- A desktop app. I'd pay for a native one, without Electron.
These things are basically table stakes for competing with Facebook Messenger, Telegram, and iMessage. If Signal's goal is to bring encryption to the masses they have to solve things like this, since regular people care less about security and more about convenience.
I'm working on a native app that supports Signal, Slack, Twitter etc. It's only 90 KB (!).
*edit Signal support is coming in early March.
Like I explained in the FAQ, the plans and the potential are huge, and it would be really silly to risk it all just to become another data miner. Even if it's very sophisticated, and there's a 0.01% change it's found out, why risk everything? Besides, it's simply illegal. All the information about me and the company is public.
I wonder if you have the same concerns about other closed source software like Sublime Text.
This was an unnecessary personal jab, but I'll respond. Sublime? I don't use it. Software that deals with my credentials just like you do? Yeah, I definitely do. That's why I don't trust closed source password managers either. Text editors? Mine are open source so the thought has never crossed my mind. Other random software like my OS or Visual Studio? Depends; e.g. Microsoft is a huge corporation that has nothing to gain and a lot to lose from keylogging my passwords, but e.g. I wouldn't trust Facebook not to record my audio or fish out my contacts behind my back. Smaller utilities? Yeah, but again, they don't have my credentials at their fingertips, or need Internet access at all for that matter (I turn off auto updates so I can just block internet access for them entirely).
All of which is to say, yeah, I'm not picking on you specifically, but this isn't about me, or about you. I'm just a messenger. Verifiability is the requirement many people have for software that manages their credentials; pinkie promised aren't enough. For some of them, you can make up for some of it by having a big enough reputation to lose, and criminal history to jeopardize in their jurisdictions. For others, you can't. In your case, you don't seem to have that going for you either.
I was genuinely interested, and I expected this answer. This is a very valid point of view. I hope you'll use it once it's open-sourced.
I'm asking because high-dpi support on Linux/Wayland is constantly problematic for desktop applications that don't use GTK+ 3 or Qt.
I still hope they use some of this cash to make a real iPad and Desktop app, though. I'd really love to use the service but those are deal breakers for me.
After the initial linking process, Signal Desktop has always functioned independently of your phone being on.
Yes it has, at least on Android. Within a group, press the three-dots-menu on top and choose mute notifications. You can choose for how long they shall be muted, similarly to other apps.
Adding to your list:
- Working backups for text and media.
Yes pretty please! For Android, any kind of media (bulk) backup option would help, for example. (IIRC iOS doesn't even have plain text backup). This is affecting a lot of everyday common users who cannot move to a new phone (or uninstall and then later install again) without losing all the media in the conversations. Saving the media items one by one (and detached from conversation and context) is not the same and sometimes impossible due to the sheer quantities involved. And so on.
I know the resources have been really scarce but since this is hopefully changing now, this would be greatly appreciated. There's been some recent related work required for encrypted backups to work, though. Also see ongoing discussion, GH issue thread and possible implementation PR etc., for anyone curious. Alpha testing may help, too. (Me, I'm trying to find time and energy to help with this, but so far have only be able to grovel and complain). :)
- Improved export functionality on all platforms :: I should be able to export my chats in some readable format from any client.
- More clients :: I should be able to read my Signal messages within emacs.
- Support for non-phone-number identifiers :: I shouldn't need to purchase a new phone number in order to get another Signal account. I completely get how valuable this is in limiting certain forms of abuse, but it also limits certain forms of legitimate use (e.g. Haven).
- Better privacy for contacts :: I shouldn't be sending my contacts to Signal's servers. I don't trust Intel's secure enclave technology any more than I trust Intel's ME. There are ways to discover mutual contacts privately.
Such as? I don't have the URL handy but the Signal team did investigate the literature and known techniques for this a few years ago and found them to be nonviable.
Private set intersection (in which two Signal users compare contact lists to see which contacts they have in common, then trade Signal information for them) would work just fine.
I think Group Video would be interesting but I personally don't do video on Signal, nor did I have a hint that it supported this? I thought it was just audio?
Even so it would equally be amazing if they could improve the usage of a Desktop client and / or maybe allow for Tablet support? I don't want to run my texts through Google Chrome, I rather run them through a more stripped down Chrome (Electron, but it shouldn't be too much different!) that wont be randomly phoning home to Google or require me to open up a browser I rarely use outside of work.
I really would love to see Signal work without phone numbers at some point (email as an alternative would open up Signal for Tablets - really wish Signal worked on Tablets) but I may not know enough about the existing structure to know how feasible this is or isn't.
I think you hit the nail on the head about email though. If the Signal Foundation is serious about making encryption accessible by all I think their next big focus should be:
* Making something that allows table usage of encrypted messaging (wondering if they signed something with Facebook and Co that disallows Signal to run elsewhere?)
* Make email encryption painless and straight forward, whether they build their own mail client and plugins (please make this AND mandatory no exceptions) or they make plugins for all major mail clients, especially Thunderbird.
To go along with that-- Support for exporting group messages. I recently moved to a new phone. With the latest versions of signal on android, I had to export a plain text backup of my messages. The problem? All the group messages were removed from their groups and threaded into the individual conversations with the person who sent it. So not only did it ruin the group message, but it also ruined the individual conversations, too.
I ended up downgrading to an older version of signal, creating an android backup of the data and then copying that to my new phone.
I know many consider those to be annoying distractions, but in my experience stickers are the reason why many "normal" users prefer Telegram over WhatsApp.
This is awesome. Amazing what an excellent small team can build.
Too bad the Signal Protocol doesn't actually implement the double ratchet algorithm but a derivative of it that fails to protect metadata making the Signal Protocol leak metadata. Granted, it only leaks metadata leaked by the transport layer anyway, but this makes it pointless to implement the Signal Protocol over something like Tor, i2p or GNUnet.
How do you address the EARs (Export Administration Regulations) and ITARs (International Traffic in Arms Regulations)?
These regulations look like a tar pit to me.
Interesting to note:
>Publicly available software under the EAR, as under the ITAR, is exempt from export control. However, before strong dual-use encryption code is made publicly available via the internet or otherwise placed electronically in the public domain, exporters must provide the US Government with either a copy of the strong dual-use encryption code or a one-time notification of the internet location (URL) of the code. This must be done before making the software publicly available. Notification after transmission or transfer of the software outside the US is an export control violation
edit: More guidance on what's exempted from EAR is at https://www.bis.doc.gov/index.php/policy-guidance/encryption...
I hate these regulations but EAR and ITAR with respect to crypto seem to be concerned with the key length and algorithm. Over a certain strength the software using the encryption seems to be still treated as a munition!? I've heard of people who ignore this getting huge fines.
And any export to Cuba, N. Kora, Sudan, Syria, and Iran is banned by OFAC (Office of Foreign Assets Control). Yes, the very countries that need Signal the most are banned!
Hopefully I'm wrong and we are free of regulatory issues in the US so I'm asking a serious question here - how does Signal solve this problem?
And then still there is the issue of the OFAC banned countries list.
I'm hoping Signal's compliance can show other hackers how to also comply without hassle or fear.
> You must submit a classification request or self-classification report to BIS for mass market encryption commodities and software eligible for the Cryptography Note employing a key length greater than 64 bits for the symmetric algorithm (or, for commodities and software not implementing any symmetric algorithms, employing a key length greater than 768 bits for asymmetric algorithms or greater than 128 bits for elliptic curve algorithms) in accordance with the requirements of § 740.17(b) of the EAR in order to be released from the “EI” and “NS” controls of ECCN 5A002 or 5D002.
My research suggested they did not change the status of encryption products in general: it was a narrow set of them like mass-market, downloadable stuff that got that designation. They kept high-assurance security, tools for building secure systems, customized secure software, and so on classified as munitions needing a license.
What I can't tell you is anything about that process since I never asked for an export license for any software. Maybe it's easy as some people told me with no restrictions. They weren't doing high-security stuff that irritates surveillance states, though. There could be pressure on big companies or providers of strong stuff. There could be nothing for now but something down the road. It's kind of a black box for me from this vantage point except the parts where it straight-up says specific things have old classification.
I'm really curious what experiences any of you have had that made strong security products on hardened OS's you requested permission to export.
That cat is out of the bag.
Cat is quantum undetermined in my book - maybe someone from Open Whisper Systems, Signal Foundation, or the Freedom of the Press Foundation will share some wisdom.
They can just "ask" any of the softkeyboard makers like Swiftkey, Swipe (Rip), Hacker's Keyboard, Google, Apple, Samsung etc.
Mozilla has been doing a lot of awesome stuff and people keep forgetting that their direct competition and threat are Google, Apple and Microsoft, the world's largest tech companies. Mozilla basically had no choice with EME, but to comply.
When the majority of HN's userbase has been using Chrome for years, power users, nay, freaking developers which should know what EME means, when Chrome is approaching the monopoly of IExplorer, good luck selling your values to the general public, who don't give a shit as long as their Netflix stream ain't working.
Open Whisper Systems has been delivering the best encrypted chat protocol to the masses, their tech being used now in WhatsApp for example.
So you can be the naysayer, but IMO these foundations are building and releasing products with a measurable positive impact on the world, whereas most of us here don't ;-)
Edit: Wait, haven't installed anything yet, but I read the getting started guide. I have to sign up using a phone number? That throws all expectation of anonymity and thus privacy out the window.
src: https://news.ycombinator.com/item?id=11672199 (2016)
alternative: https://signal.org/android/apk (2017)
If you don't use it beyond the trial, it's like the public payphone option mentioned by another commenter - someone could take your number. But if you choose to get a paid account (which, among other methods, can be acquired using Bitcoin, Bitcoin Cash, or a prepaid gift card purchased with cash), then the number will be yours. JMP is probably the most anonymous way of getting a phone number.
1) what's your number, and
2) with whom you connect or communicate.
That is, there's still the danger of social graph analysis: "Oh look, this person's communicating with a known journalist!"
If the target use case was people that could reasonably do the job of limiting the information just the use of their devices leaked, it might matter. But the target use case is replacing SMS and the like, so it really doesn't matter (except that people want to pretend that the use case is something other than replacing SMS).
Signal wants to distribute a binary with a checksum. Once the checksum is different all bets are off, that's why it's not in F-Droid
Now the question is: (when) will this be supported by F-Droid?
 Scroll down for a big graph https://wiki.debian.org/ReproducibleBuilds
The real question is, when will Signal finally support it?
The end result is an app that keeps shooting itself in the foot and being beaten by Messenger and WhatsApp.
At the same time, maybe I don't want everybody who has my phone number to see that I am on Signal.
But it won't improve your anonymity significantly, unless you also use it over TOR.
Use a voip phone number if you want, you only need it to get started.
You need a phone number that can receive texts for the initial setup, but once you're set up people can add you by @username and never need your number. Stuff like https://www.textnow.com/downloads works just fine for the initial text. Once you have a single device set up, it messages your existing devices rather than sending SMS when you try to connect another device.
One of the main people behind Signal actually tried to spread a bunch of FUD about Telegram years ago, saying the crypto was weak, but it's really not. No working POC code was provided to decrypt anything, just FUD.
Protocol details here: https://core.telegram.org/mtproto They just released MTProto2 in the last year.
Group chats aren't end-to-end encrypted, and 1 on 1 chats are only end-to-end encrypted if you make it a Secret Chat.
(Actually I think Messenger might support E2EE group chats, but I'm not sure.)
Signal does not have that goal and have been shown by courts documents to not store the metadata.
I don't know what that means.
The downside to Telegram? I don't trust it - so even if any of the above we're true they're all subjective and in my mind not worth compromise.
As much as I hate fb, messenger is a pretty decent application.
I tried it with my friend some time ago and we just couldn't figure out in a reasonable amount of time how to add each other etc.
I consider both of us tech savvy and we have absolutely no trouble with other IM clients or more archaic stuff like IRC.
As I stated our entire family uses Signal across Android, IOS and desktop. That age range in our entire family group is 20s to 70s and I happen to be the only user who would be considered tech savvy.
We didn't have each others phone numbers in our contacts.
Manually adding by phone number didn't work.
At this point we just gave up.
I use prepaids because I travel a lot so my mobile numbers are just throwaways.
I'd rather not give _all_ of my contacts to an app anyway.
So there really should be a way to manage contacts inside the Signal client and add people via screen names or email addresses.
I agree that it would be nice to have another root artifact for using signal (screen name, email, etc). The one frustrating piece about Signal is not being able to use it across mobile devices.
However it needs to be considered Signal was originally securing texts via TextSecure. It didn't, fundamentally, come up as a Slack or Telegram competitor. So that design decision may make it feel "behind" in comparison. However, I'll again state that I don't trust the others. There's no way you could force me to use FB Messenger or Google (product here). Most complaints here are fundamentally still UI/UX, not privacy. And useable privacy was the original intent. Signal has that in spades.
I'm curious though; what happens if someone takes over your phone number? Eg. If the operator re-assigns a prepaid number?
The hype around Signal is insane to me considering this lack of basic functionality.
They've been able to iterate their protocol really fast thanks to it not being an RFC or something.
And FFS, it hasn't even got anything to do with protocol, it's something the client can do by itself. Having worked on secure messaging apps, I would never go to federated protocols. Signal's infrastructure allows rapid improvement of protocol and fast elimination of insecure protocol revisions. That's where we need to be at. Just look at the history of TLS and the potential in downgrade attacks. Old revisions die slowly. Signal can easily monitor what versions are still running, push updates to users and ensure codebase isn't bloated by code that merely represents insecure protocols.
Signal succeeds because of it's "closed" ecosystem, it doesn't suffer from the tyranny of the majority that occurs when there's disagreement about e.g. seriousness of some attack, when some feature might be risky. With Matrix, I worry developers of clients can affect choices, and the protocol is already dangerous, to ensure (backwards) compatibility with older clients and (other) protocols, Matrix is not end-to-end encrypted by default. I will eat my hat with mustard the day I see all Matrix clients support only end-to-end encryption for everything.
> Early on, I thought we’d federate Signal once its velocity had subsided. Now I realize that things will probably never slow down, and if anything the velocity of the entire landscape seems to be steadily increasing.
> You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run. If you think running servers is difficult and expensive (you're right), ask yourself why you feel entitled for us to run them for your product.
1. That can be minimized to the system tray.
2. That can be used when behind an http proxy server.
3. Doesn't require a phone to use.
4. Doesn't take 200MB ram to run.
Tray support behind command-line argument: https://github.com/signalapp/Signal-Desktop/pull/1676
Proxy support behind command-line argument: https://github.com/signalapp/Signal-Desktop/pull/1878
Signal would only need to make a small profit to keep it sustainable and that would bring down the handset retail cost pretty significantly. It would be like the Raspberry PI of phones.
Signal guys: if you are toying with this idea, hit me up (email in profile), I've put way too much time into researching how to do this as quickly and miserly as possible.
It may be something this simple that is holding it back from adoption.