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 Saturday, 29 April 2017 14:15:49 UTC