Tracking Protection Working Group Teleconference -- 30 Apr 2014

<trackbot> Date: 30 April 2014

<npdoty> trackbot, start meeting

<trackbot> Meeting: Tracking Protection Working Group Teleconference

<trackbot> Date: 30 April 2014

<npdoty> chair: justin

<Ari> 650.480 is Ari from Rocket Feul

<npdoty> scribenick: jeff

Justin: Let's start
... 3 agenda items

<sidstamm> what "number"?

Justin: 1. Conditions for disregard signal

<sidstamm> oh, looks like our PBX chose sip instead of pots

Justin: Background: TPE allows disregard to convey to UA that you will not honor signal
... Rob and Mike have argued that UA needs more info

<justin> https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Disregarding

Justin: they've merged their text proposal
... party MUST provide the SPECIFIC reason
... easily discoverable
... servers should implement so could be understood by UA
... Mike, how are you imagining this

Mike: When server returns status w tracking resource
... how does user find element in privacy policy
... to explain disregard
... this makes clear that what the specific reason is
... should be stated in privacy policy
... but 3rd party elements don't know enough to appreciate this
... in TPE can connect with reason for tracking resource
... here it is a MAY, with some non-normative text

<eberkower> Zakim mute me please

Justin: If a server has D for 3 scenarios, how does a user know which case it is?

Mike: The User Agent has a User I/F to make it clear
... non-normative reqt.
... so UA has to pass signal somehow
... what does D signal mean

Nick: TPE has a series of fields
... policy property and config property to give user more control
... server w disregard signal can fill in one of those properties
... that could be an implementation approach

Mike: We could use the privacy policy, but we have the field for the reason for disregard
... we wanted something in TCS to identify reason
... unstructured text doc can't be decoded by UA
... site might have 80 policies for all 3rd parties
... would a user need to plow through all of them?

Justin: I hear the reqt
... but it is not in what you proposed

Mike: First we said there should be some mechanism
... now it is qualified

<npdoty> I was trying to suggest that the config/policy properties can provide a more specific explanation to the user

Mike: maybe we should extend the non-normative text
... technical thing in TCS

<npdoty> since it doesn't seem like we have a settled list that needs to be encoded in a qualifiers list

Justin: You would require people to say this field means this reason, etc.

Mike: Yup. As a possibility

Justin: Do you want that in the doc now

Mike: We are happy w text as is

<rvaneijk> I need at least in the document: "A party MUST provide information regarding the specific reason for not honoring the user's expression. The party's representation MUST be be easy discoverable, clear and unambiguous. "

<walter> as in, Mike's and Rob's proposal

Justin: Your language and TPE language quite close
... since don't require field for qualifier

Mike: Specific reason could be in privacy policy
... non normative text says that might not be good enough

<Ari> But isn't one of the reasons why the signal is being disregarded because the user is not setting the signal?

Justin: Are you saying privacy policy needs to disclose ALL reasons for disregard?

Mike: I'm trying to avoid that

<dsinger> we already require that the policy outline the possible reasons (well, the word ‘all’ is not there)

Mike: there should be a SPECIFIC reason

Justin: See Ari's point above. Would that be OK with you?

<dsinger> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#TSV-D

Mike: Yes

<rvaneijk> the purpose is to pin down company representation.

Justin: Do people object?
... here we say you must state specific reason

<rvaneijk> It is pretty mild text, that improves transparency.

Justin: what about reason(s)?

<dsinger> do we merely need to insert “all” — “all” the reasons that a signal might be disregarded?

Mike: With Status ID return you can point to different privacy policies

<Ari> could we get some examples of the kind of specific reasons you have in mind?

Justin: Are you implictly requiring that (since you use singular)

<dsinger> issue-207?

<trackbot> issue-207 -- Conditions for dis-regarding (or not) DNT signals -- raised

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

Justin: If so be more explicit

Mike: Let's hear other opinions

Justin: Comments? Rob - more explicit to require qualifier from server?
... Or reason(s)?

Rob: Two stage thing
... 1. User transparency
... D won't be used frequently
... But if they have lots of reasons, company should be transparent
... otherwise can send the T signal

<Ari> whether or not it's exceptional is yet to be seen, no?

Rob: Mike and I met in the middle

<npdoty> how about non-normative text like: "Parties may use the "policy", "config" and "qualifiers" properties of the tracking status resource defined in [TRACKING-DNT] so that the reason can be clearly communicated to the user by the user agent."

Rob: TPE building blocks can help improve transparency
... hence non-normative text

Justin: Sound like you are OK if the policy itself has specific reason.
... Fair?

Rob: Yes

<Ari> From the industry side, I think it depends on what we mean by specific

<ChrisPedigoOPA> q

<ChrisPedigoOPA> =

Justin: Hence less prescriptive. Little more expansive than TPE. David?

David: Maybe TPE should just say ALL the reasons.
... under which a tracking request would be disregarded

Justin: I read TPE to already say ALL

Chris: I'm OK with general reqt for transparency
... But concerned about responding with a D in real-time

<moneill2> +q

<dsinger> yoyu use a different status — potential consent

Chris: You might be OK with the protocol, but then learn user is subscriber

<rvaneijk> you should not use the D signal for OOBC

Chris: then you might have permission to disregard, but didn't know that in real-time.

Justin: We have a signal for potential consent.

Mike: P signal is there for that purpose

<rvaneijk> we want to avoid abuse of D signal !

Chris: Maybe I don't know yet

Justin: I'm trying to understand the scenario
... service like Facebook?

Chris: Take a newspaper
... user comes without login
... read some article
... hit the paywall

<Ari> Rob, we also want to avoid abuse of DNT signals that are not set knowingly by humans

Chris: newspaper got some info about user
... at paywall they link it all together

<rvaneijk> You can not track before logging in ! You can not link together without being logged in.

Chris: but would not have responded with D or P

<wseltzer> +1 to rvaneijk

Justin: The way we defined tracking it should be OK
... Newspaper is not tracking in its own context

Chris: They might want to follow you at other sites, introducing a third party

<rvaneijk> And then you want to send D to justify this tracking behaviour?

Justin: Interesting

Alan: Don't understand why we are expanding beyond TPE
... Chris gave one example
... we'll become overly perspective

Justin: Good point. Maybe just a TPE question.
... should there be extra rules in compliance?
... two proposals are not much different
... two places to address same issue is confusing

Alan: ePrivacy directive. 1 or 2 word choices made a big difference

Nick: f/u on Chris
... discussed this with P

<Chapell> RVE (:

s.f/u on Chris.I would like to follow up on Chris' comment.

Chris: If I am a publisher, I'll respond with P to everybody
... I don't know if I have consent
... I have a problem with requiring any of these responses

<dsinger> Hang on, ‘P’ is for a third party, the first party can already broadly track

Chris: should list in privacy policy

Justin: Agree w Nick.
... to David's point - the case is a publisher wants to go offsite
... for retargetting
... good question for TPE implementation

<dsinger> D is for the case where you (and your third parties) simply ‘ignore’ the signal for some reason, without further consideration of permitted use, consent, etc.

<vincent> agree with dsinger, I though justin already expalined that?

Justin: orthogonal

<hefferjr> +q

Justin: we should check on that issue in implementation

hefferjr: P consent for out-of-band consent. Not verified in real-time
... we have bounds

<npdoty> the other point I was going to bring up, for Chapell, was that the difference was just that Compliance would require sending a D signal when disregarding the user's request, while the TPE just makes it possible to do so

hefferjr: not to be used every time someone logs on

Justin: TPE has bounds. Might not cover Chris' scenario. He might have issues.
... not Disregarding
... let's look at implementation testing
... Anything else on disregard signal?
... Rob and Mike don't want to back down
... maybe consider non-normative language to signal to user

<moneill2> ok

<rvaneijk> ok

Justin: Mike should consider the input and decide what to propose
... Alan has pointed out covered in TPE, may need CfO

Unknowing / Short-term

Justin: unknowing data collection (208) and short term data retention
... noone has spoken up in favor of proposal, so we will drop and close the issue if we don't hear in a week

<justin> https://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Short_Term

Justin: David, why do we need a permitted use for short term data retention

David: Clarifies short term retention
... can keep data in a closed pipe
... can keep aggregate data or have consent
... or data under another permitted use
... you tell us length of retention
... non-normative: if you process in 2 hours than you exposure is less than 2 months
... delay is OK - but be careful in treatment of retained data before processing

<rvaneijk> I concur with Walter's response on the mailinglist: in favour of Jonathan's proposal or nothing at all.

Justin: What about the broad research case?

David: Extracted data must be one of three cases
... where is the leak?

<johnsimpson> apologies for joining late… stuck in traffic

Justin: You can say end result is aggregate data

David: Then that is in your privacy policy
... "I keep data forever"
... people may or may not be comfortable with it

Justin: Broader than I read it
... some advocates may have an issue

David: We couldn't figure out a fixed retention period
... would be happy if we could find one

Justin: Agreed
... should say,"as long as end result is aggregate"

<npdoty> rvaneijk, I think you're referring to jonathan's proposal on unknowing; where dsinger is proposing an approach for short-term raw/collection

David: That relies on "tracking data" being the thing in our scope
... meaning stuff that can be tied to a user

Justin: I have more questions which I'll put into email
... Last agenda item... broad issue
... User agent compliance

UA Compliance

<dsinger> so, next steps on raw are for email discussion and possible amicable consensus?

Justin: [bunch of issue numbers said too quickly]
... how to ensure signal is valid
... do we need to be more prescriptive? consequences?

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

<rvaneijk> nick, correct.

[issues collected together above]

Justin: Before becoming chair I said this is dealt with in TPE
... lots of rules... need to make sure it reflects user choice

<npdoty> issue-205?

<trackbot> issue-205 -- user agent compliance requirements; connections to TPE -- raised

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

Justin: I propose to mirror in compliance, or leave it in TPE
... flip side of what Alan said
... other proposals in wiki
... Alan said UA itself should not track for advertising (e.g. Amazon silk browser)
... Jack had language to take sentence from scope section (applies to UA that can access web...) and move it to section 5 on UA compliance
... I won't read current TCS language (from Swire and W3C staff)
... mooted
... old proposals: Jonathan Mayer (preselected is compliant)
... those are proposals
... any others?
... Follow-UP on mailing list
... AOB?

David: 3 comments from AvK on TPE
... FOLLOWED-UP off line
... will bring to list soon

Justin: Systemically the group will not look until we have critical mass of issues
... but individual follow-up is good

<sidstamm> thanks, dsinger

<Zakim> npdoty, you wanted to comment on WD publications

Nick: We are required to publish drafts every 3 months.
... We did TPE
... We should publish compliance
... we had some editorial changes
... harmonize w TPE

Justin: Last heartbeat was January

<npdoty> http://www.w3.org/TR/2014/WD-tracking-compliance-20140128/

Nick: Yes, every three months
... just a snapshot
... does not represent consensus

Rob: I have concerns wrt audience measurement
... looks like it is a done deal
... but I'm not sure it will make it in the end
... If you publish, make it more explicit that it is not sure that audience measurement is in spec
... now implied that it is

Justin: Agree.
... make it clear there is an open debate.

Nick: We have both a note and an issue marker
... what if we drop not and leave issue

Rob: Not explicit enough.

Justin: We can say in note that there is a debate about this permitted use

<npdoty> Note: An open question for the group is whether or how audience measurement would be addressed. See issue 25.

<susanisrael> aren't there a lot of open questions? I am not sure why any one particular one should be singled out if we have noted the issues.

Justin: Susan raises a fair point
... editorial decision
... Rob has asked for more explicit

<npdoty> in all cases, we have change proposals to existing text

Justin: don't want to say no
... tell us if there are other cases

<npdoty> ... here we had a note because there wasn't existing text, and it might be confusing otherwise

<susanisrael> agree, I don't know how the issues are called out any more either. It just does seem to raise one concern above all others.

Justin: sympathetic, an extra sentence to a note is not a big deal

<johnsimpson> thanks

Justin: Thanks for joining the call

[adjourned]

- DRAFT -

Tracking Protection Working Group Teleconference

30 Apr 2014

Attendees

Contents

Unknowing / Short-term

UA Compliance

Summary of Action Items

Scribe.perl diagnostic output