Tracking Protection Working Group Teleconference -- 18 Dec 2013

<trackbot> Date: 18 December 2013

<npdoty> volunteers to scribe?

<npdoty> susanisrael can scribe to start, who wants to take the second half?

<ninja> i take over

<npdoty> scribenick: susanisrael

thanks, ninja

<ninja> yes :)

<npdoty> agenda http://lists.w3.org/Archives/Public/public-tracking/2013Dec/0090.html

<ninja> link to CfO https://www.w3.org/2002/09/wbs/49311/tpwg-collect-204/results

justin: had cfo on collecting retaining use share and they were not strong objections, but there were stronger objections to A, so we went with B (when such narrow differences in future chairs would appreciate avoiding cfo)
... when people object to how term is used please object to that not definition

<vinay> i don't disagree, justin

<dsinger> I proposed the same.

justin: note inadvertent error, that share requires you first collect. Not intended. Roy proposed friendly amendment, delete "has collected."
... vinay says he does not disagree--was unintentional. to be transparent will send revised definition to group and hope there are no concerns.....
... will send around in christmas/festivus spirit....

dsinger: not a minor problem. def says you share only if you collected. you could pass data around during transaction and that would not be sharing.

justin: did not mean to understate importance, just meant it was unintentional. Will send explanation around on collection.

<npdoty> reminder on deadline for network interaction Call for Objections: https://www.w3.org/2002/09/wbs/49311/tpwg-interact-217/

justin: one other reminder, cfo on network transaction closes tonight. Now move on to discussion of issues # ___ and 151

issues 151 and 153

Matthias: basically discussion on that one was that user agents/add ons, etc can modify preferences if they follow requirements.

on a high level, brad proposed only user agents can do so....

scribe: these 2 alternatives, and don't see easy way to reconcile them....

<WileyS> +q

dsinger: why do we need to prohibit plug-ins and add-ons?

<moneill2> the setter can change the UA string also

<justin> issue-143

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

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

wileys: primary issue is validation. today user agent string that says who user is and who set. Helps increase confidence in industry to implement standard
... as we allow other elements to inject signal we can't validate if they did the right thing...

<moneill2> if they change one header thay can another

goal is to increase confidence in industry to get strong adoption, and then ease scope from there, along with validation structure.

<FPFJoeN> 202.587 is me

scribe: discussed this around issue 143, and felt that would be too heavy (validation string) at outset, so narrowed scope to validatable source...

dsinger: sort of makes sense, discuss later, raises issues

wileys: goal is adoption

<npdoty> I don't think forbidding plugins will help with validating signals only coming from browsers

<sidstamm> hi all, apologies I am unable to dial in today, but will watch IRC

<bryan> UA headers cannot be validated today, how cabn they be used to validate the source of a DNT signal?

<moneill2> the asumption is that servers can discrimate compliance on inspecting the UA string

wileys: trying to get bulk of users/uses in v1 then expand

dsinger: could say if browser permits plug-ins and extensions it is responsible for result

wileys: fair

<moneill2> +q

Doesn't anyone else support kulick's proposal to prohibit add-ons and software from sending DNT:1 headers? On the recent calls, I don't think we've heard support for this proposal beyond kulick and WileyS. Anyone else?

<bryan> reduction of user choice is not the goal of the TPWG - removing user-requested functions outside the browser is a reduction in choice for users

wileys: it's ok if user agent makes sure plug in has done right things and takes responsibility?

<npdoty> I've provided updated text from Brad on the wiki: http://www.w3.org/wiki/Privacy/TPWG/Proposals_on_limitations_for_add-ons

Justin: i support kullick's proposal

wileys: text is purposely narrow

dsinger: agree that we're trying to find trustworthy signal, let's see if we can iterate on text

<justin> (I think susanisrael is saying she supports kulick's proposal, not me.)

<justin> This was scheduled to go to Call for Objection today.

* justin sorry, and yes, i support kulick's proposal

wileys: dsinger, you drive, we are fine with text and will review any changes you propose

<npdoty> it sounds like there was a potential iteration on plug-ins if user agents accept responsibility

<npdoty> David Singer will propose a new update, with review from Brad/Shane

<dsinger> thank you for the exchange

walter: short of hearing there is no way to validate i have heard nothing that makes any sense on this subject, and there is no way to validate signal
... i can't see how this language would enhance conficdence of industry
... we should stop wasting time on issues that are outside control of user agent

<WileyS> I couldn't hear very well - the last speaker was very mumbled

<walter> WileyS: sorry, Skype...

<walter> WileyS: long story short, stop bickering about validating the signal because you fundamentally cannot do so based on UA headers.

bryan: i dropped a couple notes on irc. user header is not validatable today. Any restriction on user choice is not in interest of tpwg or consistent with goal of tpwg. There are 2 options i submitted 12 december

<WileyS> Strongly disagree with Bryan - as to the purpose for our being here and to what the fair and balanced approach to validation may appropriately be

<walter> you probably cannot validate the signal anyway

<npdoty> sorry, Bryan, I must have missed the specific text alternatives; if you can help me find them on the mailing list, that would be great

bryan: either spec remains as is or remains silent on anything outside browser. These are 2 choices that are valid in my opinion

matthias: so now we have 2 texts that don't satisfy your requirement?

<npdoty> bryan, it sounds like the current text does satisfy your concern though?

bryan: i can submit language that says @@@. This text reads on nothing but browsers, this set. This whole argument is based on house of fallacy cards

moneill: if you can change one header can change another header. not true that user could look at user agent string as basis for deciding what to do

<WileyS> David - we will strongly object to that position

<walter> what about leaving normative language on ignoring signals to the compliance spec?

<justin> Well, we do have the disregard signal . . .

dsinger: heard a lot about balance here. should say that party MUST NOT ignore dnt signal based on suspicion about whether user set signal

<vinay> Agree with Shane. David -- that's also a compliance issue and shouldn't be addressed in the TPE

<WileyS> That means everyone would have to recognize IE10 even though we KNOW they are turning it on by default

dsinger: takes protocol away from interests of users

<ninja> dsinger, this may be related to issue 197 - the disregard signal

<bryan> reference to the proposal (I will add specific text for #2) is at http://lists.w3.org/Archives/Public/public-tracking/2013Dec/0074.html

dsinger: if hard to set then should make it hard to ignore

<dsinger> It isn't. It is an install-time option, as I understand

<adrianba> IE doesn't have a default - we prompt users during install or during first run on Win7

<adrianba> note also that IE sends different UA strings to different sites for compat reasons

<npdoty> vinay, does compliance for UAs need to be in the TPE, but compliance for servers be in Compliance?

wileys: i disagree. so IE10 forcibly activates signal as default. so then saying i still have to honor it? that's false. No one will adopt if forced to honor signal set by fault

dsinger: not true at all. YOu are ignoring validly set signals

<moneill2> WileyS, Shane you have to check for IE11 now and you cant do that (in fact) by checking the UA string

dsinger: not non compliant

wileys: it is noncompliant. we have to respond.

dsinger: i care about honest transaction

<justin> Let's move this discussion to ISSUE-197 later on the call.

wileys: if you say i believe this transaction not compliant, and here are alternatives, that is honest

<moneill2> +q

<justin> (We're rehashing old ground here.)

<fielding> nonsense

matthias: david why do you think shane is wrong

dsinger: shane you are completely wrong on this

<justin> Let's stick to 153 please.

* +1 to deep breaths

matthias: exhcnage arguments

on call for objections

<fielding> adrianba, defaulting to a set option during install is not the same as a user preference affirmatively selected at first use. Presenting IE's implementation as conforming to the protocol is completely absurd.

scribe: [who is speaking?] problematic. historically w3c has not listed broswers of day

<justin> (Yeah, we can't do that.)

<npdoty> +1, we should not (and I believe, do not) rely on lists of user agents

bryan: i was not suggesting you list browsers. was saying if you limited browsers to those following rules only then would be logical

walter: think we are arguing about a compliance issue not a tpe issue. This should be left to the compliance spec

<adrianba> fielding, protocols don't define UI

<fielding> nor, for that matter, is the pre-selected option a choice for privacy, since that option also pre-selects allowing Microsoft to collect data on that same user

walter: so issue 153--even though I agree with dsinger that IE10 should be deemed valid--don't think we should get in to this now

<adrianba> IE11 presents a checkbox during first run on Win7 if you haven't previously modified the setting in IE10

<dsinger> to fielding: an install-time choice, and asking the user, or even suggesting a setting, do not constitute a 'default'

<dsinger> I quite agree this is a compliance question

matthias: so if you want to get this in to cfo please propose text

<dsinger> The TPE merely has to say what the signal is and how it is formed

matthias: so you have user sending signals, and other side responding, i think it is a valid point that this could go in compliance text

<justin> NEW TEXT BY TOMORROW

dwainberg: i want to address this false issue of balance, as if there is any balance between sides of signal
... the costs, incentives, and consequences are very different on the 2 sides of the transactions

<fielding> adrianba, application level protocols communicate semantics, and when you deliberately lie about those semantics you are not conforming to the protocol. That is HTTP/1.1.

<WileyS> Justin, are you driving for text by tomorrow because we're moving to the CfO next week or will this be pushed out a few weeks due to x-mas and new years?

<moneill2> the contraint is already that it has to reflect the choice of the user

<fielding> dsinger, an install-time choice made by someone other than the user is not, by definition, the user's choice.

dwainberg: this notion of balance and tit for tat on what's said on client side and server side is ridiculous and we should dispense with it and focus on the outcome we want in marketplace

<justin> WileyS, well technically you were supposed to have next text in by last week! I would like to move to Call for Objection tomorrow night, and the response timing would take account of Christmas and New Years.

matthias: no agreement, so by tomorrow night ....walter suggested move to compliance...i want all this text by tomorrow night.

<dsinger> fielding: it's a choice presented TO THE USER. "Do you want fries with that?" is not McDonalds forcing fries on the population

matthias: next issue is 151.

<npdoty> 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> http://www.w3.org/wiki/Privacy/TPWG/Proposals_on_UA_requirement_to_handle_exceptions

<fielding> dsinger, you have obviously never installed IE10 or IE11

<WileyS> dsinger: more like, we've added fries with that, please let us know if you like to have those removed.

Justin: i can do that. John simpson is one of the people who wanted this to be optional and he is not on call so we may not get to agreement....

<WileyS> Sure - more than happy to merge

Justin: there are 2 proposals in wiki that are quite similar (Jack's and Shane's) so could we merge these? "If you send dnt 1 must be able to process uges. "

<npdoty> JackHobaugh, are you comfortable with Shane's text? I can more easily understand that text

Justin: so there is indication of willingness to merge... jack are you ok with other text?

<WileyS> Of course mine is better! LOL - just kidding. I need to read them again to see how best to merge but I think they are both saying the same thing.

<dsinger> can someone remind what technical reason (this is the TPE) there is to link exceptions and the DNT header?

jackhobaugh: i think shane was trying to broaden my language

<walter> again, this is a compliance issue, not a TPE issue

wileys: i have to read them, don't remember, but jack if yours just broadens ours, more than happy

justin: will ping you off line to pick one

<bryan> Neither option are adequate for me on this, I will add another option to the wiki

justin: now is a good time for questions

<WileyS> David, its about a fully formed transaction

dsinger: what tech reason to link exceptions and dnt? understand that industry looking for paper thin excuses to ignore

<schunter> This may also be a compliance issue...

wileys: really looking for fully formed transactions, so this is conversation not command
... this is why we supported response....want full conversations. If you can say no you should be able to say yes

<dsinger> this sounds like compliance to me. there is no technical link here

wileys: trying to bring balance to gain adoption

dsinger: you did say in cambridge you did not want to honor....(? not sure if this is what david said)

wileys: not true. But will register exception where granted.
... we did not refuse to store exceptions in user agent

<dsinger> in Cambridge we heard (a) we don't expect to use the exceptions API and (b) we intend to use the absence of it as (another) reason to ignore DNT headers. I am now hearing that (a) is no longer true.

wileys: instant on signal says no to everything. UGE is attempt to restore some equity

<ninja> susanisrael, I can take over starting from the next issue on the agenda

<walter> again, that is not a technical reason

wileys: I agree it is compliance-esc, but saying if you are implementing method A, must do method B

dsinger: not technical

<npdoty> I think it's the compliance of the user agent, right?

<dsinger> ok

<walter> npdoty: compliance to the technical spec or to the compliance spec?

matthias: david makes a valid point, that this may not be part of TPE.

<bryan> another option that should be considered, if we can't reach consensus on this issue, is to move the UGE to a separate spec on a different timeline (where e.g. we could consider other approaches including declarative), and support only out-of-band exceptions in the first release

<schunter> ... and one option may be moving it to compliance

justin: question for shane: came up in cambridge : why out of band consent to be retained?

wileys: for parity

<WileyS> Understood - non-JS supportive environments would not be able to support this

npdoty: i share concern about implementation, widespread adoption. My question is a clarification. Browsers with javascript off are minority, around 2 percent. for text by shane and jack do we interpret that as ...
... if user turns of java script do we say you have turned off dnt?

<npdoty> would certainly trust Shane's numbers as more up-to-date than mine

<npdoty> absolutely, it's not the common case, because JavaScript has been useful

<walter> WileyS: I disagree that DNT is comparable to willingly sacrifice some usability

wileys: if user de-activates javascript i think we could live with that; they are not getting other features. OK with that; we don't have to say DNT is off because they can't store UGE, or we could move to UGE in cookies

justin: i am confused. How would you know what's going on.
... why?

wileys: it's validatable. I don't expect major browsers to try to game the system in that way, just turning off js for UGE.

<vincent> javscript can be turned off only for a few domains (e.g. using noscript)

justin: do you need to revise proposals?

wileys: can use non-normative text

justin: would it be that if you are technically able to support UGE you must, but if you can't you can't is that right?

wileys: that's fair--consistent with Mike's and Walter's conversation on the list re: screen readers, etc.

<npdoty> I interpret that along the silence/editors' draft view; the API is required, but non-JS agents can't implement it

wileys: ok with UGE not supported where JS generally not supported....

justin: so "should"?

wileys: no keep it a must but provide escape clause in non-normative

<moneill2> sounds like a should

justin: let's work on this offline

bryan: i dropped a couple notes on irc. I think the case where you don't support this particular approach to UGE is a very important case. those people have to be protected. we don't want to eliminate...

<npdoty> out-of-band exceptions (likely stored in cookies) are already present as an option that doesn't require javascript

bryan: 2 percent of peoplle --a significant number. If we don't have way to support UGE without JS, should make it its own spec.
... reliance on a specific UA technology is really limiting

<kulick> spinning off UGE creates serious unbalance in the short term

<Zakim> dsinger_, you wanted to discuss timing

<dsinger_> Candidate Recommendation (CR)

<dsinger_> A Candidate Recommendation is a document that W3C believes has been widely reviewed and satisfies the Working Group's technical requirements. W3C publishes a Candidate Recommendation to gather implementation experience.

<Zakim> bryan, you wanted to note that user agents that do not support or have javascript activated need an option to support DNT and a javascript-only UGE process would exclude them.

<WileyS> David - that is not the answer you received - at least not from us

<fielding> actually, we are only talking about LC

<fielding> not CR

<WileyS> David - its not valid if it doesn't support UGE

<Chapell> David - I don't recall the discussion you are citing. In fact, I remember you being very upset as the discussion took a different turn while in Cambridge

<fielding> and no that whole argument is nonsense

dsinger: we have timing issue. I asked in cambridge if industry would behave like gentlemen and honor spec during implementation period/candidate rec. Answer was "NO." Apparently industry will not honor valid signals.

<WileyS> Not worth addressing

<npdoty> we'd be moving to Last Call (which is a wider comment period) before the Call for Implementations

justin: i will work with shane and jack to refine their proposal. Bryan if you want to suggest some other specific thing will try to get that done in next few days, but it's important and if it slips it slips......
... would like to have these discussions sooner in the timeline for cfo, though they are good discussions.

<WileyS> Can we discuss holiday timing? Its my understanding we're hitting the pause button for the next 2 weeks - correct?

<dsinger> after a Last Call ends, the document enters CR, guys

<ninja> scribenick ninja

<npdoty> scribenick: ninja

<WileyS> Thank you Justin!

<npdoty> we're not having calls for the next two Wednesdays, but I'm still expecting us to do work in the meantime on mailing lists

Justin: Holiday timing, christmas is next wednesday, then new years, so next call on Jan. 8

<WileyS> Nick, I'm sure everyone will be on the mailing list on Christmas ;-)

Contexts

Justin: Next issue-240 Defining context
... This is because objections raised against the definition of tracking

<npdoty> WileyS, I recall having replied to public-tracking on christmas eve in past years ;)

Justin: 3 ways to go: 1. not define at all, 2. tie it to parties, 3. new text

dsinger: first party context vs. third party context is not the way it is meant within the tracking def.

<kulick> david can you please restate

<npdoty> we may be overloading the term "context" indeed

<kulick> i am lost too

<moneill2> +q

<schunter> roy?

justin: context allows more flexibility

<fielding> I specifically explained the intent in the poll. It clearly does not represent a first/third party distinction, explicitly.

<dsinger> we are overloading 'context'. (a) context is either first-party or third-party (b) each embedding is a different 'context' (there are many)

justin: concept allows e.g. parties to change roles from first to third party and maybe similarly context

dsinger: not to confuse third party context with “whenever I collect data in a third party context it is the same context"

<npdoty> I think dsinger is referring to ways that the group have often used "context" in our discussions

<npdoty> from the explanation in the poll: For example, something along the lines of: For the purpose of this definition, a context is a set of resources that share the same data controller, same privacy policy, and a common branding, such that a user would expect that data collected by one of those resources is available to all other resources within the same context.

fielding: current definition releis on boundaries of user activity

<dsinger> The notes don't enter the spec. The definition says "outside the context in which it occurred".

fielding: one way could be that each designated resource has to state what it defines as “its context”

<dsinger> Roy, I am supporting your note that say we need a definition: "The above definition also depends on there being a definition of context"

dsinger: support the need for a definition to get rid of ambiguity of tracking definition

schunter: we want to define semantics of user's preference signal
... when he sets it the semantics should be clear

fielding: actually the same thing. If a given party has a common owner, privacy policy etc, it is the same context
... context as a defined set of resources

schunter: As I understand fielding - he suggests an easily discoverable list of resources that belong to same context

<schunter> Roy's proposed definition: Discoverable set of URLs

<npdoty> a natural way (which the group has past pursued) has been the breadth of a party

<JackHobaugh> So basically, what I am hearing is that the co-chairs ported a definition of tracking into the TPE for which the TPWG does not agree on the meaning of the terms used within the tracking definition itself. For example, the meaning of "context."

<dsinger> seems that a definition of 'context' is pretty central here.

<walter> yes indeed

<schunter> FYI (to Jack): The alterative definition was David's, which was rather broad. Defining this remaining term seemed preferable ;-)

<dsinger> quite how we can 'agree' on a definition of tracking when it depends on defining 'context', which is as yet undefined, is unclear to me

moneill: If we don't understand it, how can the user understand it? We need to define this clearly. Vague definition not helpful for a technical spec

<fielding> I think it needs to be defined and defined in a way that is discoverable by the user, but it also has to be flexible enough to suit a wide variety of multi-domain single-branded sites.

justin: A number of people on IRC, the phone, in the CfO asked for more clarity on context.

<schunter> A question I have: Are subsequent interactions "same context"? (If I visit SiteX once a month, can they cross-correlate across transactions?)

justin: I would like the participants to get out of this cal and start thinking on whether and how they would like to define context.
... continue this discussion on the mailing list

<schunter> Roy-Def: "the URLs listed in the same-party field"?

<npdoty> we have past agreed to work on easy discoverability for the breadth of a party, which seems to fit for this sense of "context"

<fielding> I also think that (ultimately) such self-identification of context would be evaluated by the same folks who would regulate compliance with DNT

<dsinger> As long as we clearly exclude someone being able to claim "all this data was collected in the third-party context"...

justin: For me it makes sense to tie it to the concept of party. But please send your ideas to the list.

issue-197

schunter: On issue-197. the current text disregard signal only rare and well defined conditions
... proposal of dwainberg to remove this sentence?

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

dwainberg: no. I agree with the intent. But think this last sentence is confusing and unclear.

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

<dsinger> I think it's a note explaining it, and is useful in that sense, and doesn't imply any conformance or requirements

dwainberg: I agree with the rationale that servers need to provide a rationale for disregarding signals.
... You cannot judge this basedon frequency of sending D

<npdoty> I think dwainberg just disagrees with the third paragraph (which is fine, just clarifying)

<npdoty> does someone who wrote this paragraph want to explain?

schunter: opinions?

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

dsinger: delete the second sentence and just leave the first one.

<fielding> schunter, not same-party (and in fact we don't even need that list). I meant just a link from a first-party resource's TSR to some resource that amounts to a name for that context. All resources that point to the same context resource would then be considered to be in the same context. Resources that are used across multiple contexts (e.g., third party subrequests) would not be allowed to make such a link.

<schunter> Roy: Can you propose text for the ISSUE-240?

<npdoty> fielding, do you have a background on this paragraph or any preference?

dwainberg: that would be better. But how to describe adequate behavior if it is unclear what is normal. Sending D could be normal and adequate behavior.

<justin> fielding, What would stop a publisher from including non-affiliated parties in the TSR? To allow for tracking that a user wouldn't necessarily expect?

<kulick> it would be normal if all browsers weren't compliant

<walter> am I the only one hearing 80's synthesizer music?

dsinger: suggestion - We could not envision a case where a server would have reason to disregard most or all DNT signals

<vinay> Did someone place the group on hold?

<walter> I think we should sick the RIAA on someone?

<Chapell> Wainberg - like the academy awards speech where you went on too long (:

<justin> dwainberg, is that you?

<justin> nope

<dwainberg> I don't think that's me

<eberkower> Zakim doesn't recognize that music as noise

<schunter> Can you mute all?

<moneill2> its the NSA

<kulick> could someone at least add some vocals to accompany it?

<laurengelman> this is a first for me in conf calls

<justin> Well, to the list then? :)

<laurengelman> heheh

<JackHobaugh> Maybe it is Zakim.

<WileyS> Can Zakim not figure out where it's coming from???

<wseltzer> WileyS, no, it couldn't

schunter: back to 197
... question is, do we find better text to say that we expect the D signal to be the exception and not the rule?

<walter> it is clearly non-normative

dsinger: phrasing: if you encounter such situation (server always sending D), please get back to us, because we did not envision it being used that way.

<npdoty> is the suggestion that we should make it non-normative note and clarify?

<fielding> The text already says that.

<fielding> It is already non-normative.

<npdoty> ACTION: singer to propose an update on normal/abnormal on D signal [recorded in http://www.w3.org/2013/12/18-dnt-minutes.html#action01]

<trackbot> Created ACTION-434 - Propose an update on normal/abnormal on d signal [on David Singer - due 2013-12-25].

schunter: action on dsinger to propose new text and then group assesses whether it is more acceptable

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

<npdoty> fielding, it's not marked as non-normative or as a Note, maybe it's hard to do that when surrounded by an option box

<fielding> Normative text in TPE is indicated by RFC2119 terms, not silly paragraph labels.

schunter: on issue 239. several proposals on the mailing list since last week

issue-239

schunter: what's the status on this. Can we reach consensus without a CfO?

<dsinger> what was the published timing?

dsinger: have not studied it yet. deadline?

schunter: currently M1. We are just looking at text proposals.

<WileyS> We're fine with the text "as is". I believe Roy has done a good job defending his thinking and approach to the current text.

schunter: soon after holidays I would like to freeze proposals.
... underlying question is - should a site be able to specifically link to a certain compliance regime?

<dsinger> ok. we may need to discuss what the requirements on the pointer or regime are, for example. I will think about it

npdoty: mailing list better for detailed discussion. Sent my proposal there.
... Would be useful if we had something coming back to the user indicating the compliance.
... /me npdoty, missed second part of your statement. you were blurred.

<fielding> Nick's objection is at http://lists.w3.org/Archives/Public/public-tracking/2013Dec/0095.html

<npdoty> npdoty: useful to give a common compliance response to the user

<npdoty> ... for the same reason that we don't parameterize the signal being sent by the user

<npdoty> ... two propoals; 1) to return to previous text (our last WD) that indicates compliance

<fielding> My response is at http://lists.w3.org/Archives/Public/public-tracking/2013Dec/0098.html

<npdoty> ... or 2) if the group prefers to remove compliance, at least capture the existing responses

<npdoty> ... for compliance in an appendix or in the Compliance document

<npdoty> scribenick: npdoty

schunter: could have a more explicit statement even if all pointing to the same document

<fielding> slacker

npdoty: haven't responded to Roy's message from 4am. :)

<Zakim> dsinger, you wanted to discuss user information

schunter: if we all agree on a single compliance document, it doesn't hurt for us all to point to it from the array

<dsinger> http://www.w3.org/2011/tracking-protection/drafts/dnt-for-users

npdoty: brief response is that if the goal is just a single compliance, then extra architecture is unneeded and could be confusing

<fielding> The motivation bits being ...

dsinger: had worked on an explanatory document for users, with no responses on the mailing list
... hard to explain to users what it means to them without a common baseline

<fielding> … If a user is not interested in verifying compliance (the far more common

<fielding> case), no response is ever obtained or checked.

dsinger: hard to help the users make an informed choice, if the meaning is a multiple set of compliance regimes

<fielding> … If a user is interested in verifying compliance, they will have to rely on some communication of compliance by the server. Preventing the response message from communicating such claims directly prevents deployment of this protocol without a completed Compliance document, and even after such a document is produced we would have to *add* a similar link or versioning feature if that document is ever allowed to change. …

dsinger: that's the conceptual problem, wanted to respect the industry request for users to be fully informed

<fielding> … In contrast, the compliance array solves this communication problem directly, without reliance on some future TCS deliverable, and does not in any way prevent TCS from becoming the one true consensus at some time in the future. Implementations can use the existing TR links to indicate compliance to specific versions of the TCS.

walter: @@@; web of trust plugin for firefox, for example
... not to dismiss the concern, but may be a way to get out of it
... was hoping for a meaningful compliance specification
... but discussions have shown unbreachable concerns, can't get to common baseline
... for example, what we've discussed hasn't met the requirements of the European Union

<dsinger> But adding an "EU specific layer" ON TOP of a baseline is fine. we can still explain the baseline.

walter: w3c may not be the best avenue to fix the compliance bit

npd: walter, sorry, missed your initial point, what was the response to dsinger's concern?

<dsinger> if there is no common basis, what do we explain to users before they start browsing?

walter: would like chairs to respond to original poll regarding ways forward

<dsinger> is happy to let people puzzle over this problem and discuss in email (or future)

schunter: run over on time; look at alternatives
... a longer discussion what we will do after the TPE document

<walter> npdoty: my initial point is that at least publicly acknowledging that the TPE as such means nothing that a user could derive an expectation from would open the possibility for third parties to step in

<dsinger> only 3 have to date!!

reminder: objections on network interaction are due tonight

<justin> Happy Holidays all!

[adjourned.]

<bryan> I sent proposed text for Issue 153 as requested.

- DRAFT -

Tracking Protection Working Group Teleconference

18 Dec 2013

Attendees

Contents

issues 151 and 153

Contexts

issue-197

issue-239

Summary of Action Items

Scribe.perl diagnostic output