Re: explicit-explicit exception pairs

On Wed, May 2, 2012 at 1:49 PM, Kevin Smith <kevsmith@adobe.com> wrote:

> I really do not understand this proposal.  This seems to incorporate all
> of the negatives of explicit-explicit exceptions without realizing the
> possible benefits.  The ad network (and so on down the chain) does not have
> direct interaction with the user.  How would they add elements to the list
> and when would that list be shown to the user?  It would be impossible to
> show it to the user at a useful time, such as early enough for the
> publisher to make an intelligent decision based on the outcome.
>


I think the point is that there is no list that the ad network presents.
E.g. site says "I include doubleclick, give doubleclick an exception."
Doubleclick gets an exception on that first party, and anyone that
doubleclick redirects to gets an exception, and so does anyone that that
person redirects to. E.g. the exception is transitive down the redirect
chain. So, DoubleClick doesn't have to add anything to the list, there is
no list that's getting shown to the user. Instead, what the user sees under
this proposal is "example.com wants an exception for DoubleClick and
anything DoubleClick serves/redirects to." Things would only change if the
site switched from using DoubleClick to a different ad network.

-Ian


>
> So, the standard still requires the complication of explicit/explicit
> exceptions.  The browsers still have to support it.  Implementing 1st
> parties still have the expense of partial exceptions, and yet users still
> do not know all 3rd parties involved.  Sounds like the worst of all worlds.
>
> Kevin Smith  |  Engineering Manager  |  Adobe  |  385.221.1288 |
> kevsmith@adobe.com
>
>
> -----Original Message-----
> From: Matthias Schunter [mailto:mts-std@schunter.org]
> Sent: Wednesday, May 02, 2012 1:35 PM
> To: Rigo Wenning
> Cc: Jonathan Mayer; ifette@google.com; Nicholas Doty;
> public-tracking@w3.org
> Subject: Re: explicit-explicit exception pairs
>
> Hi!
>
> I second Rigo's point that the following solution seems workable while
> satisfying our requirements:
> 1. A site only needs to declare the third parties that it directly uses
> (e.g., an ad network) 2. A site is not required to name any other third
> parties that are then used indirectly (e.g., recursively loaded ads) 3. The
> ad network (in this example) is then permitted to further include any
> subsequent third parties
>    (i.e.  the ad network basically obtains a "*" exception for its third
> parties)
>
> This has the following advantages (from my subjective point of view) 1.
> The user will obtain some transparency and choice 2. The list of third
> parties should be limited and known to the 1st party 3. The UI should be
> manageable and the feedback/consent somewhat meaningful 4. The ad network
> will then inherit some responsibility (at least in in the EU context)
>
> What do others think?
>
>
> Regards,
> matthias
>
> On 02/05/2012 17:34, Rigo Wenning wrote:
> > The legal solution that results in the right incentives is simple.
> > Make the site responsible for the choice of services they make. We can
> > at least write that assumption into the compliance Spec or in the
> "how-to".
> >
> > I don't believe we should go down the DRM - route and want to control
> > every subservice of a subservice, neither technically nor legally.
> > This is guaranteed to go wrong. We know that from DRM. It would also
> > overcharge the DNT Specifications IMHO.
> >
> > Rigo
> >
> > On Monday 30 April 2012 16:09:51 Jonathan Mayer wrote:
> >> 2) How does a website determine which third parties presently have an
> >> exception?
> >>
> >> I agree that this is a non-trivial problem for websites with many
> >> third parties, especially chained third parties.  I disagree that
> >> it's a particularly challenging problem, as I've explained several
> >> times in other threads.  Moreover, it's a problem that already exists
> >> for the self-regulatory opt-out programs.  At any rate, if local law
> >> allows, those websites might choose to use a site-wide exception.
> >> Allowing explicit-explicit exceptions doesn't make the problem any
> harder.
>
>