W3C home > Mailing lists > Public > public-tracking@w3.org > July 2013

RE: ISSUE-151 Re: Change proposal: new general principle for permitted uses

From: Shane Wiley <wileys@yahoo-inc.com>
Date: Sun, 28 Jul 2013 21:29:28 +0000
To: Rigo Wenning <rigo@w3.org>
CC: Chris Mejia <chris.mejia@iab.net>, "public-tracking@w3.org" <public-tracking@w3.org>
Message-ID: <DCCF036E573F0142BD90964789F720E3141113E5@GQ1-MB01-02.y.corp.yahoo.com>

Depending on the cost of #1, I would recommend we actually do both to limit false signals - and anyone thing else we can think of.

Question on #1 - can a FF Add-On intercept the UGE JS check and reply on the behalf of the browser or will this always be restricted to the browser alone?  I'm hopeful of the latter but want to double check.

- Shane

-----Original Message-----
From: Rigo Wenning [mailto:rigo@w3.org] 
Sent: Sunday, July 28, 2013 2:20 AM
To: Shane Wiley
Cc: Chris Mejia; public-tracking@w3.org
Subject: Re: ISSUE-151 Re: Change proposal: new general principle for permitted uses


nice summary. Do you want to keep this under ISSUE-151? 

I think the solutions have to be discussed with the browser makers. 

E.g. if we can find a different algorithm to generate the signature without CERT that isn't easy for the routers and dumb tools and that still has browser support, we have an option. Matthias is on holidays, but he is rather good in those encryption things. This will go into TPE anyway. 

But I do not believe that avoiding the easy router spawning of DNT- signals will lower the rate of DNT-signals on the long run. So it is decisive to have a means to turn DNT:0 on and to encourage such a solution at the same time.

So solution 1 has the advantage of giving more incentives to implement UGE. Solution 2 looks smarter from a technology perspective. 

This could be done in a TF with the browsers (like with audience
measurement) where we come back to the group with a suggestion that makes sense and look for consensus for that solution (or change proposals). 

Would that make sense to you? 


On Saturday 27 July 2013 22:24:46 Shane Wiley wrote:
> So it appears we have several possible solutions emerging:
> Solution 1:  UGE Check
>         Desc    - On each 3rd party call that receives a DNT:1 -
> bounce a UGE check call to determine if the    User Agent repeats
> with a DNT:1 
>         Pros    - If a 3rd party software/network solution is
> injecting the DNT signal, the UGE check will      come back with a
> DNT:0 or DNT:<null>.  The Server would honor the UGE check signal. 
>         Cons    - All 3rd party calls would universally need to ping
> the UA before transmitting their call      back to their
> servers.  This could be expensive from a timing perspective -
> especially in an    environment where we're already pressed for
> time.  More testing needed. - Non-JS scenarios have no solution.
> Solution 2:  Signed/Keyed DNT
>         Desc    - the DNT header signal would be signed against a
> digital certificate
>         Pros    - Removes the lazy non-compliant software
> package/network appliance from the problem - Is the same approach 
> industry would likely take if we discovered opt-out cookies were
> being           turned on by default without user interaction -
> Depending on approach would likely work with non-JS environments as 
> well
>         Cons    - Not sure how to handle cert signing in this case in
> a manner that a 3rd party software                        package or
> network device wouldn't be able to thwart in an easy manner - No 
> trusted intermediary to validate cert through - If effective, 3rd 
> party software could move to simply activating DNT:1 within the UA
> via a            config file or macro activation
> Neither is a silver bullet but definitely worth further discussion.  I 
> didn't list Mike's cookie option as I don't believe it's a fair 
> starting point to require validation through cookies which can be 
> cleared in mass whereas the DNT signal is more persistent.  DNT 
> validation should be on parity with UA persistence.
Received on Sunday, 28 July 2013 21:30:08 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:17 UTC