Re: proposed TSV for potential consensus

Roy,

could you comment on the following unease?

Sid Stamm told us about the browser making use of DNT as a tool within a 
variety of privacy tools. Some of them are of blocking nature. 

One option for a browser is to release some of the blocking behavior in 
case a valid TSV response is received. This complements Rob's argument 
about the collection limitation principle. 

Once the vacuum cleaner is fully functioning, the risk of false 
processing is entirely with the user. His data disappears in a blackbox 
where somebody promises that data is eventually filtered and erased. 
This makes assessment of data collection at collection time impossible. 
And this makes people uneasy. 

On the other hand, if one claims out of band consent, DNT is not 
applicable. The risk of false collection is only with the service if 
they claim to have OOBC and don't have it. 

Now assuming I would design a browser extension, I would either ask the 
user back whether he remembers the out of band consent or treat this 
party like not having consent at all. This means my extension would not 
honor the "potential consent" feedback signal and not let more data go 
because I can not assess what they are effectively collecting or using. 

So the unease lies in the fact that the big vacuumcleaner remains intact 
for all interactions. There will be no DNT:1 interaction with less data 
collection.

So why don't we stick with our rule that says, out of band consent 
trumps DNT and that's it? What is the goal behind saying I'm collecting 
everything but I may erase some of it? Compare it to the expected 
reaction of the music industry if I would tell them: "I collect 
everything on P2P networks for 48 hours and if I believe I have a right, 
I will keep the stuff." How can I dispute the belief if I don't know 
whether they kept it?

 --Rigo

On Monday 22 April 2013 22:28:31 Roy T. Fielding wrote:
> I think this is related to ISSUE-195, but really should have been
> raised as a separate issue.
> 
> There was a long discussion about a new tracking status for systems
> that only track by consent but do not actually determine consent
> during request time, originally requested by Alex and more recently
> by Ronan.  Unfortunately, the discussion kept going in the weeds,
> at least partly because people mistook the request as an expansion
> on the existing consent (C) response.
> 
> So, I have written a proposal within the editors' draft as a new
> option with a TSV of P for potential consent.
> 
> ....Roy
> 
> Begin forwarded message:
> > Resent-From: public-tracking-commit@w3.org
> > From: "CVS User rfieldin" <cvsmail@w3.org>
> > Subject: CVS WWW/2011/tracking-protection/drafts
> > Date: April 22, 2013 4:11:49 PM PDT
> > To: public-tracking-commit@w3.org
> > Archived-At: <http://www.w3.org/mid/E1UUPtl-0006gx-Ok@gil.w3.org>
> > 
> > Update of /w3ccvs/WWW/2011/tracking-protection/drafts
> > In directory gil:/tmp/cvs-serv25723/drafts
> > 
> > Modified Files:
> >  tracking-dnt.html
> > 
> > Log Message:
> > ISSUE-195: Add a TSV option for potential consent (P) to address
> > Ronan's use case
> > 
> > ---
> > /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 
2013/
> > 04/22 21:28:40 1.201 +++
> > /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html 
2013/
> > 04/22 23:11:49 1.202 @@ -22,7 +22,7 @@
> > 
> >       wgPublicList: "public-tracking",
> >       wgPatentURI: "http://www.w3.org/2004/01/pp-impl/49311/status",
> >       issueBase:  
> >       "http://www.w3.org/2011/tracking-protection/track/issues/",> 
> > -      noIDLSectionTitle: true,
> > +      noIDLSectionTitle: true
> > 
> >     };
> >   
> >   </script>
> >   <link rel="stylesheet" href="additional.css" type="text/css"
> >   media="screen" title="custom formatting for TPWG editors">> 
> > @@ -544,8 +544,10 @@
> > <dfn>TSV</dfn>    = "1"              ; "1" — first-party
> > 
> >        / "3"              ; "3" — third-party
> >        / %x43             ; "C" - consent
> > 
> > +       / %x50             ; "P" - potential consent
> > 
> >        / %x44             ; "D" - disregarding
> >        / %x4E             ; "N" - none
> > 
> > +       / %x50             ; "P" - potential consent
> > 
> >        / %x55             ; "U" - updated
> >        / %x58             ; "X" - dynamic
> >        / ( "!" [testv] )  ; "!" - non-compliant
> > 
> > @@ -660,6 +662,42 @@
> > 
> >           </p>
> >         
> >         </section>
> > 
> > +        <section id='TSV-P' class="option">
> > +          <h4>Potential Consent (P)</h4>
> > +          <p>
> > +            A tracking status value of <dfn>P</dfn> means that the
> > origin +            server does not know, in real-time, whether it
> > has received prior +            consent for tracking this user,
> > user agent, or device, but +            promises not to use any
> > <code>DNT:1</code> data until such consent +            has been
> > determined, and further promises to de-identify within +           
> > forty-eight hours any <code>DNT:1</code> data received for which + 
> >           such consent has not been received.
> > +          </p>
> > +          <p>
> > +            Since this status value does not itself indicate
> > whether a +            specific request is tracked, an origin
> > server that sends a +            <code>P</code> tracking status
> > value MUST provide an +            <code><a>edit</a></code> member
> > in the corresponding tracking +            status representation
> > that links to a resource for obtaining +            consent status.
> > +          </p>
> > +          <p>
> > +            The <code>P</code> tracking status value is
> > specifically meant to +            address audience survey systems
> > for which determining consent at +            the time of a request
> > is either impractical, due to legacy systems +            not being
> > able to keep up with Web traffic, or potentially "gamed" +         
> >   by first party sites if they can determine which of their users +
> >            have consented. It cannot be used for the sake of
> > personalization +            unless consent is determined at the
> > time of a request, in which +            case the
> > <code><a>C</a></code> tracking status is preferred. +          </p>
> > +          <p class="issue" data-number="195" title="Flows and
> > signals for handling out of band consent"> +           
> > <b>[OPEN]</b> The <code><a>P</a></code> tracking status +          
> >  value indicates a special case of general data collection which + 
> >           is then trimmed to exclude those without out of band
> > consent. +          </p>
> > +        </section>
> > +
> > 
> >         <section id='TSV-D' class="option">
> >         
> >           <h4>Disregarding (D)</h4>
> >           <p>

Received on Tuesday, 23 April 2013 20:50:01 UTC