Re: Fwd: Monday Call

#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>
> *To:* 'Shane M Wiley' <wileys@yahoo-inc.com>; 'Matthias Schunter (Intel
> Corporation)' <mts-std@schunter.org>
> *Cc:* 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]
> *Sent:* 28 April 2017 18:51
> *To:* Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
> *Cc:* public-tracking@w3.org (public-tracking@w3.org)
> <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>>
> *To:* Shane Wiley <wileys@yahoo-inc.com <mailto:wileys@yahoo-inc.com>>
> *Cc:* "public-tracking@w3.org (public-tracking@w3.org)
> <mailto:public-tracking@w3.org%20(public-tracking@w3.org)>"
> <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>
> Date: Thu, 27 Apr 2017 13:41:54 -0700
> From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org
> <mailto:mts-std@schunter.org>>
> To: 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>>
> 
> 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.
> 
> 
> 
>  
> 
>