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

It's not so much the number of possible entities (the number is higher than 1000 "possible") but rather the overhead of managing the list in real-time as checks would need to occur on each transaction to ensure the list was updated at all times.  This is where the core costs come into play.  The structure you've highlighted is also not a full representation of what would need to be placed in the cookie - as we'd need creation and expiration dates for each entry as well and likely other anti-fraud elements - further bloating the size of the cookie - not to mention the additional overhead of compression algorithms in the mix.  While the picture you've painted seems feasible since its so overly simplified, in pragmatic reality it is much harder and much more expensive than you imagine.  And your metrics are off as well - we aim to keep total cookie size at under 100 bytes to minimize latency - with an overall goal of sub 100 millisecond transaction speed.  Please remember even if the average page size is 3K - each ad on that page represents a very small portion of the overall size with many other contributing factors coming into play.  The ad industry is already "too slow" and consumers only want their experiences to happen faster - you're pointing in the wrong direction.
- Shane Shane Wiley
VP, Privacy & Data Governance
      From: Mike O'Neill <>
 To: 'Roy T. Fielding' <>; 'TOUBIANA Vincent' <> 
Cc: 'Tracking Protection Working Group' <> 
 Sent: Saturday, November 1, 2014 5:06 AM
 Subject: 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 13:57:19 UTC