- From: Shane M Wiley <wileys@yahoo-inc.com>
- Date: Mon, 1 May 2017 18:58:14 +0000 (UTC)
- To: Rob van Eijk <rob@blaeu.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>
- Message-ID: <453014942.1755447.1493665094140@mail.yahoo.com>
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
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> 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>>
> > *To:* 'Shane M Wiley' <wileys@yahoo-inc.com
> <mailto:wileys@yahoo-inc.com>>; 'Matthias Schunter (Intel
> > Corporation)' <mts-std@schunter.org <mailto:mts-std@schunter.org>>
> > *Cc:* 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>]
> > *Sent:* 28 April 2017 18:51
> > *To:* Matthias Schunter (Intel Corporation) <mts-std@schunter.org
> <mailto:mts-std@schunter.org>>
> > *Cc:* public-tracking@w3.org <mailto:public-tracking@w3.org>
> (public-tracking@w3.org <mailto:public-tracking@w3.org>)
> > <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>>>
> > *To:* Shane Wiley <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>
> (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:public-tracking@w3.org>)>"
> > <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>>
> > 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>>>
> > To: 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>>>
> >
> > 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 18:59:00 UTC