Tracking Protection Working Group Teleconference

24 Apr 2013


See also: IRC log


kulick, schunter, +1.609.258.aaaa, eberkower, npdoty, +1.202.347.aabb, Fielding, rvaneijk, Aleecia, +1.202.326.aacc, WaltM_Comcast, prestia, paulohm, hwest, +1.916.641.aadd, hefferjr, RichardWeaver, sidstamm, Joanne, Rigo, [Microsoft], WileyS, Peder_Magee, David_MacMillan, Chris_IAB, JeffWilson, Dan_Auerbach, +1.781.482.aaee, samsilberman, Jonathan_Mayer, [FTC], Chapell, Brooks, BerinSzoka, moneill2


<trackbot> Date: 24 April 2013

<aleecia> (took a few tries to join)

<paulohm> Zakim aacc is paulohm

<aleecia> I can scribe but not talk much


<npdoty> scribenick: kulick

<npdoty> agenda: http://www.w3.org/mid/5176909E.7040407@schunter.org

<aleecia> (even better!)

schunter: TPE call only today

<npdoty> yes, thanks kulick! yay for volunteers

schunter: let's get started on discussed

TPE working draft

<Joanne> Zakim aadd is Joanne

schunter: if you have more points to discuss please send to group

<aleecia> request: please send the diffs and a deadline for comments to the non-discussion mailing list. Seems like exactly what it's for.

<npdoty> required, and, roughly every 3 months

schunter: must publish working draft every 8 weeks/2 months, we are overdue right now
... correction, every 3 months
... any major comments on plan wrt pushing working draft out

<aleecia> …other than last week, I assume

schunter: no comments recognized

<fielding> aleecia, should we update your affiliation in the Acks?

schunter: we tried to address major comments from last week. if you feel they weren't addressed please send again

<npdoty> aleecia, I meant to follow up with you yesterday, I'm not sure how to address the issue of sentences that may not be true after changes to the draft

<aleecia> yes, or drop me all together. either way is fine.

schunter: moving on and diving into the technical issues

ISSUE-195 Flows and signals for handling out of band consent

issue-195 flows for out of band consent

<aleecia> Nick, the issue was we no longer have tagged what is at consensus and what is not.

<rigo> trackbot, ISSUE-195?

<trackbot> ISSUE-195 -- Flows and signals for handling out of band consent -- open

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

UNKNOWN_SPEAKER: tracking pref sent to site
... <missed>
... in order to send signal site needs to be able to determine if it have consent from user.

<aleecia> If people believe the spec is at consent due to lack of disclaimers otherwise, this is a problem (raised more forcefully by Jonathan than by me, but presumably his points have all just gone to ignored.)

<Chris_IAB> just joined via Skype

UNKNOWN_SPEAKER: Ronan raised a concern

<Chris_IAB> btw- not easy to join today-- kept getting an error message

<aleecia> I agree with Matthias that a global "not at consent" disclaimer is unduly broad.

<aleecia> Chris, I had to try a few times too, but did get in.

Ronan: if deter cannot be made in real time then signal will be sent that out of band consent will be gathered later
... <missed late part>

<fielding> aleecia, changes were made to the SOTD in the last two days to address the comments

<aleecia> Nick, I think one of the goals is to document what is, and is not, at consensus. But we appear to have lost that in the document. That is my point. Not "things could change"

<npdoty> ... data could not be used, just collected and retained until consent is determined

schunter: issues is out of band consent is not available immediately
... and 3rd parties

ronan: I would not include 3rd parties

ed: want to know more about implementation scenario

<aleecia> Roy, glad to hear it; do we have a deadline for review? Or is it at some arbitrary time suddenly things are decided to not have attracted comment? If there is a deadline, it would be spiffy for Matthais to send that to the official dlist

ed: how would user be notified later. if youi could lett know later, why not now? ... secondly, how would they be notified later?

Ronan: <sorry, missed responses>

<fielding> aleecia, ask the chair ;-)

<aleecia> <grin>

<rigo> big vacuum cleaner for 48 hours to determine what you can keep

<npdoty> ... might have determined later (based on being sent the IP addresses later that night, for example) that a user has given consent

ed: Still don't understand why you you need to keep data longer?

schunter: let's not get into the 48 hours discussion.

ed: this is about servicing the request not retaining data

schunter: you have to determine in 200 ms, but if not you dont have a way to honestly answer
... therefore need way to handle that

ed: okay, how is user to find out later

<npdoty> didn't we propose a separate TSR to avoid having to make all determinations in real-time for the HTTP response?

ronan: this is where control link comes in
... i threw out 72 hours

<dan_auerbach> "and you're curious

<dan_auerbach> "

<fielding> edit link, at the moment -- anyone with better suggestions for a name are welcome

ronan: notify UA a time to comeback

<dan_auerbach> means the user agent MUST present this to user, or not

ronan: UA would know and should let user know

schunter: 72 hours is extremem case.
... some cases you cannot do inline due to time constriants
... IP address case with many hours is special case

<Zakim> npdoty, you wanted to ask if out-of-band consent is typically retrospective

schunter: most cases are shorter

nick: 2 questions

<dan_auerbach> +q

<rigo> npdoty: is oobc always retrospective?

nick: is out-of-band (OOB) consent retrospective?

ronan: consent prospective
... has to be retropective

nick: <didnt catch>

ronan: would catch in some cases, but not all
... real time might not be possible on some cases

<rigo> npdoy: TSR can be requested asynchronously, so you can have the TSR manipulated later and have the browser fetch it later

ronan: there are technical hurdles

<dan_auerbach> why is that so hard?

ronan: response could be very heavywieght

<dan_auerbach> to push that info to CDN or whatever front-end system

<aleecia> +1 on that -- tend not to be heavily into real time needs

Roy: divide problem, certain things we cannot improve on, like surveys to do online response for every request. Problem might not be technical, but rather related to the size/expectations of the company.
... make sense for compliance is the 200 ms response needed.
... would expect related test if you have given consent to be immediate (within normal page request time)
... this should not be hard to solve
... there is a limit to scale to responses
... many times these are requests to other sites and could create probs
... i dont see the privacy concern

<efelten> If we want UA to be able to check these things itself, we shouldn't use a link to an unstructured web page. Want machine-readable.

schunter: i believe ronan's answer ccould be within ~1 min

<aleecia> (I'm not sure why "we collect this data for this use, regardless of DNT" isn't sufficient for consent right there. I think I am missing the important part of this discussion somewhere.)

schunter: if you are panelist, we keep your data
... if not, we dont
... completely diff solution to consider
... if site complies with 1 or 3 all of these OOB consent apply

<fielding> efelten, why would we need the UA to check this?


<npdoty> it sounds like the problem is that sometimes a measurement company can't identify the user until several hours later (when their panel program reports IP addresses), but will want to add that data to their panel once the identification is made

<efelten> Ronan suggested a scenario where the UA checks automatically, rather than interrupting the user.

rvaneijk: comliance concern -- cookie ? <missed, sorry>

scribe thanks you

<rvaneijk> Ronan is trying to solve a very specific problem. Once it gets in the spec it becomes a generic solution. That does not seem logical to me. Two remarks: - Cookie for the control link looks problematic by itself, for it is not a functional coockie and you will run into the 5.3 requirement in the EU - OOBC determintatinon: alternative solution may be a browser add on for panel members. In my view that would be much more proportional.

<aleecia> Nick fills in nicely what I'm missing: I hear "panelist" as member of a specific research study, not, say, Nielsen measurement panels. Thank you.

ronan: we cannot force installation of plugins, but we have some contraints

rigo: dont understand why need special treatment

<fielding> forgot to mention … I don't think the cookie thing is worth specifying -- that can be a dialog with permission of the user in the extremely rare case it would be desired

rigo: falls under 2 existing things
... 1. shorter collection and use
... 2. tracking compl spec says ooob consent trumphs dnt
... therefore, i dont understadn need for additional rule
... it makes it difficult to understand what service collects

ronan: if site response 3, then it must respond 'C' later and that would be less transparant (correct?)

rigo: browser wants to understand the conditions which the data was given

<schunter> " If an operator is relying on "out of band" consent to disregard a "Do Not Track" instruction, the operator must indicate this consent to the user agent as described in the companion [TRACKING-DNT] document. "

schunter: must be able to represent that received oob consent

<schunter> Rigo proposes to signal "3" & "short-term use exception". Out of band then trumps these statements for the panelists.


<npdoty> +1 that it's less transparent, which is why we added the C requirement

<npdoty> ronan: it would cover everything we want to do, but is less transparent to the user than a P response

dan: privacy concerns hinge on UA does with this info
... could UA side speak to what this would look like
... Roy mentioned some companies might not be able to address due to size/resources... what happens if the site goes down
... good to keep simple
... what is we say not oob consent mechnism
... ronan, why would this be cripling to you
... what is the data to suggest a problem

ronan: depends on usage of DNT
... we use panels

<schunter> An alternative is to define "3" as "we follow third party rules (including the fact that all constraints are relieved if you gave consent)"

they represent large groups

scribe: they represent large groups

<schunter> In this case, one does not need "C" or "L"

<npdoty> schunter, that was alex's original request, as ronan points out, it is less transparent

dan: you could normalize for that

ronan: you can't
... affects reliability

dan: let's offline this

<rvaneijk> In terms of proces, I want to mark down that although this discussion is useful there is no way consensus can be assumed.

rvaneijk: no way consent can be assumed, want to caution about adding tech into public doc

<fielding> It is an option in the current document -- there is no concern about that being mistaken

<npdoty> we currently have text in an "Option" box, with the issue box marking it

schunter: there is some text and is marked as option or text under discussion

<aleecia> :-)

rvaneijk: also could mark as no text

fielding: removing is not a solution
... we need proposals in the spec... we should not remove
... should we havea specific issue for this?

<rigo> ISSUE-195?

<trackbot> ISSUE-195 -- Flows and signals for handling out of band consent -- open

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

schunter: 195
... what is we remove flags and leave spec as it was

<rigo> +1 to schunter suggestion

<npdoty> I actually think we're only using 195 for the possibility of an additional possible-consent flag for oob consent

<rigo> as soon as we have short term collection permission

schunter: OOB gives general expection, which use 3
... ?OOB consent relives of 3rd party rule?

<rigo> +1 to Aleecia's interpretation

aleecia: short time period is to figure out how handle not that you can do anything until you figure out

nick: the concer with respoinding with '3' is that we lose transparency to user

<aleecia> we do lose that transparency, but if they've opted in they should know

<dan_auerbach> +1 to nick

<rigo> aleecia, I think we have to get a better wording for Short Term Collection and Use

<schunter> We could mandate "edit" if a site uses OOBC or inline consent.

<fielding> so the proposal is respond "3" and allow 48 hours to keep the data until consent is determined? (BTW, 48 is just a number I made up)

nick: need to provide feeback to user and is important

<rigo> to reflect what you just sayd

<dan_auerbach> the problem is that they will never know, right?

schunter: roty, proposal is to answer with 3 and use short term retention exception

<npdoty> fielding, I think it would be respond "3" and retain data for up to a few weeks to determine whether or not you have consent to use the data

<aleecia> please do! I think you've followed the discussion for the past two years

schunter: 3 means follow 3rd party rules or you have consent

<aleecia> (I guarantee a lack of time on my part in the next month)

<dan_auerbach> the scenario nick suggested would look the same to a user who is NOT opted into a panel

schunter: if you use oob consent, you must provide link

<aleecia> is there a way for users to find out after that they remain in a panel?

<aleecia> or more to the point, that the company thinks they are part of a panel?

nick?: there would be no way for user to know

schunter: users should be careful about where they provide oob

<schunter> Solution:

<schunter> (under consideration)

<aleecia> Nick's problem is real I'm just looking for any way to make this work and not seeing a better alternative.

<schunter> - Signal "3" and permitted uses (here: Short-term retention)

rigo: we have to have qualifiers in spec for exception we dont have qualifier yet

<schunter> - "3" allows processing under OOBC

rigo: and we need one

<schunter> - If OOBC is used "edit" allows to learn more.

<fielding> qualifiers are optional, so they aren't going to be sent regardless

<npdoty> we have an open issue that that list of qualifiers will be updated to match the Compliance document, when we have settled on them

<aleecia> (yes)

<hefferjr> yes

schunter: i suggest sending '3' if allows using oob consent and having to provide link

<aleecia> I'm wondering how we can get transparency outside DNT, just as consent is out of band

schunter: suggest updating text and get feedback

nick: not clear who the solution is better for

<dan_auerbach> i have mixed feelings

nick: <breaking up>

schunter: 1 less signal

scribe's head is about to explode ;)

<aleecia> rigo, you're wonderful, but don't make me beat you :-)

<fielding> okay to remove text, though I would prefer to keep the text until after the WG meeting so that we can talk two alternatives at the F2F

schunter: not full agreement... so let's update spec
... let's put both options in spec and discuss at F2F

<dan_auerbach> i share nick's concerns, but also am concerned that in practice the other flag will also be non-transparent given the complexity proposed and the reliance on user agents to present the info to the user

<fielding> yes

<rigo> +1 to fielding to keep text and add markup that there is another option

nick: need anyone else to review?

<aleecia> I'd like to brainstorm other ways of notice

<aleecia> But I don't have anything solid here

<aleecia> Just a sense that perhaps there is another approach for this particular edge case

schunter: roy to provide text

<dan_auerbach> i think one third alternative

schunter: rest to review

<dan_auerbach> already on the table

<npdoty> ACTION: fielding to add text noting the option of not indicating out-of-band consent [recorded in http://www.w3.org/2013/04/24-dnt-minutes.html#action01]

<trackbot> Created ACTION-394 - Add text noting the option of not indicating out-of-band consent [on Roy Fielding - due 2013-05-01].

<dan_auerbach> is to just not have special consideration for OOBC

<fielding> happy to add more text if someone wants it -- send to mailing list

ISSUE-168 What is the correct way for sub-services to signal that they are taking advantage of a transferred exception?

schunter: explain by example

<fielding> issue-168?

<trackbot> ISSUE-168 -- What is the correct way for sub-services to signal that they are taking advantage of a transferred exception? -- open

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

<rigo> dan, I think P or L will not alter browser behavior, so rather say 3t

<dan_auerbach> apologies all, must take off

schunter: user vists sites and site is using ad network. site says i am okay sending DNT:0 to ad network
... site passes on consent and i will get 'C' signals from ad providers I never interacted with

<rigo> having P may mean: "give me all data and accept all cookies because I may have consent about it". Which is much more unclear than "I can keep data for 48 hours to determine what I'm allowed to do with it".

schunter: browser will be confused b/c it didnt directly interact
... do we want to tackle it all? or too much or a corner case?

rigo: b/c of ad auction system we need a specific transitory permission for ad networks to deal with the data that was initially given to 1st party
... signaling is transparency issue
... we dont need explicit flag for everything we do
... hinders deployment
... make more complex with limited gain

schunter: other opinions

aleecia: complexity isnt only prob
... transparency is vital

<schunter> without this feature, browsers can not double-check exception claims.

aleecia: needs to be some mechanism to represent propogation of consent

nick: imp difficulty is unclear to me
... _ ---__--___

<aleecia> (Nick breaking up; best scribing ever)

<Wileys> Works in both directions - bascially in server-to-server transactions that originated in a client-side request, are DNT signals to be conveyed (0 or 1)?

<schunter> This distinguished "I got the exception from you" vs "somone else gave it to me2

<schunter> "

<Wileys> Nick, many online bids occur server-to-server, not thought client-side 302 redirects.

nick: destinction are already made between DNT:1 requests

rigo?: it speaks to sub-services

<npdoty> Wileys, but for the response header to the user, only direct to-the-user requests would need to provide the signal

<Wileys> I'm on the call

scribe: need to exchange sign to sub service and back

schunter: are headers coming from 1st party or sub service

shane: origical ad call froms from exchange itself
... but redirects cold include 302 redirects

<npdoty> right, the bid participants don't need to send a tk: response header because they're not sending a response to the user at all

shane: then there are bid participants via server-to-server call and outside of UA interaction
... some participants dont interact with UA at all

rigo: this is why i said we need to invvent transitory perms, but carry limits related to the transitory perms

<npdoty> we don't have to add anything to the protocol for the cases where server-to-server communication is taking place; it's up to those servers to indicate that the request is DNT:1 or not propogate the communication at all

rigo: signalling back to UA is a different issue
... s/different/another/

<Wileys> Nick, they should equally be able to convey DNT:0, correct?

<npdoty> Wileys, right.

schunter: how to approach this then?

<Wileys> I'm okay with that

nick: i'm confused.

<fielding> I think this is too complex for a phone call … we need a whiteboard diagram that shows the sequence of requests to each party and then explain why some get DNT:1 and others get DNT:0 and which ones the user has actually consented. Maybe.

nick: my understanding that some 3rd parties are geting redirectd and would say they have consent, but for s-2-s calls wont have it?
... i think we might need a placeholder for this issue

<aleecia> I'm not seeing how DNT:0 propagates in a sane way, ever.

<npdoty> I agree whiteboard would help, but I think we are managing even so. :)

schunter: are you suggesting have flag and allow for transferring of signal and move on?

<aleecia> Maybe Roy can convince me with a whiteboard but...

rigo: i am okay with that

<aleecia> Yah: just shoot it

schunter: anyone canot live
... with it


scribe: ?

<fielding> I am not convinced.

<npdoty> maybe we can put it in Pending Review and if when we have a whiteboard conversation we find out something different, we can make a change?

<aleecia> +1 to Nick's procedural suggestion

rvaneijk: some people might no follow flow and therefore the issue, maybe talk about at f2f

<rvaneijk> ok

<rigo> fielding, being not convinced is a privilege reserved only for npdoty

<fielding> me?

<rvaneijk> s/HHH/rvaneijk/

schunter: follow nick's suggestion and discuss at f2f

<aleecia> I don't see how this works for users at all. Not fails a little at the edges, but toasts the value of DNT and in unpredictable and invisible ways.

<aleecia> So I'd love to hear more

whoi is talking ?


<aleecia> (roy)

<Wileys> Roy right now


schunter: shane, would this work?

<npdoty> I think rather than a complex proposal, we just need to fill in the value currently in the text as "XX"

roy: can shane write up and i'll add to spec

shane: i'll put togehter a slide for f2f to discuss
... then we can decide on inclusion for TPE

schunter: i like

nick: just need a placeholder. that was my only concern
... i can add the text and pending review

<npdoty> ACTION: shane to provide a couple slides explanation of exchanges / redirects / server-to-server [recorded in http://www.w3.org/2013/04/24-dnt-minutes.html#action02]

<trackbot> Created ACTION-395 - Provide a couple slides explanation of exchanges / redirects / server-to-server [on Shane Wiley - due 2013-05-01].

<Wileys> Issue-143?

<trackbot> ISSUE-143 -- Activating a Tracking Preference must require explicit, informed consent from a user -- closed

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

schnuter: no more issues on agenda

<Wileys> Can we discuss that today?

schnuter: whoa

<Wileys> +q

schnuter: open for any other topics

<npdoty> ACTION: doty to provide pending review text for signal of transferred/redirected exception (issue 168) [recorded in http://www.w3.org/2013/04/24-dnt-minutes.html#action03]

<trackbot> Created ACTION-396 - Provide pending review text for signal of transferred/redirected exception (issue 168) [on Nick Doty - due 2013-05-01].

shane: can we talk about issue 143
... large issue for us
... tied to who is setting the signal

<fielding> aleecia, I tend to agree, but maybe it would be possible if we reduced the allowed exception to read-only? i.e., transfer the exception to use existing data, but not to save this request data?

<rigo> ISSUE-143?

<trackbot> ISSUE-143 -- Activating a Tracking Preference must require explicit, informed consent from a user -- closed

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

shane: 143 is about if someone other than UA setting DNT signal that they identify themselves as the setter

<rigo> use https

<npdoty> issue 143 is closed, with pointers to 194?

<aleecia> existing data. I'm not sure what you mean (cue HTTP is stateless)

schnuter: hmmmm.
... good issue

shane: maybe we discuss later due to how big it is

schunter: how can we make this discussion more productive at f2f?

<rigo> issue-194?

<trackbot> ISSUE-194 -- How should we ensure consent of users for DNT inputs? -- open

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

<fielding> aleecia, I mean the ad auction is about finding a premium based on past behavioral data -- the current request cannot be added to that data, but older data can be used to make the ad personalized

shane: f2f discussion would be okay. one conern is size addtion to header... no one has a problem with doing it, it is more about the technical imp

schunter: no formal discussion now, but would like to hear feedback here with thots about this
... unclear how to make this work

<fielding> this is assuming that the user has consented to personalization for *this* site.

nick: i would have concern with trying to id software in the signal
... this could go against decreasing fingerprint-ability
... i do understand the concern, why servers would want to distinguish software other than the user agent setting dnt:1

<aleecia> roy, i'm not sure that solves anything?

<Wileys> +q

nick: maybe add an additional char to represent default versus user setting

<schunter> Nick: user preference vs default setting

<Chris_IAB> ndoty, I don't think we want to condone the default setting by incorporating it in the spec

rigo: user choice has 2 things
... group agree defualt should be DNT unset
... user choice should be required for DNT:0

<npdoty> Chris_IAB, I agree, it would be a non-compliant signal (that is, we would indicate in the spec that you can signal it but that it isn't compliant, the way we do with "!") right now

rigo: getting to DNT:1 should be symmetric with getting to DNT:0

<Chris_IAB> npdoty, why would we build a "non-compliant signal" into our spec? Our goal is compliance with the spec, not giving those who want a different flavor of DNT an easy way out of their non-compliance

<Chris_IAB> npdoty, that would be a slippery slope

schunter: issue that other tools can "spray" DNT settings

<npdoty> Chris_IAB, a rare instance of your vehemently agreeing with jmayer!

schunter: shane's concern "how do i get reliable channel?
... "

<npdoty> Chris_IAB, some in industry have asked for ways to signal non-compliance, even though we would need to be explicit that defining the signal does not make it a compliant response

shane: yes, that is my concern

<Wileys> The goal is to force transparency of who is setting the DNT signal

schunter: want to be able disctiguish who set signal

<aleecia> isn't that what dnt:1 is? :-)

<Wileys> If we don't have that, I don't believe DNT will be implemented by industry

<Chris_IAB> npdoty, how about simply adding an identifier that "we are not compliant with the spec"? Seems a bit silly to me, but it would be better than parsing out fine delineations

<fielding> I am not seeing the point here -- no invalid sender is going to signal they are invalid -- it will be identified by product charateristics (if ever)

schunter: back to queue

aleecia: matthais raise a point i want to re-visit

<npdoty> fielding, yes, I have some doubts about how practically helpful it would be

aleecia: anti-virus sftware that was setting DNT for users and did in registry and therefore rending UA unable to distinguish how it was set
... we dont have solutions how to handle conflicts

<Wileys> I believe a signal stating "I'm a valid DNT signal" is a waste of time. Just tell who you are and I'll determine if you've sent a valid DNT signal or not.

aleecia: furthermore, how to even know if conflicts occured
... shane, technically how would this happen?

<Chris_IAB> would someone setting the signal actually want to identify that they are non-compliant?

shane: multiple options
... some change in-flight and some at registry level
... in either case,
... in registry, if DNT is set other than by user, they would need to convey in registry as well.

<aleecia> ("via the UA UI" is one of the best phrases I've heard spoken this week)

<fielding> Wileys, self-identification won't work either -- they'll just lie

shane: for in-flight, they would add their id at the same time

<Wileys> Roy, but I can go after liars legally :-)

chris: <breakin up>

<aleecia> Rigo, how many times do we need to go 'round on that point? Argh.

<npdoty> Wileys, aren't there already legal implications to non-compliance with the spec when claiming compliance?

<rigo> aleecia, isn't this one option?

chris: if they are motiviated to lie, maybe we have a signal to say i am non-compliant

<aleecia> it's one we've said no to so very very many times

chris, are you in a cave?

<aleecia> like a zombie, it keeps lumbering out of the grave

<aleecia> matthias?

<Chris_IAB> bad phone connection-- sorry, did you catch me?

<aleecia> are you on mute?

schunter, on mute?

<Wileys> Nick, I don't believe so if they are stating something different on their side. If the standard requires the party setting the DNT signal name themselves and they don't, I now have grounds for a deceptive claim.

schunter: concern, no viable tech solution that is robust enough
... would like to have a bunch of tech proposals

<Chris_IAB> kulick, to clarify for the record, it would be "if they are motivated NOT to lie"

chirs, sorry

<fielding> Remember, the cost of sending additional data on every request MUST be justified on Internet-scale terms

<Wileys> DNT:<value>, <user agent string of setter>

scribe: send proposals to the mailing list and get responses

<aleecia> given a choice between user agent and "I comply," I'd go with "I comply" to avoid the issues Nick raised

scribe: need options to compare

<npdoty> Wileys, if a party indicates a user agent string that you find deceptive but they're clear about it on their site, do you have more of a deception claim than if they sent dnt:1 and are non-compliant but claim compliance?

<Wileys> Roy, agreed - so how do we make is "smaller" and still meet the need.

<aleecia> and it does create an additional hook for enforcement

<aleecia> but, I don't see how we get there -

<aleecia> if one UA isn't compliant but three others are, which one do we send?

scribe: make sense?

<aleecia> we'd need an array

<aleecia> of all the UAs

<aleecia> but some are in flight and some are not...

<aleecia> ick

rigo: concerned that we make untestable reqirements

<Chris_IAB> maybe... if the option is "this is my signal that I am non-compliant with the spec"

rigo: servers cannot see into a user's computer... we are in untest territory

<Wileys> Rigo, if we don't have this, then DNT will likely not be adopted

<aleecia> "I'm non-compliant" is parallel to "I see your signal but don't do DNT." These are both ok with me. I just don't see how we *do* the UA side in a reasonable way.

schunter: how would you solve the problem
... some product sprays DNT:1

<aleecia> (Ok = I can live with, not that I like. But, details)

<Chris_IAB> rigo, what do you mean by "untested signals"?

<fielding> Wileys, I don't think it can work -- what we would need is discovery within the user agent itself (like testing to see if javascript is enabled) but that still wouldn't work for user-installed proxies. Ultimately, this issue needs to be solved by social action, not technology.

rigo: it is difficult situation, but sending untestable signals <wont buy anything>
... there is no clear tradeoff

<Chris_IAB> fielding and Wileys, I think I agree with fielding on this

rigo: haveing untestable signal does buy anything

<aleecia> oof

<npdoty> +1 to fielding (I was just giving possible alternative suggestions)

rigo: have to solve by clear reqs and rules in compliance

<Wileys> Roy, if we can't find a solution, I believe DNT is DOA

<Chris_IAB> rigo, not just social, but also potential regulatory (ie FTC encorcement?)

schunter: legacy prob also

<rigo> maybe, yes, unfair competition

<rigo> -> to Chris_IAB

<Chris_IAB> if DNT is sent and it is non-compliant, that's probably a deceptive behavior

schunter: we should look at some and see if they provide partial solutions... important that we respect the concern and try to solve
... we might fail...

nick: procedural question
... 143 was closed based upon 194

<fielding> If the working group does not pressure Microsoft to change its bad behavior, then I agree that DNT is well past dead. There is no point in continuing if folks on the side of "good" are not willing to police their own bad actors.

<Wileys> Without a solution here, we have no balance within DNT. We're forcing high levels of transparency on the Server side (URI resources, TSAs, etc.) and almost none on the UA side.

nick: we could re-open but just for signially as it is broad

schunter: i will make sure there is an open issue
... for this

<aleecia> Shane, you get that I'm saying "how do we do this, I don't see how" and not "we shouldn't do this," right? So far your proposal doesn't work yet.

<Wileys> Yes

schunter: you okay with approach mentioned?

<Wileys> Matthias - yes

<rigo> it is is ISSUE-194 that superseded ISSUE-143

yes on IRC

shane: yes

schunter: good use of last 2o mins, nice work

<npdoty> reminder: register for the f2f if you expect to attend

schunter: we will do whiteboard on this at f2f
... may 1 for next meeting... bye

<fielding> forgot to ask about Acks

Summary of Action Items

[NEW] ACTION: doty to provide pending review text for signal of transferred/redirected exception (issue 168) [recorded in http://www.w3.org/2013/04/24-dnt-minutes.html#action03]
[NEW] ACTION: fielding to add text noting the option of not indicating out-of-band consent [recorded in http://www.w3.org/2013/04/24-dnt-minutes.html#action01]
[NEW] ACTION: shane to provide a couple slides explanation of exchanges / redirects / server-to-server [recorded in http://www.w3.org/2013/04/24-dnt-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013-04-24 17:30:30 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/@@@/Ronan/
Succeeded: s/@@@/ronan/
Succeeded: s/XXX/rvaneijk/
Succeeded: s/UUU/rvaneijk/
Succeeded: s/UUU/rvaneijk/
Succeeded: s/III/fielding/
Succeeded: s/roty/roy/
Succeeded: s/HHH/rvaneijk/
FAILED: s/HHH/rvaneijk/
Succeeded: s/i do understand why this is needed/i do understand the concern, why servers would want to distinguish software other than the user agent setting dnt:1/
Succeeded: s/so invalid/no invalid/
Found ScribeNick: kulick
Inferring Scribes: kulick
Default Present: kulick, schunter, +1.609.258.aaaa, eberkower, npdoty, +1.202.347.aabb, Fielding, rvaneijk, Aleecia, +1.202.326.aacc, WaltM_Comcast, prestia, paulohm, hwest, +1.916.641.aadd, hefferjr, RichardWeaver, sidstamm, Joanne, Rigo, [Microsoft], WileyS, Peder_Magee, David_MacMillan, Chris_IAB, JeffWilson, Dan_Auerbach, +1.781.482.aaee, samsilberman, Jonathan_Mayer, [FTC], Chapell, Brooks, BerinSzoka, moneill2
Present: kulick schunter +1.609.258.aaaa eberkower npdoty +1.202.347.aabb Fielding rvaneijk Aleecia +1.202.326.aacc WaltM_Comcast prestia paulohm hwest +1.916.641.aadd hefferjr RichardWeaver sidstamm Joanne Rigo [Microsoft] WileyS Peder_Magee David_MacMillan Chris_IAB JeffWilson Dan_Auerbach +1.781.482.aaee samsilberman Jonathan_Mayer [FTC] Chapell Brooks BerinSzoka moneill2
Agenda: http://www.w3.org/mid/5176909E.7040407@schunter.org

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 24 Apr 2013
Guessing minutes URL: http://www.w3.org/2013/04/24-dnt-minutes.html
People with action items: doty fielding shane

[End of scribe.perl diagnostic output]