Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Privacy-Respecting Software

github.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Privacy-Respecting Software

#31

Post by dngray »

cookiengineer wrote: post #28
dngray wrote: post #11

The problem with lists like this is they really are just a "here's 100 open source products", without any criteria or individual evaluation. It is often just parrots repeating what other parrots say. Something which is clearly alpha-state isn't usable to regular users shouldn't have a "recommendation". Then you get sub optimal recommendations, listing some projects which are unmaintained etc. With the cleanup at http…

What's your take on Briar? I've followes the specs a little and it seems to be implemented in a cautious manner. But haven't seen it being mentioned anywhere on privacy focussing lists, and I haven't heard of any audit of their codebase/protocol specs. Do you know by chance anyone currently auditing and/or describing threat models etc for it?

> What's your take on Briar?

Briar is audited was audited https://briarproject.org/news/2017-beta-released-security-au...

It's a decent piece of software.

Re: Privacy-Respecting Software

#32

Post by dngray »

_Algernon_ wrote: post #26
doix wrote: post #19

Earlier quoted context omitted.

Hmm, I guess that matters if you are using public servers. If you are running your own server, then it is a non-issue. I still think self hosted mumble is a great solution to the problem. Looking through the privacyguides recommendations[0], I don't see a good alternative. [0] https://www.privacyguides.org/real-time-communication/

As long as everyone involved trusts the server operator, and the risk of the server being compromised is negligible, you would be right. I do think that removing it from the list here was the right call, as most people probably aren't going to self-host.

> - 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 mentioned but nothing about who is running it.

On a side note something we're looking very forward to is:

[WIP] MSC3401: Native Group VoIP Signalling #3401 https://github.com/matrix-org/matrix-spec-proposals/pull/340...

Which seems to be a focus for 2022:

https://element.io/blog/introducing-native-matrix-voip-with-...

Re: Privacy-Respecting Software

#33

Post by dngray »

upofadown wrote: post #23
dngray wrote: post #11

The problem with lists like this is they really are just a "here's 100 open source products", without any criteria or individual evaluation. It is often just parrots repeating what other parrots say. Something which is clearly alpha-state isn't usable to regular users shouldn't have a "recommendation". Then you get sub optimal recommendations, listing some projects which are unmaintained etc. With the cleanup at http…

>PGP: NO. It has no forward secrecy, it's a terrible way to encrypt real time communication. OpenPGP is a message standard that specifically covers the offline, end to end encryption case. So the contention that it bad at other cases isn't very interesting. Forward secrecy can be implemented in the OpenPGP case in way compatible with regular usage, but no one bothers. Offline encryption can be made arbitrarily secure…

> OpenPGP is a message standard that specifically covers the offline, end to end encryption case. So the contention that it bad at other cases isn't very interesting.

It's an overly complicated protocol, https://latacora.micro.blog/2019/07/16/the-pgp-problem.html which has no place in an instant messenger protocol..

There are actually some XMPP clients which offer it as an option, which you should never use when you've got OMEMO, or (OTRv4). The double ratchet protocols olm, etc are better for this usecase.

There is also MLS https://en.wikipedia.org/wiki/Messaging_Layer_Security which is looking to become an IETF standard.

> Forward secrecy can be implemented in the OpenPGP case in way compatible with regular usage, but no one bothers. Offline encryption can be made arbitrarily secure so that it is always better to spend the time and effort on preventing the compromise in the first place. Besides, no one wants to have to immediately delete all their emails after having read them. Forward secrecy is simply not relevant for offline applications.

I was specifically talking about instant messengers, not email usecases. It's also why things like Deltachat are basically taking the worst parts of email encryption and mashing it into an instant messenger client.

Re: Privacy-Respecting Software

#34

Post by dngray »

vmoore wrote: post #27

> https://github.com/Lissy93/personal-security-checklist/blob/... I went through a mad phase where I had loads of extensions installed in my main browser. Then all these stories came out about addon authors getting contacted by shady actors who wanted to buy the addon so they could add malicious code that siphons off personal data. Now I just have uBlock Origin and that's it! I trust it NOT to be taken over by bad ac…

Would upvote parent more than once if I could.

> I went through a mad phase where I had loads of extensions installed in my main browser. Then all these stories came out about addon authors getting contacted by shady actors who wanted to buy the addon so they could add malicious code that siphons off personal data. Now I just have uBlock Origin and that's it! I trust it NOT to be taken over by bad actors.

Addons increase the number of parties you trust and also can make your browser more vulnerable. As we say in our openening paragraph https://www.privacyguides.org/browsers/

These are our current web browser recommendations and settings. We recommend keeping extensions to a minimum: they have privileged access within your browser, require you to trust the developer, can make you stand out, and weaken site isolation.

- https://en.wikipedia.org/wiki/Device_fingerprint#Browser_fin...

- https://groups.google.com/a/chromium.org/g/chromium-extensio...

> Addons also have exploitable bugs in them, and also having multiple 'privacy addons' can mean some overlap in functionality where the tracking protection is redundant since it's covered by another addon. Like who really needs Privacy Badger, DuckDuckGo privacy essentials, and then uBlock running all together?

Which is why common methodology now is very conservative. If you look at the research Arkenfox has done https://github.com/arkenfox/user.js/wiki/4.1-Extensions they recommend very few extensions.

> And with browsers shipping with fingerprinting mitigation, and having the option to surf strictly HTTPS sites, some addons are becoming redundant, like HTTPS Everywhere & 'useragent spoofing' addons which can actually make you stand out (privacy.resistFingerprinting:true in Firefox FTW). The trick is to blend in with a useragent, not stand out.

RFP does more than just adjust the user agent. User agent spoofing does *not* work.

As soon as you allow javascript there are dozens of metrics that can be used to profile you and to determine exactly what browser you have.

Re: Privacy-Respecting Software

#35

Post by dngray »

philjohn wrote: post #22

For 2FA leaving out Yubico Authenticator seems strange? The TOTP seeds live on the Yubikey itself, and the app only communicates via NFC (or USB) with it - no phoning home.

Yeah, it is. A lot of these lists focus on the fallacy that all open source software == secure, and anything that is not open is instantly bad.

We list the Yubikey, as it is at the moment it's one of the better MFA products out there.

https://www.privacyguides.org/security/multi-factor-authenti...

https://www.privacyguides.org/multi-factor-authentication/

Re: Privacy-Respecting Software

#36

Post by dngray »

bodge5000 wrote: post #15

Whats the current consensus on Brave? Last time I tried it, it seemed to be an alright alternative to Chrome, but remember it wasn't entirely well liked on HN for whatever reason.

> Whats the current consensus on Brave?

If you want to use Chromium based browsers it's probably the only browser that is:

- Cares about security, (not doing stupid shit like disabling CRLSets), they are proxied by Brave. See https://qua3k.github.io/ungoogled/

- Does try to do some anti-fingerprinting, while its not a strong as Firefox+Arkenfox, it's at least a step in the direction as opposed to other browsers which don't even attempt to do anything about it

- Its a resourced fork with timely security updates, don't use small browsers which lag behind.

- Their shields thing aren't bad, they have a script blocker (a bit like noscript) too you can enable, that isn't an addon.

Re: Privacy-Respecting Software

#37

Post by upofadown »

dngray wrote: post #33
upofadown wrote: post #23

Earlier quoted context omitted.

>PGP: NO. It has no forward secrecy, it's a terrible way to encrypt real time communication. OpenPGP is a message standard that specifically covers the offline, end to end encryption case. So the contention that it bad at other cases isn't very interesting. Forward secrecy can be implemented in the OpenPGP case in way compatible with regular usage, but no one bothers. Offline encryption can be made arbitrarily secure…

> OpenPGP is a message standard that specifically covers the offline, end to end encryption case. So the contention that it bad at other cases isn't very interesting. It's an overly complicated protocol, https://latacora.micro.blog/2019/07/16/the-pgp-problem.html which has no place in an instant messenger protocol.. There are actually some XMPP clients which offer it as an option, which you should never use when you'…

I was so annoyed at all the misleading stuff in "The PGP Problem" that I did a deconstruction:

* https://articles.59.ca/doku.php?id=pgpfan:tpp

I actually do PGP over XMPP these days. It is so simple that it ends up being quite reliable. So I consider it the superior protocol.

>I was specifically talking about instant messengers, not email usecases.

Forward secret PGP would be simple for an online application like instant messaging. You could just throw up a new public encryption key on the server before you delete the private key.

Deltachat also embodies some of the best parts of email encryption. Open federation based on the popular and well known SMTP standard. Encryption based on the popular and well known OpenPGP standard. Contrast with what happened with the Signal encryption protocol. OMEMO, Signal Messenger, Matrix are all entirely incompatible. Things are worse off now than they were before.

Re: Privacy-Respecting Software

#38

Post by dngray »

deif wrote: post #21
dngray wrote: post #11

The problem with lists like this is they really are just a "here's 100 open source products", without any criteria or individual evaluation. It is often just parrots repeating what other parrots say. Something which is clearly alpha-state isn't usable to regular users shouldn't have a "recommendation". Then you get sub optimal recommendations, listing some projects which are unmaintained etc. With the cleanup at http…

Why don't you submit a PR with a more up to date list? Or fork it? Lists don't get solved magically and a single person cannot keep up with all projects although your Privacy Guide seems to do a good job.

If I submitted PRs re-writing every privacy list/gist on Github. yeah you know where I'm going with that I'm sure.

Privacy Guides, is a community project, we accept community contributions, which are then verified before being merged with the main repository.

We are now looking at translation of our content https://github.com/privacyguides/privacyguides.org/discussio... which is exciting because we feel there really many resources in languages other than English.

Re: Privacy-Respecting Software

#39

Post by dngray »

upofadown wrote: post #37
dngray wrote: post #33

Earlier quoted context omitted.

> OpenPGP is a message standard that specifically covers the offline, end to end encryption case. So the contention that it bad at other cases isn't very interesting. It's an overly complicated protocol, https://latacora.micro.blog/2019/07/16/the-pgp-problem.html which has no place in an instant messenger protocol.. There are actually some XMPP clients which offer it as an option, which you should never use when you'…

I was so annoyed at all the misleading stuff in "The PGP Problem" that I did a deconstruction: * https://articles.59.ca/doku.php?id=pgpfan:tpp I actually do PGP over XMPP these days. It is so simple that it ends up being quite reliable. So I consider it the superior protocol. >I was specifically talking about instant messengers, not email usecases. Forward secret PGP would be simple for an online application like ins…

> 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 built client with a purpose built protocol rather than trying to butcher email to do it.

Re: Privacy-Respecting Software

#40

Post by upofadown »

dngray wrote: post #39
upofadown wrote: post #37

Earlier quoted context omitted.

I was so annoyed at all the misleading stuff in "The PGP Problem" that I did a deconstruction: * https://articles.59.ca/doku.php?id=pgpfan:tpp I actually do PGP over XMPP these days. It is so simple that it ends up being quite reliable. So I consider it the superior protocol. >I was specifically talking about instant messengers, not email usecases. Forward secret PGP would be simple for an online application like ins…

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

Post reply on HN