My biggest problem with messaging applications as a whole is that I need
so many of them. I have a few contacts who are reachable with Signal,
a few more who are reachable on Hangouts or whatever Google is calling its
latest thing, and a few more who are reachable with Skype. That's three
programs, to communicate with three different subsets of people.
I'm sure if I used Facebook Messenger and Whatsapp, I'd have two more
subsets of people who are only reachable through those.
XMPP was supposed to solve all those problems when it came out in the early
2000s. But then all the big tech companies who build "ecosystems" decided
to push their own applications, all incompatible with one another. So
here we are again with this proliferation of programs that really only
do one thing: communication. It's like the 90s / early 2000s with the
proliferation of instant messengers: ICQ, AIM, Yahoo, MSN, and on and on and
on.
The players are different, but the game is still the same.
I suspect that twenty years from now, when the players have all changed
yet again, there will still be one reliable method of reaching me: IRC.
If the Googles and Whatsapps and Facebooks of the world had been around
in the early 90s, you'd have one email client from Facebook for mailing Joe
and Fred, an email client from Google for mailing Mary and Jane, and an
email client from Whatsapp for mailing Alice and Bob. Thankfully, email
became entrenched before that could happen.
I want messaging to be like email, where I use one and exactly one program
to communicate with all of my contacts, regardless of what server they use.
People say that federation is more complicated than centralization. I'm
sure that's true for developers, but in fact, federation can be vastly
simplifying for an end user.
I'm a fundamentally lazy person. Having to learn all these different
messaging tools is frankly a waste of my time.
All I want is a federated protocol and an open system, be it Matrix, XMPP,
or something else.
As a final aside,
you know what else that bugs me? The word "ecosystem". I worked for
a big tech company for a while, and the only people I ever heard use that
word were people out to build a walled garden.
> XMPP was supposed to solve all those problems when it came out
That's also what Matrix said it would solve when it started. Except now it's yet another protocol with its own chatrooms that are not reachable from any other protocol by default (even rooms on matrix.org); and bridges are at best in "beta" (except the Telegram bridge, which is "late beta"): https://matrix.org/bridges/
We tend to be pretty conservative on maturity estimates on Matrix (and bad at keeping the website updated).
IRC, Slack, Gitter bridges are all considered stable these days.
XMPP, Discord, Telegram, WhatsApp work usably too.
The UX for managing them is not always great or consistent (we’re working on that currently), but “yet another protocol with its own chatrooms” is untrue. You can certainly access the entirety of Matrix via Bifrost (the XMPP bridge) if you so desire, for instance.
Hi, I am trying to write an article in French to introduce Matrix to a wider public. Especially non tech people.
So I'd like to describe the possibilities accurately. Bridges are a very interesting feature, but how do you implement them ?
I went to the #whatsapp:maunium.net room and only saw guys wondering the same thing with no answer given to them.
I went to https://github.com/tulir/mautrix-whatsapp/wiki/Bridge-setup and understood they have to be implemented from the server itself ? Is that right ? So as a basic user I can't really make any adjustment on my side to join a Whatsapp group from Matrix, right ?
Regarding Bifrost, it's the first time I hear about it. I'm glad it exists.
Is there an hosted instance that allows me to access Matrix rooms without installing anything other than an XMPP client? I can't find any info about it other than the code repo.
The IRC bridge shouldn’t restart that frequently (and we’re in the process of decoupling the irc connectors from the bridge itself so we can fix bugs in the bridge without bouncing all its connections). Membership should categorically be synced correctly - if you ban a Matrix user on IRC their Matrix side should be kicked out too. If not, it’s a bug and we need to know the details asap. The only scenario I can think of here is if the matrix server was lagging on handling traffic, but that shouldn’t cause a desync like this either.
For bifrost; we used to run one on matrix.org but temporarily stopped due to lack of ops bandwidth. There’s a community one somewhere though - come ask in #bridges:matrix.org about it
I have lots of warm and fuzzy feelings toward Matrix, but my take is that
XMPP solved my basic problem over 15 years ago. The problem being:
I want to talk to Alice, Bob, Mary, Jane, Fred, and Joe without having
to install ICQ, AIM, and Yahoo Messenger. Or should I say Facebook, Whatsapp,
and Signal? I don't know what Matrix buys me over XMPP, but at this point,
I don't care. I'll gladly drink the Matrix kool-aid, as long as it solves my
problem and somehow ends up being the clear winner among federated protocols.
I don't think XMPP "lost" because it was bad technology. AFAIK the big
players are still using it in various places under the hood. It lost because
big players want to build "ecosystems".
XMPP lost because there was no big player behind it willing to push it as far as possible under its public name. Only a community of enthusiasts and a steering committee that only cares about what is going in the next spec.
Matrix at least has a company pushing for it, so there's a better chance it'll have more success than XMPP; unfortunately we'll have to wait a few more years to see the difference.
tbf there was a big player (Jabber Inc), and they sold out to Cisco. Hopefully the difference is already visible for Matrix, or if it isn’t it should be visible this year.
In practice those bridges function very well. It's common to find channels in the Matrix ecosystem that have IRC and Discord users that aren't even aware that there's Matrix participants.
The IRC bridge between matrix.org and freenode disconnects almost every week, showing sometimes hundreds of clients disconnecting, then reconnecting a few hours later.
I didn't check it personally, but I heard they (understandably) have issues enforcing bans: if one of their users is banned but another one is in the channel, the banned user can still read messages.
Matrix is general lacks support for community tools to handle stuff like that (unless you're running a channel with loose rules that doesn't get raided by 4chan on a weekly basis).
Yes and it's perfectly acceptable for a Beta service. It's just too bad they don't have a single bridge that's of release quality yet, while it was their main promise.
I don't believe this is really fixable, on various occasions when I ask for the community tools I need, I get blown off and told that such features won't be implemented in Matrix or will depend on client support (which is unacceptable).
better late than never: i don’t know what community moderation tools you’re talking about here. we certainly haven’t closed the door on any moderation features in Matrix, and certainly wouldn’t make them client specific. my guess is you are conflating random feedback from randoms in matrix rooms with input from the actual matrix core team. https://matrix.org/docs/guides/moderation/ is the official moderation guide, which is evolving fairly constantly, and we have a tonne of work on communities & moderation coming up in Feb/Mar.
And those are the reasons I use phone calls, sms and email. It is more than enough to keep contacts and to arange where you will meet in-person. For distant relations I prefer email, I always loved a well formed letter where sender has actually put some thought into it.
Yeah, I dont have 999 friends but those 10 good friends is all I need. And they DO call, sms, email me. For everyone else I dont care.
I'm not sure if I want that. Most of my communication over email can be read by Google, regardless of myself using Google. Moreover, there's the risk of things like AMP for email unilaterally changing the protocol in ways that as a user I might not like, but that I can't really influence through my choice of client.
I don't believe matrix.org will become such a thing, but if Matrix becomes as successful as email, I fear it's practically inevitable for a Google, Facebook or whatever to arise and become the dominant player, whereas that is practically impossible with, say, Signal.
I do see the value of the world that's made possible by technologies like Matrix, but I'm not so sure if they're possible with social processes evolving the way they do. I feel like Signal may be the best we can get.
(Though I'm certainly happy that Matrix is trying to prove that wrong.)
> XMPP was supposed to solve all those problems when it came out in the early 2000s. But then all the big tech companies who build "ecosystems" decided to push their own applications, all incompatible with one another.
Facebook Messenger and Google Talk actually used XMPP back then, I'm sad it's no longer the case.
A 'chat' client in the style of eg WhatsApp, but based on S/MIME over SMTP/IMAP, seems perfectly doable, and appropriate for most people's needs, with the obvious advantage of being supported by traditional email clients as a fallback.
Additionally, message threading is the feature I most appreciate in a messaging system, but which is painfully lacking in most products (and no, Slack doesn't cut it). SMTP has built-in support for it.
I'm old enough to remember when this was exactly how email was used. (but using a normal email client).
It was acceptable to send one-word email replies, and there were email chains of hundreds of emails (I was the guy who tended to "snip" them after 20 or replies).
Now email seems to have taken over from where snail mail was: bills, newsletters, and formal communication. Chat is now the norm.
Though I do notice a generational divide: one of my co-founders is in his 60's, and will phone randomly (which is now considered rude), another is a bit younger and prefers email to messaging, but will message to ask if it's OK to call. My younger colleagues send formal email replies, and use Whatsapp/Keybase for all other communication. I vetoed using Slack in the organisation completely ;)
I wonder if in another 30 years, chat apps will be the formal channel, and something else will have taken over for just chatting.
Yep: Direct thought transfer protocol, and people will just assume, that you are OK with them dumping their brain load full of irrelevancies and distractions into yours, unable to form a coherent thought and making an appointment, "because everyone is on TTP" (they wont know what TTP stands for though), so you are supposed to be too! And we will be "outdated", for using chat applications. "It's soooo slow!"
Check out deltachat, it uses autocrypt and pgp for e2ee, smtp for transport and has a UI based on signal. It is compatible with autocrypt-supporting e-mail clients like thunderbird
I guess most of the people that you mentioned can be reached through Email?
Email is a very good system, completely decentralized and yet still agile. It is sad that the protocol (SMTP, POP and IMAP etc) is stopped advancing into today's world.
If somebody from IETF is watching, maybe consider renewing the email protocol standards to make it more modern (like what you guys did in HTTP/2: Binary protocol, multiplex, better security etc)?
I was using multi-protocol clients such as Trillian/Miranda/Pidgin for most of the 00's. It did not matter much what client/protocol somebody was using, in all likelyhood it was supported by such multi-protocol clients.
At some point, reverse engineering/implementing protocols must have lost the interest of that part of the community.
> XMPP was supposed to solve all those problems when it came out in the early 2000s.
The really frustrating thing is that it almost did. I swear I remember at some point in the mid-2000s being able to send a message from Google Chat to Facebook. I think the option was hidden behind some account flags to enable external messages, but it was there.
One frustrating thing about Moxie's original post is that Signal derives huge amounts of value by piggybacking on an existing distributed federated network: the phone system. If phone numbers weren't an existing working identifiers that people had regardless of what OS, carrier, or messaging app, Signal as designed wouldn't work.
People should think harder about how to replicate that experience, instead of how to appropriate it and then abandon it.
In his "The Ecosystem is Moving" talk at CCC, he had many presumptuous and dubious "arguments" but one regarding privacy of phone numbers was that a user's APN would be used to determine their phone number, so there was no point in trying to keep phone numbers private.
This fails to account for the possibility of not using the cellular network. With unlocked smartphones, it is possible to remove the SIM card, clear any APN settings and access WiFi. That can be enough for a messaging app to work.
The only identifier needed for iMessage and FaceTime is a working e-mail address (and only for sign up). No cellular account is required.
That's not the representative experience for most consumers/users. Most people do have a phone number, though, so it's easy enough to bootstrap with.
I might not agree with the phone number thing, but I recognize the tradeoff being made and am willing to begrudgingly accept that for right now, Signal/Moxie are probably making the right call. It's not like they're not moving to fix it anyway.
Also, unless I misunderstood him, the APN bit is referencing push notifications, and he's right - if that's out there, it could identify you not just by phone but by Apple account in general. You realistically can't use Signal without an Apple ID, as you couldn't get it from the store otherwise.
> You realistically can't use Signal without an Apple ID
I do, because I got it and signed up for an account on my Android phone...
Okay, I realize what you're getting at here, but it seriously irks me when people talk as if Apple was the only ecosystem, or even the most popular ecosystem, when it is neither.
I probably don't even need a Google Play Store account if I can find an unmodified APK that's signed by OWS.
Thanks! I must admit I never looked for one, the point was more about the possibility. I think this implies it is definitely false that OWS would be able to identify you without a phone number. Because there are ways to use their app without providing any other personal identifier.
> That's not the representative experience for most consumers/users. Most people do have a phone number, though, so it's easy enough to bootstrap with.
It's a trap most don't realize they are falling in. It's easy to set up things without one time registration step (instead of making a user id and password, just download some client and boom - you are set). But think about it. One time(!) convenience is paid with constant(!) reduction of privacy.
Compare it to one time inconvenience of registration step, that gives you constantly better privacy. I'd say the second is the obvious choice.
And it's easy to sell this "convenience" for the clueless, but it's also evil to do so, because most don't realize what they are paying with. So I blame developers who are proliferating this approach. Unlike many of their users, they know very well what they are doing, and they exploit people's cluelessness and natural preference for convenience.
The second isn't better by default - no matter what, you're trusting some organization/entity somewhere in the chain.
Furthermore, your comment just eschews what Signal has said elsewhere - if you have a social app, you need a social graph to operate. They have to piggyback somewhere or else store a bunch of data themselves, and it's clear that they take their time to make sure they're doing something as best as possible before committing to it.
It's also not developers proliferating the approach. This is what the market developed into, and if you want your product/service/whatever to be successful, you have to win with that constraint. What you're describing is idealist, but not realistic at time of writing this. Hopefully it changes, but place the blame where it's appropriate.
> it's clear that they take their time to make sure they're doing something as best as possible before committing to it.
If you mean developers of such tools, they are surely not doing it "as best as possible", because they by design chose the worse approach. Decentralized approach is more difficult, but it is as best as possible.
> This is what the market developed into
Yeah, right, and developers just follow the "invisible hand of the market". It's not an excuse in the slightest, for fooling their users into trading off their privacy for convenience. Those who create such tools bear responsibility for what they created and for proliferation of such approach.
"You realistically can't use Signal without an Apple ID, as you couldn't get it from the store otherwise."
Isn't this the issue people are complaining about. They want to install this program without going through an "app store" to get it.
Is it possible to avoid using APNS. Probably it is enabled by default even the user does nothing with her phone and installs no third party apps. What if the user blocks the DNS requests to Apple.
If you don't accept push notifications, sure, you wouldn't technically be using APNS - the tokens change every time you give access for notifications. Last I checked, there's a connection to APNS running on every device or something... so blocking it would be interesting.
You'll be SOL on iOS anyway, ultimately - you're def not building it yourself with Xcode without an Apple account. Jailbreaking may be a fit here, but in defense of Signal, jailbreaking was kinda dead for a few years and only recently became usable again. Altstore[1] is... interesting, but I don't have enough experience with it to comment further.
I get what you're after, but Signal's not about to ignore the massive iOS userbase, and these are defining parts of the iOS ecosystem currently. You either play by those rules or you probably don't grow.
In the context of this talk, APN means "Apple Push Network", I think. The concern is that even if the service doesn't ask for a phone number directly, it does still have an APN or GCM/FCM push token. Through the push provider, that token can probably be linked to the user's phone number.
> With unlocked smartphones, it is possible to remove the SIM card, clear any APN settings and access WiFi.
If you're willing to do all that, I suppose getting some free VoIP number for registering with Signal (e.g. through Textnow) won't be too much of a hassle?
>People should think harder about how to replicate that experience, instead of how to appropriate it and then abandon it.
That's great and all, but because Signal takes advantage of that existing network of identifiers, it is able to deliver usable private messaging to many users today. Replacing phone numbers as identifiers is a much harder problem than what Signal has done so far. We shouldn't wait to solve this at some unknown point in the future before offering "huge amounts of value" to users.
The position you're taking, roughly that with limited resources you have to aim for achievable goals and while distributed federated networks are the underlying reason Signal works, it can't try to replace them right now, is totally reasonable, although not everyone will agree. However, that isn't at all what Moxie said. Instead he made no acknowledgement of the distributed nature of the phone system, he suggested that everyone who disagreed lived in the imaginary past, and suggested that his approach was the only sensible one. So I'm not inclined to read it as charitably as I read your comment.
"However, over the past six years, we’ve also seen the user cost of switching
between centralized communication services reduced substantially,
particularly given the tendency towards addressing with user-owned identifiers
like phone numbers."
Does he really believe that phone numbers are user-owned?
My phone carrier owns my number. If I'm lucky, I might be able to take
it to a new carrier. It's far more likely that I'd drop the number in
favor of one in the area code in which I actually live, however.
I own my own domain, and I self-host my own email. I'm not likely to change
it for geographical reasons. It has a much stronger tie to me than some
string of digits used by an analog voice network from the last century.
The other user cost of switching between centralized services is network
effects. If you want to switch from ICQ to AIM, you need to get
all your friends to join you.
Of course. Nothing in life is guaranteed. I'm sure the Buddha would tell me
that "there ain't no such thing as permanent". Nevertheless, I've had
my domain name longer than I've had my current phone number. I'm far
more likely to put up a fight for that name than I would be to fight for the
current string of digits that represents me in the phone system.
Maybe the whole concept of user-owned identifiers is a myth, or a Platonic
ideal. At least in my case, my phone number is pretty far from the Platonic
ideal.
When i asked if i could use his libraries in ios/android apps Moxie refused. He licensed them under GPL that prohibits distributing of software via app stores. Quite a strange for a guy who claim that he wants to spread encryption. Sure, but only on your own platform. Fastforward he sold such rights for a whatsapp. Just simple business, nothing about privacy itself.
GPL doesn't prevent you from using it on mobile devices, it prevents you from making changes to his code proprietary. You seem to just want to release proprietary software. You should say that out loud if so!
Apple _forces_ you to make proprietary changes to your application (and doesn't allow you to publish the source code of that modification). There is no way to have both a GPL-compliant app and have it on the app store at the same time.
While some comments here mention freedom zero (ability to run the program) another problem with ios is that you can only build on Apple hardware - so there's limits on how you can distribute and use changes.
This is only really a convenience limitation; it’s possible to run the iOS toolchain on other platforms with a significant amount of work. In any case, I can’t see GPL’s clause on distribution and modification kicking in here.
Generally, the way app stores work is that the developer uploads a copy of the app to the app store, and then the app store makes and distributes copies of that for people that request the app.
Note that since it is the app store making those copies for end users, the app store needs permission of the copyright owner to do so. There will be something in the agreement between the app developer and the app store that says that the developer grants such permission when the developer submits the app.
For app code whose copyright is actually owned by the developer, that's all that is necessary. The developer is able to grant all the necessary permissions to the app store.
If the app contains code that the developer does not own, then the app store also needs permission from the owner of that code in order to make and distribute copies of the app.
Consider a developer who includes someone else's GPL code in their app. To be able to make and distribute copies of it, the app store is going to have to obey GPL.
Most app stores require downloaders to agree to a license agreement with the app store, which typically includes things like prohibiting reverse engineering and prohibiting reselling or making and distributing copies.
GPL, however, prohibits such restrictions. If you impose such restrictions, GPL does not give you copyright permission to make and distribute copies. This makes the app store license and GPL incompatible, and so the software cannot be distributed on the store.
IMO this is pure laziness on the part of the app store. Any store could just say “this app is licensed to you under the GPL — download source here.”
Even ignoring licensing, I think app stores could add considerable value by offering reproducible builds. Let developers upload source, verify the has (git tree hash or plain sha256sum), and rebuild in a sandbox server-side. Reject the submission unless the binary’s hash matches the developer’s.
Now stick a badge on it: “verified open-source build”. And give it a small bonus in ranking relative to other apps.
Adding that license information doesn't help the end user to run modified code. You need an apple developer license to run changes that you have made. Thus, the code is not free.
On the other hand, apple offering to compile and run any modification that users made will never happen. Then, people could start with one program and run whatever they want. The app store would collapse.
That doesn’t contradict my point. Apple could achieve two goals here:
1. Allowing GPL code in a lightweight and compliant manner at a essentially no cost to Apple.
2. Adding a class of free (or paid) open-source apps that are more trustworthy. If Apple could effectively replace a decent fraction of the free shitware apps on the App Store with better free, open-source apps, the value to end-users and hence the value of the platform would increase.
There is no requirement in the GPL that recipients of source code be able to run modified versions of the code on the target device.
> Most app stores require downloaders to agree to a license agreement with the app store, which typically includes things like prohibiting reverse engineering and prohibiting reselling or making and distributing copies.
Apple’s (https://www.apple.com/legal/internet-services/itunes/dev/std...) actually has a very interesting clause that seems like you can discard their EULA and substitute your own (with some minimal restrictions pertaining to making sure that you don’t bring Apple into it and comply with warranty laws and such):
> Your license to each App is subject to your prior acceptance of either this Licensed Application End User License Agreement (“Standard EULA”), or a custom end user license agreement between you and the Application Provider (“Custom EULA”), if one is provided.
So can you just substitute one that grants your users the GPL freedoms?
In this case however, the code is under the GPLv3, which is far more problematic. It contains a "anti-tivoization" clause, which says you cannot require any "methods, procedures, authorization keys, or other information required to install and execute modified versions"
> In this case however, the code is under the GPLv3, which is far more problematic. It contains a "anti-tivoization" clause, which says you cannot require any "methods, procedures, authorization keys, or other information required to install and execute modified versions".
That doesn't actually apply to the Apple app store. The "anti-tivoization" clause is narrowly written to only cover what Tivo did. Namely, providing hardware with locked down firmware.
This is the trigger for the "anti-tivoization" clause:
> If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information.
A "User Product" is:
> either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling.
When someone downloads an app from the Apple app store for their iPhone, the iPhone is the "User Product", and the transaction is not one in which "the right of possession and use of the User Product is transferred to the recipient", and so the "anti-tivoization" does not apply.
>anything designed or sold for incorporation into a dwelling.
I'd be willing to make the argument that a program integrated into a previously owned computing device is a totally valid case for this clause to trigger under. Your computer is part of, and is increasingly integrated into your dwelling. The program being pulled down is just another module for it.
It wouldn't matter. Two things are required to trigger the clause.
1. The GPLv3 object code has to be conveyed "in, or with, or specifically for use in, a User Product", and
2. This must occur "as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient".
The "User Product" in your argument is still the computer, and so unless you are buying the computer itself from the App Store at the same time as the app you are buying, the second condition is not met.
The definition of "User Product" in GPLv3 might seem a little puzzling at first. There are two kinds of things that count:
1. "any tangible personal property which is normally used for personal, family, or household purposes", or
2. "anything designed or sold for incorporation into a dwelling".
There is no definition of "dwelling" in GPLv3, so it is going to be given its ordinary meaning which according to Oxford is "a house, apartment, or other place of residence".
#1 already covers any tangible personal property used for personal, family, or household purposes, and since dwellings are places of residence it might seem that anything incorporated into a dwelling would also be covered by #1.
So what is #2 actually getting at?
The answer, I'm sure, is fixtures. A fixture is physical property that is permanently attached to real property. Crucially, if something is a fixture then it is not considered to be personal property and so does not fall under #1 of the "User Product" definition.
Unless the sales contract specifically says otherwise, fixtures go with the house, and personal property goes with the seller.
Nowadays a lot of things that include software might be fixtures. Some things that might be considered fixtures and might also have software in them:
1. Thermostats.
2. Smoke alarms.
3. Security cameras.
4. Appliances.
5. Lighting fixtures.
(I'm not saying that they are fixtures. In some houses they might be fixtures and in others they might not be, depending on how they were installed).
Without #2 in the "User Product" definition, manufactures of those things might be able to include locked down GPLv3 firmware without trigger the "anti-tivoization" clause.
I say "might be able to" because those things aren't fixtures until they get attached to the house. A thermostat sitting in a box on the shelf at Home Depot is not a fixture at that point. It only becomes a fixture when someone installs it.
This would probably cover it under #1, closing the loophole.
But what if the thermostat is not sold through stores like Home Depot? What if instead you have to buy it through the manufacturer, which sends an installer to install it, and only conveys ownership to you after it has become a fixture? This could probably be done in a way that evades #1.
#2 shuts down such shenanigans.
What I'm puzzled by is what about things that are neither personal property used "for personal, family, or household purposes" nor for incorporation into dwelling?
Would it be OK for Boeing or Airbus to Tivoize the software in their planes and still use GPLv3 code in it? Can John Deere use GPLv3 code in its combines and Tivoize it?
> What I'm puzzled by is what about things that are neither personal property used "for personal, family, or household purposes" nor for incorporation into dwelling?
Moxie / signal chooses pragmatism over purity, and is striving towards improve the status quo bit by bit vs a pure perfect solution that never ships, even though that improvement has it's own vital problems.
You can see it in his choices, and you can see how they want to eventually deliver improvements like no phone numbers, with them working on things like secure value recovery.
I kind of wish he spelled it out fully for the nit picky peanut gallery out there, so he can just reference it instead of wasting energy on them. You can just feel the exasperation when you read his writing and see him speak about this.
I'd argue that Matrix also chooses pragmatism over purity - the balance is more that we prioritise freedom as well as privacy.
Signal's whole mantra of "only implement features which are privacy preserving" is a great mentality. It's just a shame it comes at the expense of locking down the platform.
I'd argue you can't prioritise two things: prioritisation means deciding what comes first when you have to choose between two things. And it appears to me that Signal tries to ensure privacy first, and then sees if it can make that work with freedom later (see e.g. the delay in adding support for de-googled Android, or the ground work they're only doing now that might (or might not) lead to accounts without phone numbers), whereas Matrix does it the other way around (by first working on support for many different clients, and then trying to make that work with encryption). I hope that both succeed, and I'm happy that both paths are taken.
As an aside, I'd like to voice my appreciation for how you respectfully acknowledged moxie's point of view, take effort to understand it, and then pinpoint why you reach different conclusions from the same observations. A pleasure to read.
I would make the opposite argument: that at pretty much every point along the way, Signal has chosen purity over pragmatism. Which is why they didn't even have user profiles until recently, why they're just now getting group access control for a Slack-y experience, and why it's taking a fairly spectacular amount of engineering to get them off of phone numbers. Signal has a track record of delaying features common to messenger applications in order to get them cryptographically right. No other mainstream messenger tool has a comparable track record.
I completely agree. Ironically, centralization has not helped them move faster.
They won’t have usable group messaging without proper “mentions only” notifications. I’ve tried to explain so many times on the forum that they don’t need usernames for this. Just allow us to configure our own list of keywords we want to be notified of.
It’s very frustrating to keep up with the development of the apps. I wouldn’t recommend it.
You can make this argument about anyone simply by changing the metrics you're judging them by. So if you judge Signal by usability and messaging features, of course centralization isn't paying off. But that's not what Signal is optimizing for. On privacy features, no mainstream messaging app is doing anything resembling what Signal is doing; Signal's "competitors"† obtain their messaging features by storing vast amounts of valuable metadata in plaintext on their servers. Signal gets those features, with privacy assurance and without accumulating the hazmat, by inventing and deploying new high-end cryptography.
Consider how long it's taken Matrix to get to a point where it's just E2E by default. That's table stakes, Matrix very much wants to get there, and if they're lucky (see downthread) they'll be able to flip that switch in Q1 2020.
If Signal invents some new feature based on Attribute Based Encryption or pairing curves or PQ exchanges or whatever, they'll have it deployed within a week of merging the code into master. You've seen them do things like that repeatedly. That's what centralization buys.
† I'm not sure I accept the premise that it has competitors; the companies you're thinking of are, to my mind, competing more with WhatsApp and Slack than Signal.
The slow bit of Matrix’s E2E by default isn’t the roll-out; we’ll also flip the switch when we get to that point. The problem instead was that we implemented way too many pre-E2E features (serverside search, etc) and have had to reimplement them to force everyone onto E2E.
So yeah, Signal’s approach to only roll out features if they’re privacy preserving is great. But it’s nothing to do with centralisation/decentralisation.
Do all the Matrix clients implement the E2E functionality that exists today, the functionality people talk about when they say Matrix is E2E encrypted? If not: that's decentralization in action.
Downthread, you were explaining that you're waiting to flip a switch to require E2E support for clients, and that there's a "pantalaimon" proxy service that people are going to have to use to retrofit E2E onto clients that don't support it. So I think I know the answer to this.
I'm always going to come across like I'm rooting against Matrix, which isn't what's happening.
There are a bunch of Matrix clients from various sources, with a wide spread of features and maturity. All the commonly used ones are pretty much feature complete and support E2E. The fact others exist is because they are WIP or experiments. This is a feature not a bug.
We’re declaring that private chats (or at least DMs) must default to being E2E at end of Jan. This could screw over these WIP and experimental or venerable clients, so we provided pantalaimon as a shim daemon to help them out.
To me, this says that we can successfully evolve Matrix with massive breaking changes by providing migration paths and decent layering abstractions, despite being decentralised.
So “Do all the Matrix clients implement the E2E functionality that exists today” is not a very revealing question.
It has been "moving" from the times of Compuserve and AOL trying to prevent e-mail federation. Good thing they failed then! Kudos to Matrix for pushing against such movement in IMs. Someone has to push against it, instead of looking for excuses to proliferate walled gardens.
> If users don’t trust their app provider, they can always go switch apps, which gives them freedom.
Sounds like Moxie meant it's a downside. It's a huge benefit! Forcing one to use something that's not trusted is horrendous.
Note that since a while there is also the possibility of using web sockets. But they are an extreme battery drain, and thus google services are quasi-mandatory. Telegram solves this without being a battery drain, possibly at the cost of delivering messages with a delay, but why isn't that my choice.
I can't tell you how they do it, but Telegram is lightning fast with push notifications across all kinds of devices, including Android. Been rocking it as my primary messenger for years.
Whenever a few of us are sitting around in real life, and someone sends something to a group chat, all the phones on the table will buzz instantly together (iOS and Android).
And on top of that, battery usage is really low on Android. I use it a TON, and it's never in the top n apps of battery usage. Meanwhile, I can just open Snapchat once, and I lose a few percent.
Yes but the implementation of the notification handling is impressive on the client side. The server side software as far as this is concerned should be easily deducible and isn't the interesting part.
I use Signal without gapps and do not have extreme battery drain. I always get real-time notifications too - no late or missing deliveries. This is both on a galaxy s9 which went from stock ROM to deleted Gapps with no battery impact, and s 1+ 7 Pro with no Gapps from the very beginning (I get the expected excellent battery life).
I suspected that Signal basically took Over Gapps's role since it's the only app I use with notifications. Google keeps open a single optimized connection and apps go through it instead of having 10 open connections. After deleting Gapps, Signal is the only app keeping open a connection so it basically has the same impact.
But then I installed WhatsApp and Signal+WA both work perfectly without Gapps and with no gigantic battery drain. So I have no idea what black magic is making this work.
I just looked up my battery stats; since the last full charge 32 hours ago Signal has used 1% of the power. I got a few notifications and used the app for a few minutes in this time. WhatsApp's power usage is too low to show up in the stats.
Telegram without GCM is incredibly fast. Compared to my computer with the app/website open, it's at most one second slower, and often times faster at delivering messages, even on battery saver. It also uses less than a percent of my battery per day if I don't open the app, and was 2% of my battery usage in the last two days despite being on the app for close to an hour.
Of course not, but what's the point? Who complains that Signal doesn't run without Google Play Services are the kind of users that wants to run a mostly free distribution of Android (like LineageOS) without any Google software on it. Saying well you should buy a more closed and proprietary system that can run Signal without Google software is nonsense.
Luckily for those users, Signal does run on mostly free distributions of Android without Google software on it - specifically without Google Play Services. I do so.
Email is flawed and will become a one way protocol to receive spam, newsletters and invoices just like paper mail.
I think Matrix is our second chance to build a secure federated communication suite. So far it's going in the right direction...
> Email is flawed and will become a one way protocol to receive spam, newsletters and invoices just like paper mail.
I don't recall the last time I've received spam in my email inbox among the tens of emails I've receive daily, and newsletters/invoices are messages that users intend to subscribe. You might argue that instant messaging scratches an itch that email doesn't, but that's a bit shortsighted and doesn't make a case on why email is flawed.
Agreed. Fifteen year ago I set up an email system that let me give everyone a different email, depending on what service it was/when, and since then I've only had my email clearly sold off to a third party that spammed me once. It was a startup that got bought by a private equity firm (and is still around) and fwiw, after I unsubscribed from the first spam I got, it stopped...
Newsletters and other BS notifications are the new spam.
Sure, you can technically opt-out and keep your inbox clean by spending 5 minutes opting out of the garbage every time you sign up to a new service, but that’s irrelevant considering nobody does this and most of my friends’ mailboxes are pretty much unusable because this kind of spam arrives every minute and they have tens of thousands of unread emails in their inbox.
However, in this case I’m not sure Matrix or any other service would be the solution. If the service is neutral and doesn’t impose policies on the content then scum like marketers will just move to it. On the other hand actually having “acceptable use policies” would require centralisation and bring its own problems to the table.
The real solution here is regulation, not technology.
Most sites will allow you to opt out from account creation and also will allow you to unsubscribe without even having to login to your account. If your mailbox has 10k+ spam messages it is IMO a personal problem of either not opting out, or signing up for total garbage sites in the first place.
Most subscription options at signup are using dark patterns to make you subscribe against your will (“untick this box if you want to miss out on the inconvenience of not receiving our latest deal”).
There’s also the issue of it being implemented badly (mostly by mistake rather than on purpose) where there are several spam systems & lists, the website opts you out of one but there’s another one in the background you can’t opt out of without at least receiving one and clicking the unsubscribe link - sometimes they make multiple campaigns so opting out of one doesn’t mean you’re safe from the next one, etc.
And finally there are those who aren’t technically marketing but a huge lack of respect for the person’s time & attention - customer service reviews and the “how did we do?” emails. Why can’t you put the feedback buttons in the existing emails instead of sending a new one and interrupting my flow & wasting my time?
For the latter I had a company doing this every single f’ing time for every ticket I opened about a benign bug or suggestion (using in-app chat still opens a ticket thanks to Zendesk Chat). I’ve eventually started forwarding them straight back into the main support email. I think they got the hint after several months - I’ve removed the forwarding rule and the feedback crap is nowhere to be seen. VICTORY!
Even if there are not technically marketing a lot of companies just have a complete lack of respect for their users time. Let’s take Facebook, Twitter or even Spotify for example; they have like over 20 categories of email notifications (excluding the newsletter) which are guaranteed to fill up your inbox by themselves, let alone having signed up to multiple of those services. You shouldn’t have to be manually unticking 20+ checkboxes just to enjoy a clean inbox.
If we didn't have email we would immediately have to invent something that did the same thing. The world needs non-real time text messaging way more than it needs real time text messaging. After all, we still have phones which work well real time. They don't work well at all for non-real time messaging. That is why we went to all that trouble to invent and use things like teletypes.
I think the timing makes Moxie's point very well without him saying a thing.
All these years later Matrix only has... The ambition to some day try to offer the core privacy features Signal already delivered back then. Some of the most basic stuff is, you believe, almost kinda sorta done.
This is, to be clear, much better than just sitting back insisting you were right but not lifting a finger. But for an actual user who needed privacy and security any time between then and now - and for future users who need it between now and whenever you get this stuff working in the real world, it was Signal that delivered. Moxie was right so far.
Talking about privacy of a system that requires you to sign up with a phone number, that in my country (and in most other European countries as far as I know, and without talking about non democratic regimes) is required to be associated with your ID (it's illegal to buy a SIM without registration) is nonsense.
And you know another thing? Email works great to me, and it's decentralized. I have my email server, with my domain, so I don't depend on anyone to provide me a service. I have full control of my data that is on my server. I can even send encrypted emails with GnuPG without any problem, and it's as secure as Signal, if not better. I can use whatever client I want, a fancy application, a web interface, or as I do a small CLI program since I don't use graphical user interfaces.
Sure, having a chat protocol that is decentralized like email would be great! I wish that Matrix will evolve in something usable in the following years, we need that. I need a chat application where I can have a client that I can use in my terminal, and Signal doesn't do that (Telegram does, for example, since the API is more open, and it's what I use second to email).
> I can even send encrypted emails with GnuPG without any problem, and it's as secure as Signal, if not better.
Alas this requires a fairly contorted definition of "secure" to be true. The cryptography in GnuPG has plenty of problems even if you insist on manually doing everything from your own CLI tools which maybe don't suffer the problems from EFail.
Mostly it's just kinda old, AEAD hadn't been conceived when Phil wrote PGP you know. That's a big foundational idea for modern crypto and instead PGP had to kind of fudge a separate MAC into the design and hope that's good enough.
When you send your GnuPG encrypted mail, how do you decide which cryptographic primitives to use? With Signal the whole _point_ of Moxie's decision is that Signal gets to insist on all clients having whatever the best option is, so that's always used. But in GnuPG you've got to guess, what might the other participant's client be able to handle? If you guess wrong then your email is unreadable, or, worse, bad guys might be able to read it more easily.
> in most other European countries as far as I know
In England at least SIMs are available in the pound shop. You buy a SIM with cash (a single bright coin) and it comes with a phone number. British people do not carry any ID as a habit, and I make a point of never having ID unless I've been specifically asked to bring it for a good reason (e.g. to leave the country or when I got a job that required security clearance).
>...if you insist on manually doing everything from your own CLI tools which maybe don't suffer the problems from EFail.
The only surprising thing that EFail revealed is that there are email clients out there that will silently allow html emails to communicate with the outside world. Encryption isn't the only thing that leaks from such clients.
>...PGP had to kind of fudge a separate MAC into the design and hope that's good enough.
Well isn't it? What attack is possible here? What attack was ever possible?
>When you send your GnuPG encrypted mail, how do you decide which cryptographic primitives to use?
You use the best ones supported by the receiver as listed in their public key. No one actually has to decide this and no guessing is required. This is something that the OpenPGP standard gets right for a crypto standard. Such things by necessity have to evolve over time. Sure this was hard to figure out, but it's done now. This particular wheel does not have to be reinvented or avoided.
> Well isn't it? What attack is possible here? What attack was ever possible?
No. Unsurprisingly the result is exactly what you'd expect. Idiots build software that throws away the error result and returns the unauthenticated text. This has always happened, which is why AEAD modes exist now. EFail documents what it names "CFB gadgets" to abuse this in typical HTML-based OpenPGP clients but you could attempt the same fun attacking a human subject directly, in some ways it might be easier because humans tend to just sort of "read past" nonsense in the search for meaning.
Phil Zimmerman didn't have a better option. You do.
> You use the best ones supported by the receiver as listed in their public key
So, you never use anything in the least bit new unless you're communicating with somebody who just minted new keys. For older users, you're stuck with whatever was current in the software version they ran five, ten, twenty years ago.
>For older users, you're stuck with whatever was current in the software version they ran five, ten, twenty years ago.
GPG2 doesn't support V3 keys anymore so old keys just won't work. That point is fairly moot in that pretty much all the ancient encryption is still unbroken.
> And you know another thing? Email works great to me, and it's decentralized. I have my email server, with my domain, so I don't depend on anyone to provide me a service. I have full control of my data that is on my server. I can even send encrypted emails with GnuPG without any problem
OK, and how many non-technical people do you email that have GPG keys? If they don't have GPG, how do you have end to end encrypted communications with them?
This is where Signal won and GPG lost, with the Signal protocol integration into WhatsApp, one billion people instantly got secure comms without even having to know what a key is.
> it's as secure as Signal, if not better.
Signal uses a new key for every single message you send, so it could be argued that actually Signal is better than GPG.
When comparing to signal, or indeed to any modern chat client, you need to call out when you are mentioning non-Riot clients that don't support encryption.
In the original article you did this well: when you claimed "no fragmentation," the next sentence explained that the claim didn't apply to encryption.
In general, matrix feature-boasting about things it can do without encryption is confusing people. Most new users are coming to matrix expecting encryption, and they get it. But then matrix advocacy presentations proceed from the ridiculous assumption that open-source chat without encryption would be interesting as something to move onto, while hiding this assumption. Please stop doing this to preserve your credibility.
> Some of the most basic stuff is, you believe, almost kinda sorta done.
The core Matrix stuff has been usable for years, and in many ways you've had better metadata and censorship protection available than Signal - given you have the option of running your own server which could be entirely off the grid, and used only for your own conversations.
However, if your point is that Matrix focuses on freedom as well as privacy (rather than privacy at the expense of freedom), then we're agreed :D
No, a hypothetical option to never communicate with anybody on the network isn't "better protection" in any meaningful sense than a system designed from the outset to actually protect you when you communicate with other people.
When you say we're trying to improve I want to believe you. When you stubbornly declare "we're better" in "many ways" while actually being much worse, what could I conclude? Only that your goal is to deceive people because you're not really interested in improving. Blergh.
Back in February 2015 you did not understand the gravity of the mistake in leaving end-to-end encryption as a TODO item for Matrix and defended this decision as "Pragmatic" repeatedly. Matrix itself is a bit older, mid-2014 I think, but 2015 was the first time I ran into the arguments for Matrix. It's important to underscore those dates. I've moaned (including to his face) about Tim's choice not to do encryption out of the box in his toy hypermedia system, but that was almost 25 years earlier and whilst annoying a lot more understandable. 2014 on the other hand is after BCP #188 ("Pervasive Monitoring Is An Attack") and all that implies so there are no excuses. Matrix was a defective design on day zero. 2020 begins with a promise that it'll be fixed soon, kinda, sorta and then a retreat to old arguments about how it's all worth it for "freedom".
When I say "kinda sorta done" I am not referring to being able to send unprotected plaintext over the Internet in 2020. What's "kinda sorta done" is the basic task of sending messages between participants without anybody else knowing what was said, or preferably who by and who to. It sounds like Matrix's _ambition_ is still that in 2020 this will be the case for certain groups of participants, at least some of the time. Not everybody, and not all the time, and not yet unless you go out of your way which we know users will not do.
? I'm confused. My understanding is that Matrix/Synapse has E2EE; it's just that the UX around it right now is still garbage (and that's what they're working on).
Building monoliths (like Signal) is easy and that's a core take-away point of Matthew's response in the blog post. Building Matrix is not and has not ever been a small task, but the effort gives us the freedom to run our own services and still be able to talk with our friends. Matrix is the "long game".
And it's a worthwhile pursuit. Moxie's points simply don't make sense, and are infuriating / disrespectful to those who are working on solving decentralization's issues.
_Of course_ it will be difficult. But the same argument could be made for building a completely unencrypted messenger app. You won't have to worry about managing keys, obfuscating metadata, or anything like that.
At the end of the day, it's about realizing the importance of both privacy _and_ decentralization that our current infrastructure threatens.
For one, it's a lot of text for the myriad of ways you can moderate your server/chat. It's just a paragraph for kicking "a nazi out of the cybersecurity chat."
And two, "In Riot, Admins are shown in the membership list with a golden shield, and Moderators are shown with a silver shield. Other clients use similar metaphors."
If you actually used Matrix, you'd notice in whatever client that you're using that it's actually very easy to see who the mods are.
>All these years later Matrix only has... The ambition to some day try to offer the core privacy features Signal already delivered back then.
E2E on Matrix works, plus key verification is easier than on Signal. Managing metadata is hard, but my Matrix homeserver doesn't have my phone number (unlike Signal) and does not require Google Cloud Messaging. I can even run it on a PinePhone or Pocket CHIP!
>But for an actual user who needed privacy and security any time between then and now - and for future users who need it between now and whenever you get this stuff working in the real world, it was Signal that delivered. Moxie was right so far.
...that wasn't Signal leaking data, though, and unlike Twitter, which until last week allowed anyone to mass-check phone numbers, Signal doesn't publicly broadcast your number.
I don't use Signal, and won't as long as they force a phone number, but at least be accurate.
E2E in Matrix "works" with which Matrix clients? The whole point of a decentralized federated messaging protocol is to allow people to build their own clients. Do Matrix clients uniformly and interoperably support E2E today?
Nearly; we’re aiming to force on E2E by default at end of Jan (but it’s getting tight). There are at least 6 complete independent implementations, and once cross-signing lands it’s good to go. For clients/bots/bridges without E2E we have pantalaimon (a clientside daemon which you proxy all the traffic through in order to encrypt it).
Well, XMPP had working e2e encryption a decade before Signal. That's not really a reason to consider something done. Axolotl and OMEMO improved on OTR, and it seems OTRv4 will improve on it further.
Wait a minute. When you say "Axolotl improved OTR", what you're really saying is that Signal improved on OTR, because that's where Axolotl comes from. The same is true of OMEMO.
Security: sure, but privacy: no. An application focused on privacy should never require a phone number. In many countries phone numbers can easily be tied to individuals.
This reminds me of the book "Zen and the Art of Motorcycle Maintenance", which is also about a father-son roadtrip, and which uses it as an excuse to talk about what happens when we do long, boring tasks requiring some focus but leaving enough of the brain unoccupied. It's a good book and I should probably reread it.
The way they defend WhatsApp is heart-breaking. It's cute to see them saying there is no backdoor when it can't be proven to be the case, since it's all proprietary. They can't show the server side wasn't tampered with. Same with Skype.
The constant repetition of this ignorant claim is starting to be annoying. Think there is a client backdoor? Go find it. It is not like the binary is not available to you. It is not like there are not emulators in which you can step through the code. Please, show us the backdoor.
Server side tampering? Show us how it can be done. Create a server that can tamper with a patched client. Demonstrate your chops.
It's not up to us to reverse engineer a binary every update to guess if it's secure...
It's up to Facebook, which has time and again proven that it is absolutely not trustworthy, to open its code and make builds auditable, inspectable, and reproducible.
This is what ANY secure software does. That's the cost of entry. Imagine if OpenSSH were closed and its devs issued the same response you just did. "Just reverse engineer the binary and prove that it's not secure!"
Actually it _is_ up to you; put up or shut up is a fairly well-known principle. Find the backdoor and make yourself famous, or continue to whine and listen to everyone laugh.
I left FB because it was getting too creepy and I would not trust 99% of FB dev with a single shred of my personal info, but the code is right there for you and people who actually have skills to disassemble and examine. They are under no obligation to do your work for you and the people who can actually do the work make good money so maybe you will learn a useful skill or two.
Random people are not in obiligation for Facebook to constantly reverse-engineer their binary code just because they do not want to publish their sources. This is not a criminal trial, but engineering. A mere doubt might be well enough to look for other solutions.
All that money and effort is probably better spent in e. g. developing alternative communication systems.
There’s no obligation for Whatsapp to prove that there is no backdoor? Yeah I guess when a product is too big to fail, they’re not obligated to do anything. True.
I think that protocols that are simple and open should be used, rather than very complicated and messy ones. Text-based also helps since it allows to use without specialized software. IRC is designed like this and I think it is good.
This is a very unpopular position from a security perspective. All messages should be exchanged by some type-safe structured container like protobuf to avoid a huge class of bugs that comes from quoting and odd character sets, manually implementing parsers, confusing types, and broken string arithmetic.
"Democracy and republics are hard, so we should all just give up and have autocratic governments"
It may sound flippant or unrelated, but I think this extreme projection of his argument makes it evident how silly it is. This is one of the reasons I switched away from using Signal, as much as I'd like better privacy on my text messages it's not worth handing that much control over to someone I shouldn't have to put my trust in. Instead I do my text messages over Jabber/XMPP with jmp.chat now and for others who have a proper XMPP address I use that (which gives me the option of OMEMO encryption which is basically the XMPP version of the signal double ratchet).
For the average user, installing conversations.im and hitting "create account" or whatever and calling it a day is good enough, so it's not even significantly harder than dealing with Signal.
I saw Moxie Marlinspike's talk when it was posted on CCC's official channel [1] and was disgusted by it. The talk has been now censored and video was made private. It was one of the most defeatist talks I've ever come across when it comes to messaging and privacy. His message was basically that anything you do is pointless and that his and WhatsApp/Facebook's way is the right one.
I've used Signal on few occasions in the past but his talk made me uninstall it. I simply do not trust him after hearing his opinions. I do not support centralization and other ideals he's now pushing (including the use of a phone number as Signal's primary ID).
The talk was mirrored on few channels on YT [2] and you can still see it.
I don't particularly like a centralized model either.
Federation is much more difficult, but can create ecosystems which can survive longer/better than a single company can.
But on the specific issue of phone numbers as ID, they have been making some substantial progress on a technological solution to address this, specifically without running central servers.
You were "disgusted" by the talk? The controversial parts were spelled out in a post Moxie wrote 3.5 years ago, with the same title. The only deviations are new privacy-preserving features Signal is building, one of which is intended to address the most common objection to Signal (the use of phone numbers as identifiers).
The talk wasn't "censored"; the conference made a mistake by recording and posting it in the first place.
I think if Moxie had framed this from a perspective of "centralization has some advantages, so how can we make a centralized service as safe as possible" the outcry would be much less. Because signal is genuinely doing some very great stuff in that area. But the framing as a dismissal of decentralized solutions as unworthwhile is very frustrating, especially when it so transparently overlaps with his business interests.
Yea, how can we talk about privacy of a service that I need to register with a phone number (and in my country to register a phone number is obligatory to give your ID and signature, you can't activate a SIM card anonymously)
Centralized services should be avoided for a multitude of reason, the primary one is being dependent on some company that offers you the service and can and probably will shut down one day, with the result of loosing all the things you had on that service.
Look at the past, how many centralized services closed down and we lost all our data? Instead decentralized services are still up and running: email, usenet, IRC, even if unfortunately a bit forgotten these day (with the exception of email, even if most of people uses GMail anyway so it's in fact centralized...)
It's fine, but you should know that pretty much everything Moxie and Signal talk about contrast sharply with Wire. For instance: last I checked, Wire stores your entire social graph on their servers in a database --- effectively forever, Wire stores a plaintext log of everyone you've communicated with.
To be fair, since there is no remote attestation possible for the Signal servers, and you realistically can't run one yourself, you only have their word that they don't store any of that information.
This is similar guarantees that a lot of other chat and VPN companies offer. Personally I would consider any information given out to a company non-secret, especially to those operating outside my jurisdiction.
> You only have their word that they don't store any of that information.
No, we have the fact that they don't collect it in the first place. The whole point of the Signal design, reflected in the published source code, is that the server doesn't need this type of information and so it isn't sent to their server at all.
As Thomas explained this takes a bunch of extra effort in the Signal design, hoop jumping that normal users will never appreciate. Moxie believes this is worth doing, although I think people's constant cynicism is gradually wearing him down or maybe that's just the jetlag.
If you tell me and Alice and Bob your real name, and then it's leaked to the press, I guess I sympathise if you distrust me as a result even though Alice is a famous gossip.
But if you only gave Alice your name, and then you distrust me because she sold it to the press that makes you a crazy person. "It could have been anyone". No, it couldn't, it was Alice. She's the only person you gave it to.
The difference is that Signal's competitors are designed in such a way that they have to keep this information, and Signal has delayed key features, like user profiles, until they've managed to create designs that don't have these restrictions.
So the logic you're using here is essentially: "since we have to take Signal's word for some part of this, we might as well use services that promise the exact opposite". I don't find that argument persuasive, but you do you.
Not all Signal alternatives store user information on servers. Threema for example has fully decentralized groups and even decentralized profiles (while Signal uses encrypted-but-centralized profiles, and their new Private Groups system moved from decentralized to encrypted-but-centralized as well).
I don't really care and think this is all a red herring, since every other mainstream messenger doesn't protect this information at all, but instead stores it in plaintext databases.
I read on a privacy-oriented website that Wire was purchased by an American company not trusted for its record on privacy (or perhaps it was that since the company is American, their data can be read by the US govt.). I can't find it now though. There isn't anything mentioning it on the website of `www.privacytools.io`: https://www.privacytools.io/software/real-time-communication...
First off, I have to say this about matrix: they have by far the best foss community I have seen. Excellent work on managing the community, others should take note.
Second, both signal and matrix collect too much metadata. signal means you're completely screwed by their dependency on phone numbers. I expect little metadata privacy from signal because to me, it is practically the same as using my SSN or fingerprint as my user name,same for all my contacts, this key field is used by everyone and their mother to track everything we do like 1984 was target practice. For matrix, it's the defaults and how easy it is for others to fingerprint you using your specific device (equivalent of a user-agent seen by everyone iirc?) and other profile details ,but none of this is easy to correlate and answer questions like "which social network demographic micro-group does this user belong to so we can perform targeted infiltration of their device?" or "Hey, let's use this phone number to look perform the equivalent of a background check on this person who is sending us a message because we now have their phone number". Oh and the best part is, you can't just get a burner to use for registration, and to link a signal desktop,you need the mobile app. Matrix has none of these issues.
Third, consider your threat models carefully. As an individual, is it better if you have infrasructure diversity and protocol interoperability or is it better to put all your eggs in signal's basket. I never liked their use of google infra at the begining for example because I consider google more of a threat to me than most other parties. I can see the argument both ways. I personally consider the set of parties that have the most to benefit from targeting me as an individual plus those who have the most to benefit from dragnet surveillance where I reside. To me, matrix is more flexible to adopt to various threat models by for example self hosting compared to using a popular matrix server. Signal is better than the competition, if your fear is being exposed to unpatched vulnerabilities and/or if you are worried about metadata snooping (but you trust signal's infra provider, still google??) Then Signal makes more sense. For dragnet, I think matrix is better for me because implementation vulns only apply to a few users,making reliable dragnet attacks less likely. For anyone that might target me, my mobile phone is completely defenseless, so my concern is someone identifying my specific device for targeted attacks, with matrix they need to compromise the matrix server and even then they might need to do a lot more work to correlate which matrix user is me (real life "target worthy" identity). Where as with signal,they can easily micro target a group ,find out everyone's phone numbers (e.g.: hk protesters) and target their device for further exploitation via signal or any other pwnable app that is known to present on a device associated with that phone number.Practically, I am more worried about how each app fits in with everything else I do and matrix wins the security round for me.
Last but not least, I use signal for 98% of my comms because the phone number usage by Signal means I can easily connect to and invite people who don't have signal. If there is a Matrix client app that can be used as an sms client and can discover contacts' matrix account/server over sms without communicating or collecting phone number/name details of the contact, I think i might jump ship. The way I envision this to work is: the matrix client would have an invite button for non-matrix contacts and it will have an option to initiate discovery of contacts. Both options would do a challenge-response with each contact and instead of associating with a phone number they would ask to create a new martrix only contact.
Matthew outlined much of the Matrix problems but not in the context of the latter part of his idealistic thoughts.
Just going to point out that if agreeing on spec is six time slower, that's just the first car of traffic jam slowing down. The next car has to slow down more: The feature needs to move into SDKs. Then the next car, the client vendors need to actually implement and test their implementation of the feature and write documentation. That's even more slow.
"HOWEVER: all of this completely ignores one critical thing - the value of freedom."
I really value freedom. To me freedom means a non-technical dissident doesn't have to sit in jail when their messages weren't E2EE. It doesn't mean I can choose a value from a list of servers and have faceless entity #1, #2 or #3, or worse, Mike - the creepy IT guy from my peers - observe my metadata with everybody, and content with Karen who refuses to switch to Matrix client that supports E2EE.
"Freedom to run your own server (perhaps invisibly in your app, in a P2P world)."
Now this is something I can get behind. Which is why I've spent the last eight years working on P2P messaging system. Perhaps Matrix should move their efforts into being the change they want to see in the world instead of defending a bad solution of decentralization by saying they're thinking about implementing a better solution of P2P.
"Freedom to pick which country your server runs in"
Which you can't do if you're running P2P server on your device. I think every faceless service provider from Signal to any XMPP server has the same guarantee of privacy in practice. The only difference is Signal has to abide by the GDPR, independent users hosting servers don't. Before anyone screams about PRISM, I will point out that coercing insertion of a backdoor is the same as compelled speech, which would violate the constitution.
"Freedom to select how much metadata and history to keep."
We have precedence of Signal keeping none of that. With Matrix servers the server has access to all metadata by default, the server program doesn't attempt to hide anything, there's no sealed sender etc. Your only hope is to run your own server, somehow convince your peers you're the one they should trust with their metadata (there's a third party on every decentralized server with more than two users), and hope you don't grow enough to get hacked by nation state actors or criminals.
"Freedom to choose which apps to use - while still having the freedom to talk to anyone you like. Freedom to connect your own functionality - bots, bridges, integrations etc"
A nice idea, but everyone needs to have same features for it to work, so what you get is differences in UI, implementation language, and platform support. What matters most here is the programming language: Matrix client written in Rust is more secure that one written in C. But unless everyone uses the Rust version, the group chat is as secure as the weakest link. Same goes with bridges. You'll never have security because of this guy who likes to re-live their youth through irssi: https://xkcd.com/1782/
Also, what happens when Facebook implements their own Matrix client that steals your metadata from the endpoint, and what happens when they start bundling their app on every Samsung smartphone? Perhaps it's not your idealistic Riot client that's the problem, perhaps it's the bundled spyware on every peers' device used by people who just, don't care. I'm not saying Signal fixes the problem of user laziness, I'm saying it's better to know what's on the receiving end.
"Freedom to select which identifiers (if any) to use to register your account."
Which is kind of pointless considering the IP-address still leaks to the server by default. And the UUID means all your metadata can be tied together. The social graph is revealed to the server so unless everyone keeps rolling their IDs and exchanging them over some other channel, it's pretty much impossible to hide metadata from a malicious server running statistical analysis. Even if you're not malicious, there's no way to know if your server has been compromised. Or, if you somehow can harden your server against the NSAs of this world, please, go work for the Freedom of The Press Foundation or something.
"Freedom to extend the protocol."
When the protocol fails to mandate BASIC security features like E2EE, it's kind of pointless to talk about the possibilities of extendability. There's always going to be maintainers and theyneed to prioritize, so there's always going to be someone who decides whether something will be implemented by them. Signal doesn't forbid pull-requests if you want something done. The nice thing is, it's at least six times faster to do it for Signal.
"Freedom to write your own client, or build whole new as-yet-unimagined systems on top."
So it's the freedom of the developer we're talking about. Reminds me of BSD vs GPL (BSD says developer has freedom to fuck over users with proprietary fork, GPL says user has right to not be abused like that, and that developers have the obligation to not do that). It's the rights of the users that matter. That is, human rights. You can merge as-yet-unimagined systems to Signal. You might face initial criticism because it needs to be secure by default. But it's not like Moxie will show you the finger for proposing something before it's discovered or announced. I have first hand experience with this: https://github.com/signalapp/Signal-Android/issues/4171
"It’s true that if you’re writing a messaging app optimized for privacy at any cost, Moxie’s approach is one way to do it."
If you consider privacy is a human right, developer freedom isn't, it's easier to see who has their priorities in order.
"you end up thoroughly putting all your eggs in one basket, trusting past, present & future Signal to retain its values, stay up and somehow dodge compromise & censorship… despite probably being the single highest value attack target on the ‘net."
So which one is easier to subvert, community of experts constantly under scrutiny by peer experts trying desperately to make a name for themselves, or open work group on protocol that still isn't secure by default, and that is much more susceptible to stagnation via bike-shedding and mission hijacking. OpenPGP work group still hasn't agreed on v5 fingerprint, the SHAppening happened five years ago. I'm going to have to disagree and say I don't have faith in unnecessarily large organizations.
I'm just going to say this FUD is worth being pointed out, but that it's not worthy of dissection.
"We owe the entire success of the Internet (let alone the Web) to openness, interoperability and decentralization."
A thought that was denounced in the 36c3 talk whether you watched the stream or not.
"To declare that openness, interoperability and decentralization is ‘too hard’ and not worth the effort when building a messaging solution is to throw away all the potential of the vibrancy, creativity and innovation that comes from an open network"
The worth was not addressed by this writing in any way, and the practical problems that far outweigh the idealistic goals were discussed by Moxie because what matters is the human rights to privacy of the users of the tool, not whether the infrastructure is based on idealistic ideas that don't offer tangible security benefits in practice.
Like Moxie said, prove that decentralization works by doing the bare necessities of implementing E2EE, then it's worth discussing whether the idealism part matters, and if decentralization has something useful to offer.
"Sure, you may end up with a super-private messaging app - but one that starts to smell alarmingly like a walled garden like Facebook’s Internet.org initiative, or an AOL keyword, or Google’s AMP. "
The negative connotations of these companies are about lack of respecting privacy. It's really weird to essentially say "you end up with super private app that shares other commonalities with privacy invading companies". Walled garden isn't ideal, but for now, it's more secure and that's what matters more to users.
"So, we continue to gladly take up Moxie’s challenge to prove him wrong - to show that it’s both possible and imperative to create an open decentralized messaging platform which (if you use reputable apps and servers) can be as secure and metadata-protecting as Signal…"
That's the attitude we need. Now go out there and use your preferred methods to make the idealistic protocol secure by default! Just don't expect me or anyone else to recommend its use before that happens.
"and indeed more so, given you can run your server off the grid, and don’t need to register with a phone number"
Will you be getting rid of IP-address leak to servers too? Quick jabs in closing notes that aren't thought out too well are not very nice.
"and in future may not even need a server at all."
Also maybe reconsider ending your refutal of criticism towards decentralized architecture by hinting that users should look towards upcoming P2P architecture.
Signal could be more tolerable if they did not threaten and harass those who develop third-party clients, citing their unreasoned claims that they somehow "burden" them (1). They cannot demand pull requests if they treat the community like that. Depending on the locale, even frivolous lawsuits can be a real nuisance.
Encryption is also not the only thing that matters. Amateurish functionality omissions are really annoying. For example, in 2015, Signal developers removed the option to create, join or leave groups in the desktop client (2), and they apparently haven't still fixed it. They don't want, nor does anyone else. Maybe a less hostile approach towards community would yield better results.
While I agree with you that this Matrix e2ee thing has took way, way too long, let's not pretend that everything happens at time in those walled garden systems...
> I just prefer to present something as part of a conversation that's happening in a place, rather than a webinar that I'm broadcasting forever to the world.
To me it sounds an awful lot like not wanting to be scrutinized or held accountable for what he says.
I also find this rather disappointing as it excludes anyone who is unable, for whatever reason, to be at his talks from hearing what he has to say. Given how influential he's been in this domain, this sadness me quite a bit.
> I have less faith in the internet as a place where a conversation can happen
This feels a bit ironic, given he's built an enterprise on enabling conversations to happen on the internet, though arguably only with a limited set of people.
> , and the timelessness of it decontextualizes.
Not quite sure what that's supposed to mean. Perhaps it's a language barrier thing, but I can't parse that into something sensible.
In addition to writing on the Signal blog and on Twitter, he's on HN regularly addressing questions about what he's doing; you've had plenty of opportunities to engage with him directly. This seems like a swipe you're making for its own sake.
1. Does the same thing not also apply to the blog post he authored, which contains the exact same points?
2. Is a talk where you get a big stage to preach your opinion from and take two questions at the end really the best way to do this? As opposed to say, a panel discussion or similar.
He wants to have a conversation where he can use shorthand that won't be turned against him later through decontextualized misunderstanding. This doesn't sound unreasonable to me at all. In fact, it's something we take advantage of frequently as individuals.
If I were a high-profile person recorded for everything I did I'd almost certainly be raked over the coals for "Just kill all the apaches. They are fucking useless." when talking to a friend as we hacked on apache running in forked mode and spawned a million processes that can't respond. This is why I use nginx now. Much safer.
Moxie has always gaslit users with legitimate concerns because addressing them would mean giving up power. Signal is a self serving design and driven by self serving decisions. I've written about this in depth before:
I still stand by everything I said here, and lots more that goes unsaid in this article. Every single weird decision Signal makes is not because they've reasonably decided to come down on some side of the fence that others haven't - it's because their decisions serve moxie's wants above anyone else.
No personal attacks on HN, please, regardless of how right you are or feel, or how wrong someone is or you feel they are. Maybe you don't owe that person better, but you owe this community better if you're posting here.
And if we extrapolate your logic, we can never comment on anyone's bad behavior at all. My complaints are on topic for the article in question, I'm not just swinging at Moxie at random here.
The "beating your wife" bit comes with words like "gaslight", "self-serving", and "moxie's wants above all else". I'm trying to imagine what the comment originally said, because the one you've edited is obviously a personal attack.
Not to mention the fact that you appear to have just conceded my point. "But we were talking about Bob!" doesn't make it OK to ask Bob whether he's stopped beating his wife.
XMPP was supposed to solve all those problems when it came out in the early 2000s. But then all the big tech companies who build "ecosystems" decided to push their own applications, all incompatible with one another. So here we are again with this proliferation of programs that really only do one thing: communication. It's like the 90s / early 2000s with the proliferation of instant messengers: ICQ, AIM, Yahoo, MSN, and on and on and on. The players are different, but the game is still the same. I suspect that twenty years from now, when the players have all changed yet again, there will still be one reliable method of reaching me: IRC.
If the Googles and Whatsapps and Facebooks of the world had been around in the early 90s, you'd have one email client from Facebook for mailing Joe and Fred, an email client from Google for mailing Mary and Jane, and an email client from Whatsapp for mailing Alice and Bob. Thankfully, email became entrenched before that could happen.
I want messaging to be like email, where I use one and exactly one program to communicate with all of my contacts, regardless of what server they use. People say that federation is more complicated than centralization. I'm sure that's true for developers, but in fact, federation can be vastly simplifying for an end user. I'm a fundamentally lazy person. Having to learn all these different messaging tools is frankly a waste of my time. All I want is a federated protocol and an open system, be it Matrix, XMPP, or something else.
As a final aside, you know what else that bugs me? The word "ecosystem". I worked for a big tech company for a while, and the only people I ever heard use that word were people out to build a walled garden.