W3C

- DRAFT -

Tracking Protection Working Group Teleconference

29 Jan 2014

Attendees

Present
WaltMichel, Fielding, Ninja, Wendy, dsinger, npdoty, Carl_Cargill, +1.202.785.aaaa, schunter, moneill2, kulick, +1.202.785.aabb, joesteele, JackHobaugh, hefferjr, WileyS, justin, Bryan_Sullivan, rvaneijk, Chris_Pedigo, vincent, Jeff, Chris_IAB, walter, Brooks, [CDT], GSHans, [FTC], Peder_Magee, LeeTien, +1.202.370.aacc, [Microsoft], Chapell
Regrets
SidStamm
Chair
schunter, justin, carlcargill
Scribe
npdoty, GSHans

Contents


<npdoty> scribenick: npdoty

<Chris_IAB> Hi there, I just joined

<Chris_IAB> from a blocked number

<Chris_IAB> wseltzer, yeah, but I just gave everyone on this call a user exception to my DNT!

Announcement: Getting closer to Last Call

justin: wseltzer, can you briefly describe what getting to Last Call looks like?

<wseltzer> http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

wseltzer: Last Call is an important step in w3c process [link to Process doc]
... WG concludes they have a stable report they want to send for wider public review

<scribe> ... closed the major issues, while we haven't had unanimity, found options with least strong objection, complete draft with that

UNKNOWN_SPEAKER: release to the world for public review
... coordinate with any groups that have dependencies
... this is a complete spec, look at it, tell us if we missed anything, if anything needs update or correction
... then the group is required to make formally respond to comments received during that Last Call period
... a milestone: we've gotten work done
... now a good time to look through these requirements and make sure we have things in order

<WileyS> +q

justin: anything WG members need to do? (besides going through issues and making a decision)

<JackHobaugh> Regarding Last Call, how is "Record the group's decision to request advancement" accomplished?

wseltzer: chairs can help guide, make sure we've satisfied charter requirements, like communicating with other groups, and recording group decision

WileyS: helpful overview. we have a slightly modified process on TPE about opening new issues, one we're discussing today; we were going to have a lock set of open issues
... based on the current number of issues left, estimate of time left
... is there an opportunity to re-open issues? will we allow glaring issues to be corrected before last call?

<WileyS> What happened to ISSUE-143?

justin: not a lot of issues we need to close out beyond the ones we have queued up
... open to open new issues that might have changed, new information we would certainly take into account
... either for opening a new issue or revisiting a past decision
... sooner to bring to the group is better than later

cargill: whether we can open new issues now: agreeing with justin, if there's something horrendous or compelling, I think we could

<scribe> ... new information could cause re-opening, but needs to be compelling to re-open

<WileyS> Carl, closure on exisiting issues sometimes creates other issues that we hadn't considered previously.

<WileyS> Based on the current queue, what do you see as the timeframe to reach Last Call?  Any guesstimates?

justin: a lot of us feel we've worked so hard, want to get something done, have it pretty much right as we go to Last Call

<ChrisPedigoOPA> +q

justin: want to respect the work everyone has done up to this point

<WileyS> That's fair - thank you Justin and Carl.

justin: if there are issues, please bring them forward
... regarding irc question from JackHobaugh, regarding recording decision, like any decision, ideally by consensus

<ninja> ach Chris

wseltzer: same decision process as usual, unanimity is great, CfO possible

ChrisPedigoOPA: what's next?

justin: could take a one week to relax and celebrate and turn back to Compliance, open to feedback

ChrisPedigoOPA: and there was some talk about testing?

wseltzer: Last Call is not the end of work, review of comments by the WG, once comments are addressed, go to a call for implementations

<Zakim> wseltzer, you wanted to mention next steps

wseltzer: that step allows for testing
... and a Proposed Recommendation step before then going to final Recommendation
... require documentation of multiple interoperable implementations
... when comments, implementations and testing come back clean, we can move to Recommendation

justin: up to individual organizations about how they choose when and how to implement

fielding: haven't done editorial adjustment around the rest of the text based on the decided definitions
... some more work to be done on the document before going to the group for decision
... timeline?

justin: depends on editor availability? still have a course of weeks left to close out a few more issues

<dsinger> Dave has time to edit.  I would, however, be cautious of changing words that may mean something (like, formally defiend terms getting inserted.)

justin: hoping we would have the document in a good place in a few weeks

<dsinger> Roy and I could also have an editing party, since we both work in the bay area.

fielding: my work can be complete in a couple weeks, but have IETF and travel obligations in the next week or two

<Zakim> jeff, you wanted to comment on parallel processing between TPE and Compliance

dsinger: I'm back from travel, have fewer blocking obligations, happy to have an editing party in person if need be

<jeff> http://www.w3.org/2011/tracking-protection/charter-draft.html

prefers this URL: http://www.w3.org/2011/tracking-protection/charter

jeff: the charter suggests that TPE should move to Proposed Recommendation along with Compliance
... so will need to start moving to parallel processing
... a lot of WG focus will necessarily move to resolving Compliance issues
... public comments and external implementations will feed back into the WG, but a lot of that work will be done outside the WG

<fielding> my guess would be a complete editors draft by mid Feb and a WG decision to advance around first week of March

<WileyS> +q

WileyS: can we get a rough timeframe?

<fielding> I wasn't counting the open issues ;-)

<WileyS> LOL

justin: Roy's assessment in IRC is comparable or perhaps slightly more aggressive than mine

<WileyS> We need to include open issues as well.  Issue-143 needs to be pulled back on the queue - not sure how it slipped.

justin: would like that WG decision in March, based on very few and largely contained issues
... think the document is fairly stable

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

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: 143 is allowing technically the ability to pass, in as efficient a manner as possible, who set the DNT signal
... may have been closed because of another issue; otherwise shouldn't be closed

justin: signing DNT headers?

<walter> WileyS: and what keeps an add-on or intermediate router to claim to be the UA itself?

WileyS: not in a cryptographic sense, just an indicator of who set the header

<walter> eh, from claiming so

<ninja> WileyS, schunter closed it in April 2013

<dsinger> I think we need some archeology on why this is closed.  I think we had comments (from Roy?) that the problem was formally insoluble.

<WileyS> David, I believe its solvable but may come at some expense in # of bytes

<WileyS> We not provided formal TPE language yet - only the high-level issue

<WileyS> Was hoping to have dialogue on the issue prior to suggesting text - happy to do that now if it gets us moving on the issue.

npdoty: as I recall from memory, discussed in Sunnyvale, didn't see likely in the protocol to be amenable to adding "really-sure" signal

<bryan> The trackker says "Closed (unless I receive further input by April 16): - We will continue this discussion as part of ISSUE-194."

<walter> dsinger: I think not only Roy has said as much, others including me have done so as well

npdoty: and so we instead referenced a compliance issue (194) about what Compliance can do to help

justin: yes, text options would be useful, chairs will dig through to see if we need to open/reopen here

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

<dsinger> walter: yes, I only quoted Roy as he's usually quite firm and clear about his perceptions!

justin: if there are other issues, please bring them up now

<walter> dsinger: and tends to be right on the money on technical matters indeed

ISSUE-240: Do we need to define context?

justin: discussions of context, fielding, can you explain your change?

<WileyS> This isn't about "really sure" - its about "AVG Toolbar" set the DNT Signal vs. "IE10" set the signal.

justin: Rob, you had more than one proposal, can we delete earlier proposal in favor of the new one?

rvaneijk: could take the earlier one out, less likely to survive group's objections
... talking to Mike about something that aligns with earlier proposal, a user-centered way that could be used for consent mechanism in EU
... can delete proposal 2, list can be a little shorter

justin: can we merge roy's proposal and your new proposal? primary difference seems to be
... rob and mike would require the same-party property field of the tracking resource to be used -- is that same as fielding?

fielding: different in that there's a compliance requirement in addition to definition
... don't need MUSTs in defining a category
... fine. could make a technical argument that if it doesn't use the same-party property then it doesn't meet the definition

<moneill2> +q

fielding: but we don't expect users to see the tracking-status resource, so doesn't attach to users' understanding of their context
... context exists in the user's mind regardless of any technical constraints

justin: TPE already requires use of same-party for some purposes?

fielding: currently just optional. it's UAs that would decide whether to make decisions based on same-party
... change to my previous proposal: a completely separate entity couldn't claim to be part of a group identity if different data controller
... not a big change, just explains it further

<rvaneijk> We will edit our proposal and make it the same as the last line of the non-normatieve section: A context is limited to the set of resources that share the same data controller, are covered by the same privacy policy, share a common branding, and whose host domains, other than that of the document origin, have been declared in the same-party property of the Tracking Resource.

fielding: definition and an explanation that users would understand

<Chris_IAB_> there is more than one Chris on this working group

<robsherman> +q

justin: chris p., susan, rob s. had proposed a context definition by taking advantage of existing "party" definition

walter: a mandatory flag like same-party, so that the context (that they assume to be under) is communicated to the user
... should at least express what they think the context is in a particular interaction

<fielding> a same-context flag or a link to some resource that serves as an identifier for the context?

moneill2: why it's important to define context -- because tracking definition. advantage of having it in same-party

<WileyS> The current proposal is an attempt to change the previously semi-consensus position of "easily discovered" versus forced branding which we know will amazingly expensive in the real-world.  This will be a serious blocker to implementation.

moneill2: the UA can take advantage of it
... need the definition to be clear about what you mean
... would the user see it as tracking for a single site over time? should be some concept of time limit, even if we don't specify it

<walter> fielding: I'd be in favour of having a same-party being mandatory for parties that are willing to take responsibility for certain other parties' behaviour

moneill2: time would be an element to be described in a compliance element

<walter> fielding: and as such the UA should be able to parse that signal

<walter> fielding: if that makes sense to you

justin: second, time element, would be new language that's not currently reflected in proposals

<fielding> WileyS, which proposal has forced branding?

<WileyS> Rob's

<walter> WileyS: I don't see that in in Rob's proposal

robsherman: the effort is to make operation of the definitions more straightforward

<WileyS> Note - "Common Branding" - A context is limited to the set of resources that share the same data controller, are covered by the same privacy policy, share a common branding, and whose host domains, other than that of the document origin, have been declared in the same-party property of the Tracking Resource.

robsherman: these proposals looked a lot like trying to define what a party is, differences between common branding vs. easy discoverability
... seems like basically the same thing
... hard to implement if we have two things that are generally the same concept, but diverging on certain points

<walter> fielding: to a non-native speaker like me it reads as if the same-party flag can be used for that common branding

<WileyS> "Context" appears to becoming a proxy for "1st party"

robsherman: already agreed that easy discoverability, need a way for users to know which parties are operating which websites
... understand the motivation (Chris M.) about not defining context as a compliance term, but worried about implementation difficulty
... particularly if there are slightly varying ways between party and context

<walter> WileyS: but proposal 2 is going to be deleted anyway

<Zakim> dsinger, you wanted to comment on the context definition

<WileyS> Walter - I'm not following you - why is Proposal 2 going to be deleted?

dsinger: either 1) have an informal definition, for more detail look at the Compliance document

<walter> rob just said so in an e-mail to the list...

dsinger: or 2) have a formal definition that is complete

<moneill2> +1

<walter> dsinger: I think that would be a good way to go forward

<rvaneijk> +1 dsinger

<walter> +1 indeed

dsinger: currently have a definition that's used in lots of different ways without the formal definition

<Chapell> +1 to dsinger

<justin> rvaneijk agreed to delete his first proposed definition.

schunter: already decided on the question of whether or not to have a definition [of "tracking"], that's closed

Chris_IAB_: dsinger's comments make sense, need something like his later suggestions
... defining tracking at all is a slippery slope

<justin> gshans: can you take over for scribing when we turn to ISSUE-241 next?

Chris_IAB_: defining context is up to the Compliance regimes
... defining it in too much detail here will limit those who want to set up compliance regimes

<GSHans> Yes I can take over on Issue-241

Chris_IAB_: and we don't know how things will change in the future
... either have a formal definition but one that yields to any compliance document
... or just have an informal definition

fielding: the reason for this definition of context is the user's understanding of what they're requesting to turn off
... doesn't determine what the server does, purely on the user's perspective
... could leave "context" undefined entirely, in which case "context" is left up to the imagination of the user
... not pleasing for companies that could then be sued over their data handling procedures
... problem with party definition is that users don't understand ownership
... reasonable to want to put that back in, but implication is a confusing notion for the user

<robsherman> Roy, are you just arguing that we should reopen the definition of "party"?

fielding: some text problems: shouldn't use "collection" in a new sense, shouldn't use the "operator" language (more about data controller)

justin: sounds like a good suggestion to Chris P. Rob S. Susan, structural changes, maybe you could run changes by fielding

Chris_IAB_: fielding, are you supportive of having a definition in this document? informal or formal?

fielding: proposal is 1b, support having a definition for user communication in the browser

justin: seems like options would be 1b, 5, RvE 2nd, Chris M no-definition
... not sure coalescing is likely, but consolidating options is encouraged

ISSUE-241: Distinguish elements for site-internal use and elements that can be re-used by others (1/3)

<scribe> scribenick: GSHans

<schunter> https://www.w3.org/wiki/Privacy/TPWG/Proposals_on_elements_for_1and3_party_use

<justin> FWIW, this has now been published as a working draft too . . .

schunter: do we need 3d party indicator? Inputs are on the wiki. Current editors' draft has a placeholder called qualifiers. Questions are:

npdoty: editors draft is fielding's draft.

schunter: old version is useful only for historical reasons.

<npdoty> don't need the Last Public Working Draft section any more, which would only be relevant to a different issue and not currently under discussion

<npdoty> thanks

<fielding> I like the way it is presented in wiki -- easier for pasting

ninja: It was put in the wiki for reasons of understanding rather than as an option. That can be made more clear.

<bryan> apologies, have to drop off today for another meeting. i'll stay on irc

<dsinger> there are 14 occurrences of 'first party' and 18 of 'third party', but none of the other words related to the qualifiers that Nick proposes

<Chris_IAB_> fielding, I think I can live with your 1b proposal if we have to have this definition at all

<justin> The group is settled on definitions of parties, first party, and third party.

dsinger: 14 uses of 1p and 18 uses of 3p, but no other concepts mentioned by npdoty. Whether we need qualifiers that relate to a particular compliance regime is not clear to me. Should we included only defining 1p and 3p, but nothing else, as an option on the wiki

<moneill2> +q

schunter: first proposal by npdoty, would define some qualifiers. informally described but not defined.

<walter> permitted uses is a compliance issue

<walter> it may be useful to have qualifiers for them

<walter> but not strictly necessary

npdoty: as dsinger points out, could be describing use for a particular purpose (formally described as permitted uses). that has been agreed upon. usefulness of 1p and 3p is just for transparency. could be just used by compliance regimes. whether they get used is a Q, but this is a way to describe what we earlier had

<npdoty> I think moneill's definition is much like Roy's: "T" and "N" are similar to "1" and "0"

moneill: could be confusing if there are too many fs and ts, but if no one else thinks so can be dropped.

schunter: moneill - OK to drop proposal 2?

moneill: yes if no one else supports it.

schunter: do others want to back it?
... replacing tracking/nontracking with 1 and 0, and then you have add'l qualifiers?

moneill: yes

<walter> having qualifiers would be good

schunter: fielding - could you live with adding first two lines of npdoty's proposal to the draft?

fielding: do not want to remove proposal 3.

<justin> Is having values for just 1/3 less incorrect than having all of Nick's text? :)

<npdoty> fielding says he could live with either one, but much prefers his ;)

fielding: i could live with it

schunter: other options?
... both options are not radically different.

dsinger: if you're in debugging on user agent side, could be useful. could be useful in determining disjunct between 1p and 3p by user agent. could be helpful in disclosing unintended uses.

fielding: what is the cost of maintaining that?

dsinger: sites know what uses they're intending to do

<npdoty> the proposal is an optional indicator, though, not mandatory

fielding: but we're talking about all resources along sites.

dsinger: believe that they are distinguished effectively. don't think it's that onerous.

<Chris_IAB_> I'm not sure we can "crystal ball" how all sites on the WWW are built

<Chris_IAB_> I have seen some VERY funky stuff out there

<fielding> I am quite certain that the costs do not justify the useless information

dsinger: if we get feedback that this is problematic, we can change it.

<Chris_IAB_> are we solving for problems that actually exist, or are we imagining the problems that might be?

<npdoty> if nobody implements it, then we should remove it

dsinger: we'd have to work out some other way then. if problematic, don't implement it and fall into the unknown category.

schunter: keep it as a feature but if no one uses it, can remove it

<Chris_IAB_> schunter, I don't particularly like that approach

schunter: in testing, we can declare features "at risk" and drop or keep as necessart

<Chris_IAB_> …of adding extra weight to the protocol just to see if people MIGHT use it

<npdoty> from Process: In the Call for Implementations, the Working Group MAY identify specific features of the technical report as being "features at risk."

fielding: this is the only instance of 1p and 3p that would appear in the protocol. why not define in compliance doc rather than toe?

<dsinger> um, we HAVE definitions of first and third party in TPE now...

TPE

<npdoty> and then can remove such features after implementation experience

<Chris_IAB_> can we apply KISS to v1, and then after testing, see what else is needed…

dsinger: value to having useful signaling since it's in the TPE.

fielding: it's only in TPE because we haven't made the editorial changes to tracking

dsinger: we have to go through, find all the refs, and determine if they're necessary

<Chris_IAB_> dsinger, necessary by what measure of the word necessary?  (nice to have does not = necessary in my mind)

schunter: don't need consensus on this call. by default would go into CfO for these two options and see what comes out. this time they are similar and well-defined proposals in the CfO.

dsinger: do you need the option of just nick's with the two lines inserted?

ninja: can be done

<fielding> We had consensus on TPE's list matching the TCS list.

npdoty: reason the other text is in there is that we already had consensus on that.

<fielding> We DID NOT have consensus on including qualifiers.

<justin> Yes, but things have changed with decision to delink documents.

schunter: decision is not to remove qualifier, but just means that def of qualifiers will be in compliance spec.
... closed issues don't have to be imported into TPE.

npdoty: could make separate proposal to move text on permitted use qualifiers into compliance doc. would just have two options for CfO

<npdoty> I will propose text to add agreed upon optional permitted use qualifiers to the Compliance draft

<npdoty> ... which I think is a change from our decision, but not a major one at least

schunter: this closes the issue and the main work items on the agenda

Announcement: result of Call for Objections on network interaction

<ninja> link to result page https://www.w3.org/2002/09/wbs/49311/tpwg-interact-217/results

schunter: only item left is announcement of definition of "network interaction." we collected input. two choices. definition based on user actions. second def was more technical - specific user action and corresponding consequences of the user action. looked at all inputs and concluded that second option had less substantive objections. more technical 3-step definition had less objections from our perspective.
... intuitive defintiion was difficult to operationalize; second def was easier to implement. objection was that defining three terms was too much.
... option B was identified as consensus

<Chris_IAB_> I'm not in accord with the approach that we keep things in just IN-CASE we need them

schunter: "in case" means just means that it needs to be addressed in Last Call.

<npdoty> I thought the suggestion was that definitions *wouldn't* be in, say, a Last Call unless it's used

<Chapell> +1 to Chris_IAB

<justin> Have to what?

Chris_IAB_ - that seems like lazy spec development process. doesn't seem like consensus approach. better to have only things are required, not things that are just window dressing. would prefer to hash out needs vs. wants in this group, and apply the "will it break w/o this?" Q to all features

<justin> If the term subrequest isn't used, we'll take it out.

dsinger: responding to Chris_IAB_, i agree. DOn't use "sub request" in doc, so keep it out until it's needed.

<npdoty> have to implement subrequests as a concept in your web app because WG defined it but didn't use the term?

schunter: OK that makes sense.

dsinger: it's not in the TPE at the moment, but it may exist under a different name.

<npdoty> I thought what dsinger just suggested was the same as what schunter said to begin with, but maybe I'm not keeping up

<fielding> Definition of terms is useful for common agreement on editorial text just as much as it is for normative requirements.  I don't want to have to go through a month-long process every time someone disagrees with the meaning of a term, so when there is a discussion about terms we are better off talking about all of them that are related to help people understand the concept even if we don't use them.

<justin> So the concept is agreed, but if the concept isn't utilized in TPE, no need to define it.

schunter: more written details to follow
... adjourned

<Chris_IAB_> fielding, I couldn't agree more, but I think we still have to test which items are necessary and which are "nice to have"; that's my only point

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-01-29 22:26:22 $