<ionel> +q

<ionel> -q

<ts_> +q

<ts_> -q

<npdoty> vinay, can you hear us?

<vinay> yep

<vinay> but not very well

<vinay> is he moving?

<vinay> he was coming in louder a few minutes ago

<npdoty> scribenick: npdoty

schunter: a smaller group today
... more technical audience, can hopefully get things done more quickly
... a couple changes to the agenda
... thomas on charter, rob and @@@ on european context

http://www.w3.org/2011/tracking-protection/agenda-2013-02-11-MIT-Boston.html

<WaltM_Comcast> what is the conf code for today?

<aleecia> Thomas: 13 jan: extended charter for LC in July. April 2014 new end date on charter. Announcement last night. Sorry for not saying anything in advance.

<aleecia> …. extended through jan this year, workshop at berkeley for input, useful but nothing beyond "get this done before you bite off anything else," workshop report forthcoming.

<aleecia> … Peter came in, end of Jan did the charter extension, sorry for the surprise

<aleecia> … questions?

<aleecia> (cannot hear the room)

<aleecia> Thomas: w3c mgmt reviewed on 30 Jan, can decide to grant extension or close it down

<aleecia> … routine decision, trying to get better on scheduling but happen regularly

<aleecia> (cannot hear questions)

<vinay> Thomas - can you repeat the questions?

<aleecia> Thomas: will send a note to the mailing list

<aleecia> seriously?

<dsinger> announcement at http://www.w3.org/mid/58B62109-FBB4-4923-814F-7368837FE74D@w3.org

<aleecia> Thomas: there was also question about if any policy work should happen at w3c

<aleecia> … didn't think there was agreement either way

<aleecia> … policy work inevitable v. others thought that not the case

<aleecia> … to the 2014 dates, schedule on home page

<aleecia> … don't want to do more extensions. Unlike last time, did schedule to recommendation. LC in July, then CR etc.

<aleecia> … leaving some padding, get april 2014

<aleecia> … would like to see before then

<aleecia> … mid of this year, get LC draft

<aleecia> … bunch of steps to get there

<aleecia> … reasonably generous time

aleecia: are there any conditions under which w3c would shut down a group?

<aleecia> … have not explicitly discussed what it would take to decide to pull the group?

tlr: success criteria of the charter and broad participation

<aleecia> … might be new info and the character of the group might change

<aleecia> aleecia: register my disappointment with this process and discussion

<Chapell> +1 to Aleecia

<aleecia> rob: EU deadlines?

<aleecia> thomas: did not put side by side with our July date, if coincide that's coincidence

<aleecia> Rob: they do

<aleecia> thomas: did not know until now

<aleecia> (can we get a scribe?

<aleecia> )

<aleecia> (hard for me to hear)

<scribe> scribenick: haakonfb1

<aleecia> (the lack of scribe for this 5 minute session is also rather amazing)

<aleecia> (and doing it *today* rather than monday?)

<rvaneijk> The question was if the decision to extend the charter was based on the trajectory process towards the Regulation in the EU?

<aleecia> (for shame)

David singer will give overview of what happens since last time

<npdoty> aleecia, I started scribing, but then was pulled away when the projector broke

<aleecia> thanks, Nick

<Chapell> I agree - it seems innappropriate to have the discussion of charter renewal after the fact

<aleecia> that's at least somewhat better than it felt

<aleecia> but

… 09:30-10:30 look at open issues. should user agents be required to have exceptions API. Should service providers declare themselves or not

<Chapell> did I miss the explanation for this?

<aleecia> there was none.

<Chapell> was it simply --- "ooops, we forgot"?

<aleecia> yes.

<hwest> Someone needs to mute on the phone!

… feedback in UA if party claims out of band consent

… coffee break

<Chapell> TLR and Peterswire - you significantly harm the legitimacy of the process with these types of tactics

… rehearsal session 12:00-12:45

<aleecia> and odds are good i'd support this outcome, but the idea that there was no actual decision or discussion of under what conditions w3c would say they'd had enough between now and april 2014 is a problem for me.

<Chapell> not sure if it was intentional or by omission --- but not sure that really matters

<aleecia> and contrary to commitments that i believe had been made to me, if no one else

… sub-domains, multiple site exceptions, signalling state/existence of site specific exceptions.

… European issues - if time

<dsinger> my perception is that the W3C closes down groups when they become non-functional;

<Wileys> Aleecia, can you speak to the commitments the W3C made to you in this context?

Presentation of the Working Draft and changes

David Singer: Not changed a lot in the document since the last time. The big change is the change to the exceptions model.

<npdoty> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html

… has moved the requirement for the UA to display users. Exceptions is the sole responsibility for the site asking for exceptions.

<aleecia> Let me review notes, make sure I am not missing anything, and then comment.

… inquiry API has changed. What will I get changed in the current context. No longer presemption that the user has an overaching setting. this means that one can ask exception without any preferences set

<Chapell> thanks Aleecia

… recently introduced under construction status. Can use this to signal that we are working on it. We are not claiming any compliance

… roy introduced a new part of the well known resource. David does not understand all implications. We need to ask Roy.

<Chapell> i'm particularly concerned as the charter scope has been used as rationale for not requiring UA's to clearly disclose dnt functionality

… Site can check what exceptions the users has granted

… this resolves a tricky question of visibility for first parties.

<aleecia> So, in fairness -- and I'm trying to listen to David too and failing -- it's not like the charter extension deadline was secret or a surprise. If you wanted a charter fight the time to bring it up was in January before the extension ended, and that date was well public

<scribe> … new section guidance on what sites that are third parties without script presence. How can they ask for exceptions.

<aleecia> cannot hear questions

<tlr> right. We announced a February meeting in December, and that meeting was after the scheduled end of the charter.

… has to get to some state there the site includes something for you or the user visits your site.

…. question: Meaning about DNT:0. How does it work in the framework

… DNT:0 can either be the users' set settings.

<Chapell> TLR: thanks. so the message to the group is -- tough luck, you should have raised it back in January.

… continue on what is changed

<tlr> Chapell, you should have raised it at the workshop in November.

… Issue database and document in sync. At the moment this is true.

… if this is not true, let us know

<npdoty> issue-148?

<trackbot> ISSUE-148 -- What does DNT:0 mean? -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/148

<justin> Language on DNT:0 in Compliance spec: When a user sends the DNT:0 signal, they are expressing a preference for a personalized experience. This signal indicates explicit consent for data collection, retention, processing, disclosure, and use by the recipient of this signal to provide a personalized experience for the user. This recommendation places no restrictions on data collected from requests received with DNT:0. The operator of a website may engage in pra[CUT]

<npdoty> for the compliance document, we have an agreement and some pending review text noted in that issue.

… one change yesterday: Lot of these exception call had to many parameters. Not a functional change, but making it a bit more modern in how we program.

<Chapell> TLR: understood. we've now moved this entire process into a very legalistic exercise

<justin> Not sure that is consensus or how old that is --- I haven't edited that page recently!

<Chapell> TLR: if that's what you'd prefer, that's fine.

<aleecia> what was the feb meeting announced in dec?

… diff of document from amsterdam and tomorrows version. Guess this is all changes

<aleecia> this one now?

Shane: Will adrian be here today.

dwainberg: Editorial question - discuss altering the explanation of DNT:0. Document says "The user prefers to allow tracking on the target site"

it will be two different DNT:0 - distinguish if it is an explicit decision for this site, or a general setting.

dwainberg: two scenrios?

Rigo: global consideriations meeting will discuss DNT:0 - how to inject this to the protocol. How to make this work as a consent mechanism. What will DNT:0 mean in regimes with stricter requirements.

<justin> If DNT:0 is set permanently, then they're all target sites!

chris: Question: What does target site mean? If the user has a general setting. The receiving site is the target site (receives http-header).

<justin> Depends if they're doing in-band or out-of-band, yes?

David Singer: What is not changed. We need to align the qualifiers - need to align with the compliance document.

<npdoty> justin, whether a site receives DNT:0 in the case of an exception depends on whether the exception is out of band or not

<fielding> This is old text that is waiting for other things to be decided.

<tlr> fielding, q+?

… the tracking expression document talks about a protocol. What it means on the site or for the user is defined in the compliance document.

<justin> npdoty, thanks that's what I thought

peter swire: Question about target site. "target" is a word that might be misunderstood

chris: No, that this not the reason for the question.

edfelten: We should use the word used in the HTTP-spec

fielding, could you please type your point in IRC. Sound is breaking

<npdoty> fielding: will be updated to latest version of HTTP spec, have been minimizing diffs

<fielding> designated resource is the term we use now in TSV section

Now open issues

Open Issues

<npdoty> issue-151?

<trackbot> ISSUE-151 -- User Agent Requirement: Be able to handle an exception request -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/151

First: Exception handling in the spec. Is the user agent required to implement this?

(Issue-151)

<fielding> I have not changed this section recently because it has not been requested and we have only been making changes requested by WG actions or purely editorial

… should we require that user agents implement this exceptions api

… "should" means it should be done if you are able to do it - nearly mandatory

<fielding> Likewise, I should note that the use cases section has not been updated for the ! value.

<Wileys> +q

… should we mandate this?

Justin: As long as we don't know how successful the api will be, we should go as lightweight as possible.

Exceptions API has advantages - can use as a signal to your third parties. Out of band does not do this automatically

dwainberg: Concerns about whether a user agent may or must infer with the exceptions?

<npdoty> it would be speculation for us to explain how first parties would signal an out of band consent to its third party trackers; it could do so through URL parameters, or a purely server-to-server communication

This is not the right place - will discuss it later

<moneill2> q

dwainberg: Crucial to have user agents. Similar issues with UAs - who sets DNT:1. It is crucial that browsers implement this.

<npdoty> I think dwainberg's comment is most appropriate to the exceptions mechanism through issue-144, issue-187

<fielding> out of band consent would be conveyed to third parties the same way it is now -- through the call from first party page to the third party (i.e., the call would not be made without consent or the consent status would be passed as a request param)

<justin> fielding, thanks

<rigo> fielding: out of band is out of band

dwainberg: open issue about what guidelines for UAs to ensure that DNT settings is the user's actual choice.

<rigo> I'm with Matthias, you can't just claim out of band for everybody and spray DNT:0

<rigo> to everybody

<fielding> rigo, for the spec, yes, but it is helpful to understand the tech

<rigo> yep

No user agent UI requirements, but has to be settings set by the user

<dsinger> fielding: I have been using 'in band' to mean you do the signalling in-band of the request (exception call) and grant (dnt header); out of band is when you record consent some other way, and you signal it some other way

Shane: Issue-151: This should be a must. If it should be a balance to the DNT standard. A "may" for UA here will not achieve this balance.

<dsinger> w3c terms are as used in the IETF per http://www.ietf.org/rfc/rfc2119.txt

… UA could just say it was difficult. Important that this is a must, not should or may.

<fielding> dsinger, yes -- out of band in this sense really just means through some protocol not defined here

<justin> If you have out-of-band consent, how can it be gamed? Is this just a proxy for concern about UAs setting DNT:1 without appropriate consent?

Should is a rather strict requirement.

dwainberg: who can decide if UAs was really not able to implement?

<justin> We're conflating multiple issues here.

<aleecia> I'm getting every rare syllable.

Justin: Prefer "may"

Rigo: If had to plan to destroy DNT - chosen "may". Everything would be DNT:1 - and thus meaningless. Exceptions are required.

<aleecia> +1 Rigo

… we need to get trust back into the market. Not support a "must".

<rvaneijk> Rigo: a communication needs two way communication. Not having exception mechanism is not an option

matthias: prefers should

edfelten: this implies that UAs implements javascript

<npdoty> efelten: do we have data on user agents that don't implement javascript?

dsinger: We want a working eco-system. Later in the process find out what are must or should for UAs.

<marc_> So, as I hear David we will need to have a conversation and very deep dive on the "should" v "must" issue or as Shane says "punt for now" and examine later

… need to find out the minimum requirements for implementation. We needs implementation experince

… should is the preferred option now. We should get some experience.

<fielding> efelten, I agree that might be an issue -- it would be just as easy for us to implement the exception creation via a response header field

<Wileys> +q

… no one here plan to spray DNT:1 around.

moneill2: should implies that UAs can't disable javascript.

npdoty: in favour of the exceptions api. users must be able to express their exceptions.

… fine to have in the spec

<efelten> Roy, agree that there are engineering options here. Generally, the more complex the exception infrastructure becomes, the stronger the argument for SHOULD gets.

thomas: like to reframe the discussion

<dsinger> I don't think that there is a practical difference between a UA that doesn't implement, a UA with JS disabled, and a UA configured to say "no" always

… conversation A: What is shipped with the UA

… conversation B: What about other players who don't implement javascript

<justin> Would a UA configured to say "no" to all exception requests be deemed compliant with the standard (if this was a MUST)?

… conversation C: What if the user has made changes to their UA (e.g. added ad-block)

… should focus on the case with a full fledged UA.

Mathias: will go for the middle ground

shane: david was talking about going with the "should" and learn from implementations. We could go with a "must" and learn from implementations.

… relates issue-143 - we don't know who sets the preference

… if you remove the option to have an discussion with the user - no sites will implement dnt

Chris_IAB: Concern for an eco-system that require you do something as publisher, but a UA can choose to do certain things.

<efelten> Haven't we heard arguments from server side in favor of SHOULDs for them?

… compliance requirements must be on both side

mathias: there are some shoulds on the server side

<vincent> Wileys, if the router does not overwrite existing DNT signal but just add one if it sees not DNT preference in the request?

<npdoty> "it is possible to implement the exception API through header calls, it would be an alternative to javascript"

<vincent> that would still allows a dialogue between the service provider and the user

<vincent> who could grant excpetion that would not be overwritten by the router

fielding: as an alternative to javascript method do this with HTTP-header interaction.

<fielding> no, not drop it -- an alternative

<npdoty> I think Roy's suggestion is not dropping the JavaScript API, but supplementing it with an HTTP mechanism

<fielding> we would have both

<npdoty> Set-DNT-Exception: 1

mathias: Any strong push for headers?

<justin> If it would be conducive to having a conversation between users and publishers . . .

dsinger: The javasript api takes some effort to implement. There is at least one company in the room that has chosen to decide ignore UAs because of no compliance

<Wileys> +q

<aleecia> suggest we reopen the queue...

<schunter> yes

<Wileys> +q

… can we have a gentleman's agreement that we don't use "non-compliant"

… to ignore

<aleecia> speaker was…? Chris?

<schunter> yes

<aleecia> thank you.

chris: cannot enter into a gentleman's agreement on behalf of all the members

shane: not appropriate to talk about gentleman's agreement in a standardisation processes.

<Brooks> well said shane +1

<BerinSzoka> +1 to everything Shane just said

… it is the text of the standards. If one remove the possibility of a dialogue with the user, we are moving away from the task.

<Chapell> +1

<justin> But it can be!

<aleecia> There is nothing fair and balanced about the status quo

… one possible outcome - take it as it is, but you need the possibility to enter into a conversation with the user.

dsinger: you can say: I need this exception, please use another user agent..

<fielding> there is no such thing as a free lunch

<vincent> +1 to dsinger. It makes, sense websit will ask for exceptions anyway and then decide if they should redirect a user

mathias: we need to discuss later how to handle UAs that behave in different ways

<Chris_IAB> why is it on publishers to clean up some non-compliant UA's mess??

<BerinSzoka> I agree, aleecia: today, any privacy-sensitive user that wants to can install noscript and AdBlock Plus--and free ride off the value created by other users that don't bother. that's neither fair nor balanced

… it is perfectly for the UA to have all APIs but say no all the time

<efelten> Compliance is optional for everybody, including user agents.

… agreement on this issue: Either "should" or "must"

<Chris_IAB> there seems to be this idea that publishers and 3rd parties have to do the dirty work with users-- we deliver the bad news. That's not a fair position to put us in.

… for the UAs in the room: All will implement it - "should" or "must" will not have practical differences.

<npdoty> I'm not sure we're hearing agreement on should/must; I believe dsinger's last comment was that he was opposed to such a requirement

<Wileys> Ed, I believe the hopeful outcome is that self-regulatory groups mandate a fair and balanced DNT standard - moving out of "optional" and into "mandatory"

<Chris_IAB> efelton- will the FTC enforce the spec on non-compliant UAs IF the UA says they are DNT compliant?

dwainberg: appreciate dsinger's sentiment. 1) what UAs must do, what servers must do.

… the incentives and consequences are not equal on both sides

<vincent> Chris_IAB, it's not the first time that publishers ask/suggest to use another UA

… 2) what is the bigger impact on the user and ecosystem as a whole?

<Chris_IAB> vincent-- nor should it be our business to do this dirty work.

… after things we do for test implementation, it is difficult to roll back from "should" to "must"

mathias: this is not the only way to have a dialogue with the user - out of band + educate the users about different user agents.

<fielding> issue-137?

<trackbot> ISSUE-137 -- Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s) -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/137

… issue-137: to what extent should service providers reveal themselves

… basically data processors (in EU lingo)

<Chris_IAB> if its a "must", it must be a "must" on both sides; if it's a "should" it must be a "should" on both sides; if it's a "may" it must be a "may" on both sides-- what's good for the goose has to be good for the gander

… proposal from tom: status response for "s". Fielding disagrees with this

<Chris_IAB> this isn't a race to the bottom IF both sides agree to the same stipulations for compliance

… need to use decision by the chairs.

<fielding> SPs often not permitted (by contract) to reveal -- the first party can of course do what they want

dwainberg: is the outcome here dependent on anything in the compliance doc?

mathias: maybe

… compliance document: No independent use of data

Rigo: The service provider is a history thing. We have solved this many times

<justin> There are questions about mandated sioling by service provider, but either way I don't think it pertains to this particular issue. I think there is consensus on the processor model.

… when taken into the barebones version - you have processors who are visible to the tools, and those who are invisible.

… the ones that are visible, must be seen as service providers by the UA

<fielding> BTW, I would be happier if we used the same terms as EU or HIPAA rather than the overly used "service provider" which is not traditionally limited to siloing

… otherwise the UAs would treat them as third parties

<Chris_IAB> dsinger- gentlemen would agree that what's good for one party should also apply to both parties; that's fairplay my friend; if it's a "should" on the UA side, it should be a "should" for publishers too. But you seem to want inequity my friend?

peter: the compliance spec has a definition of service provider

… it at least possible have a signal like "first-party/s"

<justin> I disagree with rigo that there will be strong inherent incentives to list all service providers. That said, I don't think I see a need for a signal or list mandate.

<dsinger> chris_iab: no, I don't want inequity. There are aspects of the TPE on both ends that we probably need musts and shoulds around. I want to start deploying this, and learning, without sites and UAs ignoring or blocking each other over interpretations of shoulds and musts.

mathias: this discussion is about whether the s-flag should be mandated.

edfelten: this is "may" vs "must"

dwainberg: before we get to decision by the chairs, shouldn't we set this aside for later?

<aleecia> Rigo to the contrary. first parties are putting gag orders on their third parties.

<aleecia> There is not incentive to disclose. There a push for secret data flows and calling that DNT.

npdoty: Do we have the text of the two proposals to send to the chairs?

<fielding> No, we don't have agreement that it can be an option -- I don't want the "s" flag to be in the spec at all -- it doesn't make any sense to anyone with implementation experience on servers

mathias: proposal - between "1" and "3" there is an "s"

<rigo> aleecia, this is an even stronger contract that disallows the third party to treat the data as their own. And that's what we are talking about IMHO

<npdoty> it sounds like there is an action on dsinger to compile the alternative text, though it was assigned when he wasn't on the call so he didn't understand it yet

<aleecia> That's one part of what we're talking about but not the whole of it, Rigo.

dsinger: it should be possible for a service provider to claim that it is service provider for a specific first party.

<Chris_IAB> dsinger- I do sincerely appreciate your position, and I wish we lived in that kind of world; But do you see the guys from FTC and Article 29 sitting at the table? These guys, and lawyers for advocates, are here for a reason... They won't care about "gentleman agreements" made in words when we go to deployment. There is no "grace period" for experimentation-- I wish there were.

<Wileys> +q

… we used to have a qualifier; S-flag.

<npdoty> Chris_IAB, current text has a "!" response code for servers in order to provide easier experimentation

<aleecia> Yesterday there was a suggestion this could be solved with ephemeral aspects of data (Susan's point.) It seems unlikely to me -- e.g. analytics -- but it's worth exploring.

<schunter> This is the question whether to re-vive this "S" qualifier.

<aleecia> Roy's concern is Adobe's products being programmatically blocked

… we may have solved this problem by solving multiple first parties

<justin> Chris_IAB, and there is still an open question about how to deal directly with DNT:1 sprayers . . .

<fielding> So, we could change "first-party" to "data-controller" array

<Chris_IAB> npdoty- we can't take that kind of risk, not to mention that this is an IMPORTANT (paramount) issue for us, and should be for users. Am I the only user advocate here??

… how can you indicate that you provide a service to a first party that has consent

<Chris_IAB> Shouldn't users get what they deserve?

<Chris_IAB> Shouldn't it be absolutely clear what's going to happen for users?

<Chris_IAB> Isn't that what we all want?

<efelten> +1 to dsinger. We should give sites a way to convey this information if they want to.

<dsinger> so, should first_party be data_controller, and then can we use it in 6.6?

<aleecia> We should require disclosure, optional is too weak

<dsinger> roy, we are talking ONLY about HTTP endf-points. no-one else appears in the transactions

fielding: There are many service providers on any http-request. only way to comply is to send the "s" on every response.

<efelten> +1

… no reason for this header unless we want to discriminate service providers

<rigo> fielding, are you also against noting service providers in the tracking status file?

<aleecia> DNT was supposed to limit collection. It will not. DNT was supposed to limit retention times. As stands, it will not. DNT was supposed to provide transparency. Now we are hearing that too is not ok.

… from a technical standpoint this does not make any sense

<aleecia> What are we even doing here then.

<dsinger> roy, I'd really like it if you could address the 'apparent rogue first-party' point; you are refuting things no-one is saying

<aleecia> If users do not know who they are dealing with, this is a farce.

<fielding> dsinger, you are imaginging a definition that does not exist

<npdoty> Chris_IAB, separate from your questions about why the rest of us apparently don't care about users ;), if you think the explicit "!" non-compliant flag won't work for experimenting implementers, that's something we should discuss with fielding

<Chris_IAB> justin- I appreciate that we have that open issue, but as this is a so-called "voluntary" spec, certain UAs have already made it clear that they will do what they will do despite our spec. W3C will have no jurisdiction over them to change their behaviour.

<aleecia> Yes, ouch. I wish I were wrong.

ChrisPedigoOPA: Only reason to require an "s" is to possible discriminate against service providers that looks like a third party

<rigo> aleecia, roy is saying that every ISP that transports your packet is a service provider

<rvaneijk> Loosing transparancy is hugely problematic

<Chris_IAB> npdoty, sorry, but it does feel like folks are ignoring the best interests of users

<aleecia> and routers once before, which I was openly scornful of. I'm sorry I cannot hear well enough to follow this.

<ChrisPedigoOPA> transparency of what? the data is not going to be used outside of the first party.

<rigo> and you can't require TCP-level transparency for the world via DNT

<npdoty> as I understand it, aleecia wants MUST, dsinger wants MAY, fielding wants absolutely not

<wseltzer> schunter: I hear no one advocating for "must"

<ChrisPedigoOPA> We should require transparency about who controls the data collected

aleecia: can't contribute anything new, have made the points before

<dsinger> Roy, analytics sites that appear as distinct non-first-party http end-points. it should be *possible* for them to disambiguate that they are operating under the first-party's policies and rules. I *think* the first_party element of the WKR enables that. If true, we are done

… this is an issue that we come back to again and again

mathias: the way forward the three-way decision.

<aleecia> excuse me if anyone wanted an extended discussion -- restating seems like a waste of group time

<aleecia> but in the interest of sustained objection...

… sustained opposition for both proposals

dsinger: not sure if we have the question clear in front of us

… assume that we have other means for transparency

<fielding> dsinger, again, as the expert on HTTP, I can tell you without even a shred of doubt that there is no such thing as an HTTP endpoint --- there are domain owners and request routes, and both are subject to many service providers

<aleecia> routers are not under contract to 1st parties

<fielding> Tustin is bnot the bay area

<aleecia> they are by defn not SPs

mathias: dsinger - can you provide text
... next issue

<aleecia> Roy can we agree that ISPs and routers are by no means SPs due to not fulfilling the contractual agreement, and drop this line of disucssion

<dsinger> action on dsinger to sit with Roy, aleecia, and others and try to explain the *question*

<trackbot> Error finding 'on'. You can review and register nicknames at <http://www.w3.org/2011/tracking-protection/track/users>.

<aleecia> oh lovely -- cannot hear and got an action item :-)

<Chris_IAB> npdoty, I believe that there is a fundamental disconnect here: many folks think industry are not user advocates-- that couldn't be further from the truth. "Advocates" are not the only user advocates. I believe the user needs to have clear-cut and easy to understand options.

<aleecia> and yes, that's fine with me

<npdoty> action-357?

<trackbot> ACTION-357 -- David Singer to add service provider option text (with jmayer) as an issue in the draft with an option box -- due 2013-01-30 -- OPEN

<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/357

… ISSUE-187: New exceptions model makes sure that users wants an exception

<aleecia> perhaps efelten would like to join discussions on that action?

… current proposal: Push the exception to the UA, and display it somehow to the end-users

<efelten> I would be happy to join, if y'all think it would be helpful. I think I'm in about the same place as David on this issue.

<npdoty> I've updated action-357 with notes

<dsinger> roy, I am referring to the host that is the termination of the TCP connection over which HTTP flows. I think that may be 'server' in the terms of RFC 2616

… it seems that this is now the preferred solution for the whole group

<justin> chris_IAB, It sounds like you're going to ignore/reject those UAs anyway --- not sure why the exception mechanism which no one may end up using is the proxy for that discussion.

… but privacy advocates fear that sites will exploit this

… question is: Can all live with the new API?

npdoty: Explained some concerns on the mailing list. In particular if the user could not control what exceptions that were set

… this could decrease value for third parties

<fielding> dsinger, "origin server" -- AWS and Akamai are both examples of origin servers

<Chris_IAB> justin- I cannot answer that question on behalf of the 600+ member companies I represent; nor is it a fair question; we'd prefer for the spec to be clear, and fair. Doesn't that sound reasonable?

<aleecia> Dan @ EFF noted he supports Nick on this one, but could not make the call

… concern from jmayer: putting exception mechanism only through the sites could lead to a race to the bottom.

<Wileys> +q

<npdoty> npdoty: I think giving users/user agents flexibility is the key point

mathias: sort of independent from this mechanism. If this scenario happens, the UAs will crank up their effort.

shane: agree with mathias. other mechanisms than can resolve this

… we have changed the exception mechanism to favour good actors.

dsinger: we should improve the text a little without normative changes

… for example non-normative text on how to implement exceptions API

<npdoty> ... though I know that there is a concern about a "race to the bottom" in the consent mechanism, so I think it's fair to allow jmayer and others to express that and object

<npdoty> I'm willing to volunteer to write that text on user agent flexibility

mathias: way forward - send explicit confirmation email to the mailing list to confirm consensus.

<dsinger> I am willing to help write a section on programming 'best practices' for sites as well

<justin> chris_iab, Uh . . . sure, I want the spec to be clear and fair. You don't have to respond to my substantive points if you don't want to.

<npdoty> ACTION: doty to draft text for user agent flexibility on exceptions [recorded in http://www.w3.org/2013/02/13-dnt-minutes.html#action01]

<trackbot> Created ACTION-363 - Draft text for user agent flexibility on exceptions [on Nick Doty - due 2013-02-20].

<npdoty> ACTION: singer to draft section on best practices for sites requesting exceptions [recorded in http://www.w3.org/2013/02/13-dnt-minutes.html#action02]

<trackbot> Created ACTION-364 - Draft section on best practices for sites requesting exceptions [on David Singer - due 2013-02-20].

<dsinger> roy, yes, but no-one is going to claim 1st party privileges on a CDN, as you can't use a caching network or CDN for tracking

<fielding> dsinger, I am not sure why you think CDNs can't be used for tracking -- have you seen Akamai's ops displays?

<hefferjr> CDNs can also deliver detailed logs, with IP addresses and full URLs to websites

<fielding> dsinger, and yes, the other use case can be achieved with a "first-party" or "data-controller" array

<fielding> dsinger, though it depends on the first party being willing to list its SPs. Apple, for example, forbids it.

<fielding> dsinger, please poll the crowd on whether we should call it "first-party" or "data-controller"; I am fine with either one and see the advantage of the latter for domains that service a third party.

<dsinger> roy, sure I quite understand that there are circumstances where the other site cannot or will not reveal; OK, there may be ambiguities or misunderstandings as a result, but that's the natural consequence. I am NOT in favor of anything more than the *possibility* of transparency; no should, no must.

<dsinger> roy, cool, I will try to find a moment to ask that question. simply change the WKR first-party to data-controller (and consequent minor text changes)?

<fielding> dsinger, yes, though we may need to explain what a data controller is if the compliance document doesn't define it

<npdoty> ACTION: adrian to clarify behavior of the exception confirmation api [recorded in http://www.w3.org/2013/02/13-dnt-minutes.html#action03]

<trackbot> Created ACTION-365 - Clarify behavior of the exception confirmation api [on Adrian Bateman - due 2013-02-20].

<BerinSzoka> how soon are we restarting?

<wseltzer> [about to re-start]

<npdoty> issue-152?

<trackbot> ISSUE-152 -- User Agent Compliance: feedback for out-of-band consent -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/152

<npdoty> schunter: site sends an out-of-band consent signal

<npdoty> ... got consent independent of the protocol

<Chris_IAB> justin, sorry, I'm not trying to be trite, but I may have missed your "substantive points"

<Chris_IAB> justin, can you re-state please?

<npdoty> ... if the site sends "C", do we want to mandate that it be displayed by the UA?

<npdoty> ... Nick proposed not to mandate

<dsinger> as an aside, I have used the term "in band" to mean that you obtain consent, establish its existence using the API, and see it signalled using DNT:0; out of band means that you establish consent, remember it some other way, and claim it though you don't get a dnt:0

<npdoty> ... with the reasoning that user agents may choose to start displaying the consent if it starts to be widely used

<Wileys> +q

<fielding> AFAIK, it is not an interop requirement and so 2119 terms are not appropriate

<hwest> scribenick: hwest

<npdoty> thank you heather for scribing!

Wileys: Core issue for OOBC if OOBC is registered in the browser, that could give it greater transparency and potentially greater control from the user. I would say that a user MUST NEVER confirm OOBC

<fielding> OOB consent registered within the UA? Is that in the spec?

Wileys: because there's no reason to register OOBC with the UA
... never need to share that with the UA

<adrianba> http://lists.w3.org/Archives/Public/public-tracking/2013Feb/0050.html

Wileys: so sharing that with the UA was purposely set up to let user have consolidated view of the consents

<aleecia> :-)

schunter: three questions - does the site have OOBC? should OOBC be stored in the UA? are UAs permitted to display the OOBC?
... so if you receive the O signal do we mandate the UA to hide the signal or not?

npdoty: To calrify, the UA can't challenge the exception, but could potentially show it to the user

<aleecia> +1

dsinger: Point of terminology, have been using "inband consent" for signals through the UA/protocol, and out of band consent for stuff outside that
... site should be required to signal that they think they have consent, but who cares what hte UA does with that
... UA can basically turn into a debugging platform that signals everything if they want
... it's no more than a MAY

<efelten> +q

Wileys: There is no requirement for a website to convey that it has OOBC, that can be an internal process
... receive DNT1, confirms consent, ignores; don't think they're compelled to share that
... don't want to set up UAs challenging or giving negative dialog to the user

<fielding> The TSV has a C status for the purpose of conveying that it has OOB consent.

Wileys: want to drive good behavior and transparency, but not to set up scinario where previous actions is challenged or evaluated by UA

<aleecia> not following why sites with an exception wouldn't participate if users know about it -- users elected it

<justin> chris_iab, just that there's another place to have that fight

<adrianba> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#tracking-status-value

<aleecia> don't get this logical thread

<adrianba> "Consent: The designated resource believes it has received prior consent for tracking this user, user agent, or device, perhaps via some mechanism not defined by this specification, and that prior consent overrides the tracking preference expressed by this protocol."

npdoty: Current draft has had in there that tracking status resource will have C in it, has been MUST

<justin> how is this controversial?

dsinger: If you're tracking the user, you should say that in the interest of transparency

Wileys: Issue isn't transparency, it's what the UA can do with it

<justin> You can't give transparency to the user without also giving transparency to the UA.

<hefferjr> It may not be possible to look-up in real-time whether there is an out-of-band consent. That lookup might have to happen several hours later.

<dsinger> roy, right, so given it's possible to signal it, I don't know what we are discussing; transparency is acheived

<fielding> well, if you don't send C then the other choices are less good -- some response is required and sending a false response would be unfortunate

Wileys: UAs could convey the consent, but then does the user get upshed to rescind consent?
... just don't want UAs to be able to override it

npdoty: TSR has a control parameter to send the user back to the site

<Chris_IAB> justin, sorry, which "fight" are you talking about? I'm not here to fight with anyone-- I'm here to get a fair and reasonable DNT spec?

<aleecia> Roy++

schunter: Document some agreements here before we move on
... OOBC cannot be changed by the UA

dsinger: It can't logically, how could it

rigo: The first question is whetehr if we make an opt out mechanism for the US, that's what was in the news and the media. Now you have obtained consent for something and someone has changed their mind.

<scribe> ... new signal, now we can say "to obtain consent for tracking is very easy we have an interface for that, but to get out of consent you have to write a paper letter" is bad

<npdoty> agreed that the UA can't override out-of-band consent; the only thing it could do is to help the user go to the control path on the site

<Wileys> I'm fine with transparency (sending the signal) but I didn't want a UA to be able to override or somehow change that OoB Consent. For example, by deciding to send DNT:1 to a site even if it signals OOB consent (the site can continue to ignore of course but it was my hope that we're focusing on transparency here and not altering signals outside of OOB consent)

<dsinger> the UA cannot 'override' out of band consent, it's logically impossible.

<fielding> "a control member should be provided if the tracking status value indicates prior consent (C)"

UNKNOWN_SPEAKER: we could leave a large gray area of ??. We could just say that if someone comes in with DNT1 on OOBC, you say this is OOBC, overrides OOBC. B
... OOBC signal provides URI for changing consent, can also revoke there

<npdoty> fielding points out that the control member is "SHOULD" when out-of-band consent; that still seems reasonable to me

UNKNOWN_SPEAKER: or you can say that people can show OOBC but it's teasing, you can't change it

<Wileys> DSinger, UAs can start doing a host of negative things if they receive an OOB but they can already do that today so perhaps not worth the conversation.

UNKNOWN_SPEAKER: strange feeling if you have an opt mechnism that works and another mechanism that doesn't work

<fielding> TPE para above http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#dfn-control

<justin> WileyS, I think we're agreed here. The user needs to be able to have the choice to say, "wait, no, that never happened." The UA will make that information available to the user somehow but cannot somehow override consent unilaterally.

UNKNOWN_SPEAKER: ultimately OOBC signal should have URI to where consent can be revoked

schunter: OOBC has own mechanisms to get out of the consent

<hefferjr> The OOBC might be based on a signed contract, as with a panelist. I think that that kind of relationship needs to be allowed in the standard.

schunter: The site is who determines whether there is OOBC or not

<schunter> - Site is the sole owner

<schunter> and maintainer of OoB

<schunter> consent and determines

<schunter> its value based on its

<schunter> own preferences

<Wileys> Justin - great, that was my concern

<hefferjr> That cannot be rescinded by visiting a website.

<dsinger> Wileys: the site says "I have consent and so I am tracking". There is nothing the UA can do to alter that understanding or behavior on the site.

schunter: OOBC are not using exception API, because then they're inband by definition

efelten: Why are there two different exception mechanisms? Understand why we did before when IBC was handled UA side. But now we have two server side consent mechanisms, do we need both.
... why not just have them use the exception API?

dsinger: They fork after the consent

<Wileys> +q

<npdoty> I think there's less reason for "out-of-band" now, but still might be useful

efelten: if we're going to have both then we should think about some of these issues, like bad actor problems

<fielding> The answer is that the OOB consent is already implemented today, whereas the exception API is not

<justin> what fielding said.

dwainberg: Agree that's a good idea, scenario of concern is where the outcome of UA intervention discussion that has yet to take place

<dsinger> roy, right, thanks

dwainberg: if site says it has consent and doesn't feel it needs to ask user, is UA going tos ee that and intervene?
... that's a bad experience

efelten: Do need to deal with that, not sure we need to have the conversation twice

Wileys: Extension of where dsinger started. Movement towards this exception model may mean that there's really just one kind of exception, what we've been calling OOBC

<aleecia> any UA that says "you consented but nah, we don't like 'em so you don't any more" should be in serious serious trouble

<justin> I do not think we need to be prescriptive about how consent is obtained and intermediated. We don't know what will work.

Wileys: take the same tenets, that UA cannot manipulate that list, but can provide user with link to revokation if the want. MAYs from before would become mUST NOT.

ef

<aleecia> q+

<aleecia> (huh)

efelten: We have the same bad actor problem that we had before, what to do about bad actor that asserts consent but doesn't have it. Someone needs to be empowered to protect the user, should be UA.
... otherwise unclear how to stop bad actors from claiming bogus consent.

<justin> You could have a persistent choice for the user to block particular parties. That would not be the UA's choice.

efelten: want to know why the treatment is different in the two cases

adrianba: I think we have to have a signal for out of band consent, there is a distinction betweent he two
... one of the things we have in there now for exception API is that you should call the API at the time that the user gives consent
... should not randomly call the API later, because we allow that exception to be revoked
... also the scenario where user registers with a service, ask for exception at registration, and then when they reauth they are agreeing that they will be tracked and that consent is stored. It's not allowed that when they log in again they can call the API to re-register the exception

<Wileys> So OOB is retrospective, and in-band exceptions are real-time

adrianba: the reasons we came up with these two mechanisms still stand, I don't think we can get rid of them

<dsinger> this whole discussion doesn't persuade me we need any changes at all to the text

adrianba: On the specific ISSUE-152, the UA should not have a MUST there, UI here should be minimal

dwainberg: Said they don't re-call the API when user reauths?

<hefferjr> Yes, there will be cases where OOB exceptions have to be determined in non-real-time.

<npdoty> in addition to adrianba's points, non-JavaScript-calling entities are also able to get out-of-band consent without having an easy way to store it in the UA.

adrianba: I think that's true, because we want to allow somebody to be asked for consent for an exception, have that exception stored, and then tomorrow go in and say that they don't want it anymore.
... want that to be persistent
... otherwise revocation doesn't work

<fielding> I still don't understand why Wileys thinks the OOB consent would be "stored in the browser exception list" (in-band exceptions are not OOB)

efelten: I recognize that there's a difference between these scenarios, but still think there could be a single mechanism that merges a lot of the text and the mechanism in most ways

<aleecia> perhaps Ed could work on that as a proposal?

efelten: good to reduce text, mechanism, and discussion

<aleecia> sounds so much like offering to take an action… :->

<dsinger> let those who imagine better text, draft it!

<Wileys> Roy, it doesn't have to be but could be a better persistence mechanism than a cookie. Registration/authentication is a different model and would not require UA storage.

ChrisPedigoOPA: Questions - on the bad actor issue, if you have a publisher claiming consent, can't the FTC nail them for deceptive practice? Look at how they get consent?

efelten: If FTC can reach them, yes

ChrisPedigoOPA: I understand it's difficult to build two different mechanisms, but if there's concern that some browsers won't build that out, then need the alternative

<hefferjr> A true bad actor will just agree that it is not tracking you, and then track you.

efelten: Good points, questions are out there about what a unified mechanism would look like

<Wileys> +1 to hefferjr

<dsinger> I think we have a pretty good learning vehicle here for learning...

<fielding> Wileys, I would never use it -- persistence is less important than "works at all". If we want to explore that, then it should be specially-named cookies and not an API.

<justin> Good actor <---> bad actor is a continuum.

<aleecia> specifically-named cookies has appeal but fails in enough environments to worry me

<Wileys> Roy, is that an option within HTTP today? Or are you discussing a possible future option?

Brooks: May be a problemw ith current mechanism, exacerbated by OOBC, doesn't this create potential for someone who thinks they have OOBC and they're still seeing DNT1, what do you do?

dsinger: It should work that way

Brooks: I thought the OOBC goes to the UA so that the header is changed

npdoty: New exceptions model, server still communicates but UA stores OOBC
... OOBC allows you to ignore DNT1

Brooks: Thought Ed's proposal was to move everything into the API

schunter: Nope
... Way forward could be Site is sole owner and maintainer of OOBC

OOBC are not stored using API

<npdoty> does efelten want an action to propose an alternative combined proposal? and then we continue with this in the meantime.

Sites who have OOBC SHOULD say so

<fielding> Wileys, just agree on a cookie name like w3dnt and convince browsers that do implement this mechanism to keep it "more persistent"; other browsers will just treat it as a cookie.

scribe: Well known Resource SHOULD contain a URL to a place where OOBC can be modified/revoked/explained

<npdoty> I believe technically it's sites who have out of band consent MUST provide transparency (because any other response would be incorrect)

<efelten> +q

<hefferjr> Any other response would not be incorrect, if the standard says that that behavior is correct.

<Wileys> Roy, that's my concern - just treating something like a cookie means it'll churn at a high rate due to anti-spyware tools doing full cookie wipes on a regular basis

scribe: we can still find ways to merge mechanisms later

<aleecia> no, that's fine

<aleecia> thanks though

efelten: On your list, "sites who have OOBC SHOULD say so" - I'm wondering why that isn't must.

<npdoty> +1, I'm pretty sure it's (effectively) MUST

efelten: what would it send back if it didn't send OOBC?
... likely to lead to confusion

<schunter> "Sites who believe they have OoB

<schunter> consent SHOULD say so"

<Wileys> Agreed - if you're going to ignore a DNT:1, you should provide a transparent response (OOB, Non-Compliant UA, etc.)

fielding: No need for a MUST there because the only other choices would be complying with 1 or 3 or nothing at all
... benefit to the person who has consent
... may choose not to do any tracking and send back a 1 or 3

<npdoty> agreed.

fielding: Do require a response to be sent back

efelten: So if they use OOBC to do something outside the 3 rule, then they MUST send that back

<aleecia> any reason not to have must?

fielding: It's in their direct benefit to do so, if they don't, then they're lying. Don't see the need for a separate MUST.

schunter: Seems we agree in principle - lying isn't ok, and if you leverage your OOBC you should say so

<justin> Why not MUST?

Wileys: We already have the MUST on providing the response

<npdoty> our tendency to use the english "should" when we might be talking about rfc2119 "SHOULD" causes us confusion

<fielding> to be clear, responding "3" means that you are constraining behavior to that allowed by a third-party under TCS

Wileys: if you must always provide a response, then as long as you must be truthful in the response, don't need a new MUST

<Wileys> Heather - agreed

dsinger: Any changes to the text?

schunter: Nope!

<dsinger> issue-152?

<trackbot> ISSUE-152 -- User Agent Compliance: feedback for out-of-band consent -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/152

dsinger: Is the UA required to do anything? We're going to be silent on that.

hefferjr: Have a problem wiht OOBC being detected in rel time, technically difficult sometimes
... Maybe 90k panelists with side contracts, hard to revoke or detect on a CDN in real time

<aleecia> ouch.

schunter: Noted.

<justin> How do you know whether you can track a panelist or not?

schunter: Seem to agree that UAs MAY display OOBC and are not required to.

<hefferjr> You figure out "as soon as possible" which data you are allowed to use for which purposes.

Wileys: To the bigger issue of the MUST on the response, I think hefferjr brings up a very good point on the MUST response. How do you deal with the delay scenario?

<hefferjr> That might take minutes or hours.

Wileys: you MUST give a truthful response, but can't discover the truth untl later. It's a valid use case that draws questions into this issue.
... Recc addressing this in non-norm text in status response section.

<hefferjr> The truthful response is that I will follow the DNT spec. That may include tracking, if I have an OOBC.

<fielding> "too bad"

<fielding> not hearing

<hefferjr> poor audio on Matthias

<justin> So Nielsen in real time cannot tell DNT:1 users in real time how they are going to be treating them?

Wileys: Are we creating a new "I might have OOBC" status?

<hefferjr> You say that I will obey the DNT standard.

<justin> How can a user trust the ecosystem?

dsinger: What do I say to the user? If I say 3, that's a lie, if I say C, then that freaks out users who didn't consent

<justin> Ah.

rvaneijk: Think this is an excellent thing to put in the complaince doc

Wileys: Only reason to do in TPE is if it needs a new status code

<aleecia> How does compliance solve this?

<aleecia> I don't see moving it as useful

<justin> But how does the user find out about the fact that Nielsen thinks they have an exception to track?

schunter: So we've solved issue-152

<aleecia> (silence)

<hefferjr> The users who would be tracked in that case would know because they already signed contracts with Nielsen.

<vinay> Those on the phone can't hear whoever is speaking

schunter: Ok, going to drop ISSUE 164 for now and go to ISSUE 161

<fielding> issue-161?

<trackbot> ISSUE-161 -- Do we need a tracking status value for partial compliance or rejecting DNT? -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/161

<hefferjr> yes, thx

schunter: drop/skip for lack of time

<aleecia> I wonder if Neislen might set a cookie of "this is one of our panelists" that they read and send back they have OOBC

<Wileys> +q

<justin> Yeah, but that sets up a scenario where parties get "consent" under dodgy circumstances and users can't ever figure out who is claiming an exception. That result is untenable.

schunter: for ISSUE-161, partial compliance status value

<hefferjr> cookies get cleared, a lot

<dsinger> there are two questions in 161: 'not yet in compliance' (!), and "I am not listening to you"

<aleecia> Not sure how else to handle it, though

Wileys: I don't think JonathanM is on

<justin> Or a plugin for your panelists. But not messaging to users an allegation of OOB consent is extraordinarily problematic.

<vincent> +1 to justin

<hefferjr> If I have a signed contract with a user, and then track that user, the FTC really should not have a problem with that behavior.

<aleecia> That is: I agree cookies get cleared a lot. And I agree this is a very interesting use case. I'm in "now what?" mode

<fielding> The only concern was jmayer's wish to limit it to testing. I disagree that there is a need to limit it in that way, at least in TPE.

Wileys: He wanted to get assurance that ! cannot be used as a general punt on DNT

<justin> Depends on the contract. Sears had a contract to track users too.

Wileys: Second part of question in the issue, do think we'll need a new status code with a reference URI for those cases where a site or server is not in agreement with UA

<hefferjr> As long as we promise to follow the DNT spec, and then we do, I don't see that as a problem.

Wileys: Can provide full transparency back, and UA can choose to show that to the user, but server has fulfilled transparency obligation

<aleecia> The question is how to craft the spec, or your work flow, to match.

<aleecia> We're dealing with how to handle when companies don't know if they're first or third parties in real time, too

<npdoty> hefferjr, I think the concern is that you wouldn't be following the part of the DNT spec that requires you to tell users what you're doing at that time

<aleecia> I'm noticing that problem is harder than I'd been thinking of it as being.

<justin> Users need an automated means to figure out who is claiming an OOB exception. Not have to sift through the fine print of every TOS she agrees to.

schunter: If server cannot comply, if cannot satisfy these requests may need to say "I hear your signal but cannoy satisfy your demands at this point"

<hefferjr> If the spec limits what is allowed to be done with a user's data, and that behavior is followed (including being superseded by a legal contract), then the purpose of DNT is satisfied, IMHO.

<Zakim> dsinger, you wanted to say that there is a logical contradiction on putting conformance requirements on !, which is used

dsinger: If the end of year redux I dropped something very simple along those lines. Saying "I'm not listening, for whatever reason"

<aleecia> actually, no, you cannot contract around DNT.

dsinger: maybe should put that together

<justin> Transparency about who is claiming an OOB consent is necessary.

<hefferjr> you can if the DNT spec says that you can.

<aleecia> this is a long standing point of discussion. Finishing out the current contracts, yes

dsinger: Problem with the way ! is currently documented, because not claiming conformance but includes MUST
... not claiming conformance!

<aleecia> the point being, the spec does not say you can

<fielding> oh, sorry, was I talking about a different issue again? The ! status does not include rejecting

schunter: David will clarify that text

dsinger: Let's just delete it

<aleecia> so far so good, Nick

<hefferjr> it does if we write it that way. I think we need to write it that way.

<fielding> dsinger, I already explained that on list

dwainberg: Text is on my plate

schunter: Oppositions to following this transparency mechamism?
... Will ask again when we have text

<aleecia> zug...

<vincent> hefferjr, how would you know that the user using the computer is aware that he's been tracked?

<hefferjr> That depends on the text of the contract. As long as the person who signs the contract is responsible for restricting access to their equipment, this is not a problem.

fielding: Unclear. If we're talking about !, the reason the MUST is there is that otherwise then there's no reason to send status back. No contradiction to have that htere.

<hefferjr> It is a task for us to implement the controls to make sure that we are legal.

schunter: If you claim to be noncompliant, you MUST send !, but then all bets are off

<aleecia> we have a few assumptions here: (1) the person using the device signed the contract, (2) the person who signed the contract remembers that, potentially up to years later

<npdoty> ACTION: singer to draft text on another non-compliant/ignoring the expressed preference (by suggestion of WileyS) [recorded in http://www.w3.org/2013/02/13-dnt-minutes.html#action04]

schunter: fielding, take a look once we have text

<trackbot> Created ACTION-366 - Draft text on another non-compliant/ignoring the expressed preference (by suggestion of WileyS) [on David Singer - due 2013-02-20].

fielding: It's not a contradition

<npdoty> compliance with the TPE's syntax but not indicating compliance with the Tracking Compliance and Scope

<hefferjr> If you sign a contract and then forget about it, that does not mean that you get legal protection for having forgotten that you signed a contract.

dwainberg: If the site is not sending back any status, then there's no need to communicate anything about it. If site is communicating, that the site doesn't want to be trusted. Nothing else needs to go with that.

<aleecia> agree this is a real problem. trying to figure out how to get Neilson what they need without toasting DNT for everyone else

fielding: No signal necessary then.

<aleecia> the point - signing a contract != transparency to users

fielding: Let's not waste badnwidth on signals that mean don't trust me

<hefferjr> This problem is bigger than just Nielsen. One way to address this is with a limited market research exception.

dwainberg: If you're sending a response about testing, then you need an indication that it should not be trusted

<aleecia> and we cannot guarantee the device user is the contract signer

schunter: Let's take this offline

<Wileys> +q

<aleecia> question: how would Neilsen determine OoBC at a later time?

<hefferjr> BTW, panelists are not a "fire and forget" operation where data is just collected for years.

<aleecia> ok, we've heard "up to 5 years" from another WG member

fielding: No hardship here, no reason to object to this at all

<jeffwilson> you cant send nothing due to the "statement" in the privacy policy that says you comply with dnt, yes?

<Wileys> Two choices for an operator: do I send no signal at all or still send a signal with an "!" in the status repsonse.

<hefferjr> There are technical ways including cookies, IP addresses, etc.

<aleecia> yes, DNT needs an ack

<fielding> why?

<aleecia> so all of those sounds like real-time measures, including fingerprinting

dwainberg: Yes, need !, but arguing against the additional requirements

<hefferjr> Some panelists might have software installed on their computers to send usage information that allows tying other information back together.

<npdoty> dwainberg, your concern is that you want to send "!" and not fill out the first-party member?

<dsinger> I think Roy is arguing conformance with TPE but not yet compliance with compliance, whereas the rest of us are thinking we're not claiming either conformance with TPE or compliance

Proposed Resolutions

<npdoty> issue-112?

<trackbot> ISSUE-112 -- How are sub-domains handled for site-specific exceptions? -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/112

schunter: Issue-102
... Let's hear adrianba's proposal

Oops, ISSUE-112

<aleecia> david, that wins for most obfuscated statement to those outside the context of the discussion. beats out Ed's "this should be a must" from last hour

<fielding> dsinger, yes, because we cannot allow an invalid/malformed response and hence we need the syntax requirements

<hefferjr> If a "pinger" hits Nielsen every 5-minutes to indicated a panelists IP address, that information cannot be propogated to the data collection nodes for web surfing that are collecting a billion hits per day. Even if the info could be propogated, the data collection nodes could not look up in real-time through a list of 90k IP addresses.

adrianba: So question is how exception API works with sites that are within the same domain but may use multiple host names.

<aleecia> then it sounds like you have a real problem here

adrianba: principle is that people shouldn't have to choose between different tech based on capabilities. Could use a cookie to store OOBC, but it's not as persistent.
... Or couse use exception API, but doesn't allow storage for subdomains.

<justin> I'm sure there's a reason, but why can't you store through the API.

adrianba: Eliminate that, should make the capabilites of exception API match those for cookies.

<hefferjr> if the spec is written in a way as to make business processes un-workable, yes, that is a problem. we don't have to write the spec that way.

<moneill2> q

adrianba: Should be an additional domain arguement for site specific and web wide exception
... Omit domain and it'll just be for current domain. Provide it, and then works according to domain argument for cookie. Can set for any domain up to and not including public suffix.

<aleecia> an absence of an ack breaks the basic structure of DNT as designed.

adrianba: Works just like a cookie.
... I want this to explicitly refer to the cookie rules so that exceptions change if cookies change.
... As an implementer can call same code as for cookies and know it will work.

<dsinger> add argument: "domain". If omitted, we use the document origin, and the database match is an exact match. If provided, it must work like a cookie (i.e. non-public-suffix of the document origin), AND the database matching is now for that domain and all sub-domains.

<hefferjr> i don't see why that is true. if the ack is a promise to follow the spec, that doesn't mean that the ack has to contain an answer to be determined later.

<vincent> hefferjr, so you would track every person using this IP address during these 5 minutes?

moneill2: If we take the domain and host aspect of a cookie, can also apply expiry date and secure and other pieces of HTTP cookie protocol
... When you gate DNT 0 you say how long it lasts for

<hefferjr> would we "track" them? no. would we collect data that could be used to track people? yes. but we have to collect that same data for fraud prevention, anyway.

<adrianba> sounds like a great feature request for v2

schunter: Create issue, it's a valid question

<aleecia> or you could decide DNT is incompatible with your business model and not implement

schunter: table this for now

<npdoty> issue: should exceptions have expiry date, secure flag or other cookie-like attributes?

<trackbot> Created ISSUE-192 - Should exceptions have expiry date, secure flag or other cookie-like attributes?; please complete additional details at <http://www.w3.org/2011/tracking-protection/track/issues/192/edit>.

<aleecia> but perhaps there's some other solution

<justin> The standard is unbalanced if the user does not have scalable visibility into who is asserting permission to track despite a DNT:1 signal.

npdoty: One common use case might be third party asking for web wide exception

<hefferjr> that is possible. a market research exception would be one way around this.

npdoty: want that to include subdomains so that you continue to silo cookies by domain

<aleecia> and an exception for all advertising would "solve" many things too, but...

npdoty: Is there any need for this outside asking for WWE/
... i proposed solution including subdomain parameter on requests, wouldn't need to otherwise change scope

<hefferjr> the market research exception could require that all data be turned into gross aggregate data before it is used operationally or delivered to another party.

dsinger: Don't think the dominant use case is WWE. It's for SSE. You have a whole bunch of associated primary sites, want it to work on all those properties.

<justin> But would still allow for unfettered retention on an individualized basis, hence the original decision to strike from the std.

dsinger: What adrianba proposes fixes that. Not complicated to implement.

<aleecia> not seeing how that would be acceptable but we should keep thinking / talking

<aleecia> going to mull this for a bit

<hefferjr> there will be collection and retention for fraud purposes and other allowed uses, so there is no "extra" collection or retention for research.

<justin> But we are reopening that discussion to try to see if it's possible to allow for a narrower market research operational exception.

rvaneijk: One concern - if you have different subdomains that provide different services under different terms, then the * cannot imply consent over all these services.

<aleecia> agree that anyone who has consented to market research should be able to participate in that, but those who do not, should not have their data collected while under DNT

schunter: Only do * if you know consent covers all the domains.

<hefferjr> I will be interested in following that discussion.

<aleecia> that's not how permitted uses work

schunter: moneill2 is addressing problem where API pushes exceptions into UA. UA plays it back, doesn't know how old it was.

<aleecia> may be useful to ask you to read the minutes from a meeting on this topic two (or so?) meetings back

<justin> Fraud is allowed because it is strictly necessary for the web to work.

<dsinger> …lost. we seem to have changed subject

schunter: No way to revalidate the consent periodically

<aleecia> we went through the "we already collected the data" discussion at length and reached agreement

<dsinger> …do we do the 'domain' parameter as proposed, or not?

schunter: Do sites need that?

adrianba: Great future feature request

<aleecia> :-)

schunter: We'll get text and look at it

<hefferjr> If you are collecting for fraud detection, then doing research analysis does not create any extra risk or harm as long as the data is only what was already collected.

npdoty: I would present an alternative

<aleecia> i keep doing the "fraud" as short-hand for "anti-fraud measures" too.

<aleecia> ok: that's not how we're viewing this

<dsinger> ok, editors to work with Adrian to integrate the said 'domain' parameter for the exceptions calls

<hefferjr> I have been following and attending meetings. perhaps I missed one?

<npdoty> nick to follow up with adrian within the hour, regarding cookie-like rules for exceptions

<aleecia> there have been decisions already made here

schunter: For timing issue, should open a new issue. Either should provide expiration date or register initial storage date.

<vincent> hefferjr, as aleecia said, this has been discussed many times already

<aleecia> going to go see what i can quickly find in minutes

Wileys: If you take into account that users can remove exceptions, then is this as big an issue?

<hefferjr> thanks.

<vincent> hefferjr, I'm sure that it has been discussed in DC, many other time as well

<npdoty> I'm fine with postponing

<moneill2> q

Brooks: If we're using this to maintain state, then might have lost state. Only place is in the mechanism, so reasking the question is a difficult prop

<aleecia> vincent i think it was Bellevue? 2nd day? does that sound right?

<dsinger> issue-167?

<trackbot> ISSUE-167 -- Multiple site exceptions -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/167

<dsinger> issue-111?

<trackbot> ISSUE-111 -- Signaling state/existence of site-specific exceptions -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/111

schunter: Pushing ISSUE 167

<justin> Yes, Ian and I floated it in Bellevue and I do not think it was well received.

schunter: so for ISSUE 111

<hefferjr> I was minimally engaged back then, only as a backup for Alex Deliyannis. I will try to brush up on those minutes. Thanks.

<vincent> aleecia, might be that, I confuse both f2f meetings, sorry

schunter: Should sites know whether it's a general or specific preference?

<aleecia> thanks, will take a look

<aleecia> http://www.w3.org/2012/06/21-dnt-minutes

<aleecia> will try to narrow that down to something grep-able

dsinger: At the moment if you receive a DNT0, you don't know whether it's the user's pref or a registered exception. Might be useful to distinguish them, trivial to do so.

<fielding> can't hear

schunter: In Europe, explicit exceptions are stronger than general preference, so may be helpful to know

npdoty: Don't see a reason for this.

<moneill2> q

dsinger: How does first party know what is sent to third party? Query API.

<aleecia> likely after "Post-Breakouts" still looking

dsinger: API is more precise

Wileys: Caveat is if WWE and SSE are requested. Don't know which you got, could matter if yo uhave WWE but your third parties aren't getting 0

<aleecia> discussion starts here: "aggregate reporting" on the url pasted, http://www.w3.org/2012/06/21-dnt-minutes

<hefferjr> Got it. Thanks.

Wileys: Getting a 0 with an s or w would be helpful in that case, but may not be competely necessary
... you can inference it, but need to test two conditions for that

<aleecia> and thanks to Nick for getting all of the minutes up

moneill2: Other than just an e, could put in domain that initiated the exception
... helpful for accidentally set exception

<npdoty> I believe you can use dsinger's confirm API methods to know what kind of exceptions you have

<npdoty> +1 on minimal

schunter: Want to keep headers minimal. Additional info goes in query API.

efelten: One thing to make UA remember it, another to send it over the wire everytime

adrianba: Issue with this exception API is that we have to process through the exception rules
... for every single network request made
... has a performance hit
... want API to allow fast exit out of this check

<fielding> FTR, if we consider changing the request header then it would be "DNT: E" (not DNT: 0e). There is no need to retain the 0 and no deployed practice of 0. And then we could discuss "DNT: A" and postpone LC for a few years.

<fielding> Matthias, please grab a mic

<schunter> ok

schunter: So does anyone want the e?

dsinger: Add it later if we need it

<npdoty> both simpler and faster (for implementers) to send 0?

schunter: Use query API for additional info

<npdoty> all fine with not sending an "e", just a "0" when exceptions.

schunter: ISSUE-111 is closed, no E.
... ISSUE-167 is something where we have discussion

<dsinger> issue-167?

<trackbot> ISSUE-167 -- Multiple site exceptions -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/167

schunter: question is who has SSE, you have many domains, you want to register SSE for all your domains
... similar discussion for WWE, saying that claims WWE for many, open iframe as solution
... same question for SSW

<Wileys> +q

<Wileys> +q

schunter: solution is to cycle through iframes, but that's not a scalable solution
... from a privacy perspective, unclear whether that site actually has control over the other sites

<efelten> +q

<aleecia> silence

Wileys: So we've looked at this. Difficulty with iframes i taht we have page load issues as well as persistence of state issues within a page on a web browser. UA is not limited by these issues.

<aleecia> haven't been able to follow for a while

<aleecia> yes!

<fielding> yes

On the phone - all the portable mics are dead

<aleecia> thanks

<dsinger> can you hear shane now?

<fielding> yes

<vincent> yes

Wileys: Page load issues, esp if you open a hundred iframes in the middle of the UX. State handling within those iframes is an issue too.
... as I'm opening those, page load and experience will suffer.

<moneill2> q

Wileys: I may not execute the exception without knowledge of state/before execution of domain requests is done. That could be a never ending cycle.

<rigo> hwest, I was testing the mobile micro to tone it down

Wileys: Only resolution is to halt user's experience until process is done
... UA on the other hand can do this as the user moves through experience
... Go with well known resource, store known domains there - dupe for every domain on the list to enable cross-checking.
... Allows interrogation outside the UA
... Self-reg, advocates, regulators could look at that
... iframe doesn't provide that
... iframes works for a small number of domains, but lots of folks with many brands that will be a problem and drive them not to implement DNT if tehy can't do exceptions in a way that's good for UX

<aleecia> (suggest wildcards and inclusion and exclusion as well when we get to implementation details)

<Zakim> npdoty, you wanted to clarify that the multiple iframes would only be needed during the consent process, not in general, right?

<efelten> -q

npdoty: Clarify - multiple iframes experience would just be during exception process, not during page loads

Wileys: Could be during page load to verify consent from OOBC

<dsinger> but OOBC doesn't use the API, so it doesn't matter

rvaneijk: So in order to discover what subsites requested for exception, use WK-URI that is updated as needed. QUestion becomes how to revoke some or more of the subsites from an exception.

schunter: WKResource has this field, called it once. I think whether user can reject certain entries is a different question.

Wileys: Could be up to the site.
... Race conditions may push people to OOBC, trying to keep it away from that.

schunter: Take this offline.

<npdoty> npdoty: but according to adrianba's just described model, sites shouldn't be setting exceptions on every page load, only at the time consent is achieved

rvaneijk: Relates back to early concern about subsites tied to different services.

Wileys: That's for SSE not WWE, but UAs have come back and said that they were not going to implement explicit exceptions

<vincent> not sure mozilla said that, did they?

schunter: Had disucssion about wildcard SSE versus listed SSE

<npdoty> I think rvaneijk is suggesting the case that I could allow a site-wide exception on yahoo.com and not also allow the exception on flickr.com

<npdoty> there's no doubt that those affiliated domains are a part of the same first-party

<npdoty> ... but you don't have to grant exceptions to an entire first party

<fielding> FTR, I still think we are wasting our time with the exception model -- the notion that any of this will be implemented sufficiently on UAs to remove the need for out of band mechanisms just isn't consistent with any of my past experience with HTTP extensions. We would be far better off defining a simple named cookie mechanism with opt-in semantics that override a sent DNT: 1

Wileys: So saying that those two domains are part of the same party, is useful. This is explaining the breadth of the first party. This is good transparency, users can't say that you're not allowed to be irst party.

schunter: In current spec, users can change after the fact which domains

<aleecia> (as a note: that's not at consensus in the compliance doc, but it's how i'd bet)

schunter: which is not to say it's the right thing

Wileys: It's a MAY

<npdoty> it's not a question of a user claiming that Flickr isn't part of Yahoo!, but can decide whether to allow exceptions separately on flickr.com and yahoo.com

<dsinger> it is a technical issue, yes; the code has to run on (easily) machine-testable questions

<rvaneijk> Concern stays that if this plays out in practice that a user may have to accept all services of the first party, instead of having the ability to sign service-by-service.

<aleecia> (basically, Jonathan et al were willing to go down this path if they could get other agreements that they did not get. As the stack pops, we may see more disagreements raised. Shane's proposal could help smooth that.)

<dsinger> and 'seems to be a part of the first-party' is hard to check; cross-check the same-party arrays.

<npdoty> we would also need to parameterize the storeException method to choose whether or not to include everything in the same party

schunter: Current API does exception on per-domain basis, want to lift to first party basis which means you need to know first party

moneill2: There is an alternative to iframes, have one shared iframe that passes POST/cross domain signals.

<aleecia> we're scoped to iFrame or not?

<aleecia> if so, don't want to derail the conversation

npdoty: I think you have to call the method from within the iframe to get that

dsinger: The problem comes with parties that have a large number of otherwise unrelated site names

<npdoty> I think you need a separate iframe for each domain that wants a separate exception (under the current model)

dsinger: Not a good solution to this no matter what we do.

<moneill2> you can have a single shared iframe and use postMessage to signal consent

<npdoty> how long do we think it would take to make this many calls on a modern browser, say, for the largest first party?

<npdoty> 500 milliseconds?

<Wileys> +q

dsinger: Do you need to ask for all 2000 right now, or can you stage it on an as-needed basis?
... solutions here are worse than the disease

<aleecia> Getting little of this. But rather than foo.example.com, bar.example.com, suggest *.example.com with an ability to do -baz.example.com

ChrisPedigoOPA: Enormous list for members to maintain, and it's constantly changing. Having different lists in different places is bad.

npdoty: In either solution, a list change would needa re-call

Wileys: Stepwise approach is not great, not helpfu. Better to get all exceptions registered at the same time. Depending on how consent is structured, will need to figure out how to convey to UA that new domain is added.
... Still a valid part of first party

<dsinger> out-of-band consent is a solution here; the party doesn't use the exception mechanism to remember consent, but propagates it using their own means to all '1000' unrelated host names

dwainberg: This is the case where misuse might be easy, but I don't think that translates to common. Don't overburden good actors to address rare edge cases that are easily discoverable.

adrianba: I don't think it's easily discoverable, trying to prevent accidental drive by visit to evil.com setting SWE
... for top 5000 websites on the web in a way that devalues DNT
... Then they get a 0 they havne't been granted, and they don't know whether that's legit

<npdoty> how common is it to have a consent mechanism spread across hundreds or thousands of domains?

dwainberg: What's the motivation?

adrianba: Devalues DNT
... one of the flows we expect is that site uplls confirm API to determine whether they have exception, if no, then call the store
... How does the confirm API work if you can set it all over?
... Can't ask for it all over.
... If there's an alternative proposal for doing this across domains, need to see the proposal. Talking aout it not helpful.

<schunter> aleecia?

<aleecia> hi

<npdoty> adrianba: think there may be problems with confirm and remove

<schunter> your next.

<aleecia> would like to explain compliance history

<aleecia> thanks

adrianba: Is it necessary to solve for this case immediately or is this a progressive enahncement we could do? Also concerned about cost of implementation.

<dsinger> so, I create a spam/virus/whatever that encourages many many people to visit a transient site that sets up an exception for my buddy's site, and he benefits and gives me a kickback. My site evaporates after a while, but the exceptions last forever, and now all the UA knows is that it has records for evil.com and benefit.com, but evil.com seems permanently down. I am sure there are other abuse possibilities, alas.

aleecia: So there are three points to make here, why we went down the path we did in compliance spec.
... Long long ago, we talked about how companies might not always be images-example.com as well as images.example.com
... Wanted a way to say "this is all em"
... and sometimes thirdparty.example.com is not actually example.com
... So needed a way to say "this is me and that is not"
... Solve in compliance by determining edges at company level rather than by browsers

<rigo> I think that false first party declarations engage those who make them

<dsinger> carry on

aleecia: Some policies for P3P made it hard to have multiple high level domains and they coudn't link them. Broke the model.
... Third point, mitigates some problems, just support wildcards

<rigo> fixed in P3P 1.1 by our honrable co-chair

<schunter> wildcards are suppported

<npdoty> I believe adrianba's cookie model would help with that, even though i don't like it much

<aleecia> thanks, Heather

<aleecia> the echo was pretty bad on my side

<rigo> bye all, I have to run to the next meeting!

<aleecia> take care, rigo

schunter: Leave spec as it is with iframes and get some real world experience, wait for compliance spec.

<aleecia> made me speak more slowly and clearly - maybe that's not a harm :-)

schunter: better to have limited API than none at all

<dsinger> iFrames (for small numbers) or out of band consent (relayed between the large number of sites in some out of band way), or staged requests (a few dozen at a time);

schunter: open issue on correctly reflecting party context in TPE
... we'll iterate as we learn

<npdoty> do we like this issu: how to extend exceptions to the multi-domain breadth of a first party?

Wileys: Concern is that you remove some of your largest online players with this approach

rigo: Alternative is the cookie popups for cookies, let's just try it out.

Wileys: Disagree with that. This isn't a try it out.
... This is the fail fast concept, which I do appricaite in dev. Not sure about it in standards. Don't rush something out for testing. How long to the next version, how long will other players have to wait for the next version?

<aleecia> [Looking ahead and out of turn - please announce if we'll have the standing meeting on 20 Feb or if that's canceled. Assuming yes?]

Wileys: adrianba has the converse pressure, how long it'll take him to get this into the next version of IE. Don't want to take another month.
... We see what the complexities and costs are, want to think on it to see if there's a path in the middle.
... don't want to take too long.

<dsinger> I am willing to struggle with this issue, but I don't see something that seems reasonable to change right now

Wileys: Should move forward with the purpose of completion, not haste.

schunter: Alternative is a public draft version, adrianba implements, and we continue this discussion

Wileys: He could do that anytime anyway

adrianba: If we believe that the capabilities that Wileys is asking for are additive to the current proposal, then I'm ok with that.

Wileys: Sure

adrianba: But I couldn't have done this at any time if the spec is in flux

<dsinger> we can always add a new API "StoreMultiSiteException"

Wileys: Even within the spec there are options, but that could be appropriate.

schunter: With this dictionary type, can you add parameters without destroying the API?

adrianba: Yes.

schunter: So new parameters don't break things? Good. Then we'll do a public draft, you'll implement, and we'll try to stay compatible.

<BerinSzoka> it's a bit hard to hear Matthias on the phone

<aleecia> Berin++

schunter: We're a bit over time, but would like to push, may need additions to the spec. Early warning that there may be changes from Global Considerations, but that's not for here

<aleecia> would love date / time final for the GC mtg

schunter: Confident that adrianba can go implement

<aleecia> er, data / location

adrianba: There's some work for DavidS, Nick, and I to make the text reflect our converstaion, but I think the decisions are made.

<aleecia> date, even. sheesh

<fielding> meetings need to be announced on list, please

<BerinSzoka> SPEAK UP, PLEASE

schunter: Snapshot/PWG end of the month.

<npdoty> I'd be all for publishing another public working draft this month, with these changes

schunter: Overall, productive meeting with progress made. Not done, but we're getting there.
... as usual, thank you for being civil and maintaining decorum!

<aleecia> safe travels all

schunter: Global Considerations will be Berlin in March
... Next general meeting?

<fielding> it is already mid February!

<aleecia> Berlin, cool. march dates fixed?

schunter: Probably late April meeting.

<aleecia> next f2f late april

<aleecia> Do we have Berlin dates final?

<justin> March 11-12 I think, should be announced shortly.

<aleecia> thanks -- great. DC to Berlin works as well as anything can.

And, adjourned!

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Likewuse/Likewise/
Succeeded: s/dwaingberg/dwainberg/
Succeeded: s/tenents/tenets/
Succeeded: s/??/adrianba/
Found ScribeNick: npdoty
Found ScribeNick: haakonfb1
Found ScribeNick: hwest
Inferring Scribes: npdoty, haakonfb1, hwest
Scribes: npdoty, haakonfb1, hwest
ScribeNicks: npdoty, haakonfb1, hwest

WARNING: No "Present: ... " found!
Possibly Present: Aleecia BerinSzoka BillScannell BillScannell_ Brooks Chapell ChrisPedigoOPA David_MacMillan First Joanne Justin MIT-Star Rigo Rob Set-DNT-Exception Thomas_Schauf WaltM_Comcast Wileys Yianni aaaa aabb aacc adrianba bryan chris chris_iab dnt dsinger dwainberg edfelten efelten fielding fwagner haakonfb haakonfb1 hefferjr hwest ionel is issue jeffwilson joined kulick kulick_ left marc_ mathias matthias moneill2 npdoty ok perhaps peter peterswire robsherman rvaneijk schunter scribenick shane susanisrael thomas tlr trackbot ts_ vinay vincent wseltzer
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

Guessing minutes URL: http://www.w3.org/2013/02/13-dnt-minutes.html
People with action items: adrian doty singer

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)