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.
Yet the world insists on using red/green as bad/good indicators. Drives me nuts.
(There's a 33% chance that exactly one of them is: 0.1 × 0.9⁴ × ⁵C₁).
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.
e^-0.5*sum((i)->(0.5^i/factorial(i)), 1:5) = ~39%Why? This is basic statistics (% of population).
The Poisson distribution is what you use when the effective number of chances is "large". The Poisson distribution is effectively a special case of the binomial distribution, where the number of chances is infinity, the probability per chance is infinitesimal, and the product of the two is the expected number of events.
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%.)
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.
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!
1 https://cran.r-project.org/web/packages/viridis/vignettes/in...
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/ 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.
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.
This only works if you're also forcing DNSSEC: otherwise, the attacker can substitute their own MX in your DNS responses.
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? <<
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.