<trackbot> Date: 04 December 2013

<npdoty> trackbot, start meeting

<trackbot> Meeting: Tracking Protection Working Group Teleconference

<trackbot> Date: 04 December 2013

<ninja> Matthias will use my phone today, as we sit in the same conference room today

<ninja> justin, he just arrived

<ninja> one more minute

<npdoty> scribenick: ninja

<npdoty> with Amy to take over scribing halfway through

<npdoty> thanks to Ninja and Amy for volunteering

<johnsimpson> Apologies. Traveling today. Only able to join on IRC.

schunter: offline caller identification done. we can dive right in
... today mainly items from the batch closing, where I received comments

<johnsimpson> ?

schunter: my purpose is still to close them. Would like to address the concerns and find resolutions.

<Dsinger> Issue-153?

<trackbot> Issue-153 -- What are the implications on software that changes requests but does not necessarily initiate them? -- pending review

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

schunter: let's start with ISSUE 153

issue-153

schunter: to what extent can intermediaries change signals

<walter> correction, it is ISSUE 163, not 153

<Dsinger> Issue-163?

<trackbot> Issue-163 -- How in the spec should we ensure user agents don't twist a user preference one way or another? -- raised

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

schunter: Currently the text is flexible on the topic of changing the signal. Brad wants to insert text making sure only user agents can send/change the signal

kulick: Want to make the spec more adoptable. Let's take the well established user interfaces of user agents to get mor trust of the users

<moneill2> +q

schunter: So you have more concerns regarding the quality?

<Dsinger> Notes that plugins have UI and are really very different from routers, proxies, etc.

kulick: Yes, main concern is how user would interact with intermediaries.

walter: Think this is a non-issue. There is no way of verifying if a signal was inserted by an intermediary. So I would ask the websites to honor the signal that they receive

<fielding> The suggested text changes have nothing to do with issue 163

<justin> +1 to appreciation for providing specific text!

<walter> +1 on guidance

npdoty: These recommendations won't actually control the market place. It may have bigger impact to not forbid plug-ins but to put restrictions on them, and W3C shoudn't be restricting which technologies can implement a spec.

moneill: The tide is against user agent strings. Will be a problem to differentiate there.
... Exceptions could be established by the exception UI we have been discussing

bryan: limiting the agents that are allowed will limit our own scope and will not be future-proof.

<fielding> issue-176?

<trackbot> issue-176 -- Requirements on intermediaries/isps and header insertion that might affect tracking -- closed

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

bryan: many examples of intermediaries that already work and are in support of the user.

<fielding> issue-177?

<trackbot> issue-177 -- Should we specify compliance requirements for software and hardware other than user agents? For example, is a web server package compliant if it tweaks DNT headers? -- raised

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

bryan: fundamental question is how to validate a DNT signal. We will not solve this in DNT.

<fielding> issue-153?

<trackbot> issue-153 -- What are the implications on software that changes requests but does not necessarily initiate them? -- pending review

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

kulick: I hear the critique. The lack of actual control is an issue. I want to ensure that the manner in which we write the spec is the best manner for success
... browsers have more insights on what we want to achieve in user interaction. What I am looking to do is being more prescriptive on how to communicate with the users.

kulick, sorry. Not sure if I got this wright

right

<dsinger> An HTTP intermediary must not add, delete, or modify the DNT header field in requests forwarded through that intermediary unless that intermediary has been specifically installed or configured to do so by the user making the requests. For example, an Internet Service Provider must not inject DNT: 1 on behalf of all of their users who have not expressed a preference.

dsinger: I am concerned that websites may start ignoring DNT signals if they think it has been set by an intermediary

<walter> +1 on dsinger

<npdoty> kulick's change was about plugins:

<fielding> He wants to change the … unless that … part.

<npdoty> “Likewise, a user agent extension or add-on MUST NOT alter the tracking preference.”

<dsinger> +1 to Roy, re-visiting

<bryan> "unless that intermediary has been specifically installed or configured to do so by the user making the requests" - "installed or configured" covers a wide range of arrangements on how the user's preference is expressed by an intermediary

fielding: We may be going back on old ground here. There was an unresolved issue in the June draft on user agent compliance.
... I don't see the value in making this distinction. It will limit our options to set up restrictions for intermediaries.

bryan: Current text can be interpreted in a variety of ways. Even intermediaries can be specifically installed and configured by the user.

schunter: I think we have consensus. Kulick is the only member of the group raising this concerns. If we later find out that we run into problems with intermediaries, we can revisit the text.
... If kulick would withdraw his objection, we can close this ISSUE

kulick: We need to be more prescriptive in how the choice is offered to users.

<bryan> the points I make are general an not indicative of any position of my company - when I say "we are covered" under the current text, I mean that the group of stakeholders that I consider myself a member of, e.g. parents that care about how the web is used in their home, or users that want to ensure they don't have to manage DNT preferences in each and every device/browser/app they use

<Chapell> +1 re: providing granularity in how choice should be offered

schunter: Would a non-normative guidance, example URI be sufficient?

<npdoty> if the concern is about user education, we may have a different issue on that

kulick: Want to avoid biased presentation

schunter: Agree.

<fielding> The spec says "unless that intermediary has been specifically installed or configured to do so by the user making the requests."

schunter: dsinger, would it be possible to provide such an example of a model user agent?

<kulick> I will provide feedback today

<kulick> thx

<justin> Yes, the existing language seems fairly strong.

issue-161

schunter: looking forward to kulick's message later if we can close this issue.

<fielding> issue-161?

<trackbot> issue-161 -- Do we need a tracking status value for partial compliance? -- pending review

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

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

<npdoty> kulick, issue-194 might be relevant to your related concern

schunter: Next up, ISSUE-161

<fielding> overtaken by events

<kulick> thx Nick, I will review 194

schunter: Do we need a signal for partial compliance. The current status is either fully or not compliant.
... To us it was unclear how partial compliance could look like

fielding: Last week when I edited the TPE I removed this, as there is no way to define partial compliance within a self-contained TPE document

<npdoty> is dwainberg on the call? he had asked that this be kept open

schunter: I would like to discuss this Issue based on the TPE draft as it was last week and postpone the discussion on the editorial changes

<fielding> I raised this issue

<npdoty> or have it mean "in testing" (which would also imply non-compliance)

<walter> npdoty: +1

<justin> Well, I think this is all related to the idea of multiple compliance regimes.

<dsinger> "under construction, making no particular claims"

schunter: let us push this to next week as I need to contact dwainberg for clarification.

<npdoty> I think there were lots of people interested in an "in testing" flag, fielding, though I appreciate your having brought it up originally

<walter> justin: that too, if we have that this issue is even mooter than it is now

<dsinger> issue-197?

<trackbot> issue-197 -- How do we notify the user why a Disregard signal is received? -- pending review

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

issue-197

schunter: Now ISSUE-197. How to notify a user on a disregard signal

<dsinger> "An origin server that sends this tracking status value must detail within the server's corresponding privacy policy the conditions under which a tracking preference might be disregarded.

<dsinger> "

schunter: Based on whatever context a site may decide to disregard the the user signal. It could be beneficial to tell the user why his signal has been disregarded

<fielding> npdoty, yes, but without a single compliance document the testing mechanism is far easier -- just link to a testing compliance document.

<npdoty> I think the diff is just to remove the Option box around "5.2.7 Disregarding"

JackHobaugh: I wasn't sure to close this because I needed to give it more thought.

schunter: Let's also push this back to next week. Fielding, did I represent the old status correctly, that a disregard-signal should be explained in the privacy policy?

<amyc> Ninja, I can start scribing with next agenda item

fielding: Yes. It has not been changed in the current draft.

amyc, yes. thank you

<npdoty> JackHobaugh, what were your additional questions? (this has been stable text for many months, right?)

<Brooks> that becomes circular - if you are not in compliance then the "D" signal itself means nothing

Walter: I think a site that disregards signals cannot claim compliance.

<fielding> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#TSV-D

<dsinger> Roy deleted this sentence "An origin server that always responds with D is not considered compliant even if that response is compelled by factors beyond the origin server's control. "

<fielding> "Note that the D tracking status value is meant to be used only in situations that can be adequately described to users as an exception to normal behavior. An origin server that responds with D in ways that are inconsistent with their other published and unexpired claims regarding tracking is likely to be considered misleading."

<rvaneijk> +1 to Walter

Schunter: Understand your concerns. Unless you send a disregard signal you have to be compliant.

<fielding> dsinger, right.

<JackHobaugh> yes, we need to separate compliance issues from the TPE

dsinger: A server always sending disregard should not be able to claim compliance. It is a hole we should close.

<susanisrael> I think walter is proposing invalidating the use of the disregard signal. he is saying there is no valid reason to disregard a dnt signal. Is that right?

<dsinger> correction: the old TPE said that; we may need something similar but that isn't a formal link to compliance.

<fielding> nonsense

<fielding> As written in spec: "An origin server that responds with D in ways that are inconsistent with their other published and unexpired claims regarding tracking is likely to be considered misleading."

walter: It is important that unless the server sends disregard they have to be compliant as they claim.

<Brooks> +1 You can't have a signal that the use of makes you non-compliant

<kulick> +1 to susan's point

<justin> This seems like a question of semantics. You're compliant with the spec but you're not complying with the DNT:1 request.

<susanisrael> Justin, I think you are right.

<npdoty> maybe we're confused about "compliant": you're not complying with the expressed preference, but you could still be compliant with a set of rules

<npdoty> +1 justin

susanisrael: Don't understand what walter means. Does in your view disregard means yu contradict the claim of compliance?

<fielding> and this is why specs talk about conformance to requirements instead of compliance

walter: I am fine with a site claiming being compliant, but whenever they send disregard - the site is not compliant for this specific session

susanisrael, So the site is overall compliant but thinks they received an invalid signal.

<npdoty> fielding, you think we should say "conformant to the spec, non-compliant with the request"?

<justin> What the user does probably depends on what the user agent does in response to the disregard signal.

walter: Should be clear to the user that with a disregard signal received, he will probably being tracked

<fielding> npdoty, I think we already cover this in the spec to the extent we can without creating a universal compliance document

<susanisrael> I agree with Justin's and Nick's restatements, but I still think walter is saying you can never disregard a signal and be deemed a party (not site) that is compliant with the spec. I don't agree with that idea.

<amyc> matthias: Issue 217 and 228

<npdoty> fielding, I'm asking about your suggestions on phrasing

network transaction

<scribe> scribenick: amyc

<npdoty> I think this is just an announcement

Carl: where do we leave prior issue, raised by Roy, some confusion on agenda

<walter> susanisrael: from a user's perspective if you're tracking him/her (for whatever reason), you're tracking. It is the opposite of DNT to say that tracking can be DNT-compliant.

Justin: there is time to respond, wanted to say something about issue 151, share status

<fielding> 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

<npdoty> Call for Objections on 217/228 is https://www.w3.org/2002/09/wbs/49311/tpwg-interact-217/

Carl: we can discuss 151

<npdoty> comments requested by December 18th

<susanisrael> walter: the user may not have asked not to be tracked. That may be why the signal was not deemed valid.

issue-151

justin: options for 151, user agent must, should or may respond to request or no language at all

<npdoty> http://www.w3.org/wiki/Privacy/TPWG/Proposals_on_UA_requirement_to_handle_exceptions

<walter> susanisrael: there's no way of telling that from the server's end. And in an EU context the user doesn't need to express any preference not to be tracked.

npdoty: two options for 151, inserting

<dsinger> I thought the call for options closed ages ago?

<walter> susanisrael: if you don't send a disregard signal and claim compliance, you must adhere to the compliance spec

<susanisrael> walter: i was not thinking about the eu context but was suggesting that it doesn't make sense to include in the spec an option that makes the party that uses it non compliant. It's just illogical.

Matthias: in last call, cannot find consensus whether no language means implicitly mandatory or implicitly optional

<fielding> I am pretty sure that Shane's proposal is an explicit MUST

<justin> Yes, I think that was clear from last week's call.

Matthias: some disagreement amongst standards experts, so suggesting more explicit language

<kulick> Roy, yes, we are a MUST

<susanisrael> walter: i do agree that if you don't send a disregard signal and claim compliance you must honor the signal.

<npdoty> I think we're more likely to reach consensus with no changes to the text, which I believe has support from Shane and others

<walter> susanisrael: that is my point, if you do not claim compliance for a user whose signal you disregard, you don't need a disregard signal.

Justin: proposal from Shane, should be more clear that there is must

Dsinger: time for text submissions has closed

<fielding> I don't think this one was closed

<susanisrael> walter: and my point was that many people requested the inclusion of a disregard signal. You're just saying you don't want to include it. If that's your point, we should have a discussion about that, though I thought we already agreed to include it.

Dsinger: compliance depends on what you state, doesn't have anything to do with exceptions API, depends on what you claim you are doing - so happy with Shane's proposal to be silent

Justin: list of proposals due to be closed today, thought Shane wanted MUST to be more clearly reflected in document

<walter> susanisrael: I am not saying I don't want it included. I'm pretty agnostic to its inclusion. As long as none claims compliance while disregarding a signal without a disregard response.

<npdoty> do we have Shane on the call? I thought last call he agreed with me on not adding text

Schunter: but Shane did not submit text, not clear

<npdoty> and Shane expressed hope that David could support it as well, which I'm hopeful of

<susanisrael> walter: ok, I am ok with that. I think we can agree that if you disregard you have to send the disregard signal.

<walter> susanisrael: from a user's perspectif a 'disregard signal' or a 'non-compliance signal' are equivalent

<fielding> Nobody claims to implement a document.

schunter: if site receives DNT signal, should be confident that it can call API, per Shane

<walter> +1 to what dsinger says

<susanisrael> walter: If we stop the discussion before your last comment I think we are in agreement. So let's stop there.

<kulick> david, that's not a fair or accurate assessment

<fielding> dsinger, arguing that is counterproductive. The spec can link them. Shane wants to link them, so your opinion doesn't reduce the options.

dsinger: but browser may not have javascript enabled, so API won't work, could turn out to be excuse to ignore more signals

<npdoty> I think the understanding was that a UA can't implement the full TPE without implementing the JavaScript API.

Justin: that is POV that can be expressed in CFO, shouldn't have spec that can be interpreted different ways

<dsinger> I agree with Nick: If you claim to implement TPE, then you implement exceptions.

<walter> npdoty: that was never my understanding and was the origin of my original opposition to javascript as a vehicle for UGE

schunter: suggest to send around wiki, confirm whether these are options on table, so Shane can speak for himself, then can proceed to CFO

<npdoty> walter, the other proposed option (from johnsimpson) is to make it explicitly optional, which might fit your view

schunter: is this the final list, is there anything that was overlooked, if not then go to CFO

<fielding> Suggested text: "An implementation that generates a DNT header field MUST also implement the User Granted Exceptions API in Section X to enable the user to override their general preference".

kulick: confirms that reminder to be sent to list today, then proceed with CFO, then we are OK

<dsinger> There is no functional difference between a UA that (a) has JS disabled by the user (b) implements and always says no (possibly configured so by the user) and (c) doesn't implement them. In all these situations, the site cannot get the exception it wants, and will need to take whatever steps it feels warranted in the lack of the exception.

<kulick> amye, i want to make sure that today still allows time for proposals

walter: looking at TPE text (?), what happens if call never returned, what if user turns off javascript

dsinger: then have to have noscript element on page

<fielding> dsinger, now you are arguing against the use of a javascript API for this functionality, which I agree is a concern.

<dsinger> a 'noscript' element

nonscript

<npdoty> I think there might be some confusion about "respond", walter

<dsinger> can I review how the spec works?

schunter: if user grants exception, then browser sends DNT0 headers to site

<walter> npdoty: sorry for being such a lousy technologist

<npdoty> if the method doesn't exist, then calling it in javascript throws an exception; if the method exists, it's supposed to return void in any case

<fielding> discussions of compliance are not terribly useful at this point

<dsinger> it is worth reading http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#exceptions-by-sites before we discuss much more

schunter: asks nick to send reminder to group for last chance to submit text
... done with agenda, proceed with chairs call

<kulick> what section?

<kulick> 6.10?

<walter> dsinger: apologies for not being up to speed on the text as I should, again

<npdoty> kulick, dsinger is pointing to http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#exceptions-by-sites

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/on them/on them, and W3C shoudn't be restricting which technologies can implement a spec/
Succeeded: s/none script/noscript/
Found ScribeNick: ninja
Found ScribeNick: amyc
Inferring Scribes: ninja, amyc
Scribes: ninja, amyc
ScribeNicks: ninja, amyc
Default Present: dsinger, Jack_Hobaugh, WaltMichel, Amy_Colando, Fielding, Carl_Cargill, walter, Peder_Magee, justin, hober, +49.681.302.5.aaaa, LeeTien, sidstamm, npdoty, Jeff, +1.916.323.aabb, RobSherman, Andrew_Kirkpatrick, kulick, moneill, +1.323.253.aacc, Ari, schunter, Joanne_McNabb, Bryan_Sullivan, Wendy, Brooks, Chapell, [FTC], hefferjr, adrianba, rvaneijk, Susan_Israel, hwest, David_MacMillan, MECallahan, [Microsoft]
Present: dsinger Jack_Hobaugh WaltMichel Amy_Colando Fielding Carl_Cargill walter Peder_Magee justin hober +49.681.302.5.aaaa LeeTien sidstamm npdoty Jeff +1.916.323.aabb RobSherman Andrew_Kirkpatrick kulick moneill +1.323.253.aacc Ari schunter Joanne_McNabb Bryan_Sullivan Wendy Brooks Chapell [FTC] hefferjr adrianba rvaneijk Susan_Israel hwest David_MacMillan MECallahan [Microsoft]
Found Date: 04 Dec 2013
Guessing minutes URL: http://www.w3.org/2013/12/04-dnt-minutes.html
People with action items: