Live data from Hacker News

Privacy-Respecting Software

github.com

51–53 of 53 posts

Re: Privacy-Respecting Software

#51
post #44
post #32

Earlier quoted context omitted.

> - Mumble: Not really private Unless your self hosting, it's not really private, as it doesn't use E2EE. If you're self hosting and restricting access, then any software could fit into the "private" category. Does that mean every self-hostable piece of software should be classified as "private"? > As long as everyone involved trusts the server operator This is the key point that is never mentioned. The software is m…

> Does that mean every self-hostable piece of software should be classified as "private"? In my mind, as long as the self-hostable software isn't sending data back to some central server, yes? I guess we have different definitions, which is fine, this wasn't criticism of your list. I was just curious if you knew something I didn't. > This is the key point that is never mentioned. The software is mentioned but nothing…

The issue with lists like this though is privacy is implied by merely using the software and not from the fact you control the server.

For most people self-hosting isn't an option or something they want to do.

Software should be developed with E2EE from the beginning wherever possible.

Re: Privacy-Respecting Software

#52
post #39

Earlier quoted context omitted.

> Deltachat also embodies some of the best parts of email encryption It also embodies all of the metadata associated with it, which is still not encrypted. > Open federation based on the popular and well known SMTP standard and inefficient for messaging protocols, attachments are literally base64 encoded, every message includes a heap of metadata. For transient communication you're better off installing a purpose bui…

>It also embodies all of the metadata associated with it, which is still not encrypted. How is this worse than any system that depends on a server that routes messages? Like almost all of them... >For transient communication you're better off installing a purpose built client with a purpose built protocol... Yeah, the world definitely needs more "purpose built" protocols...

> How is this worse than any system that depends on a server that routes messages? Like almost all of them...

Not in the same way that email does. Email metadata is much more extensive than that of say Matrix.

If we look at metadata, often the subject isn't encrypted and ugly UX hacks then are made like https://tools.ietf.org/html/draft-autocrypt-lamps-protected-...

This replaces the subject with "...", however if I send that email to someone who doesn't support that every email I send is going to have the same subject, making it difficult for them to easily find the "correct" email from a group. Protonmail for example doesn't support encrypted subjects.

With Matrix for example the only real metadata is room id, and flow of events (what Matrix ID is in what room). You can have rooms which are centralized to a specific server and then that's not an issue.

It will be interesting to see where P2P functionality leads in the future. https://matrix.org/blog/2021/05/06/introducing-the-pinecone-... I think with any long-term identity, it's going to be trackable to some extent, so that is up to specific threat model, whether you get worried about that.

With Signal and Sealed Sender https://signal.org/blog/sealed-sender/ even less metadata is available, although this centralized model is not without downsides such as being operated by a single entity.

We discuss in quite some depth https://www.privacyguides.org/real-time-communication/

> Yeah, the world definitely needs more "purpose built" protocols...

With protocols like olm, you also have concept of different devices, device keys, which can be revoked, and shifted without having to ditch all your keys at once. Cross signing means new devices can be "trusted".

Re: Privacy-Respecting Software

#53
post #47
post #30

Earlier quoted context omitted.

> starting point to see what exists for your own research, the bigger issue is that it claims to be curated when it's more like a wiki. Problem is they also serve to repeat bad/out of date practices. I always feel people who put together these lists are in a competition to list as many products and cover as many areas as possible, without evaluation.

I want to revise my claim of "nothing inherently wrong with a having lists like that". This is not just a simple list of software with summaries, and after looking at it more it's worse than I thought. And you're right about propagating bad/out of date advice being a problem. > I always feel people who put together these lists are in a competition to list as many products and cover as many areas as possible, without…

> This is not just a simple list of software with summaries, and after looking at it more it's worse than I thought. And you're right about propagating bad/out of date advice being a problem.

Where we notice this effect is in our subreddit /r/privacyguides and /r/privacy, particularly in regard to browser extensions.

Fortunately through re-nforcement from the Arkenfox, Librewolf and our project we're starting to turn the tide away from "install 100 privacy browser extensions", so I think that's a positive benefit.

> Unfortunately this seems to be the quickest and easiest way to get the most attention. Proper curation takes lots of effort, and is hard to get noticed by people who don't know any better.

Pretty much why we're about quality over quantity with privacyguides.org. People have often asked "why don't we have a section for "this" or "that".

Each section requires research, and not just parroting what someone else says.

Post reply on HN