Tracking Protection Working Group Teleconference -- 08 Jan 2014

<trackbot> Date: 08 January 2014

<Chris_IAB> I just joined via a private number

<npdoty> any volunteers to scribe? (we can split halves of the call, if it helps)

<vinay> Sure, I can do the first half and hand it off to Wendy

<npdoty> scribenick: vinay

<wseltzer> ISSUE-153?

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

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

schunter: first issue -- issue 153
... already have several proposals. today is the day to announce the CfO and pick one of the options

Justin: Brad reach out to him; Brad is working with singer to see if they can merge/come up with new language
... has asked for another week

<bryan> The links posted don't work

<WileyS> +q

dsinger: exchanged some emails, but was inconclusive. singer is trying to find the emails

<npdoty> is Bryan on the call?

wileys: Brad is on vacation, but will put a draft to David when he's back for vacation

<dsinger> I suggested "A user-agent that permits an extension or plug-in to configure or inject a DNT header is jointly responsible, with the plug-in or extension, for ensuring that the rules are followed." but we are waiting for Brad

wileys: should be back and able to respond in time for next week's call

Justin: fine pushing it back a week in hopes of avoiding a CfO

<WileyS> Thank you

Justin: will ping Brad on Monday about it

<bryan> when will the draft text be shared? can it be shared with me in the meantime?

Justin: if the gap isn't bridged by next week, then we'll move to CfO
... if anyone else wants to be involved on the issue, let Singer or Brad know

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

Justin: For issue 151, we have been static for a while

<WileyS> -q

npdoty: we've heard a couple proposals from Bryan; and that the first proposal is just the current text. Is that right?

bryan: its probably pretty close. will check offline (with npdoty)

<npdoty> I think listed Proposal 3 is the same as the Editors' Draft text, modulo editorial fixes

bryan: current text is a bit more wordy, but it says the same thing as Bryan's proposal 3

Justin: thanks to Shane and Jack for merging their proposals, there are now 3 options

one by john simpson, and one by shane/jack

Going to start the CfO today

<npdoty> ... and the existing text

(got it -- thanks Nick!)

<johnsimpson> think the options are clear...

<npdoty> no change is still an option, yes

scribe: Shane's existing text is no longer part of the CfO

but option 1 is the existing language in the draft

Justin: Issue 240

<FPFJoeN> 202-587 is me

Want clarifying language on context, since many (including one of the editors) is unclear on it

<FPFJoeN> oh! nice.

Justin -- we could just define context as party and be done, but nobody proposed it

Mike and Rob both submitted language for context

scribe: alternatively, we could have it undefined

<moneill2> +q

<Zakim> dsinger, you wanted to talk about context

<ninja> sorry, link is somehow broken - http://www.w3.org/wiki/Privacy/TPWG/Proposals_on_the_definition_of_context

singer: we risk having confusion. we've thus far used context to distinguish between 1st party and 3rd party. Leaving it undefined may cause confusion

<npdoty> +1, we are overloading "context" by using it sometimes in different ways

moneill: ambiguity over issue of multiple contexts. concern over 'data collected in a 3rd party context can still be collected in a 3rd party context.' (I'm not sure I got this right)
... should have a definition of across multiple contexts

Justin: I was a little confused over your definition of context in a place where you can express consent.

moneill: we are not talking about parties, we are talking about context. and so the consent should be done in context. there is ambiguity when we're talking about things collected across multiple contexts (doesn't want things combined across unrelated contexts)

<Ari> Sorry Nick, it should be on mute but let me try using a diff headset

Rob V: Wants to offer a user-centric definition. feels right now its too industry focused

<npdoty> rvaneijk, I don't understand defining "context" in a way that includes permitted uses

fielding: The way context is used here, its talking about the environment in which the user is making decisions
... hoping someone can further explain Rob V's definition. The proposal by Mike is the opposite of context in Roy's position
... hoping for further discussion before a decision is made

<rvaneijk> I think there needs to be discussion on the mailinglist as well.

<justin> Tracking is the collection of data regarding a particular user's activity across multiple distinct contexts and the retention, use, or sharing of data derived from that activity outside the context in which it occurred.

<moneill2> +q

Justin: I believe context is used only in the definition of tracking. Is it used elsewhere, or does it impact other definitions?

Mike: There should be some idea of context in the user's experience. trying to get across the idea of the user's relation

<Chris_IAB> Contextual advertising is a form of targeted advertising for advertisements appearing on websites or other media, such as content displayed in mobile browsers. The advertisements themselves are selected and served by automated systems based on the content displayed to the user. http://en.wikipedia.org/wiki/Contextual_Advertising

Mike: we need to come up with something better than what we have

Justin: Roy's definition is narrower than the definition of party that we agreed to

<Chris_IAB> isn't context well defined in prior art?

<fielding> My proposal was "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."

Justin: it does require a degree of branding which helps for experience
... I don't think we're trying to be that precise to keep experience to one page

<npdoty> Chris_IAB, that would be context as the content of a single page, right?

Chris M: Put in definition of contextual advertising (from google search)

scribe: to the port of the use case from the advertising perspective that its an ad served against the context of the content available to the user at that page
... has nothing to do with historical record of context

<moneill2> +q

Justin: using that concept of context is more consistent with the rejected definition of tracking
... we're not trying to restrict what we generally think of as first party advertising

<Zakim> npdoty, you wanted to ask if we can use party

<fielding> Please note that "context" is a general term that is intended to fit many many use cases -- much like "set". Contextual is certainly based on the same notion, but that definition of contextual advertising is far more constrained than actual contextual ads.

npdoty: Roy's definition refers to party. Can we re-use the definition pf party?

<Chris_IAB> npdoty, that's correct

<dsinger> +1 to Nick: surely a context is at least 'a party' with maybe some extra text

<fielding> no

<ChrisPedigoOPA> +1 to nick

fielding: Our definition is limited. it avoids service providers and contractors vs employees

<npdoty> party already refers to "easy discoverability", "intends to interact", "context of a given user action" etc

Justin: Would that be solved if we revised party to add the concept of service provider in TPE?

<npdoty> ... and doesn't require a new definition, or rely on data controller

fielding: Tried to do that for months but the group didn't go that way. There are valid reasons to keep corresponding party = legal entity; so context is needed to perform something similar. Although for context we're talking about user expectation
... the user is browsing disney jr (for example), the user knows they're interacting with a disney site
... may be questions on whether they're interacting with other disney sites. not claiming to know the answer to what a reasonable understanding is
... but it is clear/fair to understand that the user expects to operate with the owner/brand of the site (in this case, Disney)

Mike O: I think the problem we got now is multiple context. I believe we're already down a path where we understand the concept of a processor

<fielding> NO, WE ARE NOT GOING TO REVISIT ISSUE-5

scribe: we should focus on defining context and keep the definition of tracking into the compliance spec (or another forum)

Note: I'm not sure I got Mike's points correctly

Justin: Lets keep as parameters the language we've adopted

David W: Shocked that we're discussing the definition pf party as the definition of context

scribe: neither the definition of tracking included parties (instead, they included contexts)

<moneill2> +q

scribe: sees it as a bait-and-switch to now use the parties of definition of party as context
... can't support adopting the party definition as the definition of context

Justin: Roy proposed a definition to support the definition of tracking. He understands why you don't like the definition of party. As an alternative, lets try to further flush out the language

<npdoty> the notes that went along with the definition of tracking when we chose it refer to party concepts

Singer: an approach that takes no more than the party (but more narrow than the party may be acceptable)

<fielding> Note that my proposal does not use the word "party"

Mike O: We did say in option B to refer to parties (not context)

<Brooks> if you choose a definition which has a key reliance on an undefined term, have you really chosen a definition?

<fielding> perhaps it should say "data controller(s)" instead of "data controller"

Justin: At least three people on the call expressed interest of linking to party.
... others have expressed that it isn't a good idea
... invites people to suggest language/proposals to the group

<Brooks> +1

Brooks: Would say fundamentally that if tracking relies on context, the CfO for tracking may re-open itself if we define context at one end of the spectrum that results in a change in the definition of tracking

<dwainberg> +1 Brooks

Brooks: undermines that there was credible work done on the definition of tracking if the definition of tracking is still wide open

Justin: Rather than say 'this is all messed up', would prefer a concrete proposal on how to handle this

<npdoty> so is that not a concrete proposal?

<johnsimpson> Exactly right; we punted

<rvaneijk> +1 the definition of tracking is not set due to an open end to what context means..

Brooks: Wants people to recognize that the definition of tracking is unset.

<rvaneijk> +1

<dsinger> (he is echoing one of my main complaints about this definition when the CfO happened, but that's water under the bridge)

Justin: Invites all concrete proposals to further define/refine it

Wseltzer - you ready to take over? :)

Brooks: Is leaving it undefined an option?

Justin: If everyone on the group agrees we don't need to define context, then that's what we'll do

<fielding> I would have no problem with no definition other than the English connotation.

Rob V: Vialbe way forward would be to have more discussion on the mailing list to get clarity on the definitions proposed

scribe: agree that the definition of tracking is not set; but it is becoming clearer

<fielding> My only real concern was that people understand we are referring to the user's activity context, rather than any of the million other contexts that can be considered.

scribe: tracking definition is a two-step process. First step was for the previous CfO, but we do need more time to get clarity on context to get it right. Ultimiately, this could lead to a workable solution

<rvaneijk> my skype dropped

<wseltzer> scribenick: wseltzer

Justin: It's an open matter before the group. If people think we need to define, propose definitions; if people think we can leave it undefined, propose that.

<WileyS> Ray - that's the issue to me - that in the current definition "context" can be interpreted in many different ways - not only the user's activity context.

Justin: Let's work to try to make it as clear as possible
... I do think our definition of tracking moved the group forward.
... Turning it over to Matthias.

schunter: Roy proposed a pointer to a compliance regime, allowing multiple compliance regimes

<npdoty> fielding, apologies, my response just went out this morning; I got stuck on a delayed flight

<moneill2> +q

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

schunter: some discussion on the list. Some saying it's good to be specific, others, it's good to have multiple options.

moneill: General idea of multiple compliance links a good one; if there's a clash, what is the user to think?
... perhaps need some non-normative text saying what happens in case of conflicting compliance policies

schunter: good to think about conflict resolution

<npdoty> right, if you can't comply with both, you wouldn't want to claim compliance with both

<fielding> npdoty, the main reason why qualifiers are only in the representation is because they need the compliance pointer to define what they mean. Also, sending more information in the header field needs compelling evidence that they won't be wasted bytes.

schunter: current state: if you have multiple links, you have to comply with all of them

fielding: that's right

schunter: That's good, puts the conflict-resolution on the site, not the end-user.
... the site needs to make sure all promises are consistent; that's best for end users.

dsinger: I'd thought these would be token strings

<fielding> right, they are just federated names

dsinger: so UA could check on user's behalf

<schunter> This only works if they cannot override each other

<schunter> Usecase: A user looks up whether _one_ of the regimes is acceptable (and can then ignore the other regimes).

dsinger: if they're additive, the customer needs to look only to see that one he likes is present.

schunter: currently, you make promises in all the URLs

<schunter> This works onlly iff the regimes cannot _override_ each other.

npdoty: concern that we're talking about providing multiple regimes, users checking; but I'm not sure that's an outcome we expect or want.
... harder to explain to users what they're getting.

<dsinger> +q to Nick

dsinger: If a site says "I comply with DNT" but the compliance regime is the Venezuelan Beaver Cheese Association @@
... what does that tell the user?

<schunter> It is important that the number of compliance regimes is kept very low (lower than the root-level certification authorities ;-)

<npdoty> thinks that was +1 to Nick, rather than +q

<justin> (LeeTien agrees with David)

Carl: Agree with DavidS it's a problem, but think it's an intractable problem

<fielding> You can't wish your way into a single universal compliance document. It is far better to at least make some progress toward documented compliance even if there is a (small) amount of variance in choice.

Carl: there's no solution of which I'm aware that can be implemented technically

<Zakim> dsinger, you wanted to Nick and to

dsinger: We've worked hard to make this balanced and symmetric.

<moneill2> i like that

dsinger: One possibility would be for the user to say "this is the compliance regime I'm seeking"

<justin> DNT 2.0? Or intermediated at the browser level?

<schunter> Sounds like P3P

dsinger: and have the site respond "I recognize and comply" or "I don't recognize and disregard"
... then the user can be communicating what he wants to the site

<moneill2> they might just tell the UA

<fielding> I don't know of any site that negotiates business compliance on the fly

<moneill2> +q

<fielding> IOW, I can hear the lawyers cringe

<schunter> Another solution would be a Javascript API where you can look up regimes that are acceptable (raises a privacy concern though)

dsinger: doesn't have to be sent frequently

<moneill2> +1

<Brooks> +q

<Chris_IAB> sorry David, not so much

<rvaneijk> Yes, it resonates with me. Is user centric.

LeeTien: I like the basic idea

<WileyS> David - are you looking for a well-known resource that calls out: Do I comply? If Yes, this is what I comply with.

<ChrisPedigoOPA> Don't support that proposal

LeeTien: having dialog is useful if we're not using a single W3C compliance regime.

<dsinger> I am suggesting that the user sends "is X in your compliance array, because that's what I seek" and get a simple yes/no

<dsinger> no 'negotiation in the fly', just improving transparency

npdoty: Interesting. I've sometimes suggested it as a counterexample

<WileyS> David - couldn't a web browser build that level of functionality on its own outside of the standard? Since the compliance array is available, I don't see why we need to add any bloat here.

<justin> It's an interesting idea, but I still think it can be done at the UA level. If the UA gets back an untrusted compliance regime, it responds accordingly.

<hober> You can imagine this being completely static: The browser sends "the user likes compliance A", and the site's well-known resource contains compliances B and C. No behavior at either end has to change, but everyone (server and browser) are fully informed about what the actual mismatch is.

<Chris_IAB> To be fair, there may be 12-19 users who would do that npdoty...

<WileyS> +1 Justin

npdoty: We want standardization to let users express one thing, not a complicated mess of parameters

<justin> Chris_IAB, Well, if the UA makes it a default . . .

<dsinger> I agree with Nick's concerns, by the way, but when we decided to split TPE and compliance this is (as Roy has said) an almost inevitable result. I am trying to roll with reality here

<johnsimpson> +1 to Nick

npdoty: concerned about multiple compliance regimes

Carl: The point of standardization is implementability.

<bryan> I disagree that users will understand, globally, the same concept in the same way, regardless of whether there is a single standard for it.

<npdoty> I agree, I would like a less-complex schema, that's what I'm asking for

<Chris_IAB> I say, let's make things less complicated (apply KISS) here, at least on v1.0

<bryan> Privacy is contextual, including regional, and per many other aspects.

<npdoty> bryan, sure, there will always be variation on practices, but the purpose is giving a common choice

Carl: have to assume that people are willing to take charge of their own privacy

<justin> I think the counterveiling concern is that if you can just point to the Venezuelan Beaver Cheese Association, have we accomplished a goal?

schunter: want to return to original issue of whether URLs are a good idea

<justin> (Not disparaging the VBCA, who has a strong privacy track record)

moneill: Darwinian selection of compliance documents

<justin> moneill2, But what does "fittest" mean here?

<npdoty> we could define a completely generic protocol: a sender to say I want X (for any X) and a server to reply I comply with Y (for any Y) ...

fielding: The best policies will win
... let the user pick what's most interesting to them

<moneill2> justin, a list of compliance documents ordered by popularity

fielding: negotiation doesn't make sense; site won't negotiate but just ignore.

<justin> moneill2, But popularity by whom? Users or ad nets?

<npdoty> I'm not sure why we think this is a market or natural selection; we don't expect users to have detailed visibility or make lots of choices based on it

<moneill2> justin, users

fielding: having to send bytes in every header would be really annoying

<Chris_IAB> Good point, Roy

schunter: Push this out to the implementation phase

<vincent> npdoty, this "generic protocol" sounds close to what P3P does right?

<WileyS> Matthias - we need to structure to communicate the compliance array - so we'll at least need that for implementation testing.

dsinger: I didn't suggest sending the request in every header; secondly, checking only on the user side doesn't give site transparency as to what the user wanted

<npdoty> vincent, it resembles the negotiation protocol of P3P that was ultimately dropped before publication because it was thought to be too complex

dsinger: whereas a request "I'd like DAA compliance" suggests ways the site can change
... balanced and symmetric.

fielding: Not realistic. We're talking about metrics on sites with millions fo r3equests/minute
... if there's a significant drop in audience, they'll look into it and learn why.

<Chris_IAB> agree with Roy, sites will be able to figure this out using their own internal analytics

<moneill2> roy, tracking via low entropy cache headers rather than UIDs

<ChrisPedigoOPA> David, if consumers are asking for a specific compliance regime, then they're likely to actually ask for it via email or other feedback mechanisms

<Chris_IAB> David, can't we leave that up to sites to implement on their own, IF THEY WANT?

<moneill2> roy, some will though

<Chris_IAB> Why do we need to make this a requirement, of v1.0?

<dwainberg> dsinger, in such a model, would Apple choose a default compliance regime to set in its browsers?

<npdoty> do we prefer that browsers just block requests for ads and beacons and use that as the feedback mechanism?

schunter: recommend a limited number of compliance regimes

<dsinger> to dwainberg: I don't know, but in this scenario we could at least explain to the user what we're asking for on their behalf (which is a longstanding request)

<justin> To be clear, people can still argue *against* including a field for multiple complianc regimes. We could still just point to the existing (unfinished) compliance document. Though that obviously has its serious problems as well.

schunter: @@ browser-based lists

<Chris_IAB> guys, let's get something out workable, and then iterate… we are trying to solve problems that don't yet exist, in v1

<Chris_IAB> we will learn a LOT once we get v1 out

dsinger: give the site a way to learn what the user was looking for. I haven't yet proposed a mechanism.

<Joanne> can pointing to a compliance regime be optional in v1 and see whether industry implements that part of the spec

<npdoty> if dsinger thinks that's useful and wants it to be used rarely, it could be a parameter of loading the tracking status resource, which we expect to be uncommon

schunter: so one way forward, keep multiple URLs, open issue asking whether we need mechanism for site to discover user privacy prefs.

dsinger: yes. open an issue.

<Chris_IAB> dsinger, is there a president you can point to where this has been done ("conversation with users" on a site-by-site basis)?

<Chris_IAB> sorry, on a transaction by transaction basis?

LeeTien: when you have multiple compliance regimes, user loses sight of what site is complying with.
... vs single standard, user knows it's set by the standard.
... With mult regimes, concern that users not be misled to think they're getting protection they're not.

<moneill2> LeeTien, +1

<Chris_IAB> to Lee's point, user confusion is likely

<fielding> joanne, the current array proposal is for an optional list of compliance pointers

<schunter> Proposed conclusion on ISSUE-239: Send a mail to the list trying to close this issue and open a new issue on how/whether web-sites should be able to discover the preferred regimes by a user.

LeeTien: implementation isn't success if users arent' getting what they think

<npdoty> I don't think anyone expects it to be common for users to request and review the tracking status resource for detailed compliance information

<Chris_IAB> anyway, any site COULD do this on their own… why don't we leave it at that?

schunter: propose close issue-239, open new issue.

<Chris_IAB> I don't think we should open another issue, but….

ISSUE-197?

<trackbot> ISSUE-197 -- How do we notify the user why a Disregard signal is received? -- closed

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

<npdoty> I'm not comfortable closing the issue, but I'm fine with moving to email :)

ISSUE-197 How do we notify the user why a Disregard signal is received? http://www.w3.org/2011/tracking-protection/track/issues/197

schunter: we need frozen list of change proposals

npdoty: we spoke last time about non-normative text; dsinger sent a proposal, that's all I've seen.
... if that's the only proposal, we're done.

<johnsimpson> can we send the proposal again, please?

<dsinger> (nick: do you have my text?)

<justin> Right, there was agreement with dwainberg to take out the language about the disregard signal being rare? Is that right?

<ninja> This is the wiki page http://www.w3.org/wiki/Privacy/TPWG/Proposals_on_Disregard_signal - I will ad Dave's text

schunter: push this to next week

<npdoty> dsinger on Disregard note: http://lists.w3.org/Archives/Public/public-tracking/2013Dec/0117.html

<WileyS> Justin - that's what I thought as well (remove "rare")

<npdoty> "Note: This specification was written assuming that the D tracking status value would be used only in situations that can be adequately described to users as an exception to normal behavior. If this turns out not to be the case, either the logic that is leading to the D signal may need re-examination, or this specification, or both."

1st and 3d Party signals

<moneill2> +1 to a simple spec

schunter: We'd had 1st and 3d party signals. Fielding removed them. I sent a proposal on the list
... received push-back.

dsinger: Given that at least one compliance regime distinguishes between 1st and 3d parties, discoverability is at least harmless, potentially useful.

<moneill2> +q

<npdoty> +1 to dsinger on that. it can be informative, even if not a compliance indicator

<fielding> To Lee's earlier point, I think the TSR performs the role of transparency. I don't see how listing the set of things the site complies with would reduce transparency versus not listing any. I understand that having a universal compliance would be more transparent, but that's a pipe dream that, if ever comes true, can be reflected by the compliance array linking to that one compliance regime (and browsers ignoring all others).

<moneill2> +q

schunter: @@from email@@

<dsinger> (I re-sent the Disregard suggestion, but for reference, it was previously <http://lists.w3.org/Archives/Public/public-tracking/2013Dec/0117.html>)

<dsinger> I see some value in uniformity of signalling for this common concept

schunter: simplicity, or giving flags for compliance regimes that need them
... continue discussion on-list

<npdoty> I don't think our main goal is helping site developers not make errors about re-use of resources

<npdoty> but it can be informative to users whether a resource is designed for first/third party use

[adjourned]

<dsinger> thanks, bye, happy new year!

- DRAFT -

Tracking Protection Working Group Teleconference

08 Jan 2014

Attendees

Contents

ISSUE-197 How do we notify the user why a Disregard signal is received? http://www.w3.org/2011/tracking-protection/track/issues/197

1st and 3d Party signals

Summary of Action Items

Scribe.perl diagnostic output