Re: do not track list?

I have a lot of concerns about simplified "do not track me" proposals, such as the HTTP header.  On the face of it, it looks nice -- like "Do not call me".  But there are two huge problems:

a) We all know what we mean by 'Calling me';  'tracking me' is way more nebulous;
b) I know when you violate 'do not call' -- my phone rings!  I might never find out that you were tracking me.

There is a tracking 'slippery slope' -- imagine an online store:  keeping records of what was purchased (clearly OK for stock management purposes), when it was purchased (sure, patterns by time of day allow me to size my services), where it was purchased (yes, this allows me to optimize the stock I hold in various distribution centers), what else was purchased at the same time or by the same individual (sure, that allows me to say "do you need a bag with that?"), and so on.  At some point, this purchase record gets detailed enough to be de-anonymizable (ugh, what a horrible word).

Or, in order to make the web site 'work', I cookie you so that when you, for example, go back to a page, I can restore the aspects of that that are related to your dynamic state.  Or I take care not to show you the same advert twice.  Am I tracking 'you' (personally)?  This might not be clear.

Ambiguities are barn doors to the nefariously minded.  Couple that with the inability to verify compliance, and that it's only a 'request', and I think we have problems.



As an aside, I am still curious to know what exactly is meant by 'privacy by design' -- or is it just that privacy management and maintenance is part of the design process and considerations?  If that's it, it sounds really hard.  We're not even sure of the privacy implications of doing a straightforward implementation of our specifications, I think.


David Singer
Multimedia and Software Standards, Apple Inc.

Received on Friday, 19 November 2010 19:30:34 UTC