RE: Remove profiling prohibition for frequency capping (ISSUE-236)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David, 

The reason it still goes on is because the directive has hardly been enforced, though that may be about to change.

The eprivacy directive is technology agnostic, not just cookies - any way of doing tracking including fingerprinting, as A29 and the CNIL have pointed out. 

Even so, http cookies are still the overarching technique for tracking in Europe. A very few  do it with extending IP addresses with a few extra bits of fingerprinting, or JSONP or ETags, but these are short lived, because the cache gets cleared or ISPs reuse the IP addresses. There is no commercially viable way to do tracking other than with cookies. 

This is why the third-party cookie blocks got circumvented, if there had been any other viable way it wouldn’t have been worth it.

Wire transparency is far better and crowd sourcing will mean it will work faster than waiting for a whistle-blower and 5% turnover fines. It would be easy for the few servers that needed to use a persistent UID for reasons other than tracking to explain it in their privacy policy along with how they de-identify.

Mike

> -----Original Message-----
> From: David (Standards) Singer [mailto:singer@apple.com]
> Sent: 11 September 2014 21:41
> To: Mike O'Neill
> Cc: Justin Brookman; Jeffrey Chester; public-tracking@w3.org
> Subject: Re: Remove profiling prohibition for frequency capping (ISSUE-236)
> 
> Mike
> 
> I don’t agree.  Even if it is true that if I want to track I need to use a cookie, it’s
> not true that seeing a cookie means I am being tracked.  It might raise your
> suspicions, for sure.  Even if the cookie appears unique to me, and has a lifetime
> that is ‘significant’ I still don’t know how much data is being retained by the
> back-end against it.
> 
> The whole question of how DNT is policed and enforced is tricky, and not tied to
> tunnel vision either.
> 
> My suspicion is that the directives on cookies have just moved the behavior to
> other technologies which are either of both of less regulated or less easy to
> detect. I don’t see any point in going there, and I see a lot of point in defining
> what effect must be achieved independent of the technology used.
> 
> On Sep 11, 2014, at 12:30 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > The link with cookies is tracking. Tracking needs cookies (here meaning any
> browser data derived UID), either in-context or other-context. If you do not see
> a cookie you are not being tracked, because the server has no way to recognise
> you (unless MAC based or static IP addresses become the norm which is
> unlikely).
> >
> > We have decided to limit our definition of "Tracking" to other-context
> tracking. If we use that as the only criteria in the compliance document we are
> left with a transparency problem because the only way to recognises it is to
> examine the data hygiene processes of the data controller, which is effectively
> impossible. Maybe if we had something like the data protection regulation
> applied across the world by an international regulator with real teeth, but I bet
> that would not be too popular in the C suite.
> >
> > Before we had separate compliance for 1st parties and 3rd parties. If you saw
> a UID from a 3rd party you could be pretty sure you were being tracked, so that
> was a gain for transparency.
> >
> > In Europe we have other rules that more or less (if they were enforced) give
> people control over tracking by requiring consent for cookies, and they are also
> controlled by some of the better self-regulated opt-out implementations.
> >
> > Now, a 3rd party can continue to use a UID for in-context tracking. It might be
> pretty pointless in most circumstances, but it would not be ruled-out because
> the server could say they had their TV glasses on and so were not "Tracking".
> >
> > This issue is crucial to a meaningful and respected DNT.
> >
> > Mike
> >
> >> -----Original Message-----
> >> From: David (Standards) Singer [mailto:singer@apple.com]
> >> Sent: 11 September 2014 19:41
> >> To: Mike O'Neill
> >> Cc: Justin Brookman; Jeffrey Chester; public-tracking@w3.org
> >> Subject: Re: Remove profiling prohibition for frequency capping (ISSUE-236)
> >>
> >>
> >> On Sep 11, 2014, at 9:45 , Mike O'Neill <michael.oneill@baycloud.com>
> wrote:
> >>
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>>
> >>> In vast majority of cases IP addresses need extra bits e.g. canvas
> fingerprinting
> >> to identify a particular device on a NAT router, and even then the external IP
> >> changes after a few days so is useless for commercial tracking.
> >>>
> >>> That is why it is all cookie based and will be for the foreseeable. IPv6 might
> be
> >> different if everybody uses MAC based autoconf but hopefully that won't
> >> happen.
> >>>
> >>> Tracking is done with cookies and it is relatively easy to detect persistent
> high-
> >> entropy ones. It does not matter what the cookie is called.
> >>>
> >>> This is the weakness of the tunnel vision approach, which otherwise has the
> >> advantage of elegance. To solve that we are going to have to say something
> >> about UIDs.
> >>
> >> I am sorry, DNT basically says “don’t remember information in your database
> >> that tracks me”.  Tunnel Vision has a different definition of what ‘tracks me’
> is
> >> than others, but I don’t see any link to cookies.
> >>
> >> Tunnel vision has two ‘issues’: if you are a privacy advocate, you might not
> like
> >> that it allows sites to remember the fact they have interacted with you;  if
> you
> >> are an industry advocate, you might not like the very clear line is draws (you
> >> identify the user with a context not your own, you’re in violation, very
> simple).  I
> >> guess the first is troubling you, but it’s nothing to do with cookies per se.
> >>
> >>>
> >>> Mike
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: David (Standards) Singer [mailto:singer@apple.com]
> >>>> Sent: 11 September 2014 17:33
> >>>> To: Mike O'Neill
> >>>> Cc: Justin Brookman; Jeffrey Chester; public-tracking@w3.org
> >>>> Subject: Re: Remove profiling prohibition for frequency capping (ISSUE-
> 236)
> >>>>
> >>>>
> >>>> On Sep 11, 2014, at 9:25 , Mike O'Neill <michael.oneill@baycloud.com>
> >> wrote:
> >>>>
> >>>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>>> Hash: SHA1
> >>>>>
> >>>>> You are not off base, but it shows up the transparency/machine visibility
> >> issue.
> >>>> If a third-party uses a cookie (or gets a 1st party cookies placed and uses
> >> that) to
> >>>> recognise the user in multiple transactions for in-context frequency
> counting
> >>>> how can the UA/extension/regulator/user tell if tracking is going on? They
> >>>> would have to rely on trust that "administrative procedures" or tunnel
> vision
> >>>> glasses were being used.
> >>>>
> >>>> Mike
> >>>>
> >>>> the achilles’ heel of DNT is that we can often not tell from the outside if
> >> tracking
> >>>> is going on or not. We’re making an ask about a database that, if all goes
> >> well,
> >>>> we never get to see. Now, that “if all goes well” is why we make the ask,
> >>>> because sometimes it goes very badly (cite notorious cases of repressive
> >>>> governments, leaks, and so on).
> >>>>
> >>>> If the site chooses to use fingerprint technology rather than cookies, e.g.
> >> uses
> >>>> my IP address and OS and Browser info, and keys a whole database off
> that
> >>>> about me, I am none the wiser.  Pushing back against cookies is, I think,
> >>>> sometimes counter-productive: at least I can see cookies flowing, and if
> one
> >> is
> >>>> set labelled ‘user-id’ my eyebrows might go up if DNT is on.
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> Mike
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: David (Standards) Singer [mailto:singer@apple.com]
> >>>>>> Sent: 11 September 2014 17:12
> >>>>>> To: Justin Brookman
> >>>>>> Cc: Jeffrey Chester; public-tracking@w3.org (public-tracking@w3.org)
> >>>>>> Subject: Re: Remove profiling prohibition for frequency capping (ISSUE-
> >> 236)
> >>>>>>
> >>>>>> Unless I misunderstand the definition of tracking, we might not need a
> >>>> permitted
> >>>>>> use at all. It just works.
> >>>>>>
> >>>>>> If an ad site remembers what ads IT has served to ME only, it’s not
> tracking
> >>>> me
> >>>>>> across contexts.  This is something I pointed out when I first floated
> ‘tunnel
> >>>>>> vision’ — that neither first nor third parties need special language to
> >> handle
> >>>> their
> >>>>>> interactions directly with me.
> >>>>>>
> >>>>>> In fact, the first/third distinction is not needed in tunnel vision, as I see
> it.  I
> >>>> think
> >>>>>> Roy may have been saying the same thing.
> >>>>>>
> >>>>>> Now, the site may be able to remember “I served this dishwasher ad to
> >> Dave
> >>>>>> thrice up to now, ’tis sufficient”, but it cannot remember “it was on
> >>>> Sears.com
> >>>>>> that I first served that ad, and on HomeDepot.com the second, but lo! or
> >> the
> >>>>>> third I cannot recall who asked it of me”. That’s remembering data
> across
> >>>>>> contexts.
> >>>>>>
> >>>>>> Or am I off base?
> >>>>>>
> >>>>>> On Sep 11, 2014, at 7:15 , Justin Brookman <jbrookman@cdt.org>
> wrote:
> >>>>>>
> >>>>>>> We are not reopening a discussion on whether there will be a
> permitted
> >> use
> >>>>>> for frequency capping. That has been stable in the TCS for years. Anyone
> >> who
> >>>>>> wanted to remove such a permitted use could have opened an issue on
> this
> >> at
> >>>>>> any time up to October of last year; no one did.
> >>>>>>>
> >>>>>>> This issue raised by Jack is an editorial one. The frequency capping rules
> >> are
> >>>>>> already subject to the Data Minimization and No Personalization
> language
> >> in
> >>>>>> Sections 3.3.1.3 and 3.3.1.4; Jack has made the argument that the last
> >>>> sentence
> >>>>>> in the frequency capping paragraph is thus superfluous.
> >>>>>>>
> >>>>>>> Companies retaining data for frequency capping alone can only collect
> >> and
> >>>> use
> >>>>>> the data minimally necessary for that purpose, and cannot use that data
> >> for
> >>>>>> secondary purposes. There is no basis for retaining web browsing history
> >> for
> >>>>>> frequency capping (unless a cap is tied to showing a number of ads on a
> >>>>>> particular site), and companies will not be able to target ads based on
> the
> >>>> nature
> >>>>>> of frequently shown ads. However, keep in mind that companies are
> likely
> >> to
> >>>>>> retain web browsing history despite a DNT:1 setting for other purposes,
> >>>>>> including attribution and fraud prevention. Of the permitted uses, I
> would
> >>>> think
> >>>>>> frequency capping would be the least concerning to advocates.
> >>>>>>>
> >>>>>>> On Sep 11, 2014, at 9:58 AM, Jeffrey Chester
> >> <jeff@democraticmedia.org>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> Thanks for reminding me that in-flight and associated ad changes are
> >>>> labeled
> >>>>>> as OBA/data driven targeting.  I believe this debate is a useful one,
> because
> >>>>>> frequency capping needs to be vetted taking into consideration EU and
> >> other
> >>>>>> data protection policies.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Jeffrey Chester
> >>>>>>>> Center for Digital Democracy
> >>>>>>>> 1621 Connecticut Ave, NW, Suite 550
> >>>>>>>> Washington, DC 20009
> >>>>>>>> www.democraticmedia.org
> >>>>>>>> www.digitalads.org
> >>>>>>>> 202-986-2220
> >>>>>>>>
> >>>>>>>> On Sep 11, 2014, at 6:53 AM, Shane M Wiley <wileys@yahoo-
> inc.com>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Jeff,
> >>>>>>>>>
> >>>>>>>>> We agreed as a group that any "in flight" changes were deemed
> >>>> behavioral
> >>>>>> targeting, not frequency capping, so we already removed that use case
> >> from
> >>>>>> consideration (such as sequential ads) at the Oct 2013 Sunnyvale
> meeting.
> >>>> The
> >>>>>> use case here is the most simple one imaginable -- not showing the
> same
> >> user
> >>>>>> the same ad more than X times in a Y given time frame - nothing more.
> >>>>>>>>>
> >>>>>>>>> - Shane
> >>>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Jeffrey Chester [mailto:jeff@democraticmedia.org]
> >>>>>>>>> Sent: Thursday, September 11, 2014 3:50 AM
> >>>>>>>>> To: Shane M Wiley
> >>>>>>>>> Cc: Walter van Holst; public-tracking@w3.org
> >>>>>>>>> Subject: Re: Remove profiling prohibition for frequency capping
> (ISSUE-
> >>>> 236)
> >>>>>>>>>
> >>>>>>>>> Walter is correct. In addition, Frequency capping is now also
> connected
> >>>> to
> >>>>>> real-time "in-flight" changes to targeted personalized campaigns. In-
> flight
> >> is
> >>>> ad
> >>>>>> biz term for such ad technique changes done during a campaign, which
> can
> >>>> also
> >>>>>> involve "creative versioning," that is new campaign dynamic elements
> that
> >>>>>> reflect how a person is responding. Capping connected to these and
> similar
> >>>>>> changes to a users experience should not be permitted under DNT:1
> >>>>>>>>>
> >>>>>>>>> Jeff
> >>>>>>>>>
> >>>>>>>>> Jeff Chester
> >>>>>>>>> Center for Digital Democracy
> >>>>>>>>> Washington DC
> >>>>>>>>> www.democraticmedia.org
> >>>>>>>>> Jeff@democraticmedia.org
> >>>>>>>>>
> >>>>>>>>>> On Sep 11, 2014, at 6:38 AM, Shane M Wiley <wileys@yahoo-
> >> inc.com>
> >>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Walter,
> >>>>>>>>>>
> >>>>>>>>>> Then we disagree on the merits here.  Removing frequency-capping
> >> will
> >>>>>> have fairly negative repercussions on users seeing the same ads over-
> and-
> >>>> over-
> >>>>>> and-over driving them to turn off DNT.  The group on both sides agreed
> to
> >>>> this
> >>>>>> carve-out long ago due to the perverse disincentives created in this
> >> scenario
> >>>> (I
> >>>>>> believe only 2 or 3 people out of ~70 ever had an issue here).  Your
> >> technical
> >>>>>> solution is simply unworkable.  Looking forward to the Call for
> Objections.
> >>>>>>>>>>
> >>>>>>>>>> - Shane
> >>>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Walter van Holst [mailto:walter.van.holst@xs4all.nl]
> >>>>>>>>>> Sent: Thursday, September 11, 2014 3:30 AM
> >>>>>>>>>> To: public-tracking@w3.org
> >>>>>>>>>> Subject: RE: Remove profiling prohibition for frequency capping
> >>>>>>>>>> (ISSUE-236)
> >>>>>>>>>>
> >>>>>>>>>>> On 2014-09-11 12:18, Shane M Wiley wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> We've always agreed the frequency-capping would be a permitted
> >> use
> >>>> in
> >>>>>>>>>>> situations where a DNT=1 is received.  Are you suggesting we now
> >>>>>>>>>>> remove that permitted use or are you simply commenting on this
> >>>>>>>>>>> specific language?
> >>>>>>>>>>
> >>>>>>>>>> I am perfectly fine with frequency-capping, as long as it doesn't
> >>>>>>>>>> require profiling at an individual level. It cannot result in
> >>>>>>>>>> collection of data by a third-party if the UA is setting a DNT:1 flag.
> >>>>>>>>>> The mere fact that this particular purpose of tracking is beneficial
> >>>>>>>>>> both to the user and the advertiser does not justify in itself an
> >>>>>>>>>> override of a
> >>>>>>>>>> DNT:1 preference. And I can think of several methods to prevent
> >>>>>> saturation of a particular user with a particular ad, for example
> >> progressively
> >>>>>> dropping least-significant bits of IP-addresses to mask out groups of
> users
> >>>> that
> >>>>>> an ad should not be shown to.
> >>>>>>>>>>
> >>>>>>>>>> I do not recall a broad consensus about this particular permitted
> use.
> >>>>>>>>>>
> >>>>>>>>>> Regards,
> >>>>>>>>>>
> >>>>>>>>>> Walter
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> David Singer
> >>>>>> Manager, Software Standards, Apple Inc.
> >>>>>>
> >>>>>
> >>>>> -----BEGIN PGP SIGNATURE-----
> >>>>> Version: GnuPG v1.4.13 (MingW32)
> >>>>> Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
> >>>>> Charset: utf-8
> >>>>>
> >>>>>
> >>>>
> >>
> iQEcBAEBAgAGBQJUEczlAAoJEHMxUy4uXm2JAj8H/iS1ghWCQ4m+THOdwLFK6m
> >>>> Yo
> >>>>>
> >> 4ChiHzhokfWid9nBxWaOXYDSUMCrIatrT0ug+ilCJUPDr8kTVcdPdsqEYQjlvm0h
> >>>>>
> >> 6MJ4qB9hbCMbr/DOSdr0eXIFjfrzw3tcaMpaqT6uVzYIrxebwJC5vh5bN5AxIjWv
> >>>>>
> >>
> 9YayL1BBjpVITiCLMFxQ9IqWmYbiOvfgwlmj42jh3TG8lNUXJgy2Lx2WyW4Eb9yg
> >>>>>
> >>>>
> >>
> lXFWuDMgutg+Z+2DgNTAhQsw2quIGYK47TdUx86ydPZFHsxOtuZ2/6mPEObioeV
> >>>> Y
> >>>>>
> >>>>
> >>
> c3V5bcXYLueEwxE0DMvak3nzWXu82fIy7atANAGdYoIWmW5IKsuBY7PZjG38TOI
> >>>> =
> >>>>> =b/zN
> >>>>> -----END PGP SIGNATURE-----
> >>>>>
> >>>>
> >>>> David Singer
> >>>> Manager, Software Standards, Apple Inc.
> >>>
> >>> -----BEGIN PGP SIGNATURE-----
> >>> Version: GnuPG v1.4.13 (MingW32)
> >>> Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
> >>> Charset: utf-8
> >>>
> >>>
> >>
> iQEcBAEBAgAGBQJUEdG0AAoJEHMxUy4uXm2JcaQIAJgGJ7Z5kByssTpkcq/dU2d9
> >>>
> >>
> qQ7xcwY9tJ0Ls9WWNP7W6jdpugOvFU7xqj8nF7EEhUmbpBE0peUoRjT1ZlEKP34
> >> q
> >>>
> oN2mDZeYBBo4XoLcUnTYhgj5vs5SfEsrga+dSZY7VFQbOEbDTz+tmvcE6l7u3cKb
> >>>
> >>
> TdmPbd8RUxQe8bDp7WMY642iKAN1QGyoOBsJo5/yw9Go478zxy9RN2xUzGL1V
> >> Qs2
> >>>
> NJ748Gj99Te+yKarp8KazJhcWZbRE6zG6x3cOAABhDVplfTcqHYhpNkNxt+OBGFS
> >>>
> WgZe7ss3JbgUKaIeZVIcs4eJtenuPNsyz6EvdZYSOYrPmzH3cdRvRPAEBS52Xt4=
> >>> =uS0R
> >>> -----END PGP SIGNATURE-----
> >>>
> >>
> >> David Singer
> >> Manager, Software Standards, Apple Inc.
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.13 (MingW32)
> > Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
> > Charset: utf-8
> >
> > iQEcBAEBAgAGBQJUEfhtAAoJEHMxUy4uXm2JZCYIALU4yPKy8pJFscXF1Xqeir9L
> > ArZfAis5pgH+kdHzCqNtau5ebVxWWcUZZnKiLkqof3EnrCbLzeGizR517Z4Q4K/l
> >
> /oC6vHaYnei3Pg0BKO014gfzx8b0HMV30bPlMGRHgOpxGJdGHPOvZ82wi2OgcOn
> F
> > oDCik4s2qFCNEfsJ220V9OrYnO2ysPOyEcWTJDtslnEo7SNsencIRdPqU8++IXX5
> > sZk4K9jSQDi4BaUnKv0z2lquFFT1UQgsmhqAAg0zkVrZZFkIxv0iIK+wV1gjSpNY
> >
> DgtGQ5sUzAA1O0i4GkRb/vOl7GX4wc0z8Dot4L36vs69xEcG3OjzdKUCXT9PXWs=
> > =JRb8
> > -----END PGP SIGNATURE-----
> >
> >
> 
> David Singer
> Manager, Software Standards, Apple Inc.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJUEiD/AAoJEHMxUy4uXm2Jt0cH/0OzwCv4WJlHhhn7y9YOBkIV
kEgMW/dq0fy/m4rNL/JlUdiOdZi9vCHDyazCgNm9m/iim6hXDFY12AdBQnLZvR6S
QF6fJLrgq8Ha2e4ld61tVRiFC14o2lwUlA0NGh8baLhJ2Vp4sgs86GcMjQp88+B4
0L1rIwLF2gOz9slRJEepnS+6JdurX5T4j6M42WmLuWxy7yL6cYtGnS5x9ZFJi96G
vg/eRBlx4XDiGAw/9XTw5b+tw2+EjsftjYyqwrpjQ4+FYQtGd1MePxrF+UgtRDWu
Me0SNFE1oSEpqBtoLUqW4QoU9UEdF9ChaCiCg5pmtsXD9yjck4/FswHqaV5iVjQ=
=pGdW
-----END PGP SIGNATURE-----

Received on Thursday, 11 September 2014 22:25:29 UTC