See also: IRC log
<trackbot> Date: 23 April 2014
<scribe> scribenick: ninja
<Chapell> I can scribe
<Chapell> at least first 45 min
justin: Today is the day we would
like to make an advancement of TPE to Last Call.
... Received two Last minute objections from Jack and Alan.
<sidstamm> thanks, wseltzer
<npdoty> Jack's email: http://lists.w3.org/Archives/Public/public-tracking/2014Apr/0099.html
justin: Jack your first point is
lots of compliance issues have been ported over to TPE.
... This has been discussed a lot of times. We want to define for TPE what the signal means.
... We need a minimum of definitions to do this.
... Your second point is a missing mechanism to verify a DNT signal. We discussed this a few times but did not come up with a technical solution. What do you expect here?
JackHobaugh: I think these issues I named should be resolved before Last Call.
justin: Second email came from Alan Chapell.
<npdoty> Alan's email: http://lists.w3.org/Archives/Public/public-tracking/2014Apr/0100.html
justin: I would characterize it
as primarily process related. On the groups decision on
tracking and context.
... The process issues will not be addressed during Last Call. This is why I would say that this objection is not relevant for the advancement.
... Regarding not knowing where the definition of context came from, he group found the definition of tracking ambiguous without defining context.
... What do you want us to do?
<npdoty> it sounds like Alan is concerned that not enough terms are defined, and Jack is concerned that too many terms are defined
AlanChapell: I think the spec is unimplementable with this number definitions. No implementer will read and understand them.
schunter: Why do you think it is unimplementable?
Chapell: Slippery slope. Had we not defined tracking we would leave it open to implementers. But we are somehow gone half way here with the definitions. Leaving things ambiguous.
<fielding> They are not ambiguous (or at least no more ambiguous than any sentence in English can be).
Chapell: My first suggestion would be to not define it. Perhaps we can now prior to implementation do a better work on the definitions that are ambiguous.
<dsinger> I think it is OK for the WG to agree to send it out for wider review, but for WG participants to comment as part of that review (and in light of wider review in their companies, implementation experience, and so on)
justin: Do the editors want to speak on this?
fielding: We cannot be
mathematically precise with definition phrases.
... The WG has spent lot of time on coming up with definitions that are as unambiguous as we could get. I would point to formal objections.
<jeff> [for the record, Alan and Roy, I would expect the Director to take any Formal Objection quite seriously]
<fielding> And LC is not the end of the process … if we learn something, it can be changed in the next revision.
dsinger: I think it is ok for the WG to ask the public for reviews. That way we would get precise feedback, where the implementers had problems with ambiguity
<Ari> I took this spec to more people in my company, and the consensus is that this is unimplementable as it stands
<fielding> Ari, please have them write down the reasons and send them in email to the group.
schunter: Important take away
from Alan's points. If we find implementers and edge cases
where our definitions do not make sense, we will need to
... Exactly the information we are looking for in Last Call.
<Ari> will do, though it's disconcerting to hear that they'll be laughed at
<jeff> [Ari, they won't be laughed at. See my statement above.]
<dwainberg> Perhaps, Roy, as helpful illustration, you can explain in detail how Adobe will be implementing these definitions across all units of its business.
<Chapell> Ari: who was laughing?
schunter: The more specific these feedback is documented, the easier it will be for the WG to address them.
<Ari> see the TPE's author's earlier statement
<wseltzer> [all input will be welcomed; input with evidence and specifics will be particularly welcomed]
<fielding> Ari, if the objection is that an HTTP protocol should not include definitions, it will be laughable. If there is an implementation problem, the WG will look at that and address it in the next revision (more likely than not).
<dwainberg> Alan, Roy suggested that objections would be received with laughter by the W3C.
<npdoty> I think there might be some confusion about implementation and compliance, as I'm not sure there are requirements in the TPE on servers regarding compliance, since servers are specifically allowed to indicate their own type of compliance
Brooks: Problem is we have definitions written in a way that is difficult to implement for important edge cases.
justin: You have known the definition of context for a month, even if we sent out the explanation late. All we want do with Last Call is to get the spec out to the public.
Chapell: To say that the decision
was conclusive without the explanation does not go well with
... I was sort of waiting for the document. I waited for the rationale to understand the decision.
... If we are not to rely on the document why does W3C provide it anyway?
<fielding> dwainberg, I wouldn't be able to express the details of every Adobe implementation even if I knew what they are, just as I can't express the details of every HTTP implementation even if I knew what they are. I do know that the purpose of LC is to encourage folks to *start* implementation and provide feedback.
schunter: I think Brooks made a
good point. If in test cases many people would interpret our
definitions in different ways than we had in ways we did not
expect. We need to make the spec better.
... This will be a task for the whole WG.
... My feeling is without public feedback the WG will not come up with better definitions.
<fielding> Like other closed issues, reopening definitions requires new information that the WG did not consider at the time.
dsinger: Having trouble understanding this. You criticize that context is ambiguous, but you strongly supported leaving it undefined. Contradictory.
Chapell: More of a comment on the spec as whole. That the linkage of definitions creates ambiguity. Heard that we cannot re-open closed issues.
<dwainberg> Roy, so pick a representative sample. If the defs are unambiguous, show us by example.
justin: Regarding these two
objections that we received, and that we discussed them before.
The chairs conclude that we have sufficient support and
consensus for the advancement for Last Call.
... We will create a page with an announcement and a specific mailing list for feedback.
npdoty: Wanted to answer the point about the mailing list.
npdoty: We will receive and
address all comments received
... You can subscribe to the mailing list if you want to get the feedback.
WileyS: AWhen will the group address the comments that come in? Want to make sure that we have time addressing them.
<fielding> dwainberg, I am not interested in wasting my time to satisfy your desire to postpone all WG decisions. If you know of an actual service that can't be implemented, then let us know. I am not aware of any that can't be implemented, inside or outside Adobe.
<dwainberg> I'm not asking to postpone. I'm asking you to provide examples of Adobe's implementations.
<npdoty> I think maybe June 19th is the deadline (was 8 weeks after the publication date)
<dwainberg> If you're not aware, go find out.
<dwainberg> Prove it.
justin: Deadline will be June 18. We have not discussed this in detail. Not sure if we will do this before the deadline? Maybe it makes sense to group them when eel received and grouped all of them.
<npdoty> +1, if we get a lot of comments early on, we could try to address them earlier. if we're getting comments at the end, we'd need to work through them then.
<jeff> +1 to Justin's idea of waiting some time so LC comments can be grouped.
<rvaneijk> Nick: http://www.w3.org/2014/03/26-dnt-minutes, June 18.
<dsinger> (I think we might need new information in the comment, that enables new discussion)
WileyS: If the gamifacition or inserting signals of a DNT signal come up again. Will we be able to re-open these issues?
<npdoty> I think the most useful thing would be new information -- like a proposal that would work, or details on the type of problem
justin: I would like to address comments that come up. Personnally would love to have new ideas and input on that to re-open the discussion.
schunter: The fact that the WG
has closed it does not mean that we brush off public
... Just resubmitting our discussion is not useful. But detailed feedback from implementers
... If this is new input it will be even stronger.
justin: Would love to see new
ideas and more information, even on closed issues.
... This is one of our hopes for Last Call.
WileyS: This is helpful. In post-Snowden era, there may be some of our closed issues e.g. on trust come up again.
wseltzer: From experience of
other WG Last Call, it is useful to have some time to group the
comments and bring them to the group after the deadline.
... We will make sure that the WG will allocate the time needed.
<WileyS> If we see a large volume, another F2F may be warranted.
justin: Will make it transparent to the group and give plenty of discussion time.
<scribe> ... New F2F could be a good idea.
<WileyS> Not until October though...
UNKNOWN_SPEAKER: We have been
productive without a F2F recently, but addressing public
comments could be a good opportunity for a F2F.
... Want to hear member thoughts.
... wseltzer is suggesting October.
<WileyS> Wendy, what is up with the IAPP and Halloween? You did the exact same thing 2 years ago :-)
<jeff> Congratulations to Justin, Matthias, Carl, and the entire Working Group on moving TPE to Last Call.
<WileyS> Collection vs. use distinction
justin: We talked a lot at Bellevue about short term collection.
<npdoty> wseltzer, WileyS : 27-31 October; we could meet on the earlier days, say
justin: proposals from David and Lee have discussed merging their proposals.
dsinger: We don't have finalized
text yet. My proposal is leaky about the time, Lee's proposal
is weak about the use restriction. so we will come up with a
... Retention period must be reasonably short. Discussed a lot whether we could come up with a fixed time limit.
... Probably a rat hole for this WG. Better to ask for a transparent written statement from the server.
... The security must be proportionate to the time you keep the data.
<dsinger> proposal, add to my text:
<dsinger> * the maximum retention period must be must be reasonable and necessary,
<dsinger> * the security and protections used to prevent mis-use (“non-compliant use”?) of the raw data should be proportional to the retention period: data accumulated and retained for two days requires more than data retained for two hours, and data retained for two months requires more than data retained for two days.
<dsinger> (Note that the first is a more explicit statement of the general statement on permitted uses; "In all cases, collection and use of data must be reasonably necessary and proportionate to achieve the purpose for which it is specifically permitted; unreasonable or disproportionate collection, retention, or use are not “permitted uses”.”)
<npdoty> that makes sense: does that sound like a promising approach to others?
... this is an issue where David and Lee will come up with a proposal. Will probably have counter proposals and discussion.
<dsinger> I will update the Wiki
justin: Please send proposals to the mailing list and you could also update the wiki.
fielding: Suggest to not spend
text on security. Rather black box approach.
... I could not interpret the text David posted.
<npdoty> dsinger, yeah, some of these sound like general restrictions for all permitted uses, rather than needing to be written to this specific paragraph
dsinger: Will not be normative text.
<trackbot> issue-208 -- Requirements on unknowing collection, retention and use -- raised
justin: Next issue - Unknowing
... Previously Jonathan wanted to put more obligations on publishers.
... *reading JM's proposals*
... Jonathan is no longer a member. Does anyone support his proposal?
... Will send out a mail to the WG and ask whether someone wants to take this up or make a new proposal.
justin: I tried to close this issue. To no avail. Much discussion followed.
<npdoty> current text: " A third party to a given user action that disregards a DNT signal MUST indicate so to the user agent, using the response mechanism defined in the [TRACKING-DNT] recommendation. "
justin: Rob van Eijk, Mike O'Neill, and Walter wanted to keep the issue open and include more specific requirements in the TCS spec.
<fielding> npdoty, TPE requires all parties to send "D" when disregarding, so that text needs to be updated in TCS (or simply remove it, since that is a protocol issue)
moneill2: Some members suggested
to provide the reason for a disregard signal in the Privacy
Policy. I think it needs to be specified on a case by case
basis or list of reasons.
... We should talk about potential reasons for disregarding.
justin: Think WileyS said that it would be difficult to come up with a comprehensive list.
<WileyS> Why would someone go through the trouble of implementing DNT only to arbitrarily send D signals? Makes no sense. We're chasing extreme corner cases here...
<npdoty> fielding, that's a good point, thanks; in particular it should be changed to apply to all parties. (I also agree it may not be necessary.)
moneill2: When we thought about the D signal, we expected it to be rare.
justin: We are hearing that it may not be rare. IE 10 example showed this.
<fielding> It should still be a rare circumstance. IE can easily fix their non-conformance.
Brooks: Careful about the language here. You are complying with the spec because the DNT signal is invalid without user choice.
<dsinger> If the user chooses to use that browser specifically because it sends DNT, then your disregard is, by your argument, straight out non-0compliant
<rvaneijk> dsinger +1
<Ari> . .. and how would you ever know that?
dsinger: If a user did chose a tool specifically for the DNT signal, that is a valid choice.
<fielding> 11 now.
Brooks: This does not hold for general purpose browsers.
<wseltzer> so those users have no way to ask for DNT, except by switching browsers?
justin: You say the choice of a UA has to show the choice for a DNT preference.
<fielding> wseltzer, correct -- the same as other browsers that have not implemented DNT. They can still use cookie-based opt-outs.
justin: specific privacy tool for example. But not a popular browser.
<wseltzer> so either alternative dis-serves some users' choice
<sidstamm> it's not unheard of for people to choose a browser based on security or privacy posture/branding...
justin: Question is, under TPE you have the chance to say “D” in this case. Rob and Mike are asking to provide the user with a reason.
moneill2: How you tell the user is important.
<Ari> it's also not unheard of for software to add features that the user does not know about or want
moneill2: But a D signal could be set for a number of reasons. Why not list these.
<justin> This discussion is mostly about WHAT to signify to the user about disregarding, not when it's appropriate to disregard . . .
<vincent> as a side effect of IE being widely used, spoofing IE11 user-agent string would sound reasonable to prevent fingerprinting, I assume DNT would be ignored in that case as well?
<justin> (And by "is" I mean "should be.")
npdoty: I understand your motivation. But it's not the way of writing the spec. We cannot guess the true intention of the user.
<fielding> wseltzer, there is no justification for violating the protocol in a way that causes the signal to be meaningless. If a user wants a working DNT implementation, they will have to use a less buggy browser.
<sidstamm> Ari, right. Point I was making is that claiming "nobody chooses x because of y" is not realistic, but saying "x is mostly not chosen because of y" is better.
<Ari> +1 brooks
<matt> +1 brooks
npdoty: Issue-207 is just about
how to communicate to the user why the D signal was sent
... I consider Rob's and Mike's point on enhancing transparency
<Ari> Sid, I understand what you're saying. But what we're talking about here from my POV is ignoring user choice in favor of a guess
<wseltzer> fielding, I wasn't saying what should happen, just noting the implications are on both sides
rvaneijk: I am trying to ensure
DNT's success in the EU.
... There it needs to function as a consent mechanism.
... I think it's fair if the user utilizes the browser to send his preference, it is not clear to the user why the preference was refused.
rvaneijk: Was it the UA, the configuration, an add-on. The user does not know.
<sidstamm> Ari, it's a grey area and I see a lot of disagreement about where (and how rigidly) the line should be drawn.
rvaneijk: We need to add transparency to level the field.
<Ari> Sid, that's an understatement :-)
rvaneijk: I ask for additional normative text for valid reasons to send D.
<rvaneijk> Where it is technically possible and effective, the user’s expression to tracking may be expressed by using the appropriate settings of a browser or other application.
<npdoty> Tk: D;misconfigured-user-agent
<npdoty> Tk: D;network-proxy-issues
<WileyS> There was a fairly exhaustive list provided to the email list from many - Roy sent an especially long list
<justin> Erg, sorry I missed that. Thought I was caught up on the mailing list.
justin: I have a hard time coming up with more reasons for the D signal than a nonconformant UA or add-on sending the signal.
<WileyS> I'd rather not be contained to a limited list as history has taught me we can't predict some of the more "interesting" moves by others in industry. I'll commit to providing a list of possible issues to the user but don't want the overheard of a limited list or enumerating specific purposes on each D response.
<npdoty> does someone have links to the list of possible disregard reasons?
justin: Would more normative text put a burden on implementers? Predefined list of reasons?
<rvaneijk> ok fair
<npdoty> rvaneijk: particular properties like "unambiguous"
rvaneijk: Happy to work on normative text.
Brooks: Would like to clarify that it is disregarding a signal not disregarding the preference.
schunter: Sometime the signal may convey a valid preference.
<fielding> "T" indicates that tracking will occur, and that is further described by the compliance array and qualifiers
<justin> I don't think we need to solve when and IE11 signal is ever a preference. I think Brooks's point is that it's unknowable (at best) and probably not a real pref.
schunter: Problem is we would do wrong to the users of e.g. IE10/IE11 that really made the choice.
<npdoty> I think in the text we refer to disregarding "a DNT signal"; similarly, we use "expressed preference" (rather than a guaranteed user preference)
Brooks: This is a side-effect.
But we are primarily disregarding the signal. Getting the
language right would move us closer to a solution.
... TPE currently talks about disregarding a preference.
<npdoty> to Brooks, should we change the language to disallowing "disregard" messages unless the site reasonably believes it to be in conflict with the user's preference ?
justin: Legitimate point. Agree with your suggestion. Editors to take this up post Last Call could be the way to go.
fielding: Tracking Prefernce is a predefined term. And this is what eevery signal conveys.
<npdoty> "received tracking preference expression", maybe
<dsinger> perhaps we should say “tracking preference expression” as that’s the full term used elsewhere?
<Brooks> if we are making formal distinction between signal and preference we have a techical problem
<Ari> agree with brooks. The document says "user's expressed tracking preference" not "tracking preference"
justin: Will discuss the joint proposal Rob, Mike and Nick come up with. Please keep Brooks remark in mind.
<dsinger> The document uses “preference” to talk about what the user sets in the UA, and “expression” for the signal sent
justin: That is it for today. Thank you all very much.
<dsinger> (I think)
justin: Congratulations on this important Milestone
<npdoty> Ari, so you agree that the fuller "user's expressed tracking preference" is better?
justin: And thanks for all of your work.
<Ari> what the user set in the UA, which is what the UA expresses. Not what the UA expresses as a result of something hard coded by an engineer who is not the user
fielding: Wanted to remind that regulatory requirement overrides our spec.
<Ari> nick, yes
fielding: Our first concern is
... We do not need to include specific legal requirements. They override TCS anyway.
rvaneijk: Got less to do with legal obligations but transparency for the user and help him.
<npdoty> indeed, but it's nice if complying with a common document will help you comply with common legal requirements, right?
justin: Next week, be nice to Ninja and volunteer to scribe
<fielding> npdoty, no doubt, it would be nice if everyone agreed to the same regulations.
<npdoty> fielding, that would be convenient, yes!
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/pony/point/ Succeeded: s/ju voted for/you preferred/ Succeeded: s/you preferred/you strongly supported/ Found ScribeNick: ninja Inferring Scribes: ninja Default Present: Jeff, npdoty, Ninja, Jack_Hobaugh, rvaneijk, WaltMichel, WSeltzer, dsinger, Chris_Pedigo, RichardWeaver, Ari, Chapell, hefferjr, moneill2, WileyS, Fielding, justin, Vinay, schunter, +aabb, sidstamm, dwainberg, eberkower, vincent, hwest, Brooks, MECallahan, MattHayes Present: Jeff npdoty Ninja Jack_Hobaugh rvaneijk WaltMichel WSeltzer dsinger Chris_Pedigo RichardWeaver Ari Chapell hefferjr moneill2 WileyS Fielding justin Vinay schunter +aabb sidstamm dwainberg eberkower vincent hwest Brooks MECallahan MattHayes Regrets: carl susanisrael Found Date: 23 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/23-dnt-minutes.html People with action items:[End of scribe.perl diagnostic output]