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

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
>
>
>