See also: IRC log
<aleecia> Doing this via iPad today. Considerably less fun than a real keyboard.
schunter: 2nd item register to the meeting in seattle
npdoty: deadline for registration is june 12
schunter: add dsinger_ API proposal to the agenda
<trackbot> ACTION-139 -- Thomas Lowenthal to improve wording of 3.9 "Meaningful Interaction" to avoid "affirmatively clicking" and make sure that "clicking" is replaced with something more general. -- due 2012-05-14 -- OPEN
schunter: next item is review of overdue action items
<Marc> I think so
<JC> [Microsoft] has JC
<trackbot> ACTION-179 -- Shane Wiley to draft section on seriousness of the request for a user-granted exception (with ninja) -- due 2012-04-19 -- OPEN
<tedleung> zakim aamm is tedleung
WileyS: I have draft with ninja, reminder sent two week ago
<aleecia> Thanks, Shane!
schunter: move this item to the pending review category
<trackbot> ACTION-180 -- Nick Doty to provide a text update to section 4.3 to resolve issue 116 and ISSUE-84 -- due 2012-05-16 -- OPEN
<aleecia> Writing up sounds good
npdoty: discussed a couple of option, could write them up and send discussion on the list
<npdoty> action-180 due today
<trackbot> ACTION-180 Provide a text update to section 4.3 to resolve issue 116 and ISSUE-84 due date now today
npdoty: will send that today
<trackbot> ACTION-185 -- Kevin Trilli to draft specific field proposal for optional auditors -- due 2012-05-05 -- OPEN
schunter: action 185 on kevin
<npdoty> action-185 due 5/26
<trackbot> ACTION-185 Draft specific field proposal for optional auditors due date now 5/26
KevinT1: will do that in a couple of week
<trackbot> ACTION-196 -- Justin Brookman to draft text on whether url shorteners are first or third parties -- due 2012-05-16 -- OPEN
<npdoty> enewland: Justin on the road, but will follow up with him
schunter: anything else in the overdue action
schunter: : next item is follow up of last week discussion on URI and header
... fielding updated the section
fielding: I took the suggesiton form Ian and restore the response call to the header field
... to not impact caching
... only dynamic response is for dynamic situation 1st/3rd party
<hwest> Roy, we still have problems with the 'if the resource doesn't know their context, this can't be implemented' but I know that's not this discussion
<hwest> But in general think that this draft is an improvement - haven't gone through in detail yet.
<schunter> I guess improving it has been Roy's goal
<tl> hwest, Yes, but that's a fundamental problem. If the resource doesn't know it's context, it can't tell the UA. If it can't tell the user, that's a no-go.
<npdoty> aleecia, we're following a similar agenda this week, so I think Zakim is not too confused
<hwest> tl, It may not be able to tell the user BEFORE the transaction. During is different.
fielding: there was one URI for access to where you can access consent and one to gather data
<aleecia> So long as we aren't
fielding: now they are merged
schunter: can you explain the interplay between header and well known URI
fielding: main difference is wether you know where to get the information before you can get the resource
... that works with well known URI, also you can search for all the site that surpport DNT
<npdoty> fielding: a search engine could crawl for all sites that support DNT
fielding: the header return the status (1st/3rd party), I m respecting DNT (or not)
npdoty: two questions could you sent a tracking status resource for a general context and process differently specific requests
... second if you send header to every request do you have to implement the well known uri?
fielding: yes otherwise users could not knwo before sending the request
npdoty: do we expect user agent to imlement that
<npdoty> tl: I expect some user agents to implement that
schunter: the URI could say I will track you and the header say I did not
<npdoty> although I can see the pre-checking mode as a nice-to-have, I'm not personally sure that it's a key requirement for communicating the tracking status
fielding: in normal case would not check for status
hwest: it seems that the server would have to track if thaere has been a status cange since the last visit
<Zakim> tl, you wanted to say that the URI should be required because it contains the important info, and the header is just one way of finding it.
fielding: that's what we don't want
tl: we should keep the semantics in the well-known URI
npdoty: one option would be to not have a general well known URI and have a specific URI sent through the header (not sure I capture that correctly)
... perhaps some parameter in the request will define the tracking value and not the path aloen (according to Ian)
<fielding> the path member is no longer in the tracking status resource -- there is only the site-wide /.well-known/dnt and header-identified dnt/status-id resources.
<schunter> tl: A user should be able to retrieve some baseline promised behavior from a well-known URI.
tl: I want a user always be able to find a URI with his status
<npdoty> fielding, apologies, I thought I had reviewed the update, but I misunderstood
tl: the response couold say I'm dynamically generated
tl: then users would have to add a token that correspond to its status
<fielding> npdoty, no worries -- thanks for the review
<npdoty> fielding, and so loading /.well-known/dnt alone would be applicable to a site-wide tracking status only?
tl: the URI could say we don't have a file that say "sorry no general policy" you have to send a specific request
schunter: could you have a look to the current text and make a list of propsal
<fielding> the tracking status already has an "s" response
jmayer: clarifying question, understading the state of a indivdual browser awarness of the well known resource would not be possible?
<npdoty> fielding's was my understanding as well
fielding: folks could usethird party system to check DNT status resource, that would be another mechanism for a UA to know what site support DNT
jmayer: how does that integrate with status update
... the status resrouce would be individualize to the brwoser and therefor recognize the browser
... that would require to track the browser (according to some definition)
fielding: I can't help cause the definition of trackign you're using is wrong
<fielding> Please send technical details with your objection.
<npdoty> rigo may be happier with fielding's most recent update to this section
<aleecia> We do have a "no really I don't track at all" path, and have a use case to support that
<npdoty> rigo: my only requirement is that we do not include the possibility of using headers
<aleecia> So if this does not, then Roy, that's a problem that should be fixed
<fielding> For performance reasons, that objection cannot be satisfied.
tl: rigo, do you say someone should be able to get the full information without requesting the URI?
<npdoty> fielding, to be clear, the performance reasons you're referring to are just the amount of text that would have to be included in the response header?
<fielding> npdoty, yes, in *every* response, and it doesn't have the cache capabilities of the resource.
rigo: not the full only the essential
<aleecia> I'm going to need to read this, but this isn't sounding viable yet
schunter: next item is discussion on specific specific
<jmayer> Well, the response + resource have gotten entirely overcomplicated...
schunter: started discussion last week
schunter: we do not longer ask to declare all third party but only the direct element of the site
... like to get feedback on the proposal :
... restrict API to web wide exception and site wide exception
... if a site choose to do so they can post the list of third parties on the well known URI
... if there is a well knwon a list of third parties and granted a site wide exception, the exception would concern only the listed third paties
jmayer: would be interested to get feedback from people who oppose explicit explicit as the main issue seems to remain
schunter: currently waiting for the review of the proposal
<npdoty> schunter: has additional transparency advantage (find out the list not only when a exception request is being prompted)
schunter: if a site propose a list of third parties, anybody can check the list of third party, not need to call the API
JC: what happen when the list of third party changes
<hwest> This doesn't sound workable, if it resets every time you have a new third party
schunter: if you change the list, you have to call the API again
<npdoty> hwest, what schunter is proposing doesn't reset, just that the new third party doesn't get DNT:0 until you ask again (if you're using an explicit list)
<dsinger> then that is NOT a site-wide exception, it's just moved the API parameter
<dsinger> site-wide means anyone who is now or might ever be embedded on the site
<hwest> npdoty, that fragments the way it all works, on the same page - kinda hard. I think this is all overly complicated, but I don't have a good solution (yet?)
fielding: I still don't think it resolve any issue regarding UI and how client will explain to user who these third parties are and why they are relevant
<jmayer> So here we have a problem.
fielding: the full exception/exception is nto fit for regular user
<jmayer> Some are unwilling to accept a standard without explicit-explicit exceptions.
schunter: other strong objection?
<dsinger> I cannot see how this proposal either works, or solves anything.
<hwest> Some are unwilling to accept a standard with them.
<aleecia> Yet blank check in EU is problematic, yes?
npdoty: are you saying that user can not understand the concept of exception at all?
<dsinger> (Blank check might be problematic for lots of people)
fielding: basic problem does not have any intereaction about this third parties and don't knwo them
fielding: I don't see any mechanism tat would inform the users and then and then get their consent about third parties
... users have trust relationship to the first party
<dsinger> I don't need a relationship to the 3rd party to approve the 1st party's list. I need to trust that the 1st party has chosen wisely. That's VERY different.
npdoty: users may have relathionship with third parties (e.g. facebook)
<npdoty> schunter: could leave this in and then see whether user agents implement it during the implementation phase
tl: that's not necessarely the user agent implementation would look like, we could use fourth parties
<npdoty> +1 to schunter on allowing implementation and drop them if unnecessary
<aleecia> I'm fairly sure user trust of first parties does not extend to all of their third parties, especially users of DNT
<schunter> tl: explicit/explicit may provide the info to allow plugins that determine trustworthyness of third parties and response based on this info.
<hwest> tl, isn't that the tracking selection lists?
<jmayer> hwest, nope, no blocking here.
<npdoty> tl: could trust an auditor, delegate that choice to someone that they trust
tl: we should expect that users will delegate that choice to someone else that they trust
<tl> For instance, I could trust everyone iff they have a TrustE seal.
<aleecia> +1 with Nick on Matthias' suggestion for what it's worth
<aleecia> David dropping
<fielding> losing you
<eberkower> having a hard time hearing
<maiello> please repeat
<schunter> singer says that by having the info, user agents are free to innovate how to best use this data (e.g., by just using DBs to track the lists).
dsinger: you only have to trust a first party and then list the third party that goes on a database in the client
... but it does nothave to expose to the user
<dsinger> Much of what I said was in email, by the way
<aleecia> I'd like to see UA's implement this and see what that looks like
<npdoty> dsinger: list doesn't need to be shown to the user, just that the list would be in the database
<schunter> Me too (wait and see)
fielding: sites that have to implement the consent mechanism does not necesseraly trust browser
... they tent to revert to cooki based echanism
<schunter> If Ian's objection has been overcome and no other strong objections appear, then we should keep it.
<aleecia> Any third party can still get out of band consent...
<npdoty> consistent experience? or customized, per-site experience?
<dsinger> Visit newspaper with DNT on. Newspaper redirects to page that says "either pay or let my advertisers track you". You say OK, the API is called, the UA says "newspaper thinks you approve an explicit list of sites to track you when you're at newspaper", you say yes, the list of 3rd parties gets rememberd by the UA.
fielding: it's another objection to the eception mechanism
<dsinger> The 1st party only needs to get exceptions for the 3rds that they monetize thru and trust
schunter: item 6, user agent behavior
... what if a UA say yes to a exception and keep sending DNT:1 all oer the place
<fielding> because the only purpose of the exception mechanism is to supply consent when the site would otherwise get DNT:1
<npdoty> I believe this section speaks to that: http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#exception-use-by-browsers
schunter: relationship between granted exception and subsequent behavior with third parties
<aleecia> It might be a good thing to add support for a text field for third parties to explain who they are and what they do, so they can communicate that (via UA display) to users when consent is requested
<fielding> (sorry, I didn't realize this was the next item on agenda)
npdoty: 6.3.2 does mention that
<aleecia> So not just Omniture, but why Omniture is something users shouldn't mind saying yes to
npdoty: it does not speak of the storage, but just of the current status
<aleecia> Then not knowing the name of brands is less a problem
<vincent> i think the problem is about distrusted browser
<Chris_PedigoOPA> Aleecia, are you envisioning multiple third parties asking for consent?
schunter: could browser cheat the exception
tl: I don't think that it is coherent
<fielding> *this* issue is about a server making decisions about what content to supply to the client based on the consent, but then the browser makes arbitrary selection of DNT:1 based on what the UA (or some third party) thinks is a good site.
...: the idea is to ask if user is ok and if user say no, then he says no
<aleecia> If a first party has multiple third parties, that's what we're talking about, yes. (are you asking if I mean 20 dialog boxes, no, I'd expect it bundled together. But I am not a browser UI designer, I'm just thinking no one wants a face full of boxes to check)
schunter: scenario I had in mind is when the exception status modify the return content (premium content if exception granted for instance)
tl: a user could use other technology to circumvent the exception mechanism
fielding: this issue is with the problem of site making content decision based on the exception status
<npdoty> schunter: in that case, I'm happy to drop this if no one else is worried
<npdoty> fielding: I'm still worried
fielding: the site can not trust the browser to make consent decision, the consent should be past to the third party by the first party, not by the browser
<schunter> i AGREE
<rvaneijk> fielding, do you want to transport the consent from 1st party on the server side?
fielding: we get out of the idea that we can solve the problem in the browser
tl: if a user want to get a web page and not load all the other resource, there is no way to modify HTTP to prevent that
fielding: I'm not asking DNT to solve that problem, we can not rely on DNT exception framework because of that problem
<dsinger> I tend to agree that the API is better used to verify the "I think I have permission to track you" response, than to send DNT:0
schunter: the excpetion API provide some consent which could be pass to third party
<fielding> rvaneijk, yes -- for example, a first-party might only supply content containing sub requests only to users who have already consented
<npdoty> vincent_: that problem is why I suggested last week a required exception
<npdoty> ... in order to visit a particular web page the user has to grant the exception or can't visit
<npdoty> ... third-party can check the referral and if it is a site that has to have that kind of exception, then it knows it can track the user
tl: if you say to users if you don't grant me the consent I'm going to punch you, users are going to lie and there is not way to prevent that
npdoty: website don't necessarely need an affirmative promise that DNT:0 will be sent
npdoty: the idea would be to have the exception granted directly to the third parties
<rvaneijk> fielding: as a consequence, retreiving consent from out-of-band consent mechanisms would become a complicated task for the user, wouldn't you agree?
<npdoty> sorry, that was a lot of text, I'll try to summarize
<rvaneijk> fielding: s/retreive/revoke/
<npdoty> users can change their mind, and an exception isn't a promise that I won't change my mind for a certain period of time
dsinger: it might be better to use out of band consent mechanism
<aleecia> I'm wondering if best practices for UAs is a good issue to add. We cannot design UI, but we can explain why Thou Shalt Not Change The User's Voice, etc
<npdoty> the requirements I heard from industry is that we didn't want to require a system of elaborate server-to-server communication
<aleecia> Suggestions seem within charter
<dsinger> The user can at any time change their mind, and delete the exception, and at the moment that would cause DNT:1 to be sent again. And the site would need to notice and respond. Out-of-band exceptions are more secure; the site responds "I have permission to track you" and the remembered grants database can then be used by the UA to confirm this. If you want to change the permission you gave a 1st party, re-visit the site and change it wherever you previously gave
<dsinger> And if the UA and/or user disagree that they have given permission, they have the rights to 'walk away', or complain.
<npdoty> and while some user agents could give confusing responses, for many many use cases this would be sufficient
<fielding> rvaneijk, that would still be the "control" link -- just a form on a first-party webpage, so not difficult at all.
dsinger: if you get a response that say "i've been granted a permission to track you" then you can complain
<rvaneijk> dsinger: one important driver inthe EU is recital 66, which is all about shifting consent to the browser.
dsinger: not sure we need the API for the right purpose
<rvaneijk> fielding: ok, ACK.
WileyS: I don't want to restrict all exception to out-of band
<npdoty> +1 to WileyS!
<dsinger> I should be clear; I am wondering, exploring issues, not really proposing
...: management on different site is the current with current opt-out cookie
npdoty: it sould also be easier for user who could change their mind
<npdoty> npdoty: being able to easily change your mind is an advantage, might get users to accept more tracking even
schunter: the issue is acutally a non-issue, does someone wnat to propose something on this issue
<fielding> right, the consent obtained by the first party still needs to be specific and informed and under control of user
schunter: I'll send a mail and if nobody object then I'll close it
<npdoty> schunter: "that's nice, I like closing issues"
<fielding> not sure what issue is being proposed
schunter: next on the agenda is the API proposed by dsinger
dsinger: all in one email what happen when an exception is granted and then when it is removed
<dsinger> 1. what is the effect of re-directs? if the original site was getting dnt:0 as a result of the exception, does that follow-through to the re-directed site?
<dsinger> proposed answer: yes. (this allows ad-indirection.)
<dsinger> 2. is the grant request agreed or denied as a package, or can the user pick-and-choose which sites to grant to?
<dsinger> proposed answer: it's a package; the UI is probably unmanageable, and the site is asking about the 3rd parties it cares about, and probably needs them all
<dsinger> 3. what is the matching rule?
<dsinger> 4. If the UI is asked for an explicit list, is it allowed to ask the user for permission for [site, *], and if granted, write [site, *] into the database?
<dsinger> proposed answer: I suppose, though I think the spec. should be silent on this
<npdoty> I see, dsinger's follow up to dsinger's earlier email
npdoty: I have a concern about redirection, should user send the same value to whoever they redirect to
... you could pass on exception to other site
<fielding> redirects inheriting DNT setting allows for transitive consent for ad chains
<aleecia> You mean agent not 3rd party to 3rd party?
<WileyS> Service Provider permitted use
<Chris_IAB> Sorry to throw a wrench in this whole conversation, but it seems to me that we are skirting the REAL issue here: given the current proposal, we don't know what choice/decision a user has actually made. If the user's action/choice is not made by the user after being properly informed, then industry can't possibly know how to respect the user's "choice", as we don't know what the use chose in the first place. An example would be a third-party that influences
<aleecia> Well: no, different approach, same outcome though perhaps
fielding: ad chains use the redirect to know if they can get high valuation for targeted ads
<Chris_IAB> (cont.) deceptive.
fielding: if they DNT:0 at the begining of the chain, then every following third party should receive DNT:0
<dsinger> to Rigo: we're talking about HTTP re-directs, so the UA absolutely knows
<Chris_IAB> SO shouldn't we be offering/requiring that the user receive at least basic information about DNT (what it is, what it does, etc.) AT THE POINT OF USER CHOICE (at the point DNT is set)?
<npdoty> aleecia and WileyS, yes, I meant service providers
<dsinger> (I think we are well off track)
<Chris_IAB> The DNT:1 signal may "mean" many things, but we are supposed to only take ONE action on it -- that's flawed logic guys.
<rvaneijk> @rigo: that is a service provider permitted use with purpose limitation in place
rigo: people who receive DNT:1, but for which the root of the chain received DNT:0 would have extended allowed uses
<aleecia> Six minutes left on call
fielding: how an third party on the chain would know the status of the root third party?
<npdoty> Chris_IAB, maybe you could send follow-up email on your concern. as I understand it you want to raise a new issue on the context/user interface of enabling DNT:1?
rigo: we should discuss this, that is a protocol issue
<Chris_IAB> The current proposal put the onus on publishers to figure out, after the fact, what choice DNT:1 means to every user... why do this down-stream? We should do this much more efficiently at the point of user choice.
schunter: what are the action we could drop for that last discussion
<npdoty> Chris_IAB, maybe that even matches the issue that Shane raised as 143
<dsinger> (seeing as we have 5 minutes remaining, Dave suggests we get the APIs in this email into the document, and the questions into open issues)
<jchester2> Consumers may not want to be tracked for their financial behaviors, collected by third parties, for ex. Or other sensitive data. But they may be ok for other non-sensitive collection purposes. Users need to have greater control over this process. The third party chain should not automatically have permission.
<aleecia> Chris I think there are two paths. One is best practices we could provide to UAs. I think we should do that if there's interest.
<dsinger> (seeing as we have 5 minutes remaining, Dave suggests we get the APIs in this email into the document, and the questions into open issues)
rigo: I could write some text about that transitive
<npdoty> ACTION: rigo to propose text (with help from Shane) about transitivity model [recorded in http://www.w3.org/2012/05/23-dnt-minutes.html#action01]
<trackbot> Created ACTION-203 - Propose text (with help from Shane) about transitivity model [on Rigo Wenning - due 2012-05-30].
schunter: rigo you propose a test and shane will have a look at it
<fielding> jchester2, yes -- the consent needs to be limited by purpose
<aleecia> Second is non-w3c discussions with browser companies. Alex has offered to talk to self-reg groups multiple times
<dsinger> (trying to dial in again)
<aleecia> That's where you can get into UI discussions
dsinger: I think we should get the API in the document
<Chris_IAB> Aleecia, I don't think "best practices" alone will work; for this to work as intended, it has to be part of the protocol and compliance doc
<fielding> agree that we should try putting in spec
<npdoty> ACTION: lowenthal to write up potential change to tracking status resource [recorded in http://www.w3.org/2012/05/23-dnt-minutes.html#action02]
<trackbot> Created ACTION-204 - Write up potential change to tracking status resource [on Thomas Lowenthal - due 2012-05-30].
<Chris_IAB> Alex and you are invited to talk to our self-reg group - no issue
<npdoty> thanks to vincent for scribing!
<aleecia> ACTION: aleecia to open a new issue on UAs [recorded in http://www.w3.org/2012/05/23-dnt-minutes.html#action03]
<trackbot> Created ACTION-205 - Open a new issue on UAs [on Aleecia McDonald - due 2012-05-30].
<npdoty> ACTION: singer to integrate http://lists.w3.org/Archives/Public/public-tracking/2012May/0280.html by May 30 [recorded in http://www.w3.org/2012/05/23-dnt-minutes.html#action04]
<trackbot> Created ACTION-206 - Integrate http://lists.w3.org/Archives/Public/public-tracking/2012May/0280.html by May 30 [on David Singer - due 2012-05-30].
<aleecia> Let's talk it through and see where the group is
<npdoty> trackbot, bye