The is a great piece by Rich Bartlett of #Enspiral, #Loomio, and #TheHub, talking about the advantages of federations of small groups, over networks of loosely connected individuals:

It's reasons like these I encourage community-hosting more than self-hosting. Note: I'm not against self-hosting, for those who have the skills and motivation to set up and maintain it, it's just not my ideal that everyone self-hosts.


@strypey the problem with community-host is trust: Web doesn't support end-to-end encryption and the host can see guests' data. With large corporations people don't care if an employee see their data while they don't trust even a friend of theirs as host.

We need non-web-centric services and at the moment we just have IMAP for emails or a way to use e2e encryption on the Web.

· · Tusky · 2 · 1 · 2

@alexl to me, a community is by definition of group of people who trust each other. Also, there are ways to do #E2E encryption over the web. #LavaBit did it. #Wire does it. There are other examples.

@strypey afaik e2e encryption can't be implemented over the Web.

I don't think people trust each other enough to give away their privacy.

@strypey it seems Lavabit developed its own (Open Source) way to implement e2e encrypted emails, "Dark Internet Mail Environment", and it uses a fork of Thunderbird as reference client. Are you sure they implement it specifically over the Web and not only over the Internet with DIME?

@alexl fair cop. I've never used Lavabit so I'm not 100% sure, but the Wikipedia page for Lavabit says:
"Lavabit is an open-source encrypted webmail service"

@strypey does Wire have a Web client? Does it support e2e encryption? I was not able to find any information

@alexl @strypey

Yes, it has a web client. I don't believe it supports e2ee but I'm not 100% sure on that.

@Blort @alexl I'm pretty sure the Wire web client does support E2E encryption, otherwise they wouldn't provide one, since it would break the security of the clients that do, wouldn't it? Source code is here:

@alexl @strypey @Blort What could they possibly say?

When people do crypto on the web, the trust boundary always ends at the web server that serves up the Javascript code.

So the question boils down to: where is the web server? If it's in the possession of the end-user, you may have E2EE. If it's in the cloud, you don't have E2EE.

It's really as simple as that, anyone telling you otherwise is selling snake-oil.

@HerraBRE @alexl @Blort is there no way to test whether the JS being served is the same JS that's in the repo? If you there is a way to test that, and the JS is under a free code license, then you can still have E2EE even if the webserver is not in the possession of the end user. Right?

@strypey @alexl @Blort No, there is nothing out there that validates the code you load.

And even if there were, Javascript is a very malleable language, if I inject another script into the same page I can mutate the code at run-time, even if I served you "the original".

This path doesn't lead anywhere, I'm sorry.

@HerraBRE @alexl @Blort ok, good to know. But coming back to the origin point of the thread, as a non-coder, I have to trust somebody (or not use software at all). Even experienced software engineers can't do a complete security audit on every line of code in every piece of software they use. So we all have to trust somebody (or not use software at all).

@HerraBRE @alexl @Blort If I trust Wire enough to believe that the code in their repos does what it says on their homepage, then surely I can trust them to deploy the software in their repo in production, with no nasty easter eggs added. If it does, and they do, then it *is* E2EE, no snake oil involved. Yes? So I either trust that's the case, or I don't, and act accordingly.

@strypey @alexl @Blort The problem is, that's not what E2EE means. The term explicitly implies not having to trust the people operating the servers.

You may still be SECURE, but you don't have E2EE.

And remember, you're not just trusting them. You're trusting their local government, their hosting providers and whoever hacked their infrastructure.

@strypey @alexl @Blort This is exactly where InfoSec becomes interesting and very tricky.

Building systems that don't require you trust everyone to play nice is hard, but quite valuable.

Crypto is just one of the tools we use to do that. We also use all sorts of social structures where people keep each-other honest through various means.


Hmm. LibreJS vets received Javascript, albeit for acceptable licenses. I wonder if & how well it can address this facet of freedom.

@strypey @alexl @Blort

@HerraBRE if you are right and as I said we can't use e2eE on the Web then Matrix and Wire shouldn't advertise their Web client as e2e encrypted because they technically use e2e encryption but in a meaningless way, because you still have to trust the server owners, they in fact could always inject JS code.

I think at this point we have a big problem to solve before implementing technologies like Matrix or decentralized social networks.

@strypey @Blort

@alexl @strypey @Blort The "big problem", is people need to stop expecting they can have all the privacy and all the security and all the decentralization... without ever installing any software themselves.

The world just doesn't work that way, no matter how much people want it to.

@HerraBRE @strypey @Blort

It seems to me that here the only problem is Web using JavaScript for both UI and business logic.

What if we put the JS code shared between instances on IPFS and restrict the execution of JS only to the one coming from IPFS? It would be verified to be the same across every instance with the same version of the app.

Of course browsers should support some kind of verification in their native UI like "running Abc version X.Y.Z"

@HerraBRE @alexl @Blort hold the phone. By your definition of E2EE, it doesn't and can't exist. Because at some point you've got to trust the repo or website you're downloading client software from. Or even if you compile from source, you've got to trust the website you're downloading the source from, and trust that it hasn't been compromised by MitM on the way. What's the difference between this and trusting a web service?

@HerraBRE @alexl @Blort my understanding is that E2EE just means that the encryption takes place on the client end, not the server end. It' important because it means unencrypted data isn't going over the wire before being encrypted, and is less vulnerable to interception. That's it.

@strypey @alexl @Blort Your understanding is just incorrect, and dangerously so.

For an example of how this breaks, Google the story behind Hushmail and how they were compelled to steal their own users' keys.

Contrast with the difficulties the US government has had compelling Apple to hack iPhones. The differences are very real, and they do matter.

@strypey @alexl @Blort Division of labour. Separation of concerns. Networks of mirrors. Reproducable builds. Encrypted transports. Codesigning.

There are a huge number of things - effective things - that are done to secure and prevent tampering with software.

None of them work with Javascript served from a website.

This topic is WAY too big for me to teach you the whole thing in a thread of toots. But you can go Google those concepts, I'm not making this shit up. 😁

@HerraBRE @alexl @Blort I'm sorry if it sounded like was accusing you of making anything up. It just seemed to me like some of your posts were falling into the old 'imperfect security = no security' fallacy. I still think it's fair to say E2EE via JS can protect users from some threats, but not others, even assuming the host is trustworthy, competent, and not compromised. Don't you?

@strypey @alexl @Blort As I said earlier, you can gain some security through measure like this, but they don't meet the bar of E2EE.

Since these attacks can be both completely silent and targeted at individual users, it becomes very hard to manage or mitigate the risk of these systems in any meaningful way.

I also hate the security binary, but the user is only given two choices here: trust the provider or avoid.

Related, here's a recent academic analysis of ProtonMail:

@HerraBRE @strypey @Blort

Just to be sure I understand correctly: is the problem JavaScript in Web pages? Would it be possible to disable JS for a page intended for E2E communication and replace JS's funcionalities with something else (implementing support in the browser of course)? Would it be enough?

@alexl @strypey @Blort The problem is the code (Javascript) you are using to encrypt/decrypt, is provided on-demand (or can be modified on-demand) by the same remote server as handles your communications.

At any time, they can just ship you code that silently steals your secrets. Generally on the web you aren't anonymous, so they also can target you specifically.

Code built in to the browser (or an extension) could be OK, but the implementation/UI gets rather tricky.

Example: Mailvelope.

@HerraBRE @Blort @strypey @alexl I think cryptpad made some attempts to mitigate that, but I don't know how successful it was.

@cryptpad was the other example of E2EE over the web I was trying to think of, thanks @bob

@ldubost @HerraBRE @Blort @alexl

I'm from the cryptpad team, this is still work in progress based on code signing, but it's a lot of work.. we'll get there eventually. However changing the code requires an active attack potentially detectable. For a cloud provider looking at its customer data in some cases is just day to day work and just written in the privacy policy
@HerraBRE @Blort @alexl @strypey

Building a desktop app is also in the plans to guarantee users they know which code they get.. but same thing.. the team is only two devs..
@HerraBRE @Blort @alexl @strypey

@HerraBRE @alexl @strypey @Blort In the example of the riot desktop client: it's JavaScript but packaged as a desktop application (electron). This way the crypto happens in local code that can be checked.

@hexmasteen @HerraBRE @alexl @Blort I don't think #Electron is the best solution. I prefer the way #Mailpile serves the UI using the default browser already installed on the system, rather than bundling most of an arguably dodgy browser (Chrome) in with the app, and using up heaps of memory in the process:

@hexmasteen @HerraBRE @alexl @Blort
Most #Chromium based software can't even be confirmed as #FreeCode software to the standard required for being listed in the #FreeSoftwareDirectory. AFAIK #Iridium is the only project accepted into the #FSD that uses code from Chromium:

@HerraBRE @alexl @strypey @Blort So maybe we have to avoid HTTP. If the JS is served via #dat or #ipfs it has a defined, globally known version. The JS can ask the user to change to a newer version when available. Do I miss something here?

@hexmasteen @alexl @strypey @Blort That part of the future hasn't arrived yet! When it does, yes, it might address some of the problems.

But only some - if any part of a web app is "dynamic", that part can compromise the rest at runtime. The browser doesn't protect JS libraries from each-other.

And conversely, if an entire [web] app is stable enough to live, rarely updated, in DAT/IPFS - why doesn't it just ship with your distro?

@alexl @hexmasteen @strypey @Blort So replace the word "distro" with "operating system" or "app store".

The argument still applies.

@HerraBRE @hexmasteen @strypey @Blort

It would be nice to stay on the Web model where you don't install anything but just visit a site, login and can communicate with other users but with e2e encryption. So maybe we would have a Mastodon-like app at a certain address but distributed over IPFS that acts as Web client for a selfhosted ActivityPub server with support for e2e encryption

@alexl @HerraBRE @hexmasteen @strypey @Blort What might be interesting in Memex is for webpages to tell the client what should be e2e encrypted from a form, and the browser follows through but also informs the user.


>The browser doesn't protect JS libraries from each-other.

There is a TC39 proposal for realms, which is meant to allow proper sandboxing at the language level.

@HerraBRE yes same here. There was a lot of activity during the summer but now it's stalled a bit. I suppose that happens , but I hope they are not stuck on a fundamental or something.

I always tell people about it when I get half a chance because the more people we have asking tc39 to do this the better!

@HerraBRE @hexmasteen @alexl @Blort
> why doesn't it just ship with your distro?

For the same reasons everything went into the web browser in the first place. Many people (maybe even most) don't have the privilege of being able to do all of their work on one computer, that they own and administrate. When they do, they lack the skills / resources needed to manually backup all the data on that computer. But web-based services can work consistently on any PC with the net and a browser.

@HerraBRE @hexmasteen @alexl @Blort we can design perfect information security, in theory, if we don't engage with the messy reality of how users actually use computers in the field. But outside of writing computer science papers, what good does that do?

@strypey @HerraBRE @hexmasteen @alexl @Blort I'd say the behavior I notice from normal people I see that if they want some information they go to Google, etc and look for a webpage. And then maybe they'll begin interacting with the site. If they want to do something they search for it on their OS's app center. That's where these tools excel.

As for communication tools, that's a bit of a gray area where some go for websites and some go for native apps.

@strypey @HerraBRE @hexmasteen @alexl @Blort I'd say the pull of communication tools tends to be different between web and native. Websites pull people in to listen to their friends. Native apps pull people in to send messages to their friends. Either way people naturally gravitate towards the tools they already use.

That said I am grossly oversimplifying here.

@alcinnz @HerraBRE @hexmasteen @alexl @Blort it depends a lot on form factor too. People are much more comfortable install native apps on mobile OS, because the "app store" #UX makes that seem safe and easy. On desktop OS, installing native apps can be difficult and seem risky, so users tend to go for web apps. Web apps usually have much better UX for getting users set up, compared to the painful, hair-pulling exercise of setting up native apps. That has an impact on user preferences too.

@strypey the only example of e2e encryption over the Web I know is Riot Web: but I don't know how it solves the issues mentioned in the article I shared.

Anyway if e2e encryption works on Riot we need it on other services like Nextcloud.

@alexl @strypey According to the article, building, applying and "exercising" trust in small teams, e.g. in a community hosting team, is an important reason to participate in such an initiative.

Very interesting reading. Btw, translated to greek by the medialibre team:

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!