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

-----BEGIN PGP SIGNED MESSAGE-----
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 adex.com 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.


Mike






> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@gbiv.com]
> 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
> 

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

iQEcBAEBAgAGBQJUVMy/AAoJEHMxUy4uXm2JnRIH/RfNvjr52NswHqGy+Gl/bREJ
JC3n4Z//LToEyii4VEVNt3rYnT1zkh7v5Nn+VlA4jHqM/DEpbwfJn/Kjj8yD7sD1
Se2P4fyN6Rqc4lo23Lcyb6DDz6i0HXpHLvEwmjpS27QEGxJTKStFegFEyMLs03Iv
PVCkZdyNm9fBJnnS8ib/OZ9WUzQ72PhA6LxMWMGl99sBmjJuD/Dxt7vvYs2qJBRg
5sA70EL6MpfMoV3h0Rt7+LbdlEOmjq+SUYK7d+/Asvys1xilNUcYma22Eq5au40W
vX+Xm8Z+WZQeyhXlUys3Zl+tTVGfIVzp1i2AAFZUh3gTcBr5/3HPdwDmu4S/x/I=
=glmw
-----END PGP SIGNATURE-----

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