I think this is an important and useful topic. And as Tim notes, I think it's worth getting to a very clear statement of the problem and associated factors, before getting to the level of technology-specific detail suggested by Kathleen (though I agree that that level of technical detail should be one of the destinations towards which this document moves us).
My main gripe is with the label "privacy protection" as applied to the issues Tim raises. I think the problem statements are good, but I think they are problems of confidentiality, not privacy. To try to illustrate why, I suggest the following scenario: 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. Thereafter. Whenever Primrose returns to the site, she is asked to log in before she can access any of her personal data. So far, this is all consistent with the requirements in Tim's paper. However, InsureMe.com also has a B2B relationship with Gotcher.com, a targeted advertising service. InsureMe.com shares Primrose's data (and that of all its other account holders) with Gotcher.com, but when doing so it always makes the Gotcher folks log in to a data server, and the data passes over an encrypted session. I Primrose hasn't consented to this, her privacy has been violated - but I'm not sure we've broken any of the principles Tim sets out. I think InsureMe.com has put some confidentiality measures in place, between itself and Primrose, and itself and Gotcher.com, but those have not protected Primrose's privacy. I think there are two options: 1 - re-label the problem as one of confidentiality, not privacy, in which case the document is already a good basis for further discussion; 2 - keep the "privacy protection" label, in which case the document needs to build on the existing confidentiality topic, but set it in the context of the broader privacy problem, and explain what confidentiality services contribute towards solving it. I think both options would take us somewhere useful, because users' confidentiality and privacy are *both* affected by the asymmetries and market dynamics Tim describes. Hope this helps, Robin Robin Wilton Technical Outreach Director - Identity and Privacy On 13 Mar 2015, at 21:28, "Stephen Farrell" <[email protected]> wrote: > > Folks, > > On 13/03/15 20:52, Tim Bray wrote: >> This was about to expire so I was going to refresh it but uploader is >> closed of course. See >> https://www.tbray.org/tmp/draft-bray-privacy-choices-01.html >> >> Just a reminder that if this group wants to do anything in this space, my >> editorial services are available. > > I'd be interested in opinions as to how/whether we ought process > this. > > Ta, > S. > > >> >> >> >> _______________________________________________ >> perpass mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/perpass >> > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
