101–110 of 290 posts
Earlier quoted context omitted.
The solution is simple. Make the decentralized systems social, with reputation.
How do you prevent bots giving each other reputation?
Or at least, that's how you make it not matter. If spam-bot hands out reputation to spim-bot and then you get a bunch of garbage from spim-bot, derate everything coming from anyone that has given either of them reputation (and perhaps ignore their attestations also).
For the longest time, Signal wouldn’t work without Google Play Services, but Moxie (the founder of Open Whisper Systems and maintainer of Signal) finally fixed this in 2017. There was also a long time when Signal was only available on the Google Play Store. Why do I make a big deal out of Google Play and Google Play Services? Well, some people might trust Google, the company. But up against nation states, it’s no con…
Moxie forbids you from distributing branded builds of the Signal app, and if you rebrand he forbids you from using the official Open Whisper servers. Because his servers don’t federate, that means that users of Signal forks cannot talk to Signal users. This is a truly genius move. No fork of Signal4 to date has ever gained any traction, and never will, because you can’t talk to any Signal users with them. In fact, th…
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
Earlier quoted context omitted.
Yes, but I can get all the parties I want to talk to on my own server (if the need arises). About your point the connection itself being MITMed, I don't exactly understand how an active attacker sitting on my connection would undermine the connection? Presumably I have a way to verify the identify of my server. Please do elaborate if I'm missing something. Regardless an interesting thought.
If you're cryptographically checking that the connection you have is to your own server, sure, but I don't know any program that does that sort of thing. I guess if you're using TLS as a transport, the client handles that (if you have a self-signed certificate that you've told the client to trust exclusively).
Earlier quoted context omitted.
My experience with Matrix/Element and the various standard-compliant Matrix chat clients, in an ISP environment, is that it's totally possible to set up a rock solid replacement for Slack within an organization that has a person on staff to spend some cycles setting it up, and periodically maintaining it. We don't have any major technical challenges or problems running our own Synapse daemon server. It's a debian sta…
An "internally-run-Slack" is definitely a great use case for Matrix in its current form. I don't own a business, but if I did, I would almost certainly consider running my own Synapse server, just to have a stronger guarantee that internal chats stay internal.
> A common defense in favor of Signal is, “But it’s all open source!”. Sure is, but on what basis do I trust them? ... The open source aspect for me means 2 things. - I can verify the e2e encryption claim. - I can reproduce the client builds ensuring that what I run matches the source [1] Is there a detail relating to the server that would invalidate this? [1] https://github.com/signalapp/Signal-Android/tree/master/r…
I think the best description I've heard of Signal is it's open source "software" not an open source "project".
One of the root causes for centralization is that we lost the ability to make our devices talk directly to each other. Before the Internet, people could contact each other directly by just making phone calls, and the phone network was neutral, so any phone or any network could call any other (even internationally) provided they pay the fee. Same with SMS and MMS. With the early Internet, every computer had an IP addr…
> Before the Internet, people could contact each other directly by just making phone calls, and the phone network was neutral, so any phone or any network could call any other (even internationally) provided they pay the fee. the more you learn about SS7 and the traditional phone network the worse it looks. it's actually held together with the metaphorical equivalent of duct tape and string, and is highly centralized…
Even the cheapest phone plan will come with a phone number that's reachable from anywhere and can reach anywhere (provided you pay the call fee). Most consumer-grade internet plans come with a single, dynamic IPv4 and no IPv6 (or the IPv6 prefix is also dynamic). No end-to-end connectivity is possible unless you engage in some NAT traversal workarounds that require an external server.
Instead of creating a new protocol, why not just have a competition between clients using the current protocols?
Earlier quoted context omitted.
> Before the Internet, people could contact each other directly by just making phone calls, and the phone network was neutral, so any phone or any network could call any other (even internationally) provided they pay the fee. the more you learn about SS7 and the traditional phone network the worse it looks. it's actually held together with the metaphorical equivalent of duct tape and string, and is highly centralized…
I'm not talking about the security or reliability aspects of it - you are right about those (though Internet isn't much better, see BGP). But when it works as intended, the telephone "world" offers something that the Internet world often no longer offers: end-to-end connectivity. Even the cheapest phone plan will come with a phone number that's reachable from anywhere and can reach anywhere (provided you pay the call…
Earlier quoted context omitted.
If you're cryptographically checking that the connection you have is to your own server, sure, but I don't know any program that does that sort of thing. I guess if you're using TLS as a transport, the client handles that (if you have a self-signed certificate that you've told the client to trust exclusively).
Yeah, TLS solves that right? So we can agree that a decentralized system effectively removes the need to ever trust any third party system?
It's a much smaller leap to go from "I trust you to have written the code correctly" to "I also trust you to run the server well" than it is to go from "I don't trust anything" to "I trust all these billions of lines of code I didn't write".
Earlier quoted context omitted.
If all the interesting stuff happens on the client and the server "just" forwards encrypted messages, why would the server need frequent updates?
if you go to the main git page https://github.com/signalapp you can see that changes were made to the server 8 hours ago. So something is happening on the server, the public cant see it. I definitely would like to see whats happening given. I trust them, but we definitely need to see whats on the server code.
Unless you’re spotting something that I’m not?