Signal Creator on Considerations for distributed and decentralized technologies
peertube.co.uk
peertube.co.uk
https://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).
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.
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.
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.
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.
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.
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...
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/
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."
peertube-dl(){ a=$(case $1 in "")sed t;;https://*)echo $1;esac|sed 's/videos/static/;s/watch/webseed/');curl -4O $a-720.mp4; }
Usage: peertube-dl https://peertube.co.uk/videos/watch/12be5396-2a25-4ec8-a92a-674b1cb6b270
echo https://peertube.co.uk/videos/watch/12be5396-2a25-4ec8-a92a-674b1cb6b270|peertube-dl
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".
# 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""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.