– DRAFT –
Tracking Protection Working Group Teleconference

<moneill2> the webex link says the meeting is cancelled

https://‌mit.webex.com/‌mit/‌j.php?MTID=m97f5fec14b837f72dfa

6049836dbffe2

https://‌mit.webex.com/‌mit/‌j.php?MTID=m97f5fec14b837f72dfa6049836dbffe2

Bert has changed the topic to: https://‌mit.webex.com/‌mit/‌j.php?MTID=m97f5fec14b837f72dfa6049836dbffe2

<wileys> Unable to connect just yet - need to recover account - one second (we switched to @oath domain last week so its causing havoc with these types of accounts)

<schunter_> I tried the info at the link that Bert posted.

<schunter_> Webex says "meeting cancelled or ended".

<moneill2> this one works: https://‌mit.webex.com/‌mit/‌j.php?MTID=m97f5fec14b837f72dfa6049836dbffe2

<schunter_> Just managed to join by manually entering meeting ID and password.

<schunter_> thanks!

Shane's issue about multiple site exceptions in one API call

<moneill2> same-party you mean?

<dsinger> I don’t recall ever linking the exception API to the well-known resource

<dsinger> but that has the caller making the assertion of same-party in a way that can’t be audited/tracked/etc.

<fielding> is someone going to scribe?

<schunter_> Bert? could you?

<schunter_> Thx!

<dsinger> I think that Mike is right, you have to open browsing contexts for those sites, and they can then register the exceptions

<fielding> We are talking about https://‌w3c.github.io/‌dnt/‌drafts/‌tracking-dnt.html#exception-javascript-api-store

(Discussion about whether this was in an earlier version. It appears it was not. Discussion about whether a site is allowed to set exception for other domain at all.)

Shane: [...] get consent as user visits each domain, iframes.

schunter_: We don't want to break same-origin policy.
… I'd like to close this discussion.

<wileys> Next issue: Notification of exception registrations from 3rd parties to 1st parties

schunter_: I think we decided earlier we wouldn't allow such mutliple registrations.

<fielding> do we have this on the issues list?

schunter_: Shane, OK?

Shane: For now, yes.
… It is harder. We'll come back in the future with more data.

<fielding> yes, the section suggests that the browser save that information along with the exception data

Shane: Some sort of freedom outside of same-origin, so yahoo,com and flickr.com can share a policy.

schunter_: Can maybe add a new call later, keeping backwards compat.

shane: This is sort of counter to natural adoption curve in internet.

schunter_: Your second issue:

3rd Parties Registering Exceptions on 1st Party Sites

shane: 3rd parties registering exceptions. Would like a way to discover that that has occured.

moneill2: Agree there should be a way to report, because the 3rd party can cause legal problem for 1st.
… I suggested we just have an indication from 1st party whether they allow it to happen.
… Some flag sayiung this 3rd party is allowed to register an exception.

shane: Say Tumblr.com displays adds in a news feed. We dont' want a 3rd party to register an exception at that point, in an iframe.
… We can't technically stop them, We would like to be informed.

dsinger: iframe is a top-level context?

moneill2: can have some flag that says *.domain can set an exception.

<fielding> This would only be the case where a third party iframe contains javascript that is executed. It can call the API to store a site-specific exception. This is not changed at all by the recent edits, other than being exposed because there is less text objuscation.

dsinger: Site setting exception has to match browsing context.

fielding: There is no change here. This is what the API did before.
… Javascript can set any target it want. Relies on regulator checking that site follows rules.
… A site would do better just ignoring DNT in that case.

dsinger: [missed]

Shane: Worst they can do is set a site-wide exception.

dsinger: Why would advertiser expect a user to visit them as a top level site?

shane: Can't they do web-wide then?

shane: Imagine an industry approach. They would need an iframe approach.

<moneill2> 6.6.1 starting "For each of the targets in a web-wide exception"

shane: I like roy's argument that there are many ways to exploit the standard. But as it is traceable, they're better off not doing it through DNT.

<dsinger> Registering a site-wide for ‘myself’ (all you can do) when myself is an ad site seems useless; no-one visits ad sites. But registering a web-wide is a huge break; but they are asserting they have consent, and if they don’t, they have a glaring error (that;s noticeable)

shane: So I'm good now. That closes the discussion for me.

moneill2: In the new confirm call: Can't confirm a sub-somain, as you used to be able to.

fielding: Yes, that did change. Made it too easy to fingerprint the user.
… could ask for a user's exceptions on sites you don't own.

moneill2: In the confirm call, site param is now ignored.

dsinger: Doesn't same-origin apply?

[Discussion about what the spec actually says.]

dsinger: Why doesn't the confirmn call exactly match the store call? Why did it change?

fielding: It allowed any party to make a query on any domain. I removed that. It now allows if an exception exists on the specific site.

<fielding> https://‌w3c.github.io/‌dnt/‌drafts/‌tracking-dnt.html#exception-javascript-api-confirm

dsinger: Previosuly you could only ask about your own site.

<fielding> "To avoid revealing too much information about other sites, any value for site is ignored and the calling script's site domain is used instead for matching with stored exceptions."

schunter_: So a site can only ask for confirmations affecting its own site.

<dsinger> I agree that the old confirm call didn’t have text saying that CORS had to be respected. But I am not sure we have not introduced a different problem here.

moneill2: I think the only diff. is you can't do it on a subdomain. Why don't we allow that? You can set an exception on a sub-domain, why can't you query it?

dsinger: Old text didn't say it explicitly that you have to respect same-origin.

<schunter_> Confirm call now only allows "site=null"

<schunter_> (means site=origin)

<schunter_> store also allows "*" for web-wide

<schunter_> and cookie rules for sub-domains

<fielding> I don't care either way, except I am not available to rewrite.

moneill2: I agree with roy's addition to web-wide. But what in 6.6.3. "any value for site is ignored"

schunter_: site param allows null and *. You cannot confirm if a web-wide exception exists.

<fielding> The old confirm API is at https://‌www.w3.org/‌TR/‌tracking-dnt/#exceptions-javascript-api-ww-confirm

<dsinger> I think Mike is saying that the confirm call doesn’t match the store; the basic operation “do I still have this that I stored?” has to work

<fielding> ... https://‌www.w3.org/‌TR/‌tracking-dnt/#exceptions-javascript-api-confirm

<schunter_> cases: site="*"

schunter_: storeTrackingException can set an exception for a sub-domain. trackingExceptionExists cannot query that same sub-domain.

<schunter_> Changes:

fielding: My concern about the previous API, which is still in /TR, is that it allowed discovering info about other domains.

<schunter_> 1. Say that it can only be called to query exceptions for the given origin

<dsinger> Two basic principles: the same-origin restrictions on confirm and store should be the same; and you should be able to confirm exactly what you thought you stored

<dsinger> i.e. ask the question: has my prior store been deleted or does it still stand?

schunter_: fingerprinting risk. A nasty company could set a user-specific cookie-like pattern.
… But I'd then have to iterate through all user patterns.

dsinger: web-wide exception now has targets, which it didn't have before.

<dsinger> I regret to say that we need a repeated security+privacy+TAG review, given the number of changes

schunter_: That is for next week.

<fielding> Reminder, the issues list is at https://‌github.com/‌w3c/‌dnt/‌issues

<dsinger> I am not enough of an expert to be comfortable

<fielding> We have no open issues on the draft, right now.

<schunter_> 2. Add "*" and cookie rules as site options (similar to store)

<schunter_> 1: Cross-origin restrictions must be documented for store and confirm

fielding: If there is something in the old API that I accidentally removed, let me know and I'll restore it.

schunter_: Who can write it?

<schunter_> Edits:

moneill2: I can write an edit and send to the list.

dsinger: We need a TAG review on this.

<schunter_> 1. Explain that confirm and store must respect same-origin

<dsinger> …and a PING review

<fielding> right, most of this work was just to get the API to the point where people might be willing to review.

<schunter_> 2. Copy options for "site" parameter "*" and "cookie-like pattern" from store to confirm

<fielding> "For each of the targets in a web-wide exception, a user agent MUST NOT store the duplets and MUST reject the promise with a DOMException named "SecurityError" unless the target domain matches both the document.domain of the script's responsible document and the document.domain of the top-level browsing context's active document [HTML5]. This effectively limits the API for web-wide exceptions to the single target domain of the caller."

dsinger: We seem to have added the possibility to set multiple targets in a web-wide exception. But most of all I want a security & privacy review of the new API.

schunter_: If we wait for review, we push off the CR again.

dsinger: Can probably have the review during CR. For Bert to check with plh and others.

moneill2: Not allowing DNT:1 by default may upset DPA in Europe. But leave well-enough alone.

fielding: I wrote a section why DNT:1 is not set by default. It is just information, but it is needed, because multiple parties have said it is OK to set DNT:1 by default.
… Not sure why that is. Is the spec not clear? Are people misleading legislators?
… Section 10.1 is not supposed to say anything different from 5.1

moneill2: "5.2"

<fielding> actually, 5.1

<fielding> we were talking about https://‌w3c.github.io/‌dnt/‌drafts/‌tracking-dnt.html#privacy.not-preconfigured