Here’s a little rant I posted to an IETF mailing list thread on whether the IETF should move its public-facing services to private-by-default mode. Someone posted a reply suggesting that “the user gets to choose the degree of security that they consider appropriate”.
Here, I think, is a key issue. I disagree. What?! How can I possibly disagree with user choice? Because, a huge majority of people:
Aren’t aware that there is a choice to be made, and shouldn’t need to be,
Do not understand the technical issues surrounding the choice, and shouldn’t have to,
Do not understand the legal/policy issues surrounding the choice, and shouldn’t have to.
This includes both the people who use online services and the people who offer them. Thus, the only sane ethical position is to operate in a mode that is private by default, because the consequences of a positive failure (the user didn’t really need privacy but got it anyhow) are immensely less damaging than the consequences of a negative failure (the user really needed privacy but didn’t get it).
Yes, it is certainly desirable that for those who are in the unusual position of being confident that they understand the technical and policy issues, they be given the option of choosing to operate in plain-text anyone-can-MITM anyone-can-eavesdrop mode. But saying that the needs of that very small and specialized group of people should trump the interests of the vast majority who shouldn’t have to understand or worry about where privacy is appropriate and how to provide it; that seems bizarre to me.
So yeah, please turn the IETF’s public-facing offerings over into private-by-default mode. It’s the only ethical course of action.
[Very lightly edited; for example, I had the positive/negative failure mode labels backward.]
Comment feed for ongoing:
From: PB (Apr 06 2014, at 15:19)
I've come to consider "opt-in" as a fundamental and necessary feature of the Internet and Web as I and most people I respect think of it and have experienced up to this point.
That extends to the choice of how to identify oneself and whether to become public under one's "true name", etc.
Personally, I've seen far more advantage come out of anonymity and pseudoanonymity than disadvantage. Non-trivial advantage.
And I think we should and need to keep participants' activity private, letting them opt-in to public visibility as a conscious and unforced choice. In a sentence, people are more invested in something when it is their choice and they are given control. I hope that this brief comment on the go conveys the essence of what has been some extensive experience and consideration for me.
[link]
From: Steve Wilson (Apr 06 2014, at 17:19)
I completely agree with having session encryption on by default. "User choice" is a consideration, not a religion. Sometimes it makes no sense to offer choice.
My gentle criticism is about something else: the language of "private-by-default". TLS is about security not privacy, and while privacy and security are related, they're very distinct. I'd urge security professionals to be more precise about what TLS/SSL achieves, and that we use the words "encrypted-by-default".
My reasoning is:
- You can encrypt all you like when sending data to a business like Facebook; they will still exploit your PII as much as they can.
- It's vital that security engineers don't equate encryption and privacy, or they will think their job stops with TLS.
- Privacy takes security but it's much more about restraint, limits on collection, limits on use & disclosure, openness etc. We must not use language that equates privacy to security, or subtly makes privacy secondary to security.
- We must not create an expectation that if someone has not encrypted for whatever reason then they have forsaken privacy.
- In fact fundamentally, being in public (that is, unencrypted) is not incompatible with privacy. Data Privacy (or Data Protection) Principles around the world are largely blind to "public" and "private". It doesn't much matter where PII has come from, the collector is still generally subject to Privacy Principles.
[link]