W3C home > Mailing lists > Public > public-tracking@w3.org > April 2012

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

From: イアンフェッティ <ifette@google.com>
Date: Mon, 30 Apr 2012 10:52:49 -0700
Message-ID: <CAF4kx8fdQEqvA9LuXK426Qd1LMg7n9F=NuzWt20UZt+qSz843g@mail.gmail.com>
To: Kevin Smith <kevsmith@adobe.com>
Cc: "mts-std@schunter.org" <mts-std@schunter.org>, "public-tracking@w3.org" <public-tracking@w3.org>
In general I'm not sure of the utility of saying "what the next thing could
be". What is this going to be used for? Are you going to pull this first,
check what it COULD be, then resolve it and see what it happened to be?
That would be a huge latency hit and not acceptable. If you aren't doing
pre-processing, then you already know what it WAS (as opposed to what it
COULD be), so then this seems to have no utility.

-Ian

On Fri, Apr 27, 2012 at 3:49 PM, Kevin Smith <kevsmith@adobe.com> wrote:

> A user granting an exception would not be worse off than without DNT, but
> rather would be exactly the same as if there was no DNT, but only when
> visiting that particular site.  So in general, they would still be better
> off.  This is what the exception means.  It means, on this site, I do not
> have DNT set.  I do not think it carries any further implications.  In
> fact, the 3rd party will not even know about the exception - it will just
> receive DNT:0 (or no DNT signal or however we do this) exactly as it would
> if DNT were turned off - it will not receive some flag indicating any
> higher level of trust.
>
> I do however think your other points are interesting.  Having each level
> of the ad chain have a URL stating what the next levels could be would
> provide a level of discoverability.  However, I still would not think that
> it would make sense to allow a customer to try to pick and choose which of
> those they are going to approve or disapprove (but it may make it possible
> to see if a particular offending site is in the list).
>
> I personally like the other option of placing the trust level with the 1st
> party and expecting the 1st party to be careful about who they decide to
> trust.
>
> Kevin Smith  |  Engineering Manager  |  Adobe  |  385.221.1288 |
> kevsmith@adobe.com
>
> -----Original Message-----
> From: mts-std@schunter.org [mailto:mts-std@schunter.org]
> Sent: Friday, April 27, 2012 4:32 AM
> To: public-tracking@w3.org
> Subject: RE: An alternative to site-specific user granted exceptions
> (Issue-111)
>
> Hi Folks,
>
>
> I still believe that the question "What third parties will be used?" or
> alternatively "what responsibilities do all these parties have?" are valid
> concerns once a user wants to decide whether to agree to a site-wide
> user-granted exception.
>
> Wouldn't the idea to post third parties at the well-known URI resolve the
> chain issue since it enables recursion?
>
> 1. A site posts its (direct) third parties at its well-known uri 2. The
> referred 1st level third parties again post their direct (now 2nd
> level) third parties at their respective well-known URIs.
>
> If this is the case, then it would provide a way to identify the (many)
> potential third parties that might be used.
>
> I believe that if we cannot identify the set of third parties, then an
> alternative would be to talk about what "please trust me to choose the
> right third parties"  means wrt responsibilities.
>
> Without either of these discussions, granting a site-wide exception would
> mean that the user would be worse-off that without DNT since
>  a) Neither site nor third parties will be constrained by DNT
>  b) The user has now indicated that he is OK with this behavior
>
> What do you think? Please currect me if I misinterpreted the current
> status.
>
> Regards,
>  matthias
>
> > 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 Monday, 30 April 2012 17:53:18 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:27 UTC