<fielding> https://github.com/w3c/dnt/issues/13

<rvaneijk> https://w3c.github.io/dnt/DNTChangeEvent.html

<fielding> I think Mike is saying that the browser would implement the doNotTrack event but might not have implemented the exceptions API.

<rvaneijk> fielding, correct, and since not every browser has implemented the exception API, a polyfill approach would simulate the DNT properties/events.

<rvaneijk> I disagree DNT is a different case, since the exception API is not shipped by most browsers

<dsinger> why aren’t they looking at it when they care?

<schunter_> 1. read the value

<dsinger> I still don’t get why you’re not reading it when you need to know the value. When you have a branch in your code that depends on the value, read it then.

<fielding> it is impossible for an event to fire faster than a read. The only distinction here is that *inside* the event handler the value is static, which is not relevant to a site implemenation. It is relevant to a browser extension trying to manage a separate UI.

<aleecia> I do not mean this as critique, but listening to people talk over each other is not the best use of my time just now. Sorry to be so constrained. Good luck — I’ll catch the next meeting.

<dsinger> just making sure (a) we don’t introduce unneeded complexity and diverge from implementations and (b) we don’t have a fundamental misconception (on either side)

in 4minutes, I would like to move on.

It seems there is no consensus evolving and I suggest waiting for more implementations.

If all implementers request the event, we can reconsider.

<wileys> Agreed - this appears to be a corner case where those currently implementing aren’t requesting this level of “event-based support”

<Zakim> dsinger, you wanted to talk about blocking

<mikeoneill> +q

+q

the right language is "if a publisher has a site-wide API and a TP does not receive DNT;0, then the publisher can discover this fact via a new API".

<wileys> +q

<wileys> Stronger disagree - in queue to explain how RTB will likely work under GDPR

<wileys> Check the email chain - Rob introduced the concept of “Blocking”

<rvaneijk> I am just calling for transparency, as an optional field, because some companies have indicated wanting to use such a property and it would help them to become compliant with EU law.

<wileys> Rob - a 3rd party list not need to be machine readable to be legally compliant

<rvaneijk> wileys, agreed

Proposed consensus:

1. otherParties can contain a complete list of third parties

2a: if otherParties exists, a new API allows the publisher to list all TPs that are not on this list.

2b If otherParties does not exist and a site-wide exception exists, then the API can be used to list all TPs that did not receive DNT;0

<mikeoneill> +q

<dsinger> The site wanting to know, and the user to know, what it is asking for can either (a) know what sites are (recursively) pulled in to their site by inclusion, and then ask for a general site-specific exception (using the wildcard for all targets in the API) or (b) be clear as to what thirs parties it needs the exception for, and list those domains explicitly in the request API. We already have the modulation ‘to the parties I care about’ in the API, we don’t

<dsinger> need it replicated in the WKR, do we?

<Zakim> dsinger, you wanted to talk about sitewide * exceptions and the EU

Simplified implementation: The otherParties are in the TSR. If you then call a site-wide exception, this is auto-constrained to this list. Would this make sense?

<wileys> Wrong - same party array is meant to determine who receives DNT:0

<wileys> Sama party array scopes the “Site” in the Site-wide Exception

<wileys> Same

<rvaneijk> otherParties should receive DNT:0 as well IMHO

<fielding> And the more useless text we require to be sent

<rvaneijk> fielding, transparency is not useless..

<wileys> +q

David (paraphrased by matthias): Studpid idea?

<fielding> rvaneijk, the user has already decided to access the site and the site contains subresources that specifically identify other sites, so this information is completely useless. I have explained that too many times already.

Shane: site-wide exception, he wants an API that lists all third parties that did not get DNT;0

Rob: Machine readable TSR optional field otherParties for pre-flight checks

<wileys> But we should all be honest that a machine readable list such as OtherParty is just another form of a Tracking Protection List

<wileys> Why build it if we don’t expect it to be used?

Because we want to see how the market evolves and what the best solution to GDPR compliance will be.

I.e. I cannot tell whether it will be used or not.

Changes to the spec needed:

(a) add a field otherParties to list known third parties

<dsinger> (Summarizing my point on Matthias’s idea) I don’t see any reaon to move a parameter of the API to the WKR; that just means the UA has to do a fetch when the API is called; we’re better with the API being self-contained

<fwagner> Shane, the list is independent from the purpose

<fielding> Yes, and the next extension can be called the extorter, because that is how it will be used.

(b) specify an API that allows publisher to retrieve the third parties that did not receive DNT;0

<wileys> Doesn’t need to be machine readilble if our only goal is user transparency.

<rvaneijk> correct, a MAY

<fwagner> But it can be handled easily, if it is machine readable

<rvaneijk> schunter, yes, makes sense

<rvaneijk> I think we are in consensus, right?

<fielding> trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/net extension/next extension/
Default Present: dsinger, fielding, hober, mikeoneill, wileys, rvaneijk, aleecia, fwagner, schunter
Present: dsinger fielding hober mikeoneill wileys rvaneijk aleecia fwagner schunter
No ScribeNick specified.  Guessing ScribeNick: schunter
Inferring Scribes: schunter

WARNING: No "Topic:" lines found.

Found Date: 08 May 2017
Guessing minutes URL: http://www.w3.org/2017/05/08-dnt-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report