Re: explicit-explicit exception pairs

Ian, 

I think I wasn't clear enough on what I want the Specification to say and 
the browser to do. The question we are trying to answer is whether the 
ECMAscript API allows to say: 

A/ I work with third parties and they may track you, OK? 
-> Yes -> browser please send signal DNT;0 to all subsequent requests in 
this context

or 

B/ I work with party P1, P2 and P3 who want to track you, OK? 
-> Yes for P1, I have a web wide exception for P2 and I don't like P3
-> browser, please send signal DNT;0 to P1 and P2 and DNT;1 to P3 in this 
context. 

The ECMAscript API allows the first party site to include scripts to 
interface the user and obtain a DNT;0 if successful. This is the entire and 
only goal of this interface. 

Agreement on this interface would already help. Once we have agreement on 
the interface, there are a bunch of consequential issues to resolve: 

1/ How long is this agreement valid? (Rigo's suggestion: until I get a newer 
expression of preference, e.g. receiving a DNT;1)

2/ Must the browser offer standard text triggered by this interface? (Rigo: 
No, this can be determined by the site via the javascript API)

3/ Must the site list all the parties that may receive personal information 
(Rigo, no, because the initial data collectors take responsibility and 
reputation to deal responsibly with data, furthermore, listing of all 
possible receivers would be a DRM on personal data and we know that this 
doesn't work at all, even for the people with the big bucks, let alone 
personal data)

4/ Bundling: 
In case A above, everything is bundled. You can either accept the entire 
bundle or leave it. No flexibility, neither for the site, nor for the user.

If a third party has changed in case A, there are two possible opinions: 
aa/ The bundle has to be renewed 

bb/ The bundle already covers any arbitrary change that may happen in the 
future. (Ian, I would like you to sign such a contract where I'm the other 
party ;)

In case B, if the new party is not yet known to the system (web-wide), the 
site is free to ask for a new permission for party P4 or deliver only with 
P1-P3. 

The advantage for me lies in the fact that we do not have to touch the 
relation of the user to P1-P3. This is a pretty big advantage unless we 
defend cas 4/bb where a given agreement extends to all arbitrary third 
parties for now and the future. (which also raises the question what 
"future" means). 

So your provocation with the nice text below ran against open doors. A 
system where this group decides on the natural language a site has to write 
can't be right because of the implied paternalism. And a system that 
deflects the main questions to a human readable statement is just not a 
system that will help in any way compared to the current situation where we 
already have privacy policies with (22) pages of legalese that run on the 
edge of the legally possible, crossed fingers behind your back. 

Is it so hard to allow sites to tell what services they use and to ask for 
permission in that granularity? I saw your idea on the simple protocol, but 
note that we are on the API here that can be used; or not.

Rigo

On Monday 07 May 2012 09:33:00 Ian Fette wrote:
> Rigo,
> 
> If we operate under the premise that an enumeration of "top-level third
> parties" is required for consent to be meaningful in the E.U. but not
> globally, then I would argue that the preferred way to satisfy this is by
> doing something where we shift the balance of where the "compliance text"
> lives from the browser to the website. That is, somewhere, a user is going
> to be offered text explaining why they are being asked for an exception,
> what the exception covers, and what this means. I would argue that in the
> context of the browser, we're working across too many jurisdictions to
> actually say anything too meaningful about what the exception means. (We
> also tend to shun long text in our UI).
> 
> What I would therefore propose is that for a site in the E.U. wishing to
> be compliant with whatever regulations end up being relevant, is that it
> could satisfy those regulations via text on the page that hosts the
> "grant an exception button". That is, the site could say,
> 
> "Dear user,
> 
> In an effort to provide you with high quality content, we have determined
> that we need to serve users targeted ads. These ads provide a higher
> amount of revenue that is otherwise possible, and this revenue directly
> pays for the content you are about to enjoy. We use the following third
> party service providers on our website:
> - A Inc.
> - B GmbH.
> - C S.A.
> 
> If you grant an exception to our website, the third parties on our website
> will be able to track your visits on our website for the purpose of
> serving you more targeted content, including more relevant ads that we
> hope will create a more meaningful interaction with our website.
> 
> Our DNT policy, located at <X> (and presumably referenced via some well
> known location and/or response header) also lists out the third parties
> that may be in use at any given time.
> 
> Click <here> to grant an exception to third parties on example.com from
> your Do Not Track preference."
> 
> 
> This still leaves open the possibility of third parties changing over
> time, but I will posit that it's a bit unclear if it's actually required
> to re-confirm consent at this time if the user has already been told that
> their data will be used by third parties for the following purposes and
> there's a clear way for them to discover what those third parties are at
> any given time. (If you really cared, the browser could compile a list of
> first-level third parties as well, after the page is loaded.)
> 
> -Ian
> 
> On Mon, May 7, 2012 at 1:17 AM, Rigo Wenning <rigo@w3.org> wrote:
> > Ian,
> > 
> > thanks for that quote. This is helpful. And I think it is in line with
> > my
> > thinking that we have to only enumerate the third parties the first
> > party
> > knows of.
> > 
> > In Detail: In the case you're taking up, the user gave his consent to a
> > particular directory service. Now this particular directory service was
> > transferring data to another directory service (e.g. because of a
> > merger)
> > The court says: You've given your data to A for purpose directory
> > service
> > and only because of a merger and no other change, there is no need to
> > ask
> > every single person in the phone-directory again. This is reasonable.
> > But
> > it
> > does not compare to the situation we have, where we start already with
> > an
> > undefined amount and identity of the data collectors (data controllers).
> > 
> > If you add your right to access and rectify the data about you, it is
> > clear that knowledge about the data controllers is needed. It may be
> > possible to have a publication of your data to unbound unknown third
> > parties, but this would equal to a generic web-wide exception for
> > everybody. And in this case,
> > your browser would just spawn DNT;0 on all requests.
> > 
> > While I see the burden you're invoking, I have trouble to get around
> > naming the third parties used by (and known to) the first party. Now
> > how can we minimize the burden technically?
> > 
> > Rigo
> > 
> > On Saturday 05 May 2012 16:21:21 Ian Fette wrote:
> > > I'm curious what you mean by "implied" consent? If the user grants an
> > > exception in response to a dialog presented by the browser on behalf
> > > of
> > > the website, that's rather explicit, is it not? I fail to see how that
> > > is
> > > "implied".
> > > 
> > > I'm not a lawyer and I don't pretend to be one, I'm just trying to
> > > figure
> > > out if there's some distinction here that you're drawing that i'm
> > 
> > missing.
> > 
> > > I looked through the opinion you linked to, and in particular, I'm
> > > having
> > > trouble reconciling your statement with the following:
> > > 
> > > "Recently the ECJ issued a preliminary ruling
> > > 22
> > > 
> > >  regarding Article 12(2) of the ePrivacy
> > > 
> > > Directive, concerning the need for renewed consent of subscribers who
> > > had
> > > already
> > > consented to have their personal data published in one directory, to
> > > have
> > > their personal
> > > data transferred to be published by other directory services.  The
> > > Court
> > > held that where
> > > the subscriber has been correctly informed of the possibility that his
> > > personal data may
> > > be passed to a third-party undertaking and s/he has already consented
> > > to
> > > the publication
> > > of those data in such a directory, renewed consent is not needed from
> > > the
> > > subscriber for
> > > the transfer of those same data, if it is guaranteed that the data in
> > > question will not be
> > > used for purposes other than those for which the data were collected
> > > with
> > > a view to their
> > > first publication (paragraph 65). "
> > > 
> > > Wouldn't this imply that if you inform the user that their data may be
> > > passed on to third party advertisers for the following (X,Y,Z)
> > > purposes,
> > > the addition of another advertiser down the line would not be
> > > material?
> > > 
> > > Also, I don't think you should take the prompt presented by the
> > > browser
> > 
> > as
> > 
> > > the full context of the request for consent. The prompt by the browser
> > > is
> > > generated by the user clicking something on the page, the text
> > > surrounding that something on the page is part of the context under
> > > which
> > > the consent is given, and can do things like explain what third
> > > parties
> > > the site uses and what purposes the site wishes to use your data for.
> > > 
> > > On Sat, May 5, 2012 at 8:40 AM, Rob van Eijk <rob@blaeu.com> wrote:
> > > > This thread starts to overlap with 'ACTION-172: Write up more
> > > > detailed
> > > > list of use cases for origin/origin exceptions'
> > > > 
> > > > My assumption in this answer is that the browser reflects valid user
> > > > consent. As a prerequisite, this implies that the user has made an
> > > > informed choice, preferably in the install/update flow of the
> > > > browser
> > > > to use DNT technology as a granular consent expression mechanism.
> > > > 
> > > > Taking this assumption into account, my answer is easy, and I can be
> > > > crystal clear on this:
> > > > 1) Implied consent for * for an unknown list of parties is
> > > > unacceptable
> > > > for it does not lead to compliance.
> > > > 2) Implied consent can only be valid for a select list of third
> > > > parties
> > > > operating in a first party context: the processors who have a legal
> > > > processor-agreement with the first party (controller).
> > > > 
> > > > In Brussels I gave a detailed presentation on the criteria for
> > > > consent
> > > > to
> > > > be valid. They are well published in the Art. 29 Working Parties
> > > > opinion.
> > > > 
> > > > Preso: http://lists.w3.org/Archives/**Public/public-tracking/**
> > > > 2012Jan/att-0268/W3C_v2.pdf<
> > 
> > http://lists.w3.org/Archives/Public/public-t
> > 
> > > > racking/2012Jan/att-0268/W3C_v2.pdf> Opinion 15/2011 on Consent:
> > > > http://ec.europa.eu/justice/**
> > > > data-protection/article-29/**documentation/opinion-**
> > > > recommendation/files/2011/**wp187_en.pdf<
> > 
> > http://ec.europa.eu/justice/dat
> > 
> > a-protection/article-29/documentation/opinion-recommendation/files/2011/
> > 
> > > > wp187_en.pdf>
> > > > 
> > > > Rob
> > > > 
> > > > On 4-5-2012 22:31, Rigo Wenning wrote:
> > > >> Ian,
> > > >> 
> > > >> this is very clear and I think we are at the core of the issue. I
> > > >> have
> > > >> to
> > > >> leave it to Rob (and it may take some time) to answer the question
> > > >> whether informed consent can be given to an unknown list of third
> > > >> parties tracking me. From my german and french law roots, I have a
> > > >> feeling it doesn't work, but maybe I'm wrong.

Received on Monday, 7 May 2012 19:56:11 UTC