- From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
- Date: Mon, 1 May 2017 21:27:54 +0200
- To: public-tracking@w3.org
Hi Rob,
thanks for the input.
Our current approach is that users (via their UA) can choose to what
extent to honor the desire of a site for a site-wide exception (SWE).
I.e. after a SWE has been registered for a site:
- some users will send DNT;0 to all third parties
- some users will do the same but blacklist some parties (receiving
DNT;1 while the SWE is in place).
- some users will add blocking
...
All these behaviors are acceptable currently AFAIR.
By adding transparency, we now create more balance: If a user chooses to
restrict some third parties, then the publisher SHOULD be notified and
can react accordingly (replacing TPs by others; redirecting to a
paywall; ...). Note that this transparency would require another
javascript API (or some response header).
If we agree that the UA continues to have this freedom to implement any
subset of an SWE the user desires (while being transparent), then we are
indeed in agreement.
If not, we have to discuss what freedom to give the users.
Regards,
matthias
On 01.05.2017 21:10, Rob van Eijk wrote:
>
> Ok, that works for me.
>
> The point we need to discuss further is what Matthias summarized as "If
> a site-wide exception exists, to what extent can a user (via its UA)
> decide what subset of third parties to accept or not (while being
> transparent about it)."
> The summary is - in my view - about user control, not about
> transparency. Therefore, I see it as an element that is overcomplicating
> Issue 22. I believe we can safely drop this element of discussion since
> we are already in agreement of an optional OtherParties property in the
> TSR and its conditions. If not, please clarify why it remains crucial.
>
> Regards,
> Rob
>
> -----Original message-----
> *From:* Shane M Wiley
> *Sent:* Monday, May 1 2017, 8:59 pm
> *To:* Rob van Eijk; Matthias Schunter (Intel Corporation); Mike O'Neill
> *Cc:* public-tracking@w3.org
> *Subject:* Re: Fwd: Monday Call
>
> Rob,
>
> I'm fine with making that representation but believe we can do the
> same by making the field optional in most cases and only required if
> the site is requesting blocking. By making the field required we
> put those not claiming a UGE in an unfair position (as the
> requirement would then be conditional and can be managed via
> compliance specification).
>
> So optional field - if populated then the UA should block parties
> not listed; if not populated should default back to the position
> represented by the publisher otherwise (such as UGE or OOBC) and/or
> other user controls in place.
>
> - Shane
>
> Shane Wiley
> VP, Privacy
> Yahoo
>
>
> ------------------------------------------------------------------------
> *From:* Rob van Eijk <rob@blaeu.com>
> *To:* Shane M Wiley <wileys@yahoo-inc.com>; Matthias Schunter (Intel
> Corporation) <mts-std@schunter.org>; Mike O'Neill
> <michael.oneill@baycloud.com>
> *Cc:* "public-tracking@w3.org" <public-tracking@w3.org>
> *Sent:* Monday, May 1, 2017 11:51 AM
> *Subject:* RE: Fwd: Monday Call
>
>
> Shane,
>
> Thank you for the clarification.
>
> >> (...) To meet the middle ground I'd recommend that we add a
> signal from the publisher in their TSR that asks the browser to take
> a firm position (block) parties not found in their "other party"
> list (other-party-block: Y/N). We would want to further this
> position by actively stating that if the other party list is empty
> the user agent should honor the publisher's user granted site-wide
> exception (they are taking full legal responsibility for having
> obtained an informed, specific, freely given, and unambiguous consent).
>
> I would argue that an additional property in the TSR is not needed.
> What I proposed is an optional OtherParty property. Based on our
> discussions today I believe that the additional property could be
> expressed by making the OtherParty property a required field in the
> TSR. If the property is populated, it can be used for mutual
> transparency and constraining third parties. If it is empty, it
> defaults in the legal representation of a website owner declaring to
> meet the requirements of informed consent. Would you agree with
> interpretation?
>
> Rob
>
>
> -----Original message-----
> *From:* Shane M Wiley
> *Sent:* Monday, May 1 2017, 8:13 pm
> *To:* Rob van Eijk; Matthias Schunter (Intel Corporation); Mike
> O'Neill
> *Cc:* public-tracking@w3.org
> *Subject:* Re: Fwd: Monday Call
>
> Rob,
>
> I believe I answered this on the call but a user should ALWAYS be
> able to withdraw consent at any time - but of course the publisher
> needs to know this so they can appropriately react (redirect ad
> calls to consented 3rd parties, reconsent site-wide, paywall, etc.).
>
> - Shane
>
> Shane Wiley
> VP, Privacy Policy
> Yahoo
>
>
> ------------------------------------------------------------------------
> *From:* Rob van Eijk <rob@blaeu.com>
> *To:* Matthias Schunter (Intel Corporation) <mts-std@schunter.org>;
> "wileys@yahoo-inc.com" <wileys@yahoo-inc.com>; Mike O'Neill
> <michael.oneill@baycloud.com>
> *Cc:* "public-tracking@w3.org" <public-tracking@w3.org>
> *Sent:* Saturday, April 29, 2017 8:47 AM
> *Subject:* RE: Fwd: Monday Call
>
>
> Hi,
>
> I also think this is a step forward. On first glance I am
> sympathetic to the proposal, since it addresses the problem of
> unknown parties on a publishers website we discussed before. I would
> like to understand to what extent the proposal impacts the user's
> ability to withdraw consent. I think it is not impacting this at
> all, but want to be sure.
> I am looking forward to an interesting call coming Monday.
> Regards,
> Rob
>
> -----Original message-----
> *From:* Matthias Schunter (Intel Corporation)
> *Sent:* Saturday, April 29 2017, 4:16 pm
> *To:* wileys@yahoo-inc.com; Mike O'Neill
> *Cc:* public-tracking@w3.org
> *Subject:* Re: Fwd: Monday Call
>
> Hi Shane,
>
>
> thanks a lot for the feedback.
>
> I realized that before we dive into the details on how to implement your
> objectives, I would like to take a step back and understand the
> objectives of the proposed changes.
>
> Since the proposed change is non-trivial, this IMHO is a better starting
> point than talking implementation first.
>
> To me it seems as if you have these requirements:
> 1. - Ensure that site-wide (without listing sub-resources) continue to
> work and that all sub-resources continue to receive DNT;0 in a future
> scenario where some/many publishers publish a machine-readable list of
> third parties.
> 2. - Allow publishers to ensure that only listed third parties are
> loaded (to ensure - for specific consent - that only third parties are
> loaded where you are sure that they do not harm your compliance).
> 3. - Help sites debug themselves (i.e. be able to find out what subset
> of their third parties received DNT;1 despite a site-wide exception
>
> Please correct me if I am wrong.
>
> Today, a site-wide exception expresses a desire by a publisher that
> sub-domains should receive DNT;0. However, the UA (and in thextension
> the users) have a choice (by choosing their UA/Plugin Mix) to what
> extent they honor that desire.
>
> So basically the proposal you are making is:
> - The users (via their browser) no longer have a choice to what
> extent to honor a site-wide exception.
> This should render UAs that "pick and choose" (e.g.
> blacklisting/whitelisting/heuristics) what part of the
> site-wide to honor non-compliant.
> - In exchange, we now allow a publisher to list its third parties.
>
> IMHo this discussion is a great step forward and let us see whether we
> can avoid the Call for Objections (or at least will have a wider range
> of options to choose from).
>
>
> Regards,
> matthias
>
> On 28.04.2017 18:06, Shane M Wiley wrote:
> > #1 - allowing the call to only come from the origin domain should reduce
> > this risk significantly.
> >
> > #2 - please explain how this could be accomplished OOB in a scalable and
> > accurate manner? How would this approach allow the publisher to request
> > consent for missing domains in real-time?
> >
> > - Shane
> >
> > Sent from mobile phone so please excuse brevity and typos.
> >
> > On Fri, Apr 28, 2017 at 5:59 PM, Matthias Schunter (Intel Corporation)
> > <mts-std@schunter.org <mailto:mts-std@schunter.org>> wrote:
> >
> > Hi Shane,
> >
> >
> > thanks a lot for the constructive proposal. It is nice to see the
> > discussion progressing.
> >
> > Two technical remarks:
> >
> > 1. I believe that being able to query fine-grained data (e.g. what third
> > parties are allowed and what are not) could create a fingerprinting risk
> > (no two users would have the same fine-grained set enabled). What do
> > others think?
> >
> > 2. Do I remember correctly that we used to say that it is safer to debug
> > out-of-band? I think our approach was that once a third party obtains a
> > referrer (1st party) and a DNT;1 (at a significant frequency) it can
> > contact the first party to inquire what went wrong with a site-wide
> > exception.
> >
> >
> > Regards,
> >
> > matthias
> >
> >
> > On 28.04.2017 12:41, Shane M Wiley wrote:
> > > Mike,
> > >
> > > Thank you for providing this. The API appears fairly
> > straight-forward.
> > > I'm curious to see what Roy and David think about this approach.
> > >
> > > - Shane
> > >
> > > Shane Wiley
> > > VP, Privacy Policy
> > > Yahoo
> > >
> > >
> > >
> > ------------------------------------------------------------------------
> > > *From:* Mike O'Neill <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com>
> > <mailto:michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com>>>
> > > *To:* 'Shane M Wiley' <wileys@yahoo-inc.com <mailto:wileys@yahoo-inc.com>
> > <mailto:wileys@yahoo-inc.com <mailto:wileys@yahoo-inc.com>>>; 'Matthias Schunter (Intel
> > > Corporation)' <mts-std@schunter.org <mailto:mts-std@schunter.org> <mailto:mts-std@schunter.org <mailto:mts-std@schunter.org>>>
> > > *Cc:* public-tracking@w3.org <mailto:public-tracking@w3.org> <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>
> > > *Sent:* Friday, April 28, 2017 12:17 PM
> > > *Subject:* RE: Fwd: Monday Call
> > >
> > > Hi Shane,
> > >
> > > I suggested an API last year on the WICG that could meet some of your
> > > requirements for notification
> > > https://discourse.wicg.io/t/api-to-monitor-subresources/1723/23
> > >
> > > I think all it would need would be a “wasBlocked” Boolean. I have
> > added
> > > that below:
> > >
> > > partial interface Navigator {
> > > SubresourceNotification StartSubresourceNotification();
> > > }
> > >
> > > interface SubresourceNotification : EventTarget {
> > > readonly attribute sequence Subresources;
> > > }
> > >
> > > interface Subresources {
> > > readonly attribute DOMString domain;
> > > readonly attribute DomString? parentDomain;
> > > readonly attribute TrackingStatusObject? TSR;
> > > readonly attribute boolean wasBlocked;
> > > }
> > >
> > > // Subresources is an array of Subresource objects indicating all the
> > > subresources requested since the last
> > > // SubresourceNotification event or call to
> > StartSubresourceNotification.
> > > // Each Subresource object contains a string "domain" representing the
> > > domain name component of the
> > > // subresource URL, a nullable string "parentDomain" representing the
> > > domain name of the parent origin of
> > > // this subresource, a nullable object reference "TSR" resulting from
> > > parsing the JSON encoded
> > > // Tracking Status Resource
> > >
> > https://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#status-resource
> > > // of the subresource, and a boolean "wasBlocked" indicating
> > whether the
> > > subresource was blocked by the user agent for reasons other than being
> > > on a user configurable blacklist.
> > > // "TSR" is null if a subresource does not have a Tracking Status
> > > Resource, or if it is not valid JSON.
> > > // "parentDomain" is null if the subresource is a child of the top
> > level
> > > browsing context.
> > > // "wasBlocked" should only be set according to the user agents
> > generic
> > > rules for protecting users' privacy,
> > > // i.e. it cannot be used to obtain specific information about the
> > > existence of user configurable content blocking.
> > > // This API notifies all subresources initiated by this browsing
> > context,
> > > // including those embedded in child subresources.
> > >
> > >
> > > *From:*Shane M Wiley [mailto:wileys@yahoo-inc.com <mailto:wileys@yahoo-inc.com>
> > <mailto:wileys@yahoo-inc.com <mailto:wileys@yahoo-inc.com>>]
> > > *Sent:* 28 April 2017 18:51
> > > *To:* Matthias Schunter (Intel Corporation) <mts-std@schunter.org <mailto:mts-std@schunter.org>
> > <mailto:mts-std@schunter.org <mailto:mts-std@schunter.org>>>
> > > *Cc:* public-tracking@w3.org <mailto:public-tracking@w3.org> <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>
> > (public-tracking@w3.org <mailto:public-tracking@w3.org> <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>)
> > > <public-tracking@w3.org <mailto:public-tracking@w3.org> <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>>
> > > *Subject:* Re: Fwd: Monday Call
> > >
> > > Matthias and Rob,
> > >
> > > After discussing the matter more with others in industry and several
> > > browser vendors I would offer the following suggested steps to
> > come to a
> > > common meeting point:
> > >
> > > - Some publishers would actually like the browser to block if a 3rd
> > > party is not in their list (but not many) but there is concern that if
> > > the list is empty that a publisher's user granted site-wide exception
> > > will not be honored. To meet the middle ground I'd recommend that we
> > > add a signal from the publisher in their TSR that asks the browser to
> > > take a firm position (block) parties not found in their "other party"
> > > list (other-party-block: Y/N). We would want to further this position
> > > by actively stating that if the other party list is empty the user
> > agent
> > > should honor the publisher's user granted site-wide exception
> > (they are
> > > taking full legal responsibility for having obtained an informed,
> > > specific, freely given, and unambiguous consent).
> > >
> > > - Browser vendors do not want to be placed in the position of
> > obtaining
> > > consent on behalf of a publisher (high risk - no reward) but
> > publishers
> > > that are asking for blocking would like to be notified of what domains
> > > were blocked on each page to (a) track down those relationships and/or
> > > (b) add those parties to their user consent process. I hopeful we can
> > > look at a queryable resource post page load that the browser can
> > access
> > > via JS to pass this information back to their servers for further
> > handling.
> > >
> > > Hopefully you'll find these suggestions fair and agreeable such
> > that we
> > > can work on joint text towards a unified proposal. Please let me know
> > > your thoughts.
> > >
> > > I'm still hoping to drag more of the industry and several browser
> > > vendors back to the conversation but as this process is coming to a
> > > close they aren't seeing much value. :-(
> > >
> > > - Shane
> > >
> > > Shane Wiley
> > > VP, Privacy Policy
> > > Yahoo
> > >
> > >
> > ------------------------------------------------------------------------
> > > *From:*Matthias Schunter (Intel Corporation) <mts-std@schunter.org <mailto:mts-std@schunter.org>
> > <mailto:mts-std@schunter.org <mailto:mts-std@schunter.org>>
> > > <mailto:mts-std@schunter.org <mailto:mts-std@schunter.org> <mailto:mts-std@schunter.org <mailto:mts-std@schunter.org>>>>
> > > *To:* Shane Wiley <wileys@yahoo-inc.com <mailto:wileys@yahoo-inc.com>
> > <mailto:wileys@yahoo-inc.com <mailto:wileys@yahoo-inc.com>> <mailto:wileys@yahoo-inc.com <mailto:wileys@yahoo-inc.com>
> > <mailto:wileys@yahoo-inc.com <mailto:wileys@yahoo-inc.com>>>>
> > > *Cc:* "public-tracking@w3.org <mailto:public-tracking@w3.org> <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>
> > (public-tracking@w3.org <mailto:public-tracking@w3.org> <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>)
> > > <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>
> > <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>%20(public-tracking@w3.org <mailto:20(public-tracking@w3.org>
> > <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>)>"
> > > <public-tracking@w3.org <mailto:public-tracking@w3.org> <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>
> > <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org> <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>>>
> > > *Sent:* Thursday, April 27, 2017 2:39 PM
> > > *Subject:* Fwd: Monday Call
> > >
> > > Hi Shane / Rob,
> > >
> > >
> > > thanks a lot for documenting your concerns on the mailing list.
> > >
> > > Rob just sent out his text proposal. I understand that Yahoo's current
> > > preference is "no such field should be included". As a consequence, we
> > > plan to issue a CfO.
> > >
> > > If either of you propose text that has the potential for everyone to
> > > "live with it", I could could invest some more time to discuss the
> > > proposal. Otherwise, I will issue a CfO before our call on Monday.
> > >
> > > The question for the CfO will be:
> > > "To what extent and in what form should TPE allow a site to
> > > publish the third party resources that may be used in a
> > > machine readable form?"
> > >
> > > The first phase will be to ask for alternative text proposals, the
> > > second phase is a short discussion to explore compromises, the final
> > > phase is collecting objections (see our web-page for the details).
> > >
> > >
> > > Regards,
> > > matthias
> > >
> > >
> > >
> > > -------- Forwarded Message --------
> > > Subject: Monday Call
> > > Resent-Date: Thu, 27 Apr 2017 20:42:30 +0000
> > > Resent-From: public-tracking@w3.org <mailto:public-tracking@w3.org>
> > <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>> <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>
> > <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>>
> > > Date: Thu, 27 Apr 2017 13:41:54 -0700
> > > From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org <mailto:mts-std@schunter.org>
> > <mailto:mts-std@schunter.org <mailto:mts-std@schunter.org>>
> > > <mailto:mts-std@schunter.org <mailto:mts-std@schunter.org> <mailto:mts-std@schunter.org <mailto:mts-std@schunter.org>>>>
> > > To: public-tracking@w3.org <mailto:public-tracking@w3.org> <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>
> > <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org> <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>>
> > > (public-tracking@w3.org <mailto:public-tracking@w3.org> <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>
> > <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org> <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>>)
> >
> > > <public-tracking@w3.org <mailto:public-tracking@w3.org> <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>
> > <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org> <mailto:public-tracking@w3.org <mailto:public-tracking@w3.org>>>>
> > >
> > > Hi Folks,
> > >
> > >
> > > I have not received any objections to having a call on monday. I
> > suggest
> > > to have our next call on May 01 at 9am Pacific (normal slot).
> > >
> > > Main Goal is to ensure that we have text for all issues for this
> > release.
> > >
> > > I cleaned the list of issues that we plan to include in this release:
> > >
> > https://github.com/w3c/dnt/issues?q=is%3Aopen+is%3Aissue+milestone%3ATPE-CR-April-2017
> > > (this are the issues that we started and that in a recent
> > discussion we
> > > declared high priority).
> > >
> > > Based on the discussion on the mailing list, I do not see any need to
> > > discuss whether we need the other-parties fileld in the TSR:
> > > - Some folks believe that it is an essential requirement for EU
> > > "specific consent"
> > > - Others believe that it must not be included and basically veto its
> > > inclusion.
> > >
> > > I suggest that we go to a Call for Objections to structure this
> > discussion.
> > > If (and only if) I see convergence onto an "i can live with this"
> > > consensus,
> > > then we may spend some time discussing. Otherwise, it is CfO time...
> > >
> > >
> > > Regards,
> > > matthias
> > >
> > >
> > > ---------
> > > Agenda
> > > ---------
> > >
> > > 1. Issue 13: https://github.com/w3c/dnt/issues/13
> > >
> > > 2. Issue 09: https://github.com/w3c/dnt/issues/9
> > >
> > > 3. Planning: What else is needed to get sufficient text as input.
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
>
>
Received on Monday, 1 May 2017 19:28:35 UTC