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:
organizationunbound.org/expres

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.

@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.

@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:
github.com/wireapp/wire-webapp

@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 @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?

Follow

@HerraBRE

>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.

github.com/tc39/proposal-realm

ยท 1 ยท 5 ยท 3

@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!

Sign in to participate in the conversation
Mastodon

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