<moneill2> the webex link says the meeting is cancelled
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.
<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?
<dsinger> I think that Mike is right, you have to open browsing contexts for those sites, and they can then register the exceptions
(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:
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.
dsinger: Site setting exception has to match browsing context.
fielding: There is no change here. This is what the API did before.
… A site would do better just ignoring DNT in that case.
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.
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.
<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
<schunter_> cases: site="*"
schunter_: storeTrackingException can set an exception for a sub-domain. trackingExceptionExists cannot query that same sub-domain.
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?
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
<fielding> actually, 5.1
<fielding> we were talking about https://w3c.github.io/dnt/drafts/tracking-dnt.html#privacy.not-preconfigured
Succeeded: s/Makes it easier/Made it too easy/
Succeeded: s/cookie/cookie-like pattern/
Succeeded: i/3rd parties registering exceptions/topic: 3rd Parties Registering Exceptions on 1st Party Sites/
Succeeded: s/conform call/confirm call/
Succeeded 1 times: s/chnage/change/g
Succeeded: s/if a an exception exiosts on a specific site./if an exception exists on the specific site./
Succeeded: s/coul donly/could only/
Succeeded: s/whay /why /
Succeeded: s/have respects/have to respect/
Succeeded: s/qdiscovering /discovering /
Succeeded: s/We seemed to have added/We seem to have added/