See also: IRC log
<trackbot> Date: 21 May 2014
<Chris_M> Just joined via a private number
<ninja> thanks Chris_M
<JackHobaugh> Zakin, aaaa is JackHobaugh
<vinay> That was me
<ninja> Volunteer for scribing today?
<vinay> I can do the first half of the call (since I haven't done it in a while)
<ninja> scribenick: vinay
Justin: Getting started. Just a
few issues on today's agenda. Going to start with talking about
... Existing language in text right now that says you can use Service providers and they're not a third party if there are protections in place that say they can use the data only for you
Justin: Roy has tweaked it
slightly. Justin is summarizing it briefly
... SP is the 'same party' if the conditions are met (as described in Roy's proposal)
... somewhat contingent on the definition of de-identified data since that's still an open item
... Roy explained the justification last time, and didn't think it was that controversial
... though there have been previous proposals in the past with more stringent requirements (like no merging...)
... nobody on the call last week wanted to take that up
... if anyone wants to resurrect/argue for that proposal, they need to speak up soon
Justin: Any questions about Roy's proposal, problems with Roy's text, etc.?
Kulick: Can someone explain the differences between current language and Roy's proposal?
<Chris_M> no fundamental problem with Roy's direction... May have to define "contract" and "contractee"
Fielding: Would label them all as
... thinks the editor's text has the same 4 requirements on it
... but are rephrasing the terms to provide either neutral terms or terms that are already used
... for example, the current text references 'data processor' whereas some people didn't want to define that term (and we don't have a definition)
<JackHobaugh> I recommend that “service provider” be delayed until “de-identified” is fully addressed because the current proposal for service provider cannot be fully understood without a definition for “de-identified.”
<scribe> ... new proposal includes the term 'contractee' because the word client may cause confusion as client has other meanings
UNKNOWN_SPEAKER: added the word
'retained' in (2) but doesn't think it changes the meaning.
just addressing the ambiguity
... (3) original text has an idea on this, but had exceptions that were already allowed. Roy's new proposal provides examples of ways to use de-identified data and lists a few
justin: To Roy, do we need to define contractee?
Roy: Doesn't matter to me, but I thought it was a clear term
<npdoty> is "contract" ambiguous? I don't think we're giving it a special meaning here
<Chris_M> let me think about it further... nothing now
Justin: Would be open if someone
wants to submit a definition of contract and contractee
... Re: De-Identification, while here, its also a separate issue. Lots of things in the process have exceptions re: de-identified uses (which are still undefined)
... Trying to solve for 'service providers' in an identifiable form on behalf of its client
... inclination is to not postpone it, but is open to hearing points to postpone it
... doesn't hear on the call more requirements for the filing of data; so Justin will email the mailing list
<ninja> agree with justin. Regarding tracking data the de-id exception could simply be stated as: The service-provider has no independent right to use the data
<Chris_M> could a contractee COLLECT the data for their client?
Justin: next topic -- Data
Appends / First Party Compliance
... concern about data appends. can a first party send data to offline data brokers (for example)?
... <summarizing of current text in editor's draft>
<Chris_M> fielding, per your proposal, could a contractee COLLECT the data for their client?
Justin: Some folks (John Simpson)
has asked for more restrictions
... trying to limit appends of first parties
<ninja> Chris_M, Service provider and first party can share data (as long as it is in the same context)
<Chris_M> fielding, from your proposal, it appears that it would have to be a 2-step process: 1) 1st party collects the data, and then 2) pass it to a service provider for processing
Justin: The group has previously talked about provisions about this that may set limits between the first party and the data broker, but i don't see any within the current proposals
Chris P: Explaining his rational for requesting the deletion of "A first party may elect to follow the rules for 3rd parties."
scribe: its an optional standard and doesn't add much
Susan I: Against adding optional language that suggests adopting a stricter standard because it could be considered mandatory by some parties
Justin: Rigo's proposal was an attempt to assist EU companies in compliance with legal requirements there
<ninja> justin, rob is on the call but muted
<npdoty> (we can decide on "MAY" and not "MUST", they don't turn into one another accidentally)
Justin: Part of the discussions around global considerations. RVE may be interested in pursuing this. Justin will follow-up with Rob about it
<fielding> Chris_M, I am not seeing that in my text … it doesn't say who received the data, so yes a SP can collect the data on behalf of the contractee
Justin: Talking about the meeting in Berlin for global considerations... Rob and Rigo were hopeful, but others (Justin and Vinay) were skeptical
<susanisrael> npdoty: happy to discuss the "may"/"must" issue generally with you offline
moneill: DNT:0 as a UGE would be
used a lot by EU companies for ePrivacy compliance
... important to take into account
Justin: Trying to understand this in practice
<Chris_M> fielding, #2 may confuse people on the matter of collection... because of the use/placement of the word "only" (and the absence of the word/practice "collect")
Mike: If you're a first party
server, and you get consent for their users, you can use a
cookie to store consent.
... but to signal to third parties, the DNT signal could assist to assign DNT:0 to third parties
<fielding> Chris_M, the data has already been received.
<Chris_M> fielding, I'm probably splitting hairs, but thinking of situations where the SP does mechanically do collection for their client
Mike: Might be good to get further clarity on this
Justin: The definition of tracking doesn't speak to first party collection
Mike: It doesn't matter. You're using DNT as a signal to 3rd parties
<Chris_M> fielding, got it... so I guess it would leave it as ambiguous for the matter of whether a SP could collect (on behalf of their contractee) in the first place
<susanisrael> i don't follow Mike's point
Justin: May not fully understand
the issue, but perhaps would be more productive to take to the
... Talking about Vinay's proposal. Reading it out loud.
<npdoty> vinay: my intent isn't to make substantive changes from the current text; just that "normal" was confusing or ambiguous
<fielding> I don't think it is ambiguous … collect would be redundant: "A party collects data received in a network interaction if that data remains within the party’s control after the network interaction is complete."
<npdoty> ... for example, if a company's normal collection is to sell to third-parties
<npdoty> ... and +1 to susan/chris on striking the optional requirement
Nick: Was on the queue before re:
Proposals 3 and 4
... Proposal 4 suggests the possibility of responding to the server using the TPE saying I'm responding to 3rd party rules
... and the TPE might have removed that possibility
... instead, the first party can indicate 'not tracking'
... so may need to change the example
<ninja> +1 to npdoty
Nick: it could just be an example
Justin: Useful to take that to the mailing list
<Chris_M> fielding, it seems ambiguous in so much as it doesn't specifically give first party collection privilege to the SP in the case where the SP is collecting on behalf of the 1P (or am I reading in wrong?)
<npdoty> I'll send that option (an Example of responding N as a first party) to the mailing list
Justin: Does anyone still support John Simpson's (and possibly Alan Chapell's) proposal?
<fielding> agree with npdoty … a first party would respond with "N" if it does not collect user activity data across multiple distinct contexts
Justin: Chris P has made the point that DNT isn't meant to solve all issues and this issue isn't really encompassed to address data brokers. but others have disagreed.
<ninja> vinay, I could take over scribing for agenda item 3, if you want
Justin: mostly designed to get this issue back in our heads
Sure Ninja, that'd be great!
Justin: will send this issue back to the mailing list to try to get this back on people's mind for further discussion
Brad: DNT is meant as a way to
let users signify what their tracking preference is within one
... in a first party setting, the user has other mechanisms to indicate their preference with 1st parties.
<Chris_M> JackHobaugh, see private query
Brad: I would propose we would remove the 'append' language as users already have other mechanisms to communicate with the first party (in which they have a direct relationship with)
<npdoty> (I thought Brad doesn't mean to remove it, but instead not to add Data Append restrictions)
Justin: Just to confirm, you're suggesting to remove the append language entirely because the user has other mechanisms for first party
Brad will repeat...
Brad: user has a mechanism to
match where the data collection is occurring
... in a first paryt context, they understand who is collecting the dat
scribe: has access to that
... its situations in the third party context where the user may not necessarily know who is collecting the data
... and so the DNT signal makes sense in that regard
<fielding> Chris_M, the way that collect is defined means that the contractee (e.g., first party) is doing the collection when it uses a service provider to receive the data on its behalf, since the contractee is the one controlling the data. Hence, saying the SP collects the data would be a contradiction. That's why it says the SP receives the data on behalf of the contractee.
<susanisrael> i think we already addressed the case that Mike is now discussing, when we included a prohibition on first parties' providing to third parties for their own use data that those third parties would otherwise be prohibited from collecting.
moneill: what worries me about the sharing is that people go around blocking third party cookie blocking technology... when we talk about sharing, you don't want to get into situations where companies can get around technologies
<I'm not really sure what Mike said.. I didn't understand it>
<Chris_M> fielding, thanks for the clarification... this makes sense in that context. Where is the "collect" defined?
<npdoty> susanisrael, is it still covered by vinay's version of that text?
Justin: I think we're all worried about the work-around situation. But do you think the existing language isn't clear enough?
<susanisrael> Let me re-read vinay's version
<fielding> Chris_M, defined in http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#terminology
Justin: I think we all agree that people shouldn't be using work arounds to allow tracking
<npdoty> moneill2: concerned about first-party sites that will pass first-party cookie unique identifiers to their third parties (perhaps through query strings, etc.) to work around user blocking or their DNT preference
Justin: do you think we need more language to make it clear?
Mike: Would lean towards John S or Rigo's language
Justin: Would love ideas to merge proposals
Brad: What I'm getting at is that the DNT signal is meant to address that users have the appropriate amount of transparency and control over who is using their data. In a first party setting, its more obvious to the user than in a third party setting.
ANd, the first party generally has other mechanisms giving the user controls over how the first party uses data
and the DNT signal is overstepping as it is meant to control 3rd party data collection/use
Mike: Goes to the core (and highlights the can of worms). DNT is a clearer way to express intention of tracking
than having a whole set of opt out cookies within different domains
<kulick> i would dispute that it is "clearer"
Chris P: I don't think Brad was talking about the DAA adchoices program
scribe: instead, first parties offer their own tools within the first party relationship. that's not part of the DAA program
Brad: Correct -- wasn't talking about the DAA program
<npdoty> I think maybe there was ambiguity about the phrase "opt-out cookies"
<rvaneijk> the problem though with 1st party opt out, is that it is not standardized !
<rvaneijk> we need text on data append, and on first party sharing
Brad: When first parties provide a rich, more detailed opt out program in which it has a dialogue with a consumer, it generally is seen as more positive for the user experience/control
Justin: Given the definition of
tracking, it seems like that itself limits how these issues may
apply. But if others want to make an argument, please do
... look at John's language and make suggestions, tweak it, etc. Lets spend some time on the mailing list working out some of the issues
<npdoty> I think maybe we're confused about whether we're talking about limits on collection in the first-party context, or how choices are presented in a first-party context about later third-party collection/use
<scribe> scribenick: ninja
<kulick> why does 1st party opt-out have to be standardized? Having a direct knowledge and transparency of your data is being used by a first party should be adequate... we shouldnt be overly prescriptive in this area
justin: Next issue is on using
first party data in another (third party) context
... Large first parties like Yahoo! operate as first party as well as third party. Question is whether and in which way they can use the first party data and combine data across contexts.
... *walking us through the proposals on the wiki page*
<npdoty> right, I think walter's proposal captures Alan's intent, as a clearer prohibition
justin: Alan Chapell's proposal would prohibit using first party data across contexts. Yanni's proposal would allow the use with an requirement of prominent branding. Walter's proposal would be similar to Alan's.
justin: Robsherman: I wonder if we have moved past that question with our definition of tracking.
<npdoty> "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."
justin: This is about is it permit table to use data which is not tracking data in third party context.
<kulick> +1 to rob's comments
justin: It is important to differentiate between previously permitted non-tracking data or collecting new behavioral data.
<npdoty> does "outside the context in which it occurred" cover cases like what robsherman suggested?
Moneill2: If you allow third
parties to utilize unique identifiers from first parties that
would not be transparent to the user
... and undermine the standard.
justin: It must not take the
users by surprise. What about the middle ground proposal from
... It requires common branding to give the user transparency.
<kulick> seems like this is a case where ad choices would suffice
robsherman: Any company who is doing this would be interested in being transparent to their users. Prominent branding may not be a solution in all cases.
Moneill2: The UGE would cover users that gave consent for tracking. Regarding users who send DNT;1
<robsherman> But that's the point -- use of previously collected data is not tracking, and the fact that previously collected data is used doesn't necessarily mean that tracking is occurring.
Sorry, moneill2, missed part of your statement
<moneill2> I was saying user agreement for append is best ensured by use of UGE, rather than assumptions about visibility
<rvaneijk> I concur with Mike on ensuring append through the use of the UGE.
kulick: justin: I still can see users getting confused by personalization while sending DNT;1. Brad?
<npdoty> " 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. "
kulick: We should be careful with the requirements we put up. First parties collected this data with the knowledge of the users and in compliance with the spec.
npdoty: Our tracking definition is limited to the context it occurred in. Taking it outside of this context may not be covered anymore.
kulick: Information specifically provided in first party context should be treated differently.
justin: May need more time to wrap my head around that.
<npdoty> if we intend the tracking definition to only cover subsequent use of data that was from the combination of activity on multiple sites, then maybe we should remove or clarify "outside the context in which it occurred" from the Tracking definition.
<kulick> ninja, I think that scribing of my comments doesnt capture my comments exactly... (I understand that capturing comments realtime isnt perfect, I just adding this since this is on the record)
justin: Will continue to discuss this in the following weeks. Any more thoughts for today?
<fielding> I was distracted, but no
ChrisPedigo: Can you give us a sense of how much longer it will take to get through the issues?
<npdoty> fielding, which are you responding to?
<fielding> we don't need to change the definition of tracking
<npdoty> fielding, and did you agree with robsherman's interpretation?
<rvaneijk> Changing the definition of tracking may shake the whole exercise. That issue is closed, right?
justin: Can give you a rough estimate. There are a bunch of issues that are raised or open that don't seem controversial. I will suggest batch closing to the group probably next week.
<npdoty> rvaneijk, I tend to agree, I was just noting that we might want to clarify if a particular clause was unnecessary
<fielding> I missed his interpretation … probably not
justin: And we have about seven
or eight more difficult issues to take up. For example
... That may take us until summer.
... Maybe August. But we make good progress and are on track.
<fielding> "use of previously collected data is not tracking" -> nonsense
<npdoty> +1, thanks vinay and ninja for scribing
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: vinay Found ScribeNick: ninja Inferring Scribes: vinay, ninja Scribes: vinay, ninja ScribeNicks: vinay, ninja Default Present: Carl_Cargill, schunter, Ninja, Amy_Colando, Chris_M, +1.303.949.aaaa, JackHobaugh, +31.65.275.aabb, eberkower, Peder_Magee, Chris_Pedigo, WaltMichel, Fielding, kulick, rvaneijk, +1.917.934.aacc, vinay, justin, npdoty, moneill2, hefferjr, RichardWeaver, +1.425.614.aadd, adrianba, Susan_Israel, +1.202.370.aaee, robsherman, vincent Present: Carl_Cargill schunter Ninja Amy_Colando Chris_M +1.303.949.aaaa JackHobaugh +31.65.275.aabb eberkower Peder_Magee Chris_Pedigo WaltMichel Fielding kulick rvaneijk +1.917.934.aacc vinay justin npdoty moneill2 hefferjr RichardWeaver +1.425.614.aadd adrianba Susan_Israel +1.202.370.aaee robsherman vincent Regrets: dsinger WileyS wileys Found Date: 21 May 2014 Guessing minutes URL: http://www.w3.org/2014/05/21-dnt-minutes.html People with action items:[End of scribe.perl diagnostic output]