W3C

- DRAFT -

Tracking Protection Working Group Teleconference

11 Dec 2013

See also: IRC log

Attendees

Present
Jeff, RichardWeaver, dsinger, efelten, WaltMichel, hefferjr, npdoty, ninja, wseltzer, Jack_Hobaugh, Peder_Magee, +1.919.388.aaaa, Ari, schunter, hober, kulick, Susan_Israel, LeeTien, David_MacMillan, walter, moneill, justin, Amy_Colando, [CDT], AnnaLong, Fielding, GSHans, sidstamm, Bryan_Sullivan, Chris_Pedigo, adrianba, Brooks, Chapell, [Microsoft], johnsimpson, MattHayes, rvaneijk, dwainberg, eberkower, AWK
Regrets
Chair
justin
Scribe
JackHobaugh, ninja

Contents


<trackbot> Date: 11 December 2013

<npdoty> volunteers to scribe?

<JackHobaugh> I will give it a shot

<npdoty> scribenick: JackHobaugh

<AnnaLong> sure

issue-5 and issue-10

Justin: the chairs have evaluated Issue 5 and 10 and decided. Will be publishing results. Chair are in three different continents. The definition of tracking: have decided on option A - that definition should be included
... on the party definition, we have decided on option A which is based on Roy's reformulation of current text in the Compliance document.
... I can give a brief overview of why-adhoc. on tracking we found the objections to option B was broader. The TPE document is to be an expression of a desire not to be tracked.
... the TPE is heavily dependent on parties. In order for the definition to have meaning it must be know who is being referred to. Cognizant that many members of the group do not want definitions brought over into the TPE. So this is meant to be very closely limited.
... We thought the objection to D. Wainberg's definition were stronger because it was too open ended.
... We will be providing a written decision document.
... Don't want to debate the merits now.
... would be happy to take questions thought now.

Matthias: noticed shortcoming in the options when doing analysis. In the future people should make better proposals.
... feedback from the group was that the options were too broad.
... need to put more effort in to fine tuning the proposals.

<dsinger_> it is regrettable that the chosen option therefore conspciuously lacks a definition of Multiple" and "contexts"

Justin: agree with Matthias
... would be good to get to consensus by front loading discussion instead of going into C for objections process

issue-239

<ninja> http://www.w3.org/2011/tracking-protection/track/issues/239

<johnsimpson> apologies for joining late. which tracking option was selected?

<dsinger_> I think Roy's recent edit has also removed a lot (most? all?) occurrences of first/third party from the TPE

Matthias: Issue-239: Roy has removed dependencies in the TPE to the compliance spec. The TPE has to be self-contained. Let's walk through edits and then go to the issue-239

<fielding> http://lists.w3.org/Archives/Public/public-tracking/2013Dec/0044.html

fielding: refers participants to his email the summarizes the edits
... issue-136 has been moved to the top.

<wseltzer> Roy's email

fielding: section 5.2: I removed the 1 and 3 tracking status values
... replaced that with a "t" to indicate tracking with the notation that it would be explained elsewhere.
... changed the symbol used for the dynamic tracking status value from "x" to "?"
... in 5.4.3: I added "compliance array"

<walter> :-)

<walter> wseltzer: yes, they're too adorable

fielding: the compliance document will explain the qualifiers. removed third party member array. too hard to maintain array. in 6.11, I removed a sentence.
... possible that I could have missed something. look for when reviewing - examples that assume a particular view of compliance on part of the server.

ChrisPeidgoOPA: Concerned about the removal of first and third party tracking status values.
... seems like the group has already agreed on that construct.

schunter: If we don't need the definitions then the best is to remove them.

<npdoty> +1, I think indicating 1st/3rd was one of the more informative fields for users

schunter: signal called "1" means complied with the first-party rules so it is technically the right thing to remove.
... if we later have a compliance regime that distinguished between first and third parties then definitions would reappear. but don't want technical dependency on the definitions.

<dsinger> we could easily change "claiming compliance to 1st party rules" to "believes they are, and is acting as, a first party", if we have the definitions in the TPE

<fielding> We have issue markers in Terminology for the party definitions, awaiting the decision today. The 1/3 does not indicate whether the site is a first or third party

schunter: they would reappear as qualifiers.

ChrisPeidgoOPA: believes the distinction regarding parties would be useful. agrees that another compliance standard could set the rules for the parties. believe it is important to note that an agreement already exists.
... I strongly oppose and think there is value in keeping.

<susanisrael> dsinger's suggestion seems worth exploring

justin: when we return to the compliance document the first and third parties will be addressed

<fielding> dsinger, no site is capable of knowing that

justin: the 1 and 3 values in the TPE do not equate to first and third party.

<fielding> it depends on how the link was used, not how the site was designed

<dsinger> fielding: the site knows what role it thinks it is claiming.

<npdoty> fielding, dsinger, sites can know what they believe about how it's being used

<moneill2> it can be described because the whole idea of context is vague

fielding: the actual definitions of third and first parties will be the TPE definitions section. the only entity that knows the first or third party distinction is the user and that is not possible to describe in the TPE. It will specified in the compliance document. the 1 and 3 distinctions can still be added to the qualifiers sections -= cannotn still respond as a first party or third pary.
... so the information can still be communicated if needed.
... this is not the time to objection that level of detail. If you object to anything I removed, please write to the group explaining why.

dsinger: feels strongly both ways.

<Zakim> npdoty, you wanted to maintain agreement somewhere

npdoty: shares Chris' concern.

<susanisrael> +1 to npdoty

npdoty: but might be important to write down the qualifier route we are taking. Willing to do that in a separate section of TPE or in TCS.

walter: good idea to allow TPE to express what the server thinks the status it is operating in. Reason: compatible with notions of processor/control data.

ChrisPeidgoOPA: agree with nick.
... long standing agreement for 2 plus years. Want it documented that the group agrees.

<npdoty> +1 to Fielding that we take these details to the mailing list as well

ChrisPeidgoOPA: have already ported over definitions into the TPE that have compliance

<npdoty> issue-239?

<trackbot> issue-239 -- Should tracking status representation include an array of links for claiming compliance by reference? -- raised

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

<justin> issue-45?

<trackbot> issue-45 -- Companies making public commitments with a "regulatory hook" for US legal purposes -- pending review

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

<fielding> The next substantive edit is to incorporate the definitions decision today -- note that the definition of tracking does not depend on a distinction between first and third party, which is new information with regard to the WG's prior work. It would be a shame to get stuck in a very unsuccessful past.

schunter: Issue-239: user needs to know what compliance regime is being used. Could have different versions - W3C compliance plus something else. Do we want to keep the old link or do we want to make explicit pointers?
... I have to unfortunately run. Justin, take over.

<fielding> yes, these are all just proposals regardless.

<fielding> issue-239?

<trackbot> issue-239 -- Should tracking status representation include an array of links for claiming compliance by reference? -- raised

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

<justin> issue-183?

<trackbot> issue-183 -- Additional Tk header status value for EU -- raised

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

justin: on Issue-239 linked issue 45 that has grown over time to include D Wainberg proposal. Also issue-183.

isn't issue-47 also related?

<npdoty> JackHobaugh, Shane had asked about 47, but then suggested we use issue-45

<moneill2> +q

<fielding> Note that this provides only the technical ability to communicate one or more compliance regimes. It does not justify there being more than one, nor does it prevent the W3C compliance document from being the only one recognized by browsers.

dsinger: choices: TPE could be silent. Could have W3C as baseline Or we could have an alternative documented in the TPE. We need to have a discussion about it.

But on October 30 Chris Mejia also asked that Issue-47 be reopened. The problem with Issue-45 is that it is against the TCS and not the TPE.

moneill: don't understand how a user would understand the implementation of Issue-239.
... should be determinable by UA, plug-ins, etc. - pretty vague
... need to bring in some definition to this.

<fielding> As mentioned on the list, the URIs are just hierarchically assigned names. The W3C does not define central registries -- this is how we do IANA stuff.

<justin> issue-47

<trackbot> issue-47 -- Should the response from the server indicate a policy that describes the DNT practices of the server? -- closed

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

<justin> yes, jackhobaugh, I think that issue is implicated here too.

<moneill2> some of the group

<fielding> This is not issue 47 -- there is no indication that the user needs to follow those links.

npdoty: some concerns around designers options. we would like to get to some consistent view. trying to be clear about what the user is expressing. don't want to put a field in unless it will be used by the UA. wouldn't expect user's to inspect the different compliance policies that they might be using. May cause unwanted blocking. if it doesn't help the user, then don't see the value.

<dsinger> I agree with Nick that there are concerns here, and we need discussion

justin: is there defense against nick's concern?

fielding: that concern can be addressed by one array value.
... there is no guarantee that there will be a universal regime for compliance but if there is than an array of one will handle it.

<npdoty> but we aren't parameterizing the DNT header, we aren't giving users N options for different tracking they want to prevent

fielding: defining a protocol that is incapable of communicating that array is wrong on many levels - doesn't permit a server to communicate its status. Doesn't have to be evaluated by users.
... for example if the EU wants a stricter definition, then one way to do that is to provide an additional link in the array.
... all that is a reference to a standardized compliance document. Very easy to configure the client to have them verify a white listed set of tolerated policies.

justin: regarding one array value - if W3C leaves that open it would be on the UA to configure?

<dsinger> I believe that an issue was opened; would it be better to get written pieces, questions, concerns, and so on, in email? It seems odd to be spending time on a new issue on the call

<moneill2> fixed uri strigs?

<moneill2> strings

<dsinger> (Indeed, formally we said that any issues raised after a deadline that was some time ago would be addressed post last-call. This one seems to be getting special treatment.)

fielding: point is that this is syntax provided for the flexibility to set more than one value.
... if we don't added it would probably be added outside the spec
... that could come back to bite us at last call.

justin: regarding why this issue is now allowed: we realized that we have some dependency issues. And there have been related issues raised and that have been before the group for a long time.
... yes, in a perfect world we would be discussing this in the mail list instead of here.

<fielding> I don't think we ever closed the issues on TPE -- that was a closure for TCS

<npdoty> we can all agree now that we've chatted that we're going to use the mailing list for civil and constructive discussion on this issue.

would someone else like to take over scrubbing?

I meant scribing. :-)

<jeff> Jack, I can scribe

<ninja> JackHobaugh, I can take over

<npdoty> scribenick: ninja

<JackHobaugh> thanks! spell checker got me.

justin: Would like to have some constructive discussion before christmas. Encourage everyone to bring their opinion to the list. It's a crucial issue for the spec.

issue-153

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

justin: Now ISSUE-153

http://www.w3.org/wiki/Privacy/TPWG/Proposals_on_limitations_for_add-ons

justin: explaining both options currently listed on the wiki.

<dsinger> notes that the issue description correctly recognizes that plug-ins or browser settings are not intermediaries

<moneill2> +q

justin: Matthias urged that we batch close, but there were objections and then a discussion on the mailing list.

<dsinger> I also wonder what new information has come to light since we settled this in June?

moneill: My thought was first that an intermediary must not change the dnt signal. But in there may be constraints with regard to children. There are legal reasons to override the decision by a child to allow tracking, which is not allowed e.g. by EU laws.

<dsinger> pending review means "did the editor integrate the decision correctly?"

<Zakim> bryan, you wanted to recommend we stay with the existing text, any more restrictive text would place non-UAs out of scope of DNT, and not reflect reality in the market's response

<dsinger> (or it did back when I did the edits)

bryan: the proposal for the text chops off where there are requirements to change a signal. This would prevent innovative services to protect users privacy.
... This is contradictory to users' needs

kulick: one of the concerns I had: Giving the consumers an easy way to communicate their preference. We have not addressed yet how to handle exceptions etc. To build trust I was concerned of several different edge cases in the first versions

<bryan> if the goal is "ease", then requiring the user to set DNT preferences in each and every browser/app/device that they have, will not serve that goal. An add-on that can sync preferences across all of the browsers/devices that a user uses is the best and easiest way.

npdoty: The text as it is does not need additional prohibitions for edge cases. If we want to get it out quickly, prohibitions do not improve the spec

<dsinger> The current text is pretty stiff already. Why do we need to prohibit software that helps configure the browser, or works as a plug-in?

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

npdoty: suggest to focus on requirements than on prohibitions.

<walter> dsinger: +1

<walter> +many

dsinger: The text is already clear on the user being the one making the request and setting the preference. I don't see additional need to add the proposed text. We should not limit it to browsers as this would raise anti-trust concerns

<dsinger> The browser is *responsible* for the behavior of plug-ins.

<moneill2> they are set by the user

kulick: one of the problems with plug ins that we have is that we cannot identify who is actually setting and sending the signal

<npdoty> 153 was opened for non-plugins, because I think we had agreement on using text on plugins as of our discussions in December 2012.

<dsinger> We discussed this at length

kulick: we want to make sure that there is transparency on who is sending the signal

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

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

<dsinger> we *had* consensus on this, we were merely verifying the integration of text

justin: issue will go to CfO next week
... Options are well captured in the wiki right now.

<dsinger> I am puzzled that new options have appeared well after the deadline passed

<wseltzer> me too

<npdoty> dsinger, these options were submitted December 5th, at the chairs' request;

<npdoty> ... I may have gotten them into the wiki later, apologies

justin: .justin: *explaining the options on the wiki*

<Chapell> I don't think Shane is on today's call

<Zakim> wseltzer, you wanted to comment on "consensus"?

<dsinger> Jack concerns intermediaries; Shane's concerns origins

justin: possibility of eliminating a few of those?

wseltzer: on the last issue: I think there was just one objection to keeping the text as it is

<kulick> Alan supported my call for 151 going to CFO

<kulick> to the mailing list

<Chapell> Wendy - I supported Brad's call for 151 going to CFO

<Chapell> As did other folks

<kulick> whoops

<kulick> 153

wseltzer: maybe no need to go to CfO with this. consensus does not need to be unanimous

<kulick> thx

<npdoty> Wendy is talking about 153, we have the multiple options on 151

<Zakim> bryan, you wanted to ask why we mandate support for the exception interface, which can be disabled if javascript is off, as out-of-band methods are just as valid\

justin: Happy to take guidance. If a subset of the group wants to go to CfO with this, we will do so. Would like to hear rationales for this.

<moneill2> yes

<wseltzer> [in part, I wanted to make sure the minutes were clear]

<dsinger> to bryan: quite; there is no functional difference between JS disabled, an API that the user has instructed always to say no, and no API

<moneill2> yes

<moneill2> +q

bryan: Are we forbidding out of band messages with this? Bcause of the mandatory java script req

<fielding> OOB consent overrides anything in the protocol

<fielding> … assuming it is correctly noted in TSV as "C"

bryan: javascript may not be the only feature if the UA does provide some way of out of band approaches

<JackHobaugh> For a device to state it has implemented the TPE version x, doesn't it have to support the ENTIRE specification?

<sidstamm> apologies all, I have to drop off

<dsinger> yes, the TPE still has "C", as Roy notes: the origin server claims it has consent

moneill: We have been talking about out of band overriding DNT. If we now say that UAs must support java script we open the possibilities to ignore valid signals that are implemented differentlx

npdoty: Software has to implement all pieces of the spec saying MUST or SHOULD, but not those from the server side

<npdoty> ... and non-JavaScript user agents aren't going to implement the JavaScript exceptions API, no matter how many MUSTs we add

npdoty: and if it has no javascript is does not adhere to the java script requirements

<fielding> The most annoying thing about this conversation is that there is no need for an API that is limited to javascript. We could have defined the same thing using Cookies.

dsinger: from the server's side of view it's indistinguishable whether the API is implemented and just rejected the request for exceptions or has not implemented javascript

<JackHobaugh> I believe my proposal can be added to Shane's language if Shane agrees.

npdoty: Suggestion to merge Jack's and Shane's proposal

<fielding> … and a Cookie-based exception mechanism would have worked with intermediaries that add DNT:1

<kulick> Sorry, I dont think I can represent on this point for Shane

justin: will talk to shane offline

npdoty, sorry, understanding and scribing did not work in synch :)

justin: reminder for the open Call for objections. Please participate

<npdoty> fielding, we heard support from sites to a JavaScript API when we wrote it

<npdoty> ... thinking that interactivity would be useful, and that it didn't have to be guaranteed, just a common case

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013/12/11 18:26:33 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/reformulation./reformulation of current text in the Compliance document./
Succeeded: s/ca/cannot/
Succeeded: s/Will/Willing/
Succeeded: s/sticker/stricter/
Succeeded: s/Suggestion to merge Issue 153 and 151/Suggestion to merge Jack's and Shane's proposal/
Found ScribeNick: JackHobaugh
Found ScribeNick: ninja
Inferring Scribes: JackHobaugh, ninja
Scribes: JackHobaugh, ninja
ScribeNicks: JackHobaugh, ninja
Default Present: Jeff, RichardWeaver, dsinger, efelten, WaltMichel, hefferjr, npdoty, ninja, wseltzer, Jack_Hobaugh, Peder_Magee, +1.919.388.aaaa, Ari, schunter, hober, kulick, Susan_Israel, LeeTien, David_MacMillan, walter, moneill, justin, Amy_Colando, [CDT], AnnaLong, Fielding, GSHans, sidstamm, Bryan_Sullivan, Chris_Pedigo, adrianba, Brooks, Chapell, [Microsoft], johnsimpson, MattHayes, rvaneijk, dwainberg, eberkower, AWK
Present: Jeff RichardWeaver dsinger efelten WaltMichel hefferjr npdoty ninja wseltzer Jack_Hobaugh Peder_Magee +1.919.388.aaaa Ari schunter hober kulick Susan_Israel LeeTien David_MacMillan walter moneill justin Amy_Colando [CDT] AnnaLong Fielding GSHans sidstamm Bryan_Sullivan Chris_Pedigo adrianba Brooks Chapell [Microsoft] johnsimpson MattHayes rvaneijk dwainberg eberkower AWK
Found Date: 11 Dec 2013
Guessing minutes URL: http://www.w3.org/2013/12/11-dnt-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]