RE: Indirect DNT Processing (Proposed)

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

Roy,

The service provider qualification is used in the opposite sense for which the definition (of service provider) was designed. In this case the ad exchange may be passing PII to bidders, DSPs  etc. who are not service providers of the ad exchange or indeed the first-party site controller. The user is led to expect from the definition that data about them is shared only with parties who have no right to use for their own purposes, acting merely as a “data processor” for the responsible party, which is not what is happening here. They do not even know who the responsible party is.

As has already been said, forwarding an expressed tracking preference to bidders is impossible (assuming a literal reading of the UGE API i.e. you cannot use a site-specific confirm to get the web-wide UGE status of other origins). If we mean that exchanges must broadcast PII to do that we undermine the whole point of the standard, as we do also asking people to believe “impossible things” (and not just before breakfast).

The alternative to server-server bidding is to have all the bidders own real estate on the page. This may be unwieldy but at least the user has the chance to see who is collecting their PII, read their TSR etc. With this the user may be allowed to see who won the bid (assuming the TSV has a dynamic "controller" property in it), but not the many who lost but were invisibly sent their web history.

Mike


> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@gbiv.com]
> Sent: 05 December 2014 01:06
> To: Shane M Wiley
> Cc: 'Tracking Protection Working Group'
> Subject: Re: Indirect DNT Processing (Proposed)
> 
> This is ISSUE-262 ...
> 
> I have attempted to address the general problem of gateways to
> multiple parties using a TSV of G.  My proposal can now be seen in the
> editors draft at
> 
> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#TSV-G
> 
> and a diff is below.
> 
> ....Roy
> 
> Index: tracking-dnt.html
> =================================================================
> ==
> RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-dnt.html,v
> retrieving revision 1.273
> diff -u -r1.273 tracking-dnt.html
> --- tracking-dnt.html 24 Sep 2014 00:09:56 -0000 1.273
> +++ tracking-dnt.html 5 Dec 2014 00:46:45 -0000
> @@ -571,6 +571,7 @@
>            <pre class="abnf">
>  <dfn>TSV</dfn>    = %x21   ; "!" - under construction
>         / %x3F   ; "?" - dynamic
> +       / %x47   ; "G" - gateway to multiple parties
>         / %x4E   ; "N" — not tracking
>         / %x54   ; "T" — tracking
>         / %x43   ; "C" - tracking with consent
> @@ -609,13 +610,61 @@
>              responses to requests on the designated resource.
>              If <code>?</code> is present in the <a>Tk</a> header field,
>              more information will be provided in a request-specific
> -            tracking status resource referred to by the <a>status-id</a>.
> +            tracking status resource referred to by the <code><a>status-
> id</a></code>.
>              An origin server MUST NOT send <code>?</code> as the
>              tracking status value in the representation of a
>              request-specific tracking status resource.
>            </p>
>          </section>
> 
> +        <section id='TSV-G'>
> +          <h4>Gateway (G)</h4>
> +          <p>
> +            A tracking status value of <dfn>G</dfn> means the origin server
> +            is acting as a gateway to an exchange involving multiple parties.
> +            This might occur if a response to the <a>designated resource</a>
> +            involves an automated selection process, such as dynamic bidding,
> +            that determines which party is able to collect tracking data.
> +            Similar to the <code>?</code> value, the <code>G</code> TSV
> +            indicates that the actual tracking status is dynamic and will be
> +            provided in the response message's <a>Tk</a> header field,
> +            presumably using information forwarded from the selected party.
> +          </p>
> +          <p>
> +            This tracking status value is only valid as a site-wide status.
> +            An origin server MUST NOT send <code>G</code> as the
> +            tracking status value in a <a>Tk</a> header field or within the
> +            representation of a request-specific tracking status resource.
> +            An origin server MUST NOT send <code>G</code> as the tracking
> +            status value if it knows in advance that all of the potential
> +            recipients have agreed on a single tracking status value of
> +            <code>N</code> (not tracking); in this case, the origin server
> +            MUST respond with <code>N</code> instead of <code>G</code>.
> +          </p>
> +          <p>
> +            If <code>G</code> is present in the site-wide tracking status:
> +            <ul>
> +              <li>the origin server MUST meet the requirements of a
> +                service provider for each of the parties to which it
> +                provides request data;</li>
> +              <li>the origin server MUST send a link within its site-wide
> +                tracking status representation to a privacy policy that
> +                explains what limitations (if any) are placed on parties that
> +                might receive data via that gateway;</li>
> +              <li>the origin server MUST forward any expressed tracking
> +                preference in the request to each party that receives data
> +                from that request;</li>
> +              <li>the origin server MUST send a <a>Tk</a> header field in
> +                responses to requests on the designated resource and include
> +                within that field's value a <code><a>status-id</a></code>
> +                specific to the selected party, such that information about
> +                the selected party can be obtained via the request-specific
> +                tracking status resource (see
> +                <a href="#request-specific-status-resource"
> class="sectionRef"></a>).</li>
> +            </ul>
> +          </p>
> +        </section>
> +
>          <section id='TSV-N'>
>            <h4>Not Tracking (N)</h4>
>            <p>
> @@ -739,11 +788,12 @@
>            <h4>Definition</h4>
> 
>            <p>
> -            The <dfn>Tk</dfn> response header field is hereby defined as an
> -            OPTIONAL means for indicating the tracking status that applied
> -            to the corresponding request and as a REQUIRED means for
> -            indicating that a state-changing request has resulted in an
> -            interactive change to the tracking status.
> +            The <dfn>Tk</dfn> response header field is a means for indicating
> +            the tracking status that applied to the corresponding request.
> +            An origin server is REQUIRED to send a <code>Tk</code> header
> +            field if its site-wide tracking status value is <a>?</a>
> +            (dynamic) or <a>G</a> (gateway), or when an interactive change is
> +            made to the tracking status and indicated by <a>U</a> (updated).
>            </p>
>            <pre class="abnf">
>  <dfn>Tk-field-name</dfn>   =  "Tk"
> @@ -769,11 +819,12 @@
>              If an origin server has multiple, request-specific tracking
>              policies, such that the tracking status might differ depending on
>              some aspect of the request (e.g., method, target URI, header
> -            fields, data, etc.), the origin server MAY provide an additional
> +            fields, data, etc.), the origin server can provide an additional
>              subtree of well-known resources corresponding to each of those
> -            distinct tracking statuses.  The OPTIONAL <a>status-id</a> portion
> -            of the <a>Tk</a> field-value indicates which specific tracking
> -            status resource applies to the current request.
> +            distinct tracking statuses. The <code>status-id</code>
> +            portion of the <a>Tk</a> field-value indicates which specific
> +            tracking status resource applies to the current request.
> +            The <code>status-id</code> is case-sensitive.
>            </p>
>            <pre class="abnf">
>  <dfn>status-id</dfn>       =  1*id-char
> @@ -791,10 +842,17 @@
>            </p>
>            <pre>/.well-known/dnt/fRx42</pre>
>            <p>
> +            Note that the <code>status-id</code> is resolved relative
> +            to the origin server of the current request.  A retrieval request
> +            targeting that URI can be redirected, if desired, to some other
> +            server.  The <code>status-id</code> has been intentionally limited
> +            to a small set of characters to encourage use of short tokens
> +            instead of potentially long, human-readable strings.
> +          </p>
> +          <p>
>              If a Tk field-value has a tracking status value of
> -            <code><a>?</a></code> (dynamic), then the origin server MUST also
> -            send a <code><a>status-id</a></code> in the field-value.
> -            The status-id is case-sensitive.
> +            <code><a>?</a></code> (dynamic), the origin server MUST
> +            send a <code>status-id</code> in the field-value.
>            </p>
>          </section>
> 
> @@ -865,12 +923,12 @@
>              If an origin server has multiple, request-specific tracking
>              policies, such that the tracking status might differ depending on
>              some aspect of the request (e.g., method, target URI, header
> -            fields, data, etc.), the origin server MAY provide an additional
> +            fields, data, etc.), the origin server can provide an additional
>              subtree of well-known resources corresponding to each of those
>              distinct tracking statuses.  The <a>Tk</a> response header field
>              (<a href="#response-header-field" class="sectionRef"></a>) can
> -            include a <a>status-id</a> to indicate which specific tracking
> -            status resource applies to the current request.
> +            include a <code><a>status-id</a></code> to indicate which specific
> +            tracking status resource applies to the current request.
>            </p>
>            <p>
>              A <dfn>tracking status resource space</dfn> is defined by the
> 

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

iQEcBAEBAgAGBQJUgZnUAAoJEHMxUy4uXm2JzuoH/iZn8peRmab1ElBz7NGn/cMB
TrM7Y+52e4zfjnLEgwI19bJg9oNBvb280muOnPrxyxYpuYXnTu5UZ4W6qDYJ5Kig
eT+9g2QGuexbx3iJSPiRBn/41Yy41qZAh2u8U5W7LrR/zV3ijnhwlPIrdWZixsJo
eBj7zGyrIuuGDlbBBj6YJ6feakGj0RJ8OqC9ga+5AAmqjQeu2dvINb2OJdHONpPI
rosl+HjXk0quftwS8sxgW6XGLneRMHS7iPEhfdYNOJov6hOwIyDbRZodFIst7w0l
rqNEA2UvxajOf1oCtndWPN5YIETNPhDdt81aepMbhvc6+4Iull/dRh3F4Z1xUzQ=
=TeI1
-----END PGP SIGNATURE-----

Received on Friday, 5 December 2014 11:42:01 UTC