See also: IRC log
<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: they've merged their text
... 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
... to explain disregard
... this makes clear that what the specific reason is
... 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
... 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
... 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
... 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
... 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?
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?
<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)
<trackbot> issue-207 -- Conditions for dis-regarding (or not) DNT signals -- raised
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
... hence non-normative text
Justin: Sound like you are OK if
the policy itself has specific reason.
<Ari> From the industry side, I think it depends on what we mean by specific
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
... But concerned about responding with a D in real-time
<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
... 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
... 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?
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
... 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
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: 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
Justin: Mike should consider the
input and decide what to propose
... Alan has pointed out covered in TPE, may need CfO
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: David, why do we need a permitted use for short term data retention
David: Clarifies short term
... 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
... "I keep data forever"
... people may or may not be comfortable with it
Justin: Broader than I read
... some advocates may have an issue
David: We couldn't figure out a
fixed retention period
... would be happy if we could find one
... 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
<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?
<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
<trackbot> issue-205 -- user agent compliance requirements; connections to TPE -- raised
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)
... old proposals: Jonathan Mayer (preselected is compliant)
... those are proposals
... any others?
... Follow-UP on mailing list
David: 3 comments from AvK on
... 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
Nick: Yes, every three
... just a snapshot
... does not represent consensus
Rob: I have concerns wrt audience
... 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
... make it clear there is an open debate.
Nick: We have both a note and an
... 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
... 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
... 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
Justin: Thanks for joining the call
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) Succeeded: s/@@/config/ Succeeded: s/singal/signal/ Succeeded: s/short term data collection/short term data retention/ Found ScribeNick: jeff Inferring Scribes: jeff WARNING: No "Present: ... " found! Possibly Present: Alan Apple Ari Brooks Carl_Cargill Chapell Chris ChrisPedigoOPA Chris_Pedigo David IPcaller JackHobaugh Jack_Hobaugh Justin LeeTien Mike Mozilla Nick Note Rob aaaa aabb aacc adrianba chairs dsinger eberkower hefferjr hober https jeff johnsimpson kulick moneill2 ninja npdoty robsherman rvaneijk scribenick sidstamm susanisrael trackbot vincent walter wseltzer You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Regrets: fielding WileyS ninja schunter Found Date: 30 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/30-dnt-minutes.html People with action items:[End of scribe.perl diagnostic output]