- From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
- Date: Tue, 2 May 2017 09:46:33 +0200
- To: public-tracking@w3.org
Hi Mike,
thanks for your input. I have not understood the "generic blocking
reasons" you indicate.
What I understand is: If a site declares OtherParties, then only the
ones blocked within this set should be reported, right?
I.e. it is not meant for debugging the set OtherParties. Is assumes that
the publisher knows what he is doing and that the user may veto a subset.
So you introduce two cases:
- No otherParties defined: Then all constrained TPs should be reported
(since one assumes that all TPs are there on purpose)
- otherParties defined: Then only a subset of those parties is reported.
Did I understand correctly?
I agree that this approach is better than what I had in mind (it
requries that publishers can find other means to debug their sites such
as a special UA that lists the third parties).
However, it would be more privacy friendly if publishers can live with
the UA only reporting back "all your TPs were loaded with DNT;0" or "not
all TPs were loaded with DNT;0" that I introduced in my last mail.
Regards,
matthias
On 02.05.2017 09:29, Mike O'Neill wrote:
> Hi Matthias,
>
> This is why I said that only those blocked for generic reasons would be reported, i.e. all parties not receiving DNT:0 who were also not on the otherParties array. Those that were blocked because they were on a user configurable block list would not be reported.
>
> Even if we decided to have specific reporting, IMO there is only a slight risk of fingerprinting using this method, because it is quite difficult and not very user specific. In reality there are far easier ways to do that now e.g. with simple third-party initiated unique device id via MediaCapture, WebRTC's ability to report back real local IP addresses which can be unique, the soon to be available instantaneous fingerprinting via Client Hints etc.
>
> If anyone used DNT otherParties to fingerprint this way they will quickly be detected, and end up on blacklists themselves.
>
> As you can see above I prefer to call it otherParties, camel casing it and making it a plural. The "same-party" property is annoying because it contains a hyphen which is a minus in JavaScript. Also, it makes more sense if it is plural.
>
> Keeping the hyphen means you save always to write var x = TSR["other-parties"], and it would be neater to type var x=TSR.otherParties. If we are introducing a new property we should avoid the hyphen.
>
> Mike
>
>
>
>
> -----Original Message-----
> From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org]
> Sent: 01 May 2017 20:33
> To: public-tracking@w3.org
> Subject: Transparency vs. Fingerprinting (was: Re: Fwd: Monday Call)
>
> Hi Folks,
>
>
> I still believe that our goal of "transparency" conflicts with privacy.
> Let me elaborate.
>
> Assume:
> - The other-parties lists all parties (usually a long list) called LIST1
> - The UA picks a subset (e.g. blacklisting some) called LIST2 to block
> - The UA informes the site of what subset did not receive DNT;9
> LIST3=LIST1-LIST2
> - This list is returned to the site (e.g. via Javascript)
>
> If List1 is large, and different users will pick different services to
> block, then LIST3 will highly depend on the user. E.g. if a user can
> interact with a plugin to determine the outcome this would be the case.
>
> I.e. LIST3 would be perfect for fingerprinting users.
>
> One fix would be to reduce the fine-grainedness of LIST3.
> E.g. returning 0 for "all is fine" and 1 for "some did not make it".
> Or a number: 20 of your 22 third parties obtained DNT;0.
>
> Any ideas anyone?
>
>
> 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 Tuesday, 2 May 2017 07:47:15 UTC