See also: IRC log
<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.firstname.lastname@example.org
<aleecia> (even better!)
schunter: TPE call only today
<npdoty> yes, thanks kulick! yay for volunteers
schunter: let's get started on discussed
<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
<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
UNKNOWN_SPEAKER: tracking pref
sent to site
... 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 ;-)
<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
... 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
... i threw out 72 hours
<dan_auerbach> "and you're curious
<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
... 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
<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
... 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
... 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
rvaneijk: also could mark as no text
fielding: removing is not a
... we need proposals in the spec... we should not remove
... should we havea specific issue for this?
<trackbot> ISSUE-195 -- Flows and signals for handling out of band consent -- open
... 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 22.214.171.124 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> (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
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
<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
schunter: explain by example
<trackbot> ISSUE-168 -- What is the correct way for sub-services to signal that they are taking advantage of a transferred exception? -- open
<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
... 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
... 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
... _ ---__--___
<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
<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
... 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
<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
<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
<rigo> fielding, being not convinced is a privilege reserved only for npdoty
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 ?
<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].
<trackbot> ISSUE-143 -- Activating a Tracking Preference must require explicit, informed consent from a user -- closed
schnuter: no more issues on agenda
<Wileys> Can we discuss that today?
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
... 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?
<trackbot> ISSUE-143 -- Activating a Tracking Preference must require explicit, informed consent from a user -- closed
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)
... good issue
shane: maybe we discuss later due to how big it is
schunter: how can we make this discussion more productive at f2f?
<trackbot> ISSUE-194 -- How should we ensure consent of users for DNT inputs? -- open
<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
... 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?
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
... 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
<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"
<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...
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
... 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"?
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
<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.
schunter: you okay with approach mentioned?
<Wileys> Matthias - yes
<rigo> it is is ISSUE-194 that superseded ISSUE-143
yes on IRC
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
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.email@example.com 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]