6 ms·
I worked in IT for an engineering company that required all external emails to be PGP encrypted. Despite all engineers having Symantec PGP software installed an
by lbenes 10y ago
I worked in IT for an engineering company that required all external emails to be PGP encrypted. Despite all engineers having Symantec PGP software installed and setup, training, and support of IT, they would often ignore this policy. The excuse, often valid, was it would require IT from both companies to setup the encrypted keys for the first time for new users. If the system is too complex for engineers, the idea of this being usable for the average users is a pipe dream.
PGP needs to be as simple as the SSL Lock in a browser if there is to ever be any hope of widespread adoption. There needs to be a single system of trusted PGP universal key servers that allow the details of key generation/management to be hidden from the user, just like SSL is with the web browser.
We'd still be using HTTP if SSL was as complex as PGP. Same ssh replacing telnet. E-mail's lack of progress on this front is primarily a UX issue, and until it's solved PGP will remain a tool for the select few.
- XorNot 10y ago99% of crypto would work just fine if you appended an OTR-like protocol over the top of email. First email is "hey we're interested in blah..." and is sent in the clear. Then have the message window change color as subsequent emails get the protocol more secured.
- DigitalJack 10y agoI hate color coding. I'm in the 8-12% of men that have red-green deficient vision. You can use 10% as a rule of thumb. If I'm not mistaken in my probability math, that means in a group of 5 men, there is a 50% chance one of them is "color blind." Yet the world insists on using red/green as bad/good indicators. Drives me nuts.
- caf 10y agoYou are mistaken. If probability of each of the 5 men being colorblind is independent (so eg. they're not related etc), then there's a 41% chance that at least one of them is (1 - 0.9⁵). (There's a 33% chance that exactly one of them is: 0.1 × 0.9⁴ × ⁵C₁).
- DigitalJack 10y agoThanks. It's been too long since I've studied statistics. Might be time to watch some khan academy. Oh, I see. Assuming probability that a man is not colorblind is 0.9, then you found the probability of none of them being colorblind and subtracted that amount from 1 to find the other side. For anyone reading this that was bothered by my use of a specific gender, it's because colorblindness occurrence is significantly higher in men than women.
- intransigent 10y agoAn ever-apologetic, yet demanding complainer. The entire world should bend to your will, and court your color blind deficiency, and yet you curtsy to the possible perception of a non-neutral, gender-specific rant. Honestly. Who fucking cares? Just say your piece, and dispose of the chivalry, since it too is technically sexist. Wallow in the reality that someone will be annoyed by such pretentiousness. Meanwhile, color coding can use HSB models to still permit differentiability via brightness contrast, and font weight, when coding. It's not like us color coders are ignoramuses, you insensitive clod!
- jballanc 10y agoI think a Poison distribution would be more appropriate here, so the probability of 1 man in 5 being colorblind, assuming 10% of the population on average is colorblind, is: e^-0.5*sum((i)->(0.5^i/factorial(i)), 1:5) = ~39%
- coldtea 10y ago>Yet the world insists on using red/green as bad/good indicators. Drives me nuts. Well, it has to use something, and other people would be colorblind in other colors, plus some will be blind too. In this case, one would expect there'd be some OS-wide color utility to alter colors to the ones the user can discern.
- btashton 10y agoYes, but these other ones are far more rare. Also there are shades that make it so much assessable for people. Almost every day I will ask someone what color something is because of poor selection. Chances are you have a color blind person in you office, just run visualizations by them really quick.
- IanCal 10y ago> Chances are you have a color blind person in you office, just run visualizations by them really quick. This is a great check, but I also recommend trying things just in greyscale as a simple test and installing something like Color Oracle [0]. Also, most of the problems can be solved by looking for an already existing solution, like swapping your heatmap colour scales for viridis [1]. The most important thing is recognising that these kinds of issues exist and pro-actively looking for good current solutions (the same applies for things like trying to ensure your site works well with screen readers). I'd love to hear of more tools or other things that can help if people have suggestions! 0 http://colororacle.org/ http://colororacle.org/ 1 https://cran.r-project.org/web/packages/viridis/vignettes/intro-to-viridis.html https://cran.r-project.org/web/packages/viridis/vignettes/in...
- KingMob 10y agoI also have red/green colorblindness, but it's not as if color coding would have an 8-12% failure rate. Typical red/green color-indistinguishability mostly applies to dark reds and green, though, whereas the reds/greens used in UI tend to be quite bright and vivid. People who can't distinguish vivid reds/greens are much rarer. (If 10% of men couldn't separate red from green at the stoplight, we'd have noticed a long time ago.) I agree we should include everyone, of course, which is why there should also be patterns, shapes, and sound to assist, I'm just saying color coding is not some collossal mistake. (Also, your math is off if you're assuming a 10% base rate. To have at least a 50% chance of 1 person in a group of men being color blind, you need 7 men. 1-(.9^7)= 52%.)
- jcrites 10y agoWell-run email clients and servers are in an OK state today regarding encryption, and the weaknesses that exist are more related to adoption than technology. Take a typical office setup: your email client communicates over TLS with your central mail server (e.g. Exchange, Postfix) to retrieve or submit messages. This is true with webmail clients like Gmail and Outlook Web Access, as well as ones like Outlook/Mail.app/etc. When sending or receiving email from other organizations, your mail server will communicate over TLS as well. Virtually all ISPs support TLS-protected SMTP today, and if you run your own server you can set it up easily enough. Google's Safer Email Transparency Report publishes statistics about the percent of encrypted email between Gmail and other top email ISPs [1]. TLS wasn't always widely supported in the past -- just as with web servers -- but any modern installation today will support TLS. Modern email installations and usage are secure against passive surveillance as well as HTTPS. Where email is still weak is in its usage of opportunistic TLS (still common if not the default). An adversary capable of conducting a man-in-the-middle attack can force connections to fall back to plaintext, or can present a bogus self-signed certificate since many servers and clients do not expect a path-validated certificate. There are defenses against those attacks, though. You can configure your SMTP server to require TLS, and to accept only path-validated TLS certificates from trusted certificate authorities. This will prevent an adversary from forcing your traffic to plaintext, and will prevent them from substituting a bogus self-signed certificate. With these protections in place, one can achieve a fairly good measure of security with basic email. This is not to say that email is suitable in all circumstances. For high sensitivity use-cases one should consider attacks on infrastructure like the mail server: as we saw in this year's political campaigns, mail servers can be a trove of confidential information. One benefit of the GPG approach is that the mail server does not need to be trusted with the confidentiality of the communication, and so cannot compromise it. [1] https://www.google.com/transparencyreport/saferemail/ https://www.google.com/transparencyreport/saferemail/ The systems that show up as plaintext in this report are largely older commercial bulk email sending systems; all consumer-oriented ISPs adopted TLS a while back.
- angry_octet 10y agoI would dispute your contention that 'most' ISPs support (opportunistic) TLS for SMTP. Looking at the email I receive, both at gmail and self hosted domains, almost no one will do TLS - only big internet companies like eBay. No clients that I'm aware of maintain a history of opportunistic TLS success. Maybe Let's Encrypt will change TLS adoption but I doubt it. It would need Google/Hotmail/Yahoo to increase the spam score for non-encrypted mail. But it's still way too complicated.
- bigbugbag 10y ago> PGP needs to be as simple as the SSL Lock in a browser if there is to ever be any hope of widespread adoption. Something like the level of confidentiality feature in (soon to be) caliopen[1]: >> What is behind the idea of confidentiality level? In Caliopen, every element has its own "confidentiality level" which tells the user what is the security level for any contact or message or conversation... Each terminal declared by the user is graded according to its use (e.g. strictly personal, at home or as a public access within the enterprise), its type (a phone is necessarily less secure than a desktop PC, as it is much easier to loose). When used for the first time, a non declared terminal receives a note of zero. Incoming messages are rated whether they are or not encrypted, and also according to the type of encryption key. The type of transport (secured or not) influences the rating as well as confidentiality level associated to the related contact if it is known. The algorithm that rates a conversation is more complex, but takes into account all described elements. For a user's contact, the confidentiality level is equal to the global confidentiality level of this contact's account: this global confidentiality level is the only public element of a CaliOpen account. Finally, every CaliOpen instance should eventually geWhat is behind the idea of confidentiality level? << [1]: https://caliopen.org/ https://caliopen.org/