This "security guide" is mind-boggling. Use instead of an /Linux device (ideally with a custom ROM), and even instead of a laptop?!? Use (not Chromium, *Chrome*) and a ?!?
techsolidarity.org/resources/b

Use ? Despite the fact that there any *many* good reasons for anyone with important secrets to protect
*not* to do that (US-based, no warrant canary etc), and Moxie has defended aspects of his centralized set-up by saying people shouldn't use it for that?

@noorul @strypey there is no "safe". There are degrees of safety, and there are very real reasons to doubt the safety of Signal.

@strypey I'm really really unhappy with this article, still. Problems are more than valid but it pretty much seems about completely misunderstanding Signals threat model and target group.
@gentoorebel @noorul

@z428 can you expand on that? If you have a blog post or a previous fediverse thread on the topic, feel free to link me to that rather than re-explaining.
@gentoorebel @noorul

@strypey I still think this comment by Moxie Marlinspike nails it, he has a few very valid points throughout the whole thread: github.com/LibreSignal/LibreSi

@gentoorebel @noorul

@z428 there's a lot to unpack in that comment. The dismissal of anyone who thinks is a necessary precondition for secure software as "cryptonerds and moralists" is notable. Once you strip out all the hyperbole and sarcasm, most of the factual claims are debunked in the proceeding comments, starting with:
github.com/LibreSignal/LibreSi

@gentoorebel @noorul

@strypey I don't general disagree, but I'm a bit concerned about trust, in this context, mistaking a "people thing" for something technical. There are already plenty of players you just got to trust using digital means of communication. I'm concerned that, with our current concepts of freedom and openness, this adds a lot more parties to the game which, in the end, most users just "have to trust".
@gentoorebel @noorul

@z428 there are at least three things to consider 1) is it possible to audit the security, 2) has the security been audited, 3) did the auditors do a thorough job? In order to meet the preconditions for 1), you need a) access to the source code, and b) a way to ensure that the source code you're given was actually used to compile the binaries/ installed on the server. Signal now meets a) but goes to great lengths to avoid b), which is ... fishy.
@gentoorebel

@z428 secondly, a federation of servers can be imagined as a single server made up of many parts, each of which has to communicate with every other part for the system to work as advertised. Instead of the server being a black box (like Signal), where you just have to trust what happens between client>server, in a federation you can check exactly what's being passed between servers, and how secure it is. Lots of people can check, and check each others' work.
@gentoorebel

@strypey Agree. But it also increases attack surface by requiring facilities for server2server communication, and it *might* get things more messy if one or some of the nodes go compromised without users noticing it, which might be more a real risk in example while looking at loads of self hosted web CMS that got setup once but aren't really "administered", updated, maintained. That's still one of my biggest issues with decentralization in general.
@gentoorebel

Follow

@z428 there are various ways to address this. OWS doesn't let clients older than 3 months connect to their servers. A secure chat federation protocol could include refusing to connect to another server that hasn't been updated for more than 3 months. There are all sorts of systems you can use to ensure security across a federated network (ask Mike from / / about it). The only main problem with XMPP is that until recently security wasn't a design goal, but now exists.

@strypey Yes, but for one, if having access to the sources and building / running them on your own, nothing would keep you from modifying these means of security. Worse, even: If all of a sudden some servers fail because they didn't update, this directly will affect users - both those on the "old" server and those in contact with them. Who's to fix that, then? Though some are vague, I see a load of Moxies arguments make perfect sense if you assume he doesn't "just" want to provide ...

@strypey ... software but actually take responsibility for offering a service that, within certain guaranteed boundaries and service levels, is available, reliable and secure for all users. If this is your mission, having people run custom nodes beyond your administration as part of your network isn't helpful. If this is your mission, having people connect with eventually modified builds of your own or even with third-party clients isn't helpful. All of these things make the system ...

@strypey ... itself more fragile and more complex to maintain, especially if you're the one who volunteered to take responsibility for doing so. That's my repeated criticism about all this: While we focus a lot on #SoftwareFreedom, we pretty much leave out that it takes responsible, skilled, well-trained operation of this software as well especially when providing services to end-users. From that point of view, I see the current distribution ...

@strypey ... model as the worst we possibly could come up with: Most end users are unable to run these services themselves. But rather than relying upon WhatsApp, Facebook, Signal, they are supposed to rely upon "someone out there" offering a federated service for free. How can they know who this is? How can they know whose payroll this person is on and why it's doing the work it does? You've been writing about auditing code, which I really think is important - but just half the truth: As ...

@strypey ... long as we don't have true Peer-To-Peer software (where running a full-blown "instance" isn't any more difficult than installing and setting up a client app), as long as we need servers run by someone, all along with auditing the software itself we also would need to audit how this software is run: How are user data kept? How do people handle their servers, their backups, ...? Are they using strong-enough credentials for databases and servers? How are they rotating passwords? Who...

@strypey ... has administrative access to the infrastructure? Are these people trained and educated to honour things such as privacy of user data? The whole idea of running federated services that aren't run by the end-users themselves completely misses out in this point in my opinion.

@z428 you raise a lot of important points. I just don't agree that the answer to the questions you're asking is centralized silo. I don't think you do either, or we'd be having this debate on the birdsite, not here. There's a lot to unpack here, so I'm working on a blog post

@strypey You got me wrong here: I don't want to praise centralized silos. But I want to "praise" reliable, trustworthy, qualified operation as an essential part of the equation, which right now is not the case as far as I see. From many points of view, the current approach to decentralization seems a "worst-of-both-worlds" way: On one side, you don't have "large entities" like Facebook and Twitter, meaning that (all along with a lot of drawbacks) you also don't have some of the ...

@z428 BTW this conversation is very valuable, but is getting too detailed to carry on here. Figuring out how to solve these sorts of problems it exactly what the group on Loomio was set up for. Feel free to contribute some of these thoughts to appropriate threads, or start a new one.

@strypey Hmmm, I'll try. We got to find a meaningful way to "bridge" these conversations over. Right over here, there's usually a flow of topics, which is hard to move elsewhere without cutting these ties...

@z428 remember that the fediverse is still the public web. Hyperlinks are your friends :) I sometimes find it helpful to reread whole fediverse threads and summarize the salient points covered and useful links shared in blog posts, and the same can be done as discussion starters on Loomio threads.

@strypey ... advantages such structures have (such as that you can deal with them in court if required, and that usually they have *very large*, very skilled teams to make sure services are running, available and as secure/safe as they probably can and are allowed to be). These structures are essentially replaced by a plethora of volunteers running services in their spare time, which is bad both in case you need to hold someone reliable if really something goes wrong and in terms of having ...

@strypey ... infrastructure reliably available 24x7, having security holes in infrastructure fixed "in time", having user-reported incidents treated in a professional way and so on. On the other side however, services like mastodon, Matrix or most XMPP servers with all dependencies (CPU, storage, RAM, reliable internet connectivity, ...) still are *way* too complex and expensive to be run by an end user who's almost overwhelmed even by setting up a Signal account on their phone. Result: You ...

@strypey ... end up with a federation of mid-sized instances maintained and administered according to vague common standards, at very different quality levels, and it's hard to tell who's "good" and who "isn't". As far as I am concerned: I firmly believe that decentralization and federation only *really* make things better once we're in a P2P setup where running a "federated node" is as simple as installing and setting up a desktop or smartphone app, without the need ...

@strypey ... to deal with something such as a "server" or "hosting". After all, most of the current federation services aren't fundamentally better or different to Twitter or Facebook, they do the same thing (databases, file storage, web server, "small centralized federating instances" yet on a smaller scale). We'd rather need potent, powerful end-user applications that don't have any server dependencies and instead work against, say, a internet-wide, replicated, encrypted, large storage that...

@strypey ... is reasonably redundant, encrypted, tamper-proof and distributed across a thousand of nodes without local administrators being able to read data, know whose data is stored on their system, let alone track users or even modify data they read. But I don't see that in any of current "federated" systems. They all seem just very little better than Twitter and just in some aspects.

@z428 all the issues you raise apply to email. Yet, email is a federated private message technology that people use every day, even for sensitive communication, without batting an eyelid. I mean, they *shouldn't*, at least not without learning to use , and even then not for anything that puts anyone's life / freedom at risk. But they do.

@z428 Decentralization is not the problem. Instance trust is the problem. It's even more of a problem with Signal, because there's only one instance, and you just have to trust it.

@z428 the solution, as I see it, is basically to go back to the 1990s ISP model, where one entity hosts all your services (email, chat, blog, micro-blog, media-sharing, remote backups etc). Unlike the 90s, that ISP need not be the company that you lease your internet connection from (probably won't be), but it is an entity you have a trust relationship with. Not just an "instance" you've picked at random via web searches. I've written a bit about that vision here:
coactivate.org/projects/disint

@strypey @z428 I'm very pleased with FastMail's offerings this way, now that I'm getting into them more. They're very standards-based!

The only problem is the AA bill...

@alcinnz I'm currently looking into mailbox.org/; so far however still torn as I still have web space hosting paid monthly where I keep my mails, nextcloud and stuff for "personal" or family use. It's the same again, though: Trust. The heap of technology not under my control (servers, storage, connectivity, ...) in there is larger than the aspects I choose to have control over.
@strypey

@strypey yes I fully agree. That's why I tend to be annoying about that. I don't have a problem with federated services. But I have a problem with too many people claiming decentralization and federated services are per se and generally "better" than centralized ones. They probably are - but only in some aspects and in some ways, by no means *generally* as they still leave a bunch of questions of organization, trust, funding, reliability more or less unanswered.

@z428 decentralized comms systems are are "better" than centralized ones in the same way published free code is better than secret proprietary code. The former provide various means of accountability that the latter do not (eg the ability to audit the code, or the ability to choose a trusted instance, to test for leaks between instances). That these accountability mechanisms exist is not an ironclad guarantee that they will be used, or that it will be enough. But it's still better to have them.

Sign in to participate in the conversation
Mastodon - NZOSS

This Mastodon instance is provided gratis by the NZ Open Source Society for the benefit of everyone interested in their own freedom and sharing with others. Hosting is generously provided by Catalyst Cloud right here in Aotearoa New Zealand.