Messenger are not easier than email, only when 2 ore more communicate on one topic. But with email you communicate with one or more people about many topcis. To archieve the same structure in a messenger, you must create several discussions. So messenger are not the holy grail of communication, that is why people still use email. We need an email user interface with open messenger protocols under the hood for secure…
The PGP Problem
171–180 of 369 posts
Re: The PGP Problem
#172Earlier quoted context omitted.
Sure, you usually don't want that feature in private setting, but you almost always want that feature in a commercial setting, and lots of communication happens in that context. E.g. vendor-customer helpdesk chat, internal workplace communication including "less internal" things like different subsidiaries of international companies, etc, etc. Half of financial world runs on Thompson Reuters messenger which is essent…
I think our main disagreement is the usage of the word "usually". There are chat systems that have non-repudiation that aren't PGP -- I don't think there's much more to elaborate. For personal communications, usually people want deniability. For business-related communication, you might want non-repudiation.
Re: The PGP Problem
#173Earlier quoted context omitted.
Good question. Not sure. Although I don't see why I wouldn't, if they have a PGP key listed? (I guess there is some question over whether the listed key is actually them?) But my point is that, well, email is a good way to do that, and Signal isn't, so I'm going to use email rather than Signal. Honestly, I wouldn't focus on (3), because as I see it, if you can replicate the feel of email, things like (1)-(2), so that…
How does one list a public PGP key, is there a verified central listing service?
Re: The PGP Problem
#174First, thanks enormously for writing this -- and for all the other recent articles that have appeared here the vein of "PGP is as bad as it is unpleasant to use". It's a point I didn't really appreciate (at least as much as I (sh/c)ould have) and I'm sure I'm not alone. It seems that the state of package distribution for many distributions is poor, security-wise. (OpenBSD, to nobody's surprise, is an exception.) For…
Arch Linux's pacman is not a good example of a secure package distribution system (especially not the AUR, where you are downloading all the bits from the internet and building them yourself as your own user or even sometimes as root). They didn't do any package signing or verification at all until (shockingly) recently -- less than 10 years ago IIRC. I am a huge fan of Arch's philosophy but am definitely not a fan o…
For the record AUR packages can use GPG keys, see e.g. GPGKEY variable: https://wiki.archlinux.org/index.php/Makepkg#Configuration
Arch also uses Web of Trust to introduce Trusted Users: https://www.archlinux.org/master-keys/ so I wouldn't call "less than 10 years" as a disadvantage, but rather advantage - they have seen problems with alternative designs (e.g. Debian's curated keyring) and came up with something better.
Re: The PGP Problem
#175Earlier quoted context omitted.
Really? When gmail came out they were explicitly up front about using the content of the email to deliver targeted ads. Has that changed?
There are a lot of misinformations around, and the Google haters crowd has plenty of pitchforks. https://safety.google/privacy/ads-and-data/ > Google does not use keywords or messages in your inbox to show you ads. Nobody reads your email in order to show you ads.
They eventually stopped, although the phrasing of the privacy policy is vague enough that, as wodenokoto mentions above, I wouldn't be surprised if email messages were still scanned for some advertising purposes. The fragment on the page you link to is only about ads shown in Gmail, doesn't exclude using keywords and messages for tracking, classifying etc. (it just doesn't use them "to show you ads") and doesn't actually exclude using programs to process messages (i.e. you can still reasonably say that "nobody reads" messages if you just feed them into a program). It's also not very obvious if "messages in your inbox" also includes messages you send.
FWIW, I think the policy is deliberately open-ended so as to be future-proof, but I doubt emails are an important source of advertising data today, so I think it's likely that Google doesn't rely on it that much anymore. Most sources of legitimate (i.e. non-spam email) that are useful for advertising -- e.g. online shops and the like -- already track you and show you ads, and Google is already deeply embedded there. Millions and millions of personal accounts are an useful strategic asset to have but I think there are better sources of data.
Re: The PGP Problem
#176- I don't want to be manually comparing hashes in 2019
- it locks me into signal, I wont be able to verify a git commit from that person as an example
Is there a system that solves this? Keybase is trying but also builds on PGP, we can use S/MIME which relies on CAs but is not better than PGP. Anything else?
Re: The PGP Problem
#177So what do I use for encrypted messaging that can, like, replace email, then? Nobody seems to have provided any sort of satisfactory answer to this question. To be clear, an answer this has to not just be a secure way of sending messages, it also has to replicate the social affordances of email. E.g., things distinguishing how email is used from how text-messaging is used: 1. Email is potentially long-form. I sit dow…
I don't get what's insecure about normal unencrypted email. It's sent over https, isn't it? It's not like I can read your emails unless I break into Google's servers, no? And even if I do, they probably aren't even stored in plaintext. I just don't get the encrypted email obsession. It's impossible for an individual to withstand a targetted cyber attack so it seems pointless to go above and beyond to ultra encrypt ev…
That's actually more complicated than that.
If you're using a web mail, your connection to the mail provider most likely uses HTTPS. That is, HTTP over TLS. When the mail is sent, it depends whether the recipient uses the same provider or not. If it's the same provider, well, protocols are irrelevant. If not, it will usually be SMTP over TLS (minus any potential problems with STARTTLS).
The main problem with that is that the mail is not encrypted on the various servers it goes through. Only the server-to-server connections are encrypted. So your provider can access your email, and so can the recipient's. When that provider's business model is reading your emails so it can send you targeted adds, this is less than great. (Yes, Google reads your emails. They try to reassure you by telling you their employees don't read it, but the fact the process is automated actually makes it worse.)
Re: The PGP Problem
#1780) https://lists.gnupg.org/pipermail/gnupg-users/2019-July/0623...
Re: The PGP Problem
#179Earlier quoted context omitted.
I'm a little confused as to why you mention Signal and WhatsApp but not Telegram?
Most cryptographers do not see Telegram as a secure encrypted protocol. This is for two reasons: the first one is that Telegram doesn't do end-to-end encryption by default (and if you enable it, functionality is limited). And secondly, they roll their own cryptographic protocol.