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

-----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
/oC6vHaYnei3Pg0BKO014gfzx8b0HMV30bPlMGRHgOpxGJdGHPOvZ82wi2OgcOnF
oDCik4s2qFCNEfsJ220V9OrYnO2ysPOyEcWTJDtslnEo7SNsencIRdPqU8++IXX5
sZk4K9jSQDi4BaUnKv0z2lquFFT1UQgsmhqAAg0zkVrZZFkIxv0iIK+wV1gjSpNY
DgtGQ5sUzAA1O0i4GkRb/vOl7GX4wc0z8Dot4L36vs69xEcG3OjzdKUCXT9PXWs=
=JRb8
-----END PGP SIGNATURE-----

Received on Thursday, 11 September 2014 19:32:25 UTC