- From: Rob van Eijk <rob@blaeu.com>
- Date: Sat, 29 Apr 2017 15:46:53 +0000
- 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>
- Message-ID: <0102015bba64b3e7-32bbe7cc-c187-471c-9d98-a93bddff5f97-000000@eu-west-1.amazonse>
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 Saturday, 29 April 2017 15:47:33 UTC