Re: An alternative to site-specific user granted exceptions (Issue-111)

Full quote as a proof that functionally, only taking the third party 
services that the first party knows (and has allowed on their site, which is 
the legally relevant act) is providing a remedy to this very complex 
situation. A requirement to know and declare the entire chain equals a full 
blown personal-data-drm-system and is overkill IMHO. In the EU this is not 
an issue because of purpose limitations (ad and tracking). For the US we 
might ad some wording if people feel a need. 

There shouldn't be a JS vs WKL. Because JS will also allow a site to 
interface to the user without using the browser interface and is more 
important for the interaction while the WKL allows easy discoverability and 
is declarative and simple for simple sites.

(and my broken record still says that you're better off with headers than 
with WKL anyway... )

Rigo

On Wednesday 25 April 2012 11:47:09 Ian Fette wrote:
> it's likely at least on the order of hundreds, and is often not in the
> first party's control. It can change dynamically without the first party
> knowing. In short, in many cases, there's no good way for a first party to
> be able to enumerate this. The first party may know the next person in
> the chain, but the next person in the chain can decide who to redirect
> to, this can be any number of people, and then that next person in the
> chain can also decide to redirect to any number of people, and all of
> these are dynamic.
> 
> -Ian
> 
> On Wed, Apr 25, 2012 at 8:01 AM, TOUBIANA, VINCENT (VINCENT) <
> 
> Vincent.Toubiana@alcatel-lucent.com> wrote:
> > Kevin,
> > 
> > I thought that it would help to solve the ad chain issue because the 1st
> > party does not have to know the chain that would be generated
> > dynamically, it could just generate a static list of all the potential
> > third parties that could be called.
> > Do you have an estimation of how many third parties would have to be
> > listed in that case? If its one or two dozens, that could work, if its
> > hundreds then it might not make sense.
> > 
> > Maybe knowing the root of the chain might be enough (that could also
> > work
> > for explicit/explicit user granted exceptions).
> > 
> > Thank you,
> > 
> > Vincent
> > ________________________________________
> > From: Kevin Smith [kevsmith@adobe.com]
> > Sent: Friday, April 20, 2012 6:03 PM
> > To: TOUBIANA, VINCENT (VINCENT); public-tracking@w3.org
> > Subject: RE: An alternative to site-specific user granted exceptions
> > (Issue-111)
> > 
> > I like this suggestion.  I have expressed many times that I believe
> > passing in 3rd parties into the specific javascript calls will only work
> > in the very simplest of cases.  I think this will extend the usefulness
> > of the JS API because it is much more scalable to manage your list of
> > 3rd parties in a single location than on a per page per JS request
> > basis.  In practice, if I were forced to use the JS API as is, I would
> > probably mimic this behavior using centralized global JS variables to
> > represent the 3rd party groups.  However, this approach would be much
> > cleaner.
> > 
> > However, I do not understand how it solves the ad chain problem.  If the
> > 1st party does not know who is in the ad chain, and the ad chain is
> > dynamic, then it cannot put the 3rd parties in this doc any more easily
> > than it could put them directly in the JS call.
> > 
> > -----Original Message-----
> > From: TOUBIANA, VINCENT (VINCENT) [mailto:
> > Vincent.Toubiana@alcatel-lucent.com]
> > Sent: Tuesday, April 17, 2012 12:04 PM
> > To: public-tracking@w3.org
> > Subject: An alternative to site-specific user granted exceptions
> > (Issue-111)
> > 
> > 
> > I suggest an alternative to site-specific exceptions (Issue-111).
> > Instead
> > of providing the list of 3rd parties through the JavaScript API, this
> > list could be provided through Tracking Status Representation
> > (available through the well-known URI).
> > There is already a field to send that list to the UA (See section 5.1.2
> > in TPE document) but it is currently optional. If we replace the MAY by
> > a MUST, then users could get the list of third parties present on a
> > site before they visit it and then decide if they are ready to grant a
> > site-wide exception.
> > 
> > Pros:
> > -       User grant exceptions knowing which third parties could track
> > them -       This does not broke the chain in ad-exchanges
> > -       Publisher do not have to ask new user granted exceptions when
> > they add third parties
> > Cons:
> > -       Users have to check the well known URI more often
> > -       Users can not provide feedback about the third parties present
> > on
> > a website (a non granted exception is - in my opinion-- an explicit
> > feedback).
> > 
> > I still prefer the site-specific exception mechanism as it gives users
> > more choices, but I believe this solution could be seen as a middle
> > ground.
> > 
> > Vincent

Received on Friday, 4 May 2012 16:41:50 UTC