I just finished watching this, it's excellent. It's a much simpler and more cogent counter argument to people's idealogical interest in decentralization from Moxie of Signal. Really worth watching in the context of privacy, decentralized internet services as well as clear thinking about product and the future.
It's interesting that the things he says are bad aspects of decentralization (that protocols become fixed) are precisely the reasons that people want decentralization. No single actor can shift the protocol out from under a distributed system. That makes it something that can be trusted.
But for the reasons he's saying, it's very unlikely that will win, everything starts decentralized going from 0 to 1 protocol wise, and then shifts to centralization for UX.
1) This was posted a few days ago when it was first posted to CCC's website, where it already had a lot of conversation. I recommend people read the posts there, as this video has a number of issues in its argument.
2) Moxie did not want to be recorded at this event, and was told he wouldn't be recorded, and yet the video was posted anyway for a bit before the CCC took it down (which is why it is being hosted on PeerTube).
Oh wow that is definitely not cool. I’m happy I got to watch it, but if he didn’t want to be recorded that is a massive breach of trust from CCC.
I got to hear Moxie speak at RWC when he received the Levchin prize and I gotta say it was one of the best talk I’ve heard and it’s a shame he didn’t want to be recorded back then as well.
It's a volunteer-ran event and mistakes happen. Probably as simple as "someone messed up the talk metadata and VOC wasn't aware that it shouldn't be recorded".
Its ironic that it is made available on a decentralized platform, since now it cannot be taken down as easily. Especially considering the topic of the video.
Actually I think it's quite a good idea if it stays up. It will show him the consequences of what he's preaching. A taste of his own medicine. (I support laws like the right to be forgotten, and I believe decentralisation to be a bad idea because it defeats those laws.)
that argument depends on the cooperation of the centralized parties in power, whose motivations are not necessarily aligned with (in fact, are usually opposed to) a person's desire to be forgotten.
> Its ironic that it is made available on a decentralized platform, since now it cannot be taken down as easily.
The irony is that this example showcases an Achilles Heel of decentralized services — an inability to moderate toxic and/or illegal content — which gives power to everyone who would make all decentralized services illegal.
Question: How does PeerTube handle child pornography?
Does he ever explain why he doesn't want recordings to be made? It seems to me like he's just interested at taking at people, but not interested at being talked to. More like a preacher than a presenter.
If you click the link I linked, the explanation is right there. FWIW, as much as I disagree with just about everything Moxie works on, I totally appreciate his issues with being recorded at a conference: it totally ruins the talk for the people who are there as now it has to be a talk that can exist without the context of "who tends to come to this event" or "the talks that came right before it on the same track" or even "stuff going on around the time of the event"; so you end up having to plan and present a talk that someone in a different field a year later is going to be able to watch without being confused about the whole thing... if you are going to do that kind of talk you should just do it at home in front of a green screen and spend time editing the video and really nailing it for a global audience instead of going to a conference to give a talk to people in person.
For Domain Fronting in particular it's embarrassing that pro-distributed people have taken it as a "victory" that AWS and Google disabled domain fronting used as an anti-censorship mechanism for Signal. That's both a terrible look "Ha! Our services are so unpopular nobody even cares to block them" and a grave misunderstanding of the situation.
The big CDNs and cloud service providers are actually very enthusiastic about domain fronting, what they blocked was the technical mechanism abused to make it happen, because it causes their reliability teams pain. Domain fronting means you figure out this is a request for thing-a.example.com using SNI, your backend systems cue up the Thing A service... and then during HTTP headers the client insists it intended to talk to thing-b.example.com all along instead and you've got to either give an error or somehow backtrack and make that happen. Doing this is very easy, indeed the default, in say one Apache httpd on a Linux box. But Google or AWS isn't a data centre full of Apache httpds on Linux boxes, it's a bit more complicated than that.
When I say they're enthusiastic I don't mean just empty words, the active direction of QUIC, eSNI, the revised HTTP service record for DNS and so on are all aligned with the domain fronting concept, just not in the form of abusing different protocol layers. They want to know early in the connection which service you're intending to reach, while preserving your privacy from snooping governments, etc.
> 5 years are not a long time to update the entirety of the internet
Given that WhatsApp manages to update its entirety of the internet in a few days, I'd say that is quite a long time. Is there a name for this fallacious "arguing for/against something without comparing it to alternatives"?
> But the answer to this problem would logically be that we need to increase our efforts to change that by reducing the number of GMail accounts and increasing the number of self-hosted email servers, right?
No, the argument is that decentralized services will mostly be centralized anyway due to the fact that centralization can move faster. Everyone has Gmail on the other end because Gmail is better than other services (that is the argument, not what I personally believe, as I think Fastmail is better).
Given that decentralization will lead to the existence of a few large points of centralization anyway, we should make those points secure, and centralizing allows us to do that better, the argument goes.
> While this is an issue, there are solutions to this problem, one being nomadic identities.
The point is that nobody has zero-knowledge nomadic identities. AFAIK Signal were the first ones to come up with a practical implementation a few days ago.
> For some reason Marlinspike confuses a decentralized system with a centralized, but distributed system. It even reads “Centralized Service” on his slides…
Moxie is talking about a centralized service. It says centralized on the slides, he said centralized twice, the author seems confused here.
> These suites act as maps that point a way through the XEP jungle.
Yes, and a centralized service needs none of this.
Personally, I don't see this article debunking many of the points. Decentralized is better for censorship-resistance, and I prefer it, but it's better for that because centralized platforms aren't usually designed for censorship resistance. Signal knows nothing about its messages, and thus it's much harder to censor people using it.
I feel like Moxie made some good arguments, and would like to see some solutions in making decentralized servers and clients more easily upgradable. Signal's approach works for signal, but it also works for almost every other person, since everyone seems happy to use Facebook or Slack or whatnot instead of Riot for their communications. I really like what Mastodon is doing in the federated microblogging space, and hopefully that will extend to other areas.
> Given that WhatsApp manages to update its entirety of the internet in a few days, I'd say that is quite a long time. Is there a name for this fallacious "arguing for/against something without comparing it to alternatives"?
You're comparing the wrong thing there. The alternative to a protocol specification is not a closed source implementation of a proprietary system. How fast Windows Update can change their architecture doesn't really matter a jot when looking at changes to apt, etc.
We can instead look at how long it took to update the IMAP spec to include TLS, or the move towards requiring OAUTH.
The original argument was comparing centralized vs decentralized services. We aren't talking about closed vs open, the point remains even if you substitute WhatsApp with Signal.
I wasn't talking about closed/open either. Outlook and Thunderbird are both clients that use known specifications. One is open, one is closed.
Getting both updated to the specification takes more time (and in Outlook's case may never happen), then updating something where no specification exists.
Good points regarding HTTP, but XMPP is an excellent example on how decentralisation can be detrimental to the user experience.
A large percentage of XMPP users are using a lowest-common-denominator client like Pidgin that supports only a small fraction of XEPs. The excellent Conversations client for Android is only on par with Signal if you use it to talk to other Conversations users using a modern server like Prosody. Good luck with simple tasks like sending a picture, otherwise :(
The only truly successful decentralized application protocol besides HTTP is SMTP, and even that is becoming increasingly centralized, with vendors like Google extending it with extra features on their own platform.
This kind of "protocol ossification" of decentralized protocols is unfortunate, and can be seen even in core internet protocols. Any attempt to improve upon TCP like Multipath TCP has faced huge issues with overly restrictive middleboxes and very slow propagation of new kernels, leading to userspace TCP reimplementations like gQUIC, now standardized as HTTP/3.0.
While I found the talk more compelling, it's also worth mentioning Moxie's 2016 article, "Reflections: The ecosystem is moving", for several of the key points: https://signal.org/blog/the-ecosystem-is-moving/
I would be interested in a blogpost going through Moxie’s argument with Matrix. I don’t know much about the project but it seems like Matrix doesn’t target normal users no?
Matrix absolutely targets normal users, much as the Web does too. I guess on the Matrix side we'll put a blog post together to respond to Moxie's points.
I'm not Moxie, and I can't speak for him, but I have a good idea what the arguments are as I "do crypto". These aren't my opinions necessarily, I'm just repeating what I believe the arguments to be.
This can be summarized quite quickly (and for all federated/distributed protocols). Should you need to deploy some kind of feature or security upgrade to the protocol, a centralized system lets you do this for everyone (and more or less force them into it). A distributed system has the potential to end up like TLS, where "ciphersuite agility" can be a negative in that you end up supporting something relatively weak or otherwise problematic because one member of the network refuses to turn it off "just in case" one of their customers need it.
This is the distributed vs centralized part. From a security perspective, Moxie would also likely take issue with the server-side metadata in Matrix. If your "homeserver" is hacked (or otherwise accessed), my understanding is that it would likely contain a fair amount of information on who you communicate with and what rooms you are in, or you would be able to piece it together. Here's the schema for data stored server-side in the reference server: https://github.com/matrix-org/synapse/blob/master/synapse/st...
Signal by contrast is designed precisely to minimize the amount of data users expose even to Signal's own servers. Profile information, group membership etc, it's all encrypted.
Finally, Matrix doesn't E2E by default - not all clients support its double ratchet implementation. This has been getting better over time, but I'm not sure if you can still negotiate cleartext connections all the time or force clients to downgrade. Experience has shown leaving users to consciously turn on encryption is a bad idea. This is also a problem in PGP, XMPP/OMEMO/OTR, Telegram, SMIME etc. If you use Signal, WhatsApp or Wire, you cannot fail to turn on the crypto, which means non-technical users benefit from it without even realizing it.
you can’t really downgrade today. so yeah, if your client doesn’t do e2e you will either be running blind or you’ll need to use a daemon like pantalaimon to bridge the gap.
the greatest concern to centralized systems like Signal is not ease of use, its censorship and de-platforming. In China, Signal servers are outright banned. No servers, no secure communications.
In the United states players like Cloudflare have demonstrated twice the can and will de-platform entire communities for controversial speech. senator Joseph Lieberman, with a single phonecall, had wikileaks immediately deplatformed from AWS. All it takes is a violation of a term of service and that service vanishes.
Increasingly Moxie seems to value the developer experience over any project goal for Signal. its still AWS, it still depends greatly on google services and play store for distribution. Begrudgingly hes added a secret-ish link on the signal website to download the APK directly, but he still ardently refuses to publish the package on FDroid.
and as for his "federated services are stuck in time" argument, these are glaring architectural issues that have plagued his application for five years. The only tangible evolution of signal in the past year has been new cat and dog stickers that no one asked for.
they're legitimate problems if you value transparency and free speech.
But I get it. We've seen this before.
First they came for the socialists, and I did not speak out—
Because I was not a socialist.
Then they came for the trade unionists, and I did not speak out—
Because I was not a trade unionist.
Then they came for the Jews, and I did not speak out—
Because I was not a Jew.
Then they came for me—and there was no one left to speak for me.
It's important for Signal's goals, "secure global communication" but it's not important for people who enjoy tinkering and like to play at James Bond once in a while.
For example, if you have Signal's goals you want Henry your hairdresser, Peter the guy who sells you untaxed vodka, and Betty the local baker to all have the same secure system for messaging and it just works even though lots of the messages are mundane and don't "need" to be secured.
But if you want to play James Bond then it's _cool_ that you had to download a alpha preview version of a clunky app and then Peter had to keep rebooting his laptop so he could tell you "The merchandise will be delivered to the usual place tomorrow night". You felt like a real bad ass turning on "Advanced Crypto: Experimental" in the Special Features preferences window and seeing it say "These messages are now secret!" in your chat window. Being interrupted with Betty's broadcast reminder of the discount on sour dough loaves through January stops it feeling special.
What a cynical comment. Signal has bleeding edge cryptography. It's virtually the most secure way to exchange messages available right now for the average person. And they keep getting better.
You're chastising them for trying to get users. Right.
All nice and true (thus upvoted), but it's not really the point he's making. The point he's making is that most modern applications require more than 1-3 developers, and therefore you need to consider the development cost and infrastructure as part of the whole consideration. So he advocates to work on decreasing these costs instead of finding another high-level distributed architecture that is running on centralized infrastructure (the internet) and that is either forgotten in a few months or built by a centralized development organization.
These happen to be important tools for a "social" thing like a messenger for helping the average person want to use it. People (generally) like stickers, and adding them makes signal an easier sell to people who might not understand the value of encryption.
> The only tangible evolution of signal in the past year has been new cat and dog stickers that no one asked for.
Oh come on, that's just not true (and I don't mean by that that the most common complaint in every thread about Signal was that lack of sticker support was hindering people's efforts of getting their friends to use Signal, although that is also true). Things the Signal team worked on in the past year include group management without revealing information about the group (including its existence) to the server (https://signal.org/blog/signal-private-group-system/) and secure value recovery (https://signal.org/blog/secure-value-recovery/), which lays the groundwork for abandoning phone numbers as identifiers and secure cloud backups of messaging history. Just because these haven't been rolled out yet doesn't mean nothing is happening. Signal also added iPad support in the past year, which is something many people have wished for for a long time.
A little bit further back, Sealed Sender (https://signal.org/blog/sealed-sender/) means that the server no longer needs to know who is sending a message (previously, it did to prevent spoofing and for rate limiting and abuse protection). Private contact discovery (https://signal.org/blog/private-contact-discovery/) allows matching of address books without revealing them to the server.
Until quite recently, there were fewer than a handful of people working on Signal, but with the funding they have now, they've ramped up hiring and have started working on features like the above. It just takes some time.
Also, Signal works without Google Play Services installed.
Mmm? The existing groups were secure and private, but lacked some useful functionality. That's exactly what I'd expect to get implemented with "security and privacy first" as priority.
For example Signal didn't have a way for a group to boot out a member against their will. If you didn't want to be in a group with Mary any more, and she wouldn't voluntarily leave, you would all need to go form a new group. Signal's servers can't know who is in a group (privacy) so it took a bunch more heavy lifting to develop this feature.
Surely the other way around to do this would indeed not be putting "security and privacy first" ?
> For example Signal didn't have a way for a group to boot out a member against their will.
This article says just as much. Sure, you could brute force a 128 bit key to get into a random group. And if you were kicked out of a group, you could re-add yourself if you had saved the group key. But even the article says it's not super likely.
> The only tangible evolution of signal in the past year has been new cat and dog stickers that no one asked for.
That's only true if by "no one" you mean "99% of people". All my friends care about is that Signal doesn't support stickers, "privacy-preserving" doesn't help convert people from Facebook as much as you'd think.
> The only tangible evolution of signal in the past year has been new cat and dog stickers that no one asked for.
I've been asking for them! I've been asking for them for years, in fact. I'm chuffed that my tiny little crusade finally bore fruit, and that the implementation they landed on is precisely as I always envisioned it.
It was the #1 excuse friends made for why they wouldn't consider Signal. But also, personally, I really do get a lot of value out of the sticker system in, say, Telegram, and it's great to have available for my Signal conversations, too.
What are the use cases for stickers? I cannot seem to get them. They seem to express the ~same thing as emojis while being non-standard and not guaranteed to be available. I guess there might also be some overlap with "gifs", but with less flexibility.
Sticker are fun and can convey nuances and intended personality emojis don't in the same bandwidth. Also always just two taps away in the same place, as opposed to gifs. Depending on your communication style, this may or may not be a feature for you.
I have also seen stickers as a hurdle for Signal adoption for years.
AFAIK, LINE was the first IM platform to make sticker-use widespread. Imagine you're about to meet up with a friend downtown for a Sunday brunch and the different situations and moods you can encounter on the way, check out their initial starter pack and I think you can see how this can actually make communication more efficient.
So a kind of middle ground between emojis and gifs? That makes sense.
I'll admit I still don't find it appealing from any examples I've seen so far and I've never encountered sticker usage "in the wild" with my contacts to get a hands-on feeling of it.
Yeah, I first encountered them living in East Asia where the majority use them consistently (including foreigners who generally pick it up pretty fast).
I'd probably have your stance if I hadn't experienced it IRL.
"It was the #1 excuse friends made for why they wouldn't consider Signal."
I keep reading this claim about stickers and it seems like one of those wishing "if we cover 80% of the feature desires of 100% of the people" delusions.
They won't migrate. If the privacy pitch isn't enough, nothing else will succeed.
Which is why I agree with GP. Signal's entire raison d'être is privacy. Yet increasingly the updates are "look, we're a kind-of-shittier-version-of-imessages".
As an aside, they update way too often. No one would complain about updates for actual privacy or security issues, but the virtually daily updates seem to be primarily "moved stuff around".
> the greatest concern to centralized systems like Signal is not ease of use, its censorship and de-platforming. In China, Signal servers are outright banned. No servers, no secure communications.
Funny thing, one of the only western apps that worked without a fuss in China (with Chinese mobile internet) was Signal. I did not test many others, but WhatsApp/Viber/... were blocked.
I am not 100% happy with Signal, but it is one of the best solutions currently available for my constraints. And even if I don't agree with some choices they make, I can at least understand why they made them. Hopefully they can continue improving and evolving.
"You are blocking Javascript, and we totally get that. However this endpoint uses Angular, so the front end is in full JavaScript and won't work without it.
There will be other non JS-based clients to access PeerTube, but for now none is available. Be sure we will update this page with a list once alternative clients are developed. You can certainly develop you own in the meantime as our code is open source and libre software under GNU AGPLv3.0.
There might be numerous reasons you refuse to use JavaScript. If it has just to do with security (or lack thereof) of JavaScript-based webapps, then depending on your threat menace you might want to go through the code running on the node you are trying to access, and look for security audits.
We are sorry but it seems that PeerTube is not compatible with your web browser.
Please try with the latest version of Mozilla Firefox.
If you think this is a mistake, do not hesitate to report it."
The standard tool for downloading videos from websites, youtube-dl, also works great with PeerTube. (Don't let the name mislead you. YouTube is only one of hundreds of supported providers.)
I do have to give peertube some thanks though - it might require javascript, but there's a large and obvious download button (at least on the mobile page).
Reminds me of when Google used to provide JSON from YouTube (and other) endpoints without requiring users to "sign up".
# list instances
curl "https://instances.joinpeertube.org/api/v1/instances?start=0&count=5&sort=-createdAt"
# search an instance
curl "https://${instance}/api/v1/search/videos?start=0&count=50&search=$1"
# list video categories
curl https://${instance}/api/v1/videos/categories/
# list videos
curl "https://${instance}/api/v1/videos?start=0&count=500"
At the risk of burning away virtual points, I have the following observations and opinions. I respect the encryption technologies that Signal has developed, but I'm always frustrated with Signal as an app, platform and where it seems to be headed. Throughout this talk, the one quote that came to my mind for every point he was defending was this:
"It is difficult to get a man to understand something, when his salary depends on his not understanding it." ― Upton Sinclair
I also found it amusing when he said that it's easier to switch from WhatsApp to Telegram to Signal. The truth is that switching people from WhatsApp to Telegram, in my experience, will earn you brownie points because Telegram is a lot more feature rich than WhatsApp (let's keep the encryption part aside for the moment). If you manage to switch people from WhatsApp or Telegram to Signal, again in my experience, you'll lose credibility and trust because Signal, for all the money the foundation has, moves at snail's pace. Moxie's argument early in the talk about centralized systems being able to change fast just does not apply to Signal. It still lacks stability in delivering messages. Its UX for joining groups, re-joining groups after reinstalling your OS, etc., completely sucks. Don't even get me started on Signal treating its users as if everyone uses a burner phone and doesn't care about keeping their conversations when they switch devices or even have to wipe a device and get it running again (Signal on iOS still explicitly prohibits backups after so many years, and the Signal team's most recent addition to the app was stickers!).
The example for switching from WhatsApp to Telegram to Signal being easy because it's tied to phone numbers is disingenuous. Following how WhatsApp and Telegram identify their users may not be the best thing to do. Signal assumes that people always have the same phone number and that phone numbers are the best way to identify people. But it fails to acknowledge that using email addresses to sign up (at least as an option for those who want to avoid phone numbers), like how Wire does, provides people a choice in how they want to appear on a platform. I know people who don't want to use a phone number based platform because they don't want all their phone contacts to know that they're on a particular platform (this was partially solved by Telegram in an update a few months ago, where you have control on who gets to know that you're using it, even if they have your number in their address book). His non-answer for the question around the 38 minute mark on Signal being tied to a phone number and that being a risk shows that Signal is stuck with what he/they believe is ideal, and refusing to acknowledge that this is a big problem for some sections of people...the very people Signal claims to be most useful for.
72 comments
[ 6.3 ms ] story [ 134 ms ] threadhttps://news.ycombinator.com/item?id=21904041
2) Moxie did not want to be recorded at this event, and was told he wouldn't be recorded, and yet the video was posted anyway for a bit before the CCC took it down (which is why it is being hosted on PeerTube).
https://twitter.com/moxie/status/1211427007596154881?s=21
I got to hear Moxie speak at RWC when he received the Levchin prize and I gotta say it was one of the best talk I’ve heard and it’s a shame he didn’t want to be recorded back then as well.
The irony is that this example showcases an Achilles Heel of decentralized services — an inability to moderate toxic and/or illegal content — which gives power to everyone who would make all decentralized services illegal.
Question: How does PeerTube handle child pornography?
It's an excellent talk, though.
The big CDNs and cloud service providers are actually very enthusiastic about domain fronting, what they blocked was the technical mechanism abused to make it happen, because it causes their reliability teams pain. Domain fronting means you figure out this is a request for thing-a.example.com using SNI, your backend systems cue up the Thing A service... and then during HTTP headers the client insists it intended to talk to thing-b.example.com all along instead and you've got to either give an error or somehow backtrack and make that happen. Doing this is very easy, indeed the default, in say one Apache httpd on a Linux box. But Google or AWS isn't a data centre full of Apache httpds on Linux boxes, it's a bit more complicated than that.
When I say they're enthusiastic I don't mean just empty words, the active direction of QUIC, eSNI, the revised HTTP service record for DNS and so on are all aligned with the domain fronting concept, just not in the form of abusing different protocol layers. They want to know early in the connection which service you're intending to reach, while preserving your privacy from snooping governments, etc.
Given that WhatsApp manages to update its entirety of the internet in a few days, I'd say that is quite a long time. Is there a name for this fallacious "arguing for/against something without comparing it to alternatives"?
> But the answer to this problem would logically be that we need to increase our efforts to change that by reducing the number of GMail accounts and increasing the number of self-hosted email servers, right?
No, the argument is that decentralized services will mostly be centralized anyway due to the fact that centralization can move faster. Everyone has Gmail on the other end because Gmail is better than other services (that is the argument, not what I personally believe, as I think Fastmail is better).
Given that decentralization will lead to the existence of a few large points of centralization anyway, we should make those points secure, and centralizing allows us to do that better, the argument goes.
> While this is an issue, there are solutions to this problem, one being nomadic identities.
The point is that nobody has zero-knowledge nomadic identities. AFAIK Signal were the first ones to come up with a practical implementation a few days ago.
> For some reason Marlinspike confuses a decentralized system with a centralized, but distributed system. It even reads “Centralized Service” on his slides…
Moxie is talking about a centralized service. It says centralized on the slides, he said centralized twice, the author seems confused here.
> These suites act as maps that point a way through the XEP jungle.
Yes, and a centralized service needs none of this.
Personally, I don't see this article debunking many of the points. Decentralized is better for censorship-resistance, and I prefer it, but it's better for that because centralized platforms aren't usually designed for censorship resistance. Signal knows nothing about its messages, and thus it's much harder to censor people using it.
I feel like Moxie made some good arguments, and would like to see some solutions in making decentralized servers and clients more easily upgradable. Signal's approach works for signal, but it also works for almost every other person, since everyone seems happy to use Facebook or Slack or whatnot instead of Riot for their communications. I really like what Mastodon is doing in the federated microblogging space, and hopefully that will extend to other areas.
You're comparing the wrong thing there. The alternative to a protocol specification is not a closed source implementation of a proprietary system. How fast Windows Update can change their architecture doesn't really matter a jot when looking at changes to apt, etc.
We can instead look at how long it took to update the IMAP spec to include TLS, or the move towards requiring OAUTH.
Getting both updated to the specification takes more time (and in Outlook's case may never happen), then updating something where no specification exists.
A large percentage of XMPP users are using a lowest-common-denominator client like Pidgin that supports only a small fraction of XEPs. The excellent Conversations client for Android is only on par with Signal if you use it to talk to other Conversations users using a modern server like Prosody. Good luck with simple tasks like sending a picture, otherwise :(
The only truly successful decentralized application protocol besides HTTP is SMTP, and even that is becoming increasingly centralized, with vendors like Google extending it with extra features on their own platform.
This kind of "protocol ossification" of decentralized protocols is unfortunate, and can be seen even in core internet protocols. Any attempt to improve upon TCP like Multipath TCP has faced huge issues with overly restrictive middleboxes and very slow propagation of new kernels, leading to userspace TCP reimplementations like gQUIC, now standardized as HTTP/3.0.
https://matrix.org/blog/2019/12/19/welcoming-mozilla-to-matr...
https://about.riot.im/
I personally would love to see the blog post on this.
This can be summarized quite quickly (and for all federated/distributed protocols). Should you need to deploy some kind of feature or security upgrade to the protocol, a centralized system lets you do this for everyone (and more or less force them into it). A distributed system has the potential to end up like TLS, where "ciphersuite agility" can be a negative in that you end up supporting something relatively weak or otherwise problematic because one member of the network refuses to turn it off "just in case" one of their customers need it.
This is the distributed vs centralized part. From a security perspective, Moxie would also likely take issue with the server-side metadata in Matrix. If your "homeserver" is hacked (or otherwise accessed), my understanding is that it would likely contain a fair amount of information on who you communicate with and what rooms you are in, or you would be able to piece it together. Here's the schema for data stored server-side in the reference server: https://github.com/matrix-org/synapse/blob/master/synapse/st...
Signal by contrast is designed precisely to minimize the amount of data users expose even to Signal's own servers. Profile information, group membership etc, it's all encrypted.
Finally, Matrix doesn't E2E by default - not all clients support its double ratchet implementation. This has been getting better over time, but I'm not sure if you can still negotiate cleartext connections all the time or force clients to downgrade. Experience has shown leaving users to consciously turn on encryption is a bad idea. This is also a problem in PGP, XMPP/OMEMO/OTR, Telegram, SMIME etc. If you use Signal, WhatsApp or Wire, you cannot fail to turn on the crypto, which means non-technical users benefit from it without even realizing it.
Edit: We're also working on minimising metadata by storing it all clientside and running peer-to-peer; see https://fosdem.org/2020/schedule/event/dip_p2p_matrix/
In the United states players like Cloudflare have demonstrated twice the can and will de-platform entire communities for controversial speech. senator Joseph Lieberman, with a single phonecall, had wikileaks immediately deplatformed from AWS. All it takes is a violation of a term of service and that service vanishes.
Increasingly Moxie seems to value the developer experience over any project goal for Signal. its still AWS, it still depends greatly on google services and play store for distribution. Begrudgingly hes added a secret-ish link on the signal website to download the APK directly, but he still ardently refuses to publish the package on FDroid.
and as for his "federated services are stuck in time" argument, these are glaring architectural issues that have plagued his application for five years. The only tangible evolution of signal in the past year has been new cat and dog stickers that no one asked for.
This has always been the case.
What are the two instances?
And a lot of people gave Cloudflare a lot of grief for not de-platforming them sooner.
But, hey. This person sees that as a fatal flaw.
https://www.wired.com/story/free-speech-issue-cloudflare/
But I get it. We've seen this before.
https://en.wikipedia.org/wiki/First_they_came_...Where are the official project goals for Signal? All I was able to gather is please use our app instead of not ours.
Signal has always focused on functionality that would get them the most users with the least amount of effort.
Decentralized or privacy and security first platforms dont get 50 million dollar donations. Everyone has a business model.
But that is extremely important for a messaging app.
It's irrelevant how secure it is if nobody is using it. Unless you are into just talking to yourself.
Signal keeps on upgrading its security feature as well, they are not being left behind, and until quite recently, they didn't really had enough devs.
For example, if you have Signal's goals you want Henry your hairdresser, Peter the guy who sells you untaxed vodka, and Betty the local baker to all have the same secure system for messaging and it just works even though lots of the messages are mundane and don't "need" to be secured.
But if you want to play James Bond then it's _cool_ that you had to download a alpha preview version of a clunky app and then Peter had to keep rebooting his laptop so he could tell you "The merchandise will be delivered to the usual place tomorrow night". You felt like a real bad ass turning on "Advanced Crypto: Experimental" in the Special Features preferences window and seeing it say "These messages are now secret!" in your chat window. Being interrupted with Betty's broadcast reminder of the discount on sour dough loaves through January stops it feeling special.
You're chastising them for trying to get users. Right.
developing open source privacy technology that protects free expression and enables secure global communication.
These happen to be important tools for a "social" thing like a messenger for helping the average person want to use it. People (generally) like stickers, and adding them makes signal an easier sell to people who might not understand the value of encryption.
This is not true. Signal has been adding some very novel and bleeding edge privacy enhancements, such as sealed sender (https://signal.org/blog/sealed-sender/) and private groups (i.e. encrypted group state, https://signal.org/blog/signal-private-group-system/).
That said, it's also untrue that federated services are stuck in time. See Matrix (https://matrix.org/).
Oh come on, that's just not true (and I don't mean by that that the most common complaint in every thread about Signal was that lack of sticker support was hindering people's efforts of getting their friends to use Signal, although that is also true). Things the Signal team worked on in the past year include group management without revealing information about the group (including its existence) to the server (https://signal.org/blog/signal-private-group-system/) and secure value recovery (https://signal.org/blog/secure-value-recovery/), which lays the groundwork for abandoning phone numbers as identifiers and secure cloud backups of messaging history. Just because these haven't been rolled out yet doesn't mean nothing is happening. Signal also added iPad support in the past year, which is something many people have wished for for a long time.
A little bit further back, Sealed Sender (https://signal.org/blog/sealed-sender/) means that the server no longer needs to know who is sending a message (previously, it did to prevent spoofing and for rate limiting and abuse protection). Private contact discovery (https://signal.org/blog/private-contact-discovery/) allows matching of address books without revealing them to the server.
Until quite recently, there were fewer than a handful of people working on Signal, but with the funding they have now, they've ramped up hiring and have started working on features like the above. It just takes some time.
Also, Signal works without Google Play Services installed.
For example Signal didn't have a way for a group to boot out a member against their will. If you didn't want to be in a group with Mary any more, and she wouldn't voluntarily leave, you would all need to go form a new group. Signal's servers can't know who is in a group (privacy) so it took a bunch more heavy lifting to develop this feature.
Surely the other way around to do this would indeed not be putting "security and privacy first" ?
This article says just as much. Sure, you could brute force a 128 bit key to get into a random group. And if you were kicked out of a group, you could re-add yourself if you had saved the group key. But even the article says it's not super likely.
That's only true if by "no one" you mean "99% of people". All my friends care about is that Signal doesn't support stickers, "privacy-preserving" doesn't help convert people from Facebook as much as you'd think.
I've been asking for them! I've been asking for them for years, in fact. I'm chuffed that my tiny little crusade finally bore fruit, and that the implementation they landed on is precisely as I always envisioned it.
It was the #1 excuse friends made for why they wouldn't consider Signal. But also, personally, I really do get a lot of value out of the sticker system in, say, Telegram, and it's great to have available for my Signal conversations, too.
I have also seen stickers as a hurdle for Signal adoption for years.
AFAIK, LINE was the first IM platform to make sticker-use widespread. Imagine you're about to meet up with a friend downtown for a Sunday brunch and the different situations and moods you can encounter on the way, check out their initial starter pack and I think you can see how this can actually make communication more efficient.
https://www.line-stickers.com/moon-james/
I'll admit I still don't find it appealing from any examples I've seen so far and I've never encountered sticker usage "in the wild" with my contacts to get a hands-on feeling of it.
I'd probably have your stance if I hadn't experienced it IRL.
I keep reading this claim about stickers and it seems like one of those wishing "if we cover 80% of the feature desires of 100% of the people" delusions.
They won't migrate. If the privacy pitch isn't enough, nothing else will succeed.
Which is why I agree with GP. Signal's entire raison d'être is privacy. Yet increasingly the updates are "look, we're a kind-of-shittier-version-of-imessages".
As an aside, they update way too often. No one would complain about updates for actual privacy or security issues, but the virtually daily updates seem to be primarily "moved stuff around".
Funny thing, one of the only western apps that worked without a fuss in China (with Chinese mobile internet) was Signal. I did not test many others, but WhatsApp/Viber/... were blocked.
I am not 100% happy with Signal, but it is one of the best solutions currently available for my constraints. And even if I don't agree with some choices they make, I can at least understand why they made them. Hopefully they can continue improving and evolving.
There will be other non JS-based clients to access PeerTube, but for now none is available. Be sure we will update this page with a list once alternative clients are developed. You can certainly develop you own in the meantime as our code is open source and libre software under GNU AGPLv3.0.
There might be numerous reasons you refuse to use JavaScript. If it has just to do with security (or lack thereof) of JavaScript-based webapps, then depending on your threat menace you might want to go through the code running on the node you are trying to access, and look for security audits.
We are sorry but it seems that PeerTube is not compatible with your web browser.
Please try with the latest version of Mozilla Firefox.
If you think this is a mistake, do not hesitate to report it."
Usage: Download link:https://peertube.co.uk/static/webseed/12be5396-2a25-4ec8-a92...
I do have to give peertube some thanks though - it might require javascript, but there's a large and obvious download button (at least on the mobile page).
Reminds me of when Google used to provide JSON from YouTube (and other) endpoints without requiring users to "sign up".
"It is difficult to get a man to understand something, when his salary depends on his not understanding it." ― Upton Sinclair
I also found it amusing when he said that it's easier to switch from WhatsApp to Telegram to Signal. The truth is that switching people from WhatsApp to Telegram, in my experience, will earn you brownie points because Telegram is a lot more feature rich than WhatsApp (let's keep the encryption part aside for the moment). If you manage to switch people from WhatsApp or Telegram to Signal, again in my experience, you'll lose credibility and trust because Signal, for all the money the foundation has, moves at snail's pace. Moxie's argument early in the talk about centralized systems being able to change fast just does not apply to Signal. It still lacks stability in delivering messages. Its UX for joining groups, re-joining groups after reinstalling your OS, etc., completely sucks. Don't even get me started on Signal treating its users as if everyone uses a burner phone and doesn't care about keeping their conversations when they switch devices or even have to wipe a device and get it running again (Signal on iOS still explicitly prohibits backups after so many years, and the Signal team's most recent addition to the app was stickers!).
The example for switching from WhatsApp to Telegram to Signal being easy because it's tied to phone numbers is disingenuous. Following how WhatsApp and Telegram identify their users may not be the best thing to do. Signal assumes that people always have the same phone number and that phone numbers are the best way to identify people. But it fails to acknowledge that using email addresses to sign up (at least as an option for those who want to avoid phone numbers), like how Wire does, provides people a choice in how they want to appear on a platform. I know people who don't want to use a phone number based platform because they don't want all their phone contacts to know that they're on a particular platform (this was partially solved by Telegram in an update a few months ago, where you have control on who gets to know that you're using it, even if they have your number in their address book). His non-answer for the question around the 38 minute mark on Signal being tied to a phone number and that being a risk shows that Signal is stuck with what he/they believe is ideal, and refusing to acknowledge that this is a big problem for some sections of people...the very people Signal claims to be most useful for.