– DRAFT –
Tracking Protection Working Group Teleconference
13 March 2017
<schunter> The first technical issue I want to discuss is our old friend issue 12: https://github.com/w3c/dnt/issues/12
schunter: Weekly call now!
… Tomorrow is last date for issues.
… I created a milestone in github.
… Everyhting that comes later doesn't get labeled with the milestone.
<fielding> works for me
schunter: Deutsche Telecom is active on DNT implem and may send somebody to the WG.
mikeoneill: the APIs may turn into a n Open Source library.
… I'll tell more about it when I'm done.
… All the plumbing.
schunter: That may speed up adoption.
<fielding> The issue milestone that Matthias referred to is https://github.com/w3c/dnt/issues?q=is%3Aopen+is%3Aissue+milestone%3ATPE-CR-April-2017
schunter: Exit Criteria between CR and REC
<fielding> I have moved the TPE editors draft to https://w3c.github.io/dnt/drafts/tracking-dnt.html
Implementation Experience (Process Doc)
Bert: based on process document
… describes how to set up exit criteria
… useful to go over the points in the document
1st point: features implemnted?
... definition of a feature, normative requirements
... report that tests have been executed
... multiple implementstions required, TWO, independent ones.
e.g. opera and chrome would be the same and count as one
... matter of interpretation of what is independent.
schunter: on the clinet side and on the server side 2 implementations?
mattias, does each feature need 2 implementations?
Bert: no. usually if every features is implemented somewhere is enough.
Matthias: if badger implements some, IE also some, enough?
Bert: correct, but watch out for dependencies.
… 3rd point: implementations from outside the working group is preferred.
… implementations need to be available to everyone, not just within the working group
… servers and clients: we need 1 sample of each type. Servers and clients doing parts of the spec.
… so if you describe multiple types in the spec, for each type you need some implementation to demonstrate on each side
… Director decides whether next level of document starts.
… members need to be convinced as well.
… if opposing views, the director decides, ( /me not a democracy by votes)
… solid test suite needed.
… Above is the general process towards recommended standard.
… not touched on native implementations, plugins. Native is most convincing. Other types of implementations do count however. Especially if people are using plugins. Example of SVG.
… But plugins may not be the most convincing type of convincing argument.
schunter: not a black and white decision tree.
… it is at the end discussions/arm twisting with the director.
… exit criteria := potential discussion inputs
bert: most working groups create their own exit criteria, we consider our work done as a,b,c.
… CSs group does this. To be clear about what the outcome of the group is. Test reports etc. done mechanically.
… is for the working group itself.
… helpful would be to prepare for answers, devils advocate strategy.
Mike: web page with javascripts that execute parts of the API. Could we hook these into our project?
schunter: Good idea to keep track of this.
Bert: not sure if wiki accepts javascript. Pointers may be needed.
Mike: javascript could go on any page. Purpose is to chekc whether the API is working.
… would be nice to move it to W3C resource.
SimonK: I'm from cable labs.
… I'll look at github, and try to be on the call if needed.
schunter: Idea is to get rid of cookie banners.
simonk: Is there a high-level summary somewhere?
schunter: The main doc is TPE
… We don't have formal reference code.
<rvaneijk> https://github.com/w3c/dnt/blob/master/drafts/tracking-dnt.html
Brendan: I work for a spin-off of IAB
… I was in the WG a while ago.
… Tech Lab works as technology component for IAB worldwide.
… I think I will be able to bring clarifying questions from IAB members.
… And make sure there is an informed populace.
schunter: Would be interesting to us if your members can bring questions & feedback.
… spec is 95% done. Don't expect many changes.
… We used to work on Tracking Compliance, but that work is paused.
<fielding> https://github.com/w3c/dnt/issues/12
<fielding> already approved
fielding: I'm supposed to add something to the draft.
mikeoneill: I'll send a patch
<fielding> https://github.com/w3c/dnt/issues/2
schunter: But no Walter today...
… Push to next week?
<fielding> https://github.com/w3c/dnt/issues/19
mikeoneill: I read the exception stuff again.
… I think you can call an exception in an iframe.
… And then dynamically create iframes.
… But user could be unaware of the subresource.
schunter: Can yu explain the issue?
mikeoneill: Take yahoo, e.g., they have sub domains.
… When asking consent, they might also wnt to ask consent for other domains.
… If you can execute the JS API in an iframe, that coul dbe an iframe from a subdomain.
… They then commuinicate with one another in some way and collect consent.
schunter: So you say we don't need to chnage the spec?
… Add an implementation guidance?
mikeoneill: I'm suggesting some normative text as well.
… If a contrlller can ask consent for multiple domains, how does that work in the browser UI?
… How to revoke multiple consents from the same controller?
schunter: Other example Alphabet, which has google, youtube, etc.
… The cannot ask a consent for Alphabet as a whole, because all have different domains.
… Browser will have consents for each domain, while user may have consented to Alphabet and gets confused when the browser shows those other names.
… Advise to browser is to keep the original context info for the user.
mikeoneill: If it is an iframe, the iframe must have a @@
… And then next question: what about a Web Worker instead of an iframe?
schunter: So good idea to keep tsr
fielding: Shouldn't worry too much about implem details.
… If we say anything, we should say that the sites for which exceptions are added must have a tsr.
schunter: Is it required to have a tsr when you register an exeption?
fielding: Not a requirement. Requeuirement is to implement the protocol.
<walter> Bert: argh, caught up in DST
<vincent_> Isn't that issue 21?
schunter: If there is no tsr, user doesn't know what he is saying yes to.
<vincent_> I agree
<fielding> I mentioned that instead of worrying about how the exception is made, make it a general requirement that the site's with a granted exception must implement the protocol (including having a TSR).
rvaneijk: The information requirement goes before.
… I agree with the proposal for issue 19
mikeoneill: I could kill issue 19 and make an issue instead about requirement for tsr
schunter: is that issue 21?
mikeoneill: Yeah, could tie them together.
schunter: Issue 19 is resolved: keep data from the tsr, but we don't say exactly how.
mikeoneill: OK, I'll edit the issue
schunter: Issue 21 is that you may only call the API if you have published a TSR.
… We need text for that.
… Any volunteer?
mikeoneill: I have some text to start with.
schunter: But I wouldn't make requirements on the tsr itelf, other that it must exist.
… No mandatory fields.
<walter> schunter: we can discuss issue #2 this week
schunter: Just a "valid tsr"
mikeoneill: Does that include that it must have a controller property?
schunter: I don't remember.
mikeoneill: It's currently not requried.
schunter: Then you should make an issue about what are the required fields for a valid tsr.
mikeoneill: Pb with dnt property is that it is a single string.
<fielding> note that controller is optional because it has a default of the site's domain
mikeoneill: Exception does not change the property.
… That's why we considered making it a Promise.
… But that is a radical change.
… So maybe create a dnt event.
<fielding> https://github.com/w3c/dnt/issues/13
mikeoneill: Javascript will read the dnt property.
… It will be the value when the context was initiated.
… So would be nice to have an event dntChangeEvent
… To make it more usable for developers.
… Thoughts?
Vincent: When is this sent?
mikeoneill: Each browsing context for subresouces could fire an event.
fielding: I'm not sure tehere is use case where the user doesn't want to go to a new page.
mikeoneill: May be a Service worker instead of a page.
<rvaneijk> I created Issue 23 on the issue of what are the required fields for a valid tsr.
fielding: The server tells the JS to register an exception, so why doesn;t it tell the JS to chnage the browsing context as well?
… The value is for the window that was loaded. It is not for the individual iframes inside.
mikeoneill: It would eb useful in my API tester.
… The thing that fired it... It only returns whether there is an exception, not what is in it.
… At the moment you will have to poll it.
schunter: Seems a bit of a corner case.
… Maybe we can fix it later.
mikeoneill: It is sugar coating, makes things nicer.
schunter: If it is only "nice to have", then I'd say it's the next version.
… Objections to not fixing this now?
fielding: I think if we did it, it would be under a different name.
schunter: Could be an attribute
mikeoneill: Would be nice to make the existing dnt an event as well as a string.
fielding: I don't have an opinion on closing or keeping the issue.
schunter: OK, We'll keep it open.
<aleecia_> have a great week!
walter: can we do issue 2?
schunter: Out of time.
Unknown options in environment variable SCRIBEOPTIONS:
Succeeded: i/Bert: based on process document/Scribenick: rvaneijk