@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.
@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
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.
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.
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.
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.
@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.
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?
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.
There are a huge number of things - effective things - that are done to secure and prevent tampering with software.
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?
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: https://eprint.iacr.org/2018/1121.pdf
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.
@HerraBRE @Blort @alexl @strypey
@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:
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?
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
@teleclimber Thanks for sharing this! I hope this proceeds.
@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!
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.
@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.
Very interesting reading. Btw, translated to greek by the medialibre team:
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!