<trackbot> Date: 20 August 2014

<amyc> I can scribe

<npdoty> scribenick: amyc

justin: goes over four agenda items, focus on de-id and how to use term tracking in compliance doc
... start with deid, then pick up tracking when Roy joins

dsinger: Apple has expert to answer limit ad tracking
... Eric can help respond, on iOS equivalent of DNT

audience measurement

Erik: question about how others would use ad id for other uses

justin: yes, can still collect data for frequency cap, billing, but there have been questions about whether data can still be used for analytics and research

ErikN: switch inside iOS that user can find and turn on, associated with Apple ID and sync across devices
... limit ad tracking brings contractual enforcement to app developers, program license agreement
... which contains restrictions on app developers. IDFA is non permanent ID that user can reset at any time. Can be used for interest targeting. If limit tracking is on, then contract requires that developer honor limit ad tracking choice

<moneill2> npdoty, i am on 735619 uk number

ErikN: in practice, most developers not doing their own ad work, using a third party framework. Generally speaking, code of that third party library will query with IDFA. Because developer ships code, the program license agreement comes into force.
... pulling up program license agreement that has specifics as to what is included as permitted when limit ad tracking is on

<WileyS> general reporting versus profiling

justin: seems to conflicting info on whether analytics is allowed

ErikN: when limit ad tracking is on, there is not exhaustive list of forbidden uses. Instead, there is a list of allowed uses.

<npdoty> that sounds like a similar model to our document

Justin: so can still collect IDFA for frequency capping, x, Y, Z, not a blanket prohibition?

ErikN: set of permitted uses, we don't define behavioral advertising. We looked at core uses, impact to advertising and impact to advertising. Some basic uses of ID that aren't tailored or targeted to individual, but are about the mechanics of advertising
... will send agreement to dsinger and list

Justin: on Android platform, different language, the ad id must only be used for ad and analytics [not sure I am getting all this, can we submit to list?]
... specifcially prohibits creation of user profiles for advertising, looks like it is silent on pure analytics or market research

<npdoty> that Android text specifically prohibits some uses, as well as permitting some uses

<npdoty> http://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Audience_Measurement

Justin: goes over ESOMAR proposal, on calibration of opt-in panels, not all users. If someone wants to propose that all research or product improvement is allowed, that would be possible. DAA has language like this in self reg.
... unless new text proposed, will go to poll on Esomar proposal in week or two

issue-188

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

<fielding> actually, I just updated the wiki

Justin: Status of deid, three proposals, plus language from dsinger that is being finalized

<dsinger> yes, my last email is http://lists.w3.org/Archives/Public/public-tracking/2014Aug/0036.html

<fielding> oh, never mind -- other page

<dsinger> right, I was waiting for dust to settle

<fielding> I updated the one on 203

Justin: may have been questions about dsinger text
... EFF and Jeff seemed supportive

Moneill2: concern was about making method public, text looks good at moment

<dsinger> I am totally cool with a change of name, to avoid confusion

fielding: drop all proposals and change word to anonymize

<dsinger> De-associated?

fielding: didn't want to use unlinkable because link is important term for web
... a few places where we use deidentified, where we should use anonymized

Justin: wouldn't we still have to define anonymize, would we use these definitions?

<dsinger> as my email indicates I am happy to use this text to define a better term (and use that term in the document)

fielding: Yes, but discussion would be closer to finalize.
... confirms his proposal would work with anonymize

Justin: does anyone care about using anonymize rather than deidentified?

npdoty: anonymize is used in dramatically different ways, could lead to confusion. Deid matches FTC language, more accurately describes process that involves pseudonymized records

<npdoty> I'm fine with a descriptor to add to de-identified

<WileyS> Either has its pros/cons - anonymous at least fits better into the anonymous, pseudonymous, personal paradigm.

dsinger: could use common term and define ourselves, risking confusion. Or pick a new term of our own choosing.

<npdoty> "sufficiently deidentified" "permanently deidentified"

<dsinger> “non-tracking data” has the advantage of clearly marking it as out of our scope

Justin: something like non-tracking data, data that meets these measures or goes through this process are non-tracking data

<WileyS> "non-tracking" would require an update to the term of "tracking" to add identity w/ across contexts

<moneill2> non-tracking data fine by me

fielding: OK with that

npdoty: OK with that too

<WileyS> +q

wileys: tracking doesn't have strong connection to identification, more about across contexts. Maybe we need to update tracking to include concept of identification

<npdoty> I think this is one way to make data not tracking data; (not that all data that isn't tracking would have this process applied)

Justin: non-tracking is not opposite of tracking data

<npdoty> what was the conflict on "deidentified"? I think this closely matches use of it by FTC, for example

fielding: agrees with Shane, all the data about user collected by single site is not tracking data (all identified/personal)

<npdoty> how about adverb to add to deidentified? if there's a conflict

fielding: we should stick with something like anonymous
... deidentified was way of unlinking data from user in a way unknown to outside world. References to data sets that have been scrubbed for publication, rather than preventing controller of data set from re identifiying

<dsinger> OK, either use anonymized, or invent a new term (‘de-associated’?)

<dsinger> Does ‘anonymized’ have similar baggage (existing definitions that are not the same)?

<npdoty> dsinger, yes, extremely so.

fielding: the way we use in TPE is that we intend to say that the person holding the data no longer has ability to re identify the data

<Zakim> npdoty, you wanted to agree on pseudonymous

Justin: agrees that anonymous has baggage, perhaps not so much for anonymized

<Brooks> just from a language perspective, if the output of "anonymize" isn't "anonymous", you've lost me

npdoty: true that some ppl use de id for release, but doesn't think that is FTC usage at all
... anonymous has been used in dramatically different ways

justin: aren't we solving for this when we define anonymized?

npdoty: true if they read doc, but may be more likely to confuse, Maybe add adverb to term.

<fielding> Maybe we should just replace the use of the term in our specs with an exact statement of what we mean ;-)

<npdoty> fielding, the text gets a little verbose if I have to repeat a few sentences in the place of every use of the word

<dsinger> It’s used 3 times, so we want a single definition

fielding: hard to say something is out of scope and deal with that on case by case mention in spec. Challenging from editorial perspective.

justin: when we go to call for objection, we should list pros and cons for terms, but doesn't seem like there are strong feelings on the term. Call for objection should focus on substantive definition.

<npdoty> do dsinger and fielding agree on dsinger's latest text except for the name of the term?

justin: now have four definitions

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

<dsinger> yes, can we check, do we have amical consensus on the definition, modulo the name?

<npdoty> or would vincent or jack be interested, given the iterations on this definition?

Justin: if roy wants to merge definition with dsinger. VIncent and Jack want their own definitions considered.

<vincent> I think this defintion could work for me actually woudl depend of the final version

<npdoty> Jack also refers to "irrevocably deidentified" in his text; although I think that's describing a different status

<dsinger> I inserted my latest text on de-id into the Wiki

Justin: turns to tracking, dsinger suggested permitted use for first parties and that looks like proposal B

issue-203

Justin: so first party data use allowed under this compliance regime.

fielding: all of the changes proposed for what a first party can do, replaced with first party permitted use. First party can, if they choose to, respond to server

npdoty: intent of permitted use for first party to address issue that user is knowingly interacting with that party. But doesn't think that form of permitted use makes sense. You are just not tracking if you are interacting with a user as a first party

justin: could argue that definition of tracking could encompass first party data collection (referrer headers). But roy's proposal would clarify this is ok.

<WileyS> We're not worried about referral headers. If you don't want referral headers please change the HTTP spec.

npdoty: if you are trying to find out where I was previously, that needs clarification

<WileyS> This is an overstretch - we should stop the referral header discussion.

justin: maybe we need first party referral exception
... what does roy's proposal miss? are there problems with it?

<fielding> WileyS, we are trying to explain why referral data is still allowed even though it is tracking, not disallow referral data.

npdoty: concerned about party handing off data to someone else that would track the user. Would need to add this requirement for all cases. Or perhaps we have downstream language

Justin: no requirement on first parties to stop embedding third parties, obligations fall on third parties.

<WileyS> Roy, okay - then we're on the same page.

<moneill2> +q

npdoty: agree that first parties embedding resources into page qualify as sharing

<WileyS> Implied consent

<npdoty> I'm not sure people were perfectly happy with it, but current text is: "A first party to a given user action MUST NOT share data about those network interactions with third parties to that action who are prohibited from collecting data from those network interactions under this recommendation."

moneill2: likes permitted use for first parties, because of EU guidance on consent on eprivacy directive.
... then would be possible for someone to come up with EU compliance doc to remove that permitted use

npdoty - I have to drop off shortly before 10

<WileyS> Disagree with a specific 1st party permitted use. The definition of tracking is focused on cross-context so it by definition is not tracking. If we feel its absolutely required (I don't) then we can provide normative direction on referrals in the standard.

npdoty: will update text with that permitted use, not sure whether we want separate issue on referrals

<fielding> WileyS, yes, but referral data is obviously cross context when the user came from a different context (i.e., site owned by some other party). We are trying to *allow* a first party to keep that data even though it technically (and clearly from the user's POV) meets the definition of tracking data.

<dsinger> I think there is little doubt that a referer header can cross contexts, so it’s banned by the definition. if we want to allow it sometimes, I think we’ll need to say so

justin: referral is unique issue, agrees that it is raised by defintiion of tracking, would be useful to know that we considered the issue and decided it in the following way

<WileyS> Roy, then why not provide normative text to address referrers in headers?

<npdoty> issue: status of referrals in navigation (is it tracking, is it permitted for DNT:1)

<trackbot> Created ISSUE-265 - Status of referrals in navigation (is it tracking, is it permitted for dnt:1). Please complete additional details at <http://www.w3.org/2011/tracking-protection/track/issues/265/edit>.

<npdoty> may need to improve on the name, but created the issue so that I wouldn't forget

aob

<fielding> WIleyS, that's what I did … making it a permitted use works very well.

<WileyS> David, to a 1st party, the referrer comes in the page request and therefore it is "within their context" and not "across contexts" from that perspective.

Justin: wants to start bringing group back to TPE, what is timing to go through issues raised

<WileyS> Roy, okay

fielding: ready to start on responses now, likely a week

<npdoty> we also have issue numbers, if we're having trouble keeping track

fielding: best way is likely for fielding and dsinger to go through a pass of issues

dsinger: finding modern javascript expert

fielding: go through issues one by one, if UGE will defer to David. Will have quick response from editor, Then working group should go through the editorial responses. with prior review by chairs
... then we can discuss on mailing list or calls. Intent is not to state opinion of working group. For each group must be chair decision that working group has considered and here is response. Then someone needs to go through and respond to commenters

<dsinger> to WileyS — if the referer header identifies a context other than yours, and you remember it and associated it with the user, you’ve remembered tracking data in our definition, haven’t you?

npdoty can you take over? thanks

<npdoty> I suspect that I'll be doing the responding to each comment step (with links)

<npdoty> scribenick: npdoty

justin: will bring it up if I see anything that concerns me. will need to refresh

fielding: when I respond to a comment, I'll CC the mailing list, the group should feel free to discuss on the mailing list if I disagree

<WileyS> David - I don't believe that's appropriate so am supportive of any instrument to remove this perspective from the standard (such as Roy's choice of a Permitted Use).

fielding: a lot of the comments were repeats of comments we had before Last Call. WG doesn't need to repeat a discussion if there's no new information.

justin: right, something we've mentioned before
... a process that we'll start next week on the call, or the week thereafter

personalization

justin: an issue we've described before
... concern over the DNT signal and the possibility of targeting (with data hygiene) when the signal is turned on
... an object of dispute in the group, likely need to proceed to CfO on that. positions are well understood

talk next week

[adjourned]

<schunter> I have to leave now.

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/Eric/Erik/
Found ScribeNick: amyc
Found ScribeNick: npdoty
Inferring Scribes: amyc, npdoty
Scribes: amyc, npdoty
ScribeNicks: amyc, npdoty
Default Present: eberkower, RichardWeaver, Jack_Hobaugh, [FTC], dsinger, npdoty, schunter, [Microsoft], kulick, Jeff, +1.202.407.aaaa, justin, vincent, +1.917.934.aabb, +1.813.366.aacc, WileyS, Fielding, moneill2, +1.425.707.aadd, adrianba, Wendy, Brooks, SusanIsrael
Present: eberkower RichardWeaver Jack_Hobaugh [FTC] dsinger npdoty schunter [Microsoft] kulick Jeff +1.202.407.aaaa justin vincent +1.917.934.aabb +1.813.366.aacc WileyS Fielding moneill2 +1.425.707.aadd adrianba Wendy Brooks SusanIsrael ErikN
Regrets: johnsimpson
Found Date: 20 Aug 2014
Guessing minutes URL: http://www.w3.org/2014/08/20-dnt-minutes.html
People with action items: