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.