Subject: Re: [perpass] draft-bray-privacy-choices-00.html

From: Tim Bray <[email-masked]>
Date: Sat, 11 Apr 2015 10:23:47 -0700

I finally got around to submitting the -01 draft, considerably
re-organized, per feedback here, to make it clear that the discussion is
independent of any particular technology, and to include a tl;dr er cough
excuse me “Summary” section.

Real HTML is at https://www.tbray.org/tmp/draft-bray-privacy-choices-01.html

===========================================================
A new version of I-D, draft-bray-privacy-choices-01.txt
has been successfully submitted by Tim Bray and posted to the
IETF repository.

Name:           draft-bray-privacy-choices
Revision:       01
Title:          Privacy Choices for Internet Data Services
Document date:  2015-04-11
Group:          Individual Submission
Pages:          5
URL:
http://www.ietf.org/internet-drafts/draft-bray-privacy-choices-01.txt
Status:         https://datatracker.ietf.org/doc/draft-bray-privacy-choices/
Htmlized:       http://tools.ietf.org/html/draft-bray-privacy-choices-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-bray-privacy-choices-01

Abstract:
   This document argues in favor of Internet service providers deploying
   technologies which offer increased privacy to users of their
   services.  The discussion is independent of any particular privacy
   technology.  The approach is to consider common objections to the the
   deployment of such technologies, and show that these objections are
   not well-founded.

On Mon, Mar 16, 2015 at 7:45 AM, Robin Wilton <[email-masked]> wrote:

> Hi Steve - and thanks for the correction.
>
> I agree with your additional use-cases/threat scenarios, naturally… I was
> just trying to keep it to one simple illustration ;^)
>
> R
>
> On 16 Mar 2015, at 14:22, Stephen Kent <[email-masked]> wrote:
>
> > Robin,
> >> ...
> >>
> >> Primrose goes to InsureMe.com, where she will be asked for a lot of
> personal data. InsureMe.com invites her to register and create a new
> account, with an ID and password; all this is done over https, so
> InsureMe.com is confident it has taken suitable steps to protect the data
> from being visible to third parties.
> > Third parties on the wire. Experience shows that Primrose's data is most
> likely to be
> > disclosed to third parties once it is on the InsureMe.com web site. Your
> example
> > goes on to cite a privacy violation in the form of Gotcher.com. But, a
> successful attack
> > against InsureMe.com also would violate the confidentiality of
> Primrose's data.
> >
> > Bottom line: I agree with your observation that privacy is not the same
> as
> > confidentiality, and we often overly simplify these discussions.
> >
> > Steve
> >
> > _______________________________________________
> > perpass mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/perpass
>
>
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>
>

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Robin Wilton <[email-masked]>
Date: Tue, 14 Apr 2015 13:19:28 +0000

Many thanks, Tim -

I think this is a substantial improvement, and still, of course, a worthwhile line of investigation.

There are two areas where I think the situation is more nuanced than the text currently suggests, though I appreciate your wish to keep things as simple and succinct as possible. Here are a couple of comments on those two areas:

5.1 Free public data:

I agree with your basic thesis, which is that the publisher of information can’t reliably tell whether accessing that information will have negative consequences for the individual concerned.
The negative consequences are likely to arise from culturally- or nationally-specific factors, which may not apply (or even occur) to the publisher, whereas access to the data in question is overwhelmingly likely to transcend national and cultural boundaries. (Of course, things that qualify as “free public data” in one national or cultural context may be no such thing in another).

Therefore, you conclude, publishers’ default should be to publish in a way that respects the privacy of their readership. The implication is that it should be possible to access free public data anonymously or pseudonymously.

I agree, but you will also encounter people who strongly believe otherwise. I blogged about some of the perverse consequences of that position, after the IGF in Baku.

Bottom line: your privacy-respecting stance here will come under attack for reasons other than the ones your thesis currently implies. I happen to think most of those attacks are ill-founded, but they will surface and need to be dealt with.

5.2 Privacy at user option

Here, your basic thesis is that privacy decisions are complex enough to make it impractical for users to have to "opt in” if they want privacy; therefore maximum privacy protection should be the default. There’s an implication that users should have to explicitly opt out of privacy protections as and where they see fit, but I’m not sure whether you even intend them to have that choice… As I will say below, I’m not sure whether you are advocating removal of the need to choose, or the ability to choose — and I think those are quite different.

I think you will encounter two forms of push-back to this position. 

First, we have seen (in the arguments over a “Do Not Track” flag in browsers) how some vendors/service providers will maintain that a “privacy by default” setting does not truly reflect the wishes of the user (and some would go further and claim that it is not in their best interests, either). There is the potential for paternalism on both sides of this argument, so one has to be careful how the question is framed: is “opted out by default, with the user choosing to opt in” any better than “opted in by default, with the user choosing to opt out”?
If maximum privacy protection is to be the default, what’s the best way to allow users to share consensually when they intend to do so?

Second, it’s probably true that the decisions to opt in or opt out are indeed complex, contextual, variable over time, etc. etc… But removing the need (or ability) to decide is not necessarily the answer. (Tired analogy: my current car’s engine is far more complex than the one my old Mini had. It makes millions of decisions on my behalf, every time I use it. But the interface presented to me is still the same arrangement of pedals, gear lever and dials… and the engine only produces the effects I intend, even if the underlying process is beyond my understanding).

Bottom line: I think there is scope for the complexity of privacy decisions (whether opt-out or opt-in) to be partly addressed by improvements in the technology that acts on the user’s behalf - putting the user’s simply-stated preferences and choices into practice, without requiring the user to renew or confirm those every time the question arises. An intelligent user agent, over which the user exercises complete control. (And, as I say, I think this would only form part of the over-all picture).

Well, I can dream, can’t I?

HTH,
Robin

Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet Society

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

On 11 Apr 2015, at 18:23, Tim Bray <[email-masked]> wrote:

> I finally got around to submitting the -01 draft, considerably re-organized, per feedback here, to make it clear that the discussion is independent of any particular technology, and to include a tl;dr er cough excuse me “Summary” section.
> 
> URL:            http://www.ietf.org/internet-drafts/draft-bray-privacy-choices-01.txt
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-bray-privacy-choices-01
> 
> Abstract:
> I agree with your additional use-cases/threat scenarios, naturally… I was just trying to keep it to one simple illustration ;^)
> 
> R
> 
> >> Primrose goes to InsureMe.com, where she will be asked for a lot of personal data. InsureMe.com invites her to register and create a new account, with an ID and password; all this is done over https, so InsureMe.com is confident it has taken suitable steps to protect the data from being visible to third parties.
> > Third parties on the wire. Experience shows that Primrose's data is most likely to be
> > disclosed to third parties once it is on the InsureMe.com web site. Your example
> > goes on to cite a privacy violation in the form of Gotcher.com. But, a successful attack
> > against InsureMe.com also would violate the confidentiality of Primrose's data.
> >
> > Bottom line: I agree with your observation that privacy is not the same as
> - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)