<wseltzer> trackbot, prepare teleconf

<trackbot> Date: 13 November 2013

<wseltzer> trackbot, prepare teleconf

<trackbot> Meeting: Tracking Protection Working Group Teleconference

<trackbot> Date: 13 November 2013

<Chris_IAB> just joined via phone

<Walter_webirc> npdoty: I should be muted now

<justin> One more minute . . .

<npdoty> any volunteers to scribe today?

I can scribe

<npdoty> scribenick: gshans

<ninja> confirmed

Justin: CFO on ISSUE-5 and ISSUE-10. Response due next Wed evening (11/20), then goes to chairs. CFO for ISSUE-16 today, extra week built in for that call to respond.

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

Justin: ISSUE-16 and ISSUE-204. Definitions of collect, share, retain, uses, shares, facilitates. Two options that will go to CFO. Difference is definition of collect vs. collect and retain. Do not have strong opinions about which to go with.

<susanisrael> npdoty, thank you. I thought he might have but wasn't sure.

<JackHobaugh> Justin, I did not see any way within the call for objections for Issue 5 and 10 for a WG participant to express whether the resulting definition should be ported into the TPE. Would it be possible to add this to the call for objections?

npdoty: Are there unreconcilable differences on these two?

<npdoty> thanks, justin, I just didn't know all the views expressed last week.

<fielding> on no definition

Justin: Not sure re: ISSUE-16. Jack - Justin thought there was a field on porting over to TPE or not.

npdoty: on party definition, Q4 is the comment field re: objections to moving.
... not on ISSUE-5

Jack: Thanks, that clarifies.

<npdoty> on issue-10 CfO: If you have an objection to including the party definition or definitions in the TPE document as well as the Compliance document, please describe your objection, with clear and specific reasoning.

<schunter> http://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Transience_Collection

<npdoty> I thought Justin just went over these, on issue 16/204

<fielding> sorry, wrong link is in the agenda

<Brooks> issue 5 has the wrong link correct?

<npdoty> issue-217?

<trackbot> issue-217 -- Terminology for user action, interaction, and network interaction -- raised

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

schunter: Point #5 on the agenda. Defintions - collect, share, use, facilitate. Two proposals on table. Option 1 defines retain, option 2 does not. CFO will be tonight.

<npdoty> issue-228?

<trackbot> issue-228 -- Revise the Network Interaction definition -- raised

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

<fielding> issue-217?

<trackbot> issue-217 -- Terminology for user action, interaction, and network interaction -- raised

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

<schunter> http://www.w3.org/2011/tracking-protection/track/issues/151 

<npdoty> I think the current wiki text we have on that is here: http://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Revise_network_interaction_definition

<fielding> yes, though I forgot to add my bits for 217 to that page

<justin> npdoty, can you change the linked agenda to http://lists.w3.org/Archives/Public/public-tracking/2013Nov/0054.html

<WileyS> Correct - Balance is key

<npdoty> fielding, can you do that this week? or merge with Jack's language if possible?

<justin> Thanks. The link for network transaction is wrong in the agenda. The correect link is http://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Revise_network_interaction_definition

Schunter: Issue 151: TO what extent user agent should be required to support user granted exception API. Should we mandate all user agents support exception API? Should site be able to engage with dialogue with user re: site-wide exception?

kulick: the fact that browser will retain DNT signal persistently. Should be some balanced mechanism on other end for exception.

<WileyS> IE10 (and 11) already implemented this - it's not difficult

Brooks: scope of compliance doc is to preference expression mechanisms to allow or limit tracking. can we do compliance doc correctly unless required for user granted exceptions in TPE
... of the compliance doc, part of that reflects allowing tracking. If TPE doesn't have mechanisms up to allow tracking, does that require rewriting the scope of the compliance doc?

<moneill2> I get doc not found to that 151 link

schunter: So both sides should be in TPE and in the compliance spec. So there should be a mechanism for user granted exceptions in TPE.

<Chapell> I believe that Brooks is implicitly refering to our charter: The mission of the Tracking Protection Working Group, part of the Privacy Activity, is to improve user privacy and user control by defining mechanisms for expressing user preferences around Web tracking and for blocking or allowing Web tracking elements.

Brooks: if you don't provide it, you can't claim it.

npdoty: do we need changes to the text? nothing says optional. We can possibly go forward with the current text.

<kulick> nick, what do you mean by optional?

<npdoty> although we did have an action open on dsinger who wanted to explicitly note this API as optional (or something similar)

<WileyS> Exceptions are mandatory - otherwise don't implement DNT

<WileyS> MUST

schunter: TPE is a range of functionalities that exist, but not all clients have to implement all pieces - unless an element is mandatory. Must determine what needs to be required.

kulick: having to have browsers support this is optional, but we should have this as a "must" - otherwise there's not sufficient balance.

<WileyS> "Should" is not acceptable here. For v1, if you can't implement, then don't.

<WileyS> +1

schunter: one proposal is the "should" should apply. "Should" means implement if technically possible.

<WileyS> +q

<moneill2> does anybody object to MUST?

<WileyS> No one that's part of the working group now objects to MUST

<fielding> if we have the API and it isn't mandatory, then its implementation status must be discoverable

<fielding> otherwise, we might as well not have the API and stick with cookies

Kulick: if you can support storing a DNT signal, you should be able to support storing exceptions.

<npdoty> WileyS, we have an open action item on dsinger (part of the WG, but sent regrets for today's call) with an alternative proposal

schunter; could be a few corner cases where it's not feasible.

<WileyS> We'll see if he follows-through now. If I'm able to convince him to not write an alternative can we have "MUST" stand?

kulick: then text should be clear to explain that context for an exception.

npdoty: as it is, it would be mandatory.

<schunter> "SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."

<schunter> "MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification."

<johnsimpson> Came late. I don't think it should be a must

<kulick> John, why don't you feel it's a must?

<npdoty> I don't think non-normative text with unenforceable normative requirements for non-compliant implementers will be useful

WileyS: Could add some non-normative text. If at this time you can't implement exceptions, you shouldn't implement the standard. dsinger was the last person who felt the opposite way.

<kulick> whoops, typo... John, why don't you feel it shouldn't be a must?

Chris_IAB: Also supportive of the "Must". If we have an API and it's mandatory, its implementation status should be discoverable.

<npdoty> +1, I think Last Call is a good time to get more implementation experience on this

<JackHobaugh> Also supportive of MUST.

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

<kulick> http://www.w3.org/2011/tracking-protection/track/issues/151

<npdoty> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#exceptions

<npdoty> there is no separate text requirement, it's just part of the spec

<Chris_IAB> Matthias, we are all on the privacy side

schunter: a MUST could be used to undermine DNT signals, but would better reflect balance.

<Chris_IAB> Looks like most people on the call/IRC support "Must"-- should we take a straw poll?

<Chris_IAB> Yes, John, about the USER, not the user agent (without the user's intent)

<WileyS> John, Not complex - IE already implemented.

<Chris_IAB> that's the entire point here

Johnsimpson: should be completely optional. Sending the DNT message, but dialogue should be optional.

<Chris_IAB> this is not complex

<WileyS> +q

<Chris_IAB> there is nothing technically complex here

<WileyS> -q

<Brooks> or he wants to say its okay to track

<WileyS> This is a conversation - there should be EQUAL and BALANCED opportunity for a Server to request and record an exception.

Schunter: if site cannot honor preference, it stops the dialogue. what would the alternative be?

<WileyS> Doesn't appear John is on IRC...

<npdoty> I think the question is whether we would define an API or if sites would rely on out-of-band, cookie-stored exceptions

Johnsimpson: if the site cannot honor it, the site isn't compliant.

<WileyS> Nick, not parity in persistence

<Chris_IAB> how would the user know John?

<npdoty> WileyS, agree, which is why I have advocated for and worked hard on writing this API; I'm just explaining what the options are that we're considering

schunter: reject signal would lead to what?

<WileyS> Anyone with any knowledge of technical standards understands there needs to be bi-directional communication for a standard to be complete.

<moneill2> +q

<WileyS> One way communication doesn't work

johnsimpson: so what happens without being convinced?

<Chris_IAB> this is not a lot of extra engineering… really

<kulick> so that you dont have to go thru the request and response flow over and over again

<npdoty> WileyS, I'm not sure we need to make any speculation about people with knowledge or not of technical standards; fielding, who we tend to think has some experience, has expressed doubts about the API for example

<WileyS> Nick, he's expressed doubt on the exceptions portion of the protocol but has continued to support a response from Servers (at least I think so - did I capture that correctly Roy???)

<justin> Fortunately, this is Week 0 --- glad to see good substantive discussion early on this.

npdoty: concrete steps forward. Followup with David Singer, and maybe John can provide alternative text that would discuss a concrete alternate.

<Brooks> -q

kulick: exceptions should have persistence. site will want to have storage for exceptions so as not continually ask.

<ninja> I think it's valid to ask about devices that won't be able to provide such a balanced dialogue. I have a hard time imagining exception requests on a smart watch

schunter: usability is a valid question w/regard to implementation

<npdoty> johnsimpson, do you want to provide alternative text? would you be interested in talking with David Singer about a potential "SHOULD" text?

<WileyS> Ninja, as an owner of 2 smart watches - they have fairly complex UIs and could handle an exception request through the attached smartphone or even within their own UI (more complex things happening today)

moneill: what a site should do should be the same as for javascript. don't think it's a big move.

<WileyS> Suggested path forward - maintain a MUST for now (current text) and if others feel strongly they can provide alternate text

<WileyS> Matthias, current text already has a MUST

<Chris_IAB> here we are again… the working group is going to divide, because some will let perfection be the enemy of good. There are folks on the phone who want this to support dog collars, watches and refrigerators, at the peril of an industry implementable spec. In that scenario, most users lose. Guys, these are EDGE CASES. There will always be edge cases.

<npdoty> WileyS, ninja -- the exceptions UI is on the site to get informed consent; that may be harder for sites on very small screens, but could still be possible

<npdoty> by when are we requesting alternative text proposals?

<johnsimpson> Nick, Glad to talk work with David Singer

<npdoty> thanks, johnsimpson.

<npdoty> initial draft text proposals by next week

schunter: populate wiki for next week, with alternative texts. can discuss concrete text proposals next week. multiple feedback mechanisms is a feature, not a bug. Initial draft text proposals by next week.

<justin> Yes, call next week.

<kulick> it's the week after

<Chris_IAB> Mattias, we are envious of ALL your European holidays… let us have a few, ok :)

<justin> We don't have *that* many holidays in 'murica.

<johnsimpson> Where does text exist now?

<Chris_IAB> you like to eat :)

<justin> Also, schunter, here is the wiki for network transaction http://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Revise_network_interaction_definition

Network Interaction

schunter: back to Issue-5.

<fielding> I still have a TO DO to update that page with a definition from issue-217

<npdoty> johnsimpson, on issue-151, the existing text is the current draft where the JavaScript Exceptions API is listed, like any other section

<moneill2> +q

schunter: concerned raised by david singer - concerns re: persistence network interaction.

<WileyS> I need to leave now...

moneill: network interaction is broader - why do we need it at this point?

schunter: not sure if there is an accidental inconsistency, but no need to define extraneous term

<npdoty> I think it's important to "collect" and "retain" definitions which talk about beyond a network interaction

<Zakim> fielding, you wanted to give an update on his alternative

<kulick> +1 if it's not referenced elsewhere

fielding: altnerative text discussed last week was the original comments made a couple months ago re: network interaction being vague.

schunter: other alternative proposal exists?

fielding: yes

schunter: major difference is...?

fielding: june draft had network transactions - network interaction (request/response pair or similar in HTTP) and mixed with set of requests starting from user's action. makes totally different contexts into one. Most of the rest of the use assumes single request/response pair. intention was to provide separate definitions for three different actions - set of actions, user generated action. single pair action.

<schunter> Def tracking version (B) contains "network transaction is complete".

schunter: chairs will check to see that definition is required.

<npdoty> and then a separate question from dsinger on whether the request/response pair correctly handles long-lived connections

<npdoty> it's in the collect/retain definitions

fielding: it was being used in definition of tracking from david singer. also being used in definition of collection.

<moneill2> +q

<npdoty> "A party collects data received in a network interaction if it retains that data after the network interaction is complete."

fieldign: deadline moved to next week?

<npdoty> fielding, you can provide your update today? if we don't have any others, then I expect we're good to go

schunter: yes, one more week.

<npdoty> so we're asking for any alternative proposals on issue-217/228 by next week, when we'll discuss and see if we need CfO or have consensus

<fielding> yep

<npdoty> call next week at the usual time. no call the following week (day before thanksgiving)

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)

Found ScribeNick: gshans
Inferring Scribes: gshans
Default Present: +1.646.654.aaaa, eberkower, +49.681.387.2.aabb, ninja, Chris_IAB, Joanne, RobSherman, kulick, npdoty, Walter_webirc, justin, Jack_Hobaugh, moneill, GSHans, sidstamm, Fielding, Brooks, Chapell, schunter, hefferjr, Susan_Israel, [FTC], David_MacMillan, Peder_Magee, WileyS, johnsimpson, WaltMichel
Present: +1.646.654.aaaa eberkower +49.681.387.2.aabb ninja Chris_IAB Joanne RobSherman kulick npdoty Walter_webirc justin Jack_Hobaugh moneill GSHans sidstamm Fielding Brooks Chapell schunter hefferjr Susan_Israel [FTC] David_MacMillan Peder_Magee WileyS johnsimpson WaltMichel
Regrets: LeeTien dsinger SomeTPACFolks
Found Date: 13 Nov 2013
Guessing minutes URL: http://www.w3.org/2013/11/13-dnt-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.