RE: ISSUE-262: guidance regarding server responses and timing

Hash: SHA1

Roy, we already have a mechanism, https, to stop intermediaries like ISPs seeing the data, and there exist legal restrictions on that almost everywhere anyway. The problem with this use case is that user's PII (at least their web history) is being invisibly broadcast to many unknown third-parties. 

With opt-out cookies there is no technical alternative, which leads to a regulatory risk as people could be misled that their opt-outs are being acted upon. Luckily this can be avoided using the TPE.

Shane, only the intersection of bidder, service provider relationships, and consented-to party needs to be in the list. How many would you estimate it to be?

For example assume a particular ad exchange has service provider contracts with 1000 bidders of which a user has given their consent to 100. There would be a JSON array of 1000 urls to be passed in the arrayOfDomainStrings property. The list would be downloaded asynchronously in a compressed JSON file, say ~4K bytes, so not much overhead.

After the repetitive calling of confirmSSTPE we end up with 100 consented-to domains, which can be encoded into 100 10bit nodes (10 bits is enough to encode the indices to a 1024 length service provider array), say ~130 bytes, into a domain cookie. This is a tiny overhead on the average 3K per page cookie burden, and could be even lower with a better coding algorithm.

I think this is very feasible. The API could be improved say in DNT2.0 by getting the confirm to return a Boolean array or even an array of indices directly.


> -----Original Message-----
> From: Roy T. Fielding []
> Sent: 31 October 2014 22:17
> To: TOUBIANA Vincent
> Cc: Mike O'Neill; Tracking Protection Working Group
> Subject: Re: ISSUE-262: guidance regarding server responses and timing
> On Oct 31, 2014, at 1:10 PM, TOUBIANA Vincent wrote:
> > The Ad-exchange is sharing the data with third parties and therefore does not
> respect the DNT signal in the first place. If an Ad-exchange plans to share data
> about a transaction with a set of third parties it should send a disregard
> response. I don't see how the "I'm a 1:N gateway" would not be interpreted as
> "I'm sharing data related to this transaction".
> We don't require ISPs and routers to respond to DNT, yet they are sharing
> just as much information as an HTTP recipient.  Why?  Because we assume
> (incorrectly) that they are service providers for the user agent.  Likewise,
> we provide definitions to allow service providers for a given service to
> answer on behalf of the owner of that service, because doing so within the
> restrictions of a service provider contract makes them no worse for privacy
> than interacting with the owner directly.
> What Shane has described is a fairly unusual form of service provider
> because it is acting on behalf of many parties (most of which are
> likely to be third parties, but some might be the first party).
> I didn't include that use case in the current design of TPE.
> However, it is fair to say that it does exist, and that it won't be
> disappearing just because the TPWG finds it inconvenient or even
> alarming.
> Our task is therefore to make the use case transparent and to include
> enough requirements to make the 1:N gateway capable of communicating
> enough of DNT's semantics so that only a deliberately non-conforming
> origin server (bidder) would fail to adhere to them.  After all, this
> use case only impacts the DNT response, which is largely irrelevant to
> users of DNT.
> ....Roy

Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.3.26.5094 -
Charset: utf-8


Received on Saturday, 1 November 2014 12:07:17 UTC