schunter: very lively, constructive and positive discussions
... like this group and our atmosophere
... and that I see many familiar faces and some new ones
... Tracking Pref Expression document now getting very close to done
... for the Compliance doc, we've now created bundles of proposals
... can choose one of these packages or a plausible mixture of them
... as we discussed last time, a focus on text
... continue the positive atmosphere
... focusing on consensus, votes this way or that way will hurt our atmosphere and culture
... find something we can live with
... important that we find solutions that all or at least most people in this room can live with

Process and current status

schunter: process review.

<npdoty> "actually we are quite nice people"

schunter: don't want to force anyone into anything, we are nice people, do not be afraid...yet.
... important for you to mention when you disagree with proposals.
... at the end, we must all consent to the conclusion.
... we need a process that gets us there.
... even if there are bumps in the road
... don't want to overrule large portions of the group
... finding solutions that most of us can live with.

aleecia: this is slide review from Belgium
... w3c standards are "recommendations", voluntarily adopted
... hi, I'm Aleecia! =D
... supported by Mozilla to work here; also work at Stanford.
...also: I am a capitalist.
... Matthias is at IBM, and he knows P3P
... our mission, from charter:

<npdoty> "The mission of the Tracking Protection Working Group, part of the Privacy Activity, is to improve user privacy and user control by defining mechanisms for expressing user preferences around Web tracking and for blocking or allowing Web tracking elements."

aleecia: needs to works for users, work for businesses
... if we don't do this, governments will
... they may not be as... sensible... as us
... and there may be different things in different countries
... also want to avoid forcing users to block ads
... users don't hate ads, they have concerns for data collection
... working on three different standards documents
... <thanks to editors>

<npdoty> yay, editors!

aleecia: +regrets Justin
... will not be chatting about TSLs this week
... <timeline>
... we have only been slightly behind schedule
... we are aiming for april (june latest) for 1st last call

<npdoty> though like with the Community Group comments, the chairs might help us group them together, propose resolutions, etc.

aleecia: also we might say "yep, we thought of that"

matthias: whether we reconvene in person depends on the amount of comment received. hopefully, can do by phone and mail

ian: cr for compliance: do we need independent implementations for the non-technical components of the spec, given the short time window and the size of companies needed to implement?

aleecia: hopefully, we'll see people making things go before cr, perhaps before 1lc

ian: yahoo says they're starting, what's their timeline?

shane: first we need a browser to support a tpe, then we can build to that, and it'll take more than a month.
... if we just have two tiny sites, that may not be enough.

tlr: doesn't need to be in production, we can have prototypes.
... what we accept as an implementation may be a judgment call.
... we're talking about what we need to go from cr to pr, good discussion.

dsinger: +1 talking about this criteria is important. hard to put dates on things that we don't control (other people doing things).

<jmayer> I strongly disagree that we need large companies to fully implement compliance to move from CR to PR. I also strongly disagree that we need browsers to implement more than the "DNT: 1" header to move from CR to PR.

ian: this is new ground for the w3c
... we really want to know if this can be done at scale
... prototypes may not be sufficient

<hwest> Given that one of two success criteria in the charter is implementability, I think it's important to make sure that it can be implemented across different stakeholders and sizes

<jmayer> I would like to also point out that, unlike a purely technical standard, there aren't sneaky bugs to squash. The compliance document is largely policy.

sidstamm: shane do you need full browser support to get started?

WileyS: no, but different components depend on browser support for different features.

<Lia> ifette: more policy than technical - seeing dates may send the wrong signals but the criteria - question as to whether this can be done on a grand scale- need implementation reports from full deployments

<npdoty> rvaneijk: one deadline that won't shift is Neelie Kroes's decision for June about whether to rely on this standard

aleecia: and this is why a june 1lc is important
... we are between 2pwd and 1lc

<rvaneijk> milestone in june is not moving, wp29 is going to have to give an answer whether DNT will fly (implementable, adoptable) by june 2012

aleecia: getting to closed: discussions+drafts lead to consensus text

shane: enough people?

aleecia: vairable. 80/20ish. "sense of the room"

<npdoty> aleecia: doesn't have to be unanimous to move forward

<npdoty> ... "80/20" wasn't meant to imply a specific 80% standard for the room, sorry for the confusion there

aleecia: issues not reopened without new info
...derailments: multiple drafts, or formal objections [onoes!]
... this happens on the list
... with multiple texts, consensus is least objectionable proposal
... [object is in english, not w3cese]
... chairs will listen to everyone, then tell us what our consensus is
... chairs are not eager to exercise their omnipotence, it's a lot of work

<npdoty> aleecia: chairs will go through every single comment looking for the proposal with the least objection
...derailments: better if we work it out

[we=the group]

aleecia: we do not make decisions based on who screams loudest or on total number of responses

matthias: better to have group reaching consensus than chairtatorship. prefer evidence-based thoughts.

<npdoty> schunter: this is more text-based, the chairs have to judge explicitly based on the text/comments submitted from the group

aleecia: all input comes from the group. chairtatorship doesn't come from chairpinions.

<npdoty> amyc: didn't see the same level of formality in the Getting-to-Closed document that we see in the HTML5 WG

aleecia: to file a FO, must in writing and in public cite technical objections, and propose changes to resolve objection. group can choose to respond and solve objection

<Lia> would be surprised with we have groups proposing formal objections

aleecia: but don't hold your breath on that

<Lia> ...if proposed then w3c review process

aleecia: goes all the way to the top to TBL's desk

<Lia> if response is to sustain the formal objection then may need to revisit and reopen

aleecia: can create a tracker of FOs <shivers in fear>

<Lia> create a tracker of formal objections

aleecia: if FO sustained, may need to reconsider other issues

amy: q? aleecia: the FO process is serious business. let's not do it.

rigo: happens at checkpoints. w3c team is mediating.
... if this fails, is this unachievable? can w3c reputation let us continue with this fo?

tlr: fundamental balance between parties in wg, such as process violations (process is most frequent cause of sustained FOs). can be a way for members to make clear that they disagree, but let group continue.

Status of specifications

dsinger: compared version from Brussels
... shortened up and revised the abstract
... removed the word cross-site before tracking
... well known url to get status
... new section on the exception model
... making sure the doc and the tracker in a consistent state
... 5 open and overdue actions
... questions? read thru on plane in fairly comprehensible shape
... need to resolve url and response header

matthias: block of time to review pending issues

david: made a table of all issues and status, sections applied to, etc. happy to share

matthias: thanks david!

claps all around

john: are we still committed to the notion there will be two docs or just one?

aleecia: i don't think we know

matthias: from a charter perspective putting out two docs

jmayer: wants to understand how doc addresses the issue of defaults
... open to pending review to close and back again
... suggestions that defaults okay, not, and instances where silent

<WileyS> Why not simply create a section called "Defaults" and address the issue directly

jmayer: are those areas ambiguous areas where they should not be marked closed?

matthias: not our purpose to confuse

jmayer: what is the intended resolution as the editors intended

matthias: should the tpe provide the default for dnt
... somewhere collect preference from user

<WileyS> I believe consensus was that the W3C would not recommend setting a default - and that any expression should come for a "user" directly and not intermediaries

heather: make more sense to figure otu what the scope one we figure out more the scope is
... a lot of options for parties
... whether defining based on EU law
... definition of tracking should prob appear earlier
... defining tracking as...
... next section outlines what means to comply
... first party should not share data with third parties
... not sharing data with third parties when dnt on
... text says we will figure out in tech spec and reference here
... third party compliance under active discussion
... a number of specific examples around geo location and cookie syncing
... number of open issues that will need to be resolved
... fraud detection...
... next section, user exceptions where user permits specific when dnt is on
... clearly the sections that are going to take a lot of discussions, def around tracking and parties as well as exemptions around third parties

david: make clear where the doc says may do limited tracking
... and user gives you permission to
... does someone in the room have a clear def of two concepts

ifette: issue deals with request injections
... should it also deal with response injections?

dsinger: should be NO for both requests and response headers

<npdoty> like if your corporate network is tracking your activity (as an ISP), should it update something in the response header or otherwise send a DNT response signal?

bryan: careful with internet architecture complexity

<amyc> Is this example, consider employers and libraries that have settings on behalf of users that use resources owned by employer and libraries

matthias: general process ok?

fielding: why are we doing this now for FPWD (vs. later)?

<bryan> there are valid reasons/contexts in which a proxy would provide value-added DNT service on behalf of users, including corporate or for support of legacy devices (non-DNT compliant) . We should not hinder innovation by putting restrictions on how Web architecture entities (including proxies) may enable DNT.

<npdoty> issue: should the spec speak to intermediaries or hosting providers to modify any responses/statements about DNT compliance?

Issue-65

<WileyS> User registration and login often are bundled with a set of sign-up flow notices, Terms of Service, and Privacy Policy by which a 1st party will operate. If these notices directly address interactions with users off of the 1st parties direct web site, such as through Widgets or other interactions with a user in a logged-in state, in an open and transparent manner, then this is considered an

<WileyS> out-of-band user consent.

<WileyS> If a party claims it supports DNT, they MUST claim their out-of-band consent in DNT response headers or well-known URIs (direction TBD) - including a link to instructions for the user to alter a previously granted out-of-band consent if they so desire. If a service that employs registration (logged-in) is silent on how their service interacts with DNT (we honor it, we don't, you're providing

<WileyS> consent to our service to ignore your DNT setting, etc.), then it should be assumed that party is not honoring DNT.

aleecia: 3 possibilities: DNT and login/out unrelated;

<WileyS> If on the other hand a service states they comply with the DNT standard, they would need to articulate what this means for their registration services. If a party both states they support DNT and is silent on how this interacts with their registration services, then that party MUST continue to honor DNT despite a user logged-in status.

2. login turns off DNT state; 3.

<aleecia> tl: do we need anything in the doc if we do that?

tl: do we need to specify that in the document, or is adequately considered by interactions understood by users?

WileyS: I don't disagree

ninja: we need to clarify logged-in status, e.g. for social networks
... user expectations may not consider logged-in in one tab to extend to other sites

rigo: what if a site leaves a logged-in cookie as you browse to other sites?

<npdoty> this sounds like the same concern that Ninja had, that users won't realize about persistent logged-in status

<fielding> npdoty, if you don't like Facebook, delete your account. The same goes for any service that does something without your consent. The first-party is expected to provide consent alternatives that satisfy their own users -- we don't need to do that for them.

jmayer: can you put something in the sign-up flow that says "if you log in, we're going to track you"?
... where is the consent line?

<dsinger> but then we're arguing about what constitutes separate, informed, consent, and THAT is not our job, it's a jurisdictional question

<fielding> npdoty, yes, but don't see your point -- consent can be removed, but that might imply the account is removed (or might not)

<justin> My proposal for non-normative text --- a paragraph in a privacy policy or terms of service is not sufficient consent. A separate forced choice during sign-up would constitute valid out-of-band consent.

jmayer: options for user consent. 1, language in signup flow
... they'd still send a response header, under TPE doc
... 2. require higher-level consent, such as what tl, pde, jmayer drafted
... 1. it can be in TOS or privacy policy; 2. it has to be separate consent
... response header or well-known url applies across both

Hum.

<aleecia> :-)

hum inconclusive between prefer option 1/2

<aleecia> "User registration and login often are bundled with a set of sign-up flow notices, Terms of Service, and Privacy Policy by which a 1st party will operate."

<fielding> Generally the requirement is prior, explicit, and informed consent! We need no other details.

<aleecia> JC, you see why I think ToS and PrivPol are part of this?

<justin> Fine with fielding (and I think JC) --- but no need for prescriptive language.

aleecia: we're looping here

"can't live with" hum

again, hums on both. inconclusive

<justin> How can you not live with clearly asking for permission to track despite DNT?! Really?!

aleecia: we'll do another round of consideration in an upcoming call

<jmayer> I agree with Justin. This is beyond absurd. If users were in the room, they'd be disgusted.

aleecia: if we don't reach consensus, those two options will come before the chair

<rigo> please use ISSUE-65 for further discussion

aleecia: next round: write things crisply and clearly

<WileyS> tl, Yes - I'm comfortable with an entity needing to send a response header/well-known URI if they are overriding the header they are receiving.

<WileyS> But I believe the TPE already states this

<pde> JC, WileyS -- something that is important, which I think underlies this conversation

pde: k anonymity should be removed from normative text
... will explain k anonymity and 1024 unlinkability
... anonymity set: the set of possible people who could fit your categorization
... when keeping anonymized records, if any record's set is smaller than 1024, it's too small
... i.e., users are not effectively anonymized in a smaller set.
... suggested standard, either theoretical or look at the data

q: where did 1024 come from?

pde: picked a number that sounded like others we were hearing
... but happy to put it into the non-normative suggestions.
... it could be smaller, but ~1000 gives margin for error

<tl> s/\~1000/1024

dsinger: make sure that the smallest value is always greater than 1

<aleecia> the context could matter too

fielding: consider human studies guidelines

<npdoty> fielding: more like 30 than 1000 from studies I've read

tl: range of values possible

<ninja> have we agreed on calling it "unlinkable data"?

<fielding> what I said was that, IIRC, the number 30 was common in human studies guidelines (because 20 is statistically sufficient)

<fielding> this does not prevent folks from choosing larger numbers

<tl> ninja: If there's a better phrase, let's use it.

<aleecia> ninja we haven't, though that's one of the possible names

jmayer: reidentification research

<aleecia> are we running into name space collision where it means something else elsewhere?

<tl> I think that this phrase is sufficiently clear about the intent and function of this suggestion.

<tl> I do not think that there is collision.

jmayer: make sure your buckets are big enough that outside information doesn't let you learn something new to identify individuals.

<ninja> aleecia, yes - there are several ISO privacy drafts which use unlinkability it in a different way

ifette: what about stream data? how do you provide k-anonymity guarantees on streams vs points of data?

<aleecia> thanks, ninja. let's find a different phrase then

<tl> Who hates "k-anonymity" ?

<npdoty> FTC refers to "data is not "reasonably linkable" to the extent that a company: (1) takes reasonable measures to ensure that the data is de-identified; (2) publicly commits not to try to re- identify the data; and (3) contractually prohibits downstream recipients from trying to re-identify the data."

pde: best-efforts, rather than absolutes here

<WileyS> I agree with Ninja (and our submission calls this out) - but "anonymization" is already a fair term here.

<tl> "Sufficiently fuzzy records."

<aleecia> de-identification is plausible

<WileyS> Anonymization = de-identification (at least in the privacy world these two should be equatable)

<tl> WileyS: Nowai? Removing identifiers does not make records anonymous.

bryan: we don't believe there should be anything normative wrt anonymization

<tl> aleecia: It would be swell if you could put the agenda (and a clock) on the projector. You know, for funzies.

rigo: pseudo-identifiers?

<WileyS> Nowai???

<aleecia> it's directly under the clock

<aleecia> on the wall

<tl> aleecia, I know. I just think that something glowing and aggressive might be more psychologically effective.

pde: if some fields are defined as "sensitive", you can sometimes re-identify from "non-sensitive" combination

<jmayer> Just to get it in the log - my point was that there are different de-identification/unlinkability problems for collection (e.g. a cookie) and retention (e.g. IP address, User-Agent, Referrer).

pde: better to treat all the fields as potentially identifying

<aleecia> i'm not willing to lose seeing IRC to put up a clock, but if you want to volunteer your laptop... :-)

efelten: different frameworks, including differential privacy, along with k-anonymity
... are you considering other frameworks?

<npdoty> pde: "just do it right" against some competent opponent, and leave open (at least normatively) the particular technique

<bryan> AT&T does not believe there should be any normative requirements included in DNT re methods of anonymization or bars of anonymization effectiveness. As noted in our comments to the FTC final report, robust anonymization practices combined with restricted access provisions, can provide sufficient protection to justify treating the resulting data sets as non-personal information"

<jmayer> I think the retention problem is much harder. I think the collection problem we are very close to agreement on.

<WileyS> tl, This depends on data sparcity. If there are only two records, one being an identifier and another being a high-level activity (viewed a page, clicked on page), then removing the identifier would render the record "anonymous".

<rigo> scribenick: rigo

Overview of the 5 Different Proposals

<aleecia> 15 minutes max each, please

dsinger: reaction to Roy, restricting to cross-site tracking.

<tl> Wileys, there are records for which the removal of a subset of identifiers renders them anonymous. However, the assertion that "removing identifiers renders data anonymous" is not correct. Indeed, consistently, attempts to "anonymise" data by removing identifiers fail. C.f. Aol, Netflix, &c.

dsinger: abandon the concept of first/third, still define party and tracking
... mainly record transaction and storing it for future use as tracking
... big win: we do not have to worry about all those distinctions of parties and mesh ups etc
... ordinary logging would be out of scope of DNT
... all other definitions of tracking would put the ordinary logging into scope
... be careful about recording which add was played on which site and remember that data

ifette: if you're doing impression based on site, would that be covered?

<aleecia> In my thinking, you can either have: data about a user, or data about another site, just never at the same time. I think that's universally true for David's proposal

dsinger: yes, you wouldn't record that ifette had seen that ad on this site, but only that the ad was served an that site
... frequency capping would say: This user have seen it so many times but not where

<aleecia> sounds like that suggests some permitted uses with discussion on how that works, just as with the other 4

WileyS: dunno how to escape the fact that user has seen particular add on particular site

dsinger: permitted uses must be fewer. still need fraud...

<npdoty> WileyS: in order for me to run an ad network, I have to, even for non-targeted ads, remember and prove to the advertiser which ads were shown to which people on which sites

aleecia: still have a discussion of the permitted uses across all 5 proposals

<aleecia> *unless* there's a permitted use

<npdoty> dsinger: not allowed to associate a user with a site that is not your own

robsherman: personalized experience across sites. couldn't record user and site together only user in a silo and site in a silo...

<aleecia> (or unless there's consent through another path)

<aleecia> closing the queue

dsinger: you're not allowed to remember on which your widget was served unless you get DNT=0

tl: silo means tl has so many like buttons and like buttons served on that site but not both

<npdoty> q

MS: discussing the baseline and have to still discuss what that means

WileyS: Proposal

3 parts:

1/ party definitions

2/ party rules

3/ permitted uses

1/ First party definition is common ownership or control

2/ ruleset that we shared in Brussels. If not out of band consent or DNT=0 the following rules apply:

a. first party may track

<npdoty> "in the context of the first party experience"

<aleecia> of note: I did not capture "all parties" in the 8 page table

b. third parties must not use data across multiple non-affiliated sites

c. linkability should not be possible

<fielding> "data" here is just "data linkable to a specific user/device", right?

d. third parties must not leviate previously collected data

e. third party should not try to identify user

f. not give data to any third party unless service provision (data processor)

g. party MAY purge previous profile from a user

h. user granted exception override

JohnSimpson: do you mean "use" or collection of data across data

WileyS: we use "use" but we do not know what collection means and what retention means, but we could discuss that

JohnSimpson: Third party can collect and use

WileyS: that's only service party
... permitted uses:

- frequency capping

wanna be very specific to the use case

we apply a reasonable data minimization rule is applied to all permitted uses

Justin: is that different from DAA?

WileyS: good question, have to look it up

<aleecia> (so, NAI is like this, DAA we're not sure)

MZ: doesn't have specific data minimization provision

WileyS: data collection for billing, cpm etc..
... cost per click and cost per acquisition
... auditing for third parties

<rigo_> notes that auditing is covered by the APEC rules

Roy: data I assume you mean linkable data to the user

WileyS: correct

aleecia: if you have pre-aggregated data, you do not need permitted uses

WileyS: security is off the one we all agree, but still some discussions on the details

<aleecia> (in this proposal, implicitly, and should be made explicit if it is not already)

WileyS: don't allow the bad guys be putting on dnt
... anything that is contextualized is permitted,
... allow data collection for aggregate based reporting
... we do require aggregation that is reasonable irreversible, but we do not talk about the timeframe for aggregation
... to fix a broken thing, we allow debugging
... but that is very punctual
... unlinkable have moved to the end because already covered by anonymization and aggregation provisions

<WileyS> q

bryan: any anonymiztion requirement should be only an open list to current practices as anonymization is a moving target
... normative list of permitted uses should not be there because it will industry put into risk that they will be held to promises they did not make

<npdoty> bryan: don't believe we should have any normative list of permitted uses

asoltani: third party siloing, is only siloed from parties, not from law enforcement?

WileyS: technical steps should be taken, but did not want to proscribe those

<aleecia> ?

<bryan> Overall comment to the approach of listing and detailing "permitted uses": We believe any defined list of permitted uses should serve as illustrative (i.e. non-normative) examples as a guide for industry compliance, rather than as an exhaustive list hemming in new and innovative practices and requiring extensive and burdensome justification if one varies from it. Various compliance regimes will apply and address any variance to a site's clearly expressed privacy p

jmayer: technical restrictions, but up to debate what the technical restrictions for silos are.
... also preventing the company of collecting the data in the first place

question: where the FTC is on affiliates, corporate affiliates would be first parties. Is the FTC proposal off the table?

==========================

jmayer: 3 phases: 1st and 3rd party (pros and cons of that) user expectations to distinguish those
... 2phase what 1st parties have to do: no circumvention of DNT by passing on information to others

<aleecia> Justin you'll be next; John may be able to sum up as "agree with X proposal on this, Y proposal on that" and save time time

jmayer: 3rd phase: definitions of use terms, some provisions on connecting to user agents, IP addresses should be something in the document about those
... exception on unlinkable data, has some requirements, how long it can be retained
... has some provisions also technical requirements for outsourcing
... we do not allow for independent use by third parties
... first party would be liable if hte third party would violate DNT
... high bar for user permissions
... contextual collection, geolocation, security and fraud prevention exception
... impression fraud.
... permitted uses will include some technologies like fingerprinting

ifette: any logging on impressions can only happen after you have some suspicion
... and then start logging

<aleecia> (this differs from the text)

Tom: gathering data for small amount of time for brief analysis and test if it there is suspicion and then escalate if you have suspicion and also store data into different area

<aleecia> (protocol logs are not captured in the table)

ifette: protocl logs means full request headers?

tl: we do not have a full definition

aleecia: good area to expand

<npdoty> pde: we were thinking protocol information was not cookies, but the rest of the headers/http request

Alex: k-anonymity with long term storage?

jmayer: as you collect data, you may want to de-identify some of it
... definition would allow for some line drawing

jmayer: lets suppose you keep logs for over a year. You may want to drop last byte of IP

Alex: if I put something into a bucket that is k-anonymous

<aleecia> Shane, you'll be next; Roy after Shane; likely closing the queue out of time then

<npdoty> pde: avoid having unique id cookies being sent when DNT is set

Peter: we want to prevent UID cookies to appear on client site

<npdoty> ... you certainly could use unique ID cookies and practice with the spirit on the server side, but auditability is a major issue

WileyS: is there are possibility for other inpoints, takes time to discover a threat, there are model threats (patterns) use cookies to do that
... discover things all the times. Need discussion: if we have system isolation and purpose isolation.
... would system separation
... or purpose separation be an option

peter: yes, that could be an option

<npdoty> WileyS: would system- and purpose- separation be sufficient? so that then the security guys can collect whatever and do what's best for the user

peter: but we have hundreds of companies and need a baseline and some guidance

<npdoty> pde: don't give a free pass to bad-faith actors

jmayer: agree with Peter. Premisse iwth Shane's concern. DNT may be attackers better off. Not my understanding, would not raise new issues,

<amyc> would be helpful to get more detail around protocol logs, what data is received

Roy: not clear about outsourcing section. Notion we could frame it as an end result instead of proscribing the way we get there

=============================================

Justin: try to find dealbreakers

<npdoty> identify potential deal-breakers, compromise on stuff that we don't find ideal but something we could live with

Justin: willing to live with the affiliate definition
... discoverable affiliate would be perhaps more beneficial
... retention periods: so long as you state that you follow minimization principles
... last part: consent is very important

<npdoty> ... outsourcee can't use identifiable data for their own purposes

Justin: outsourcing companies can not use the data for their own purposes

<npdoty> ... (outside of maybe a narrow debugging exception)

Justin: no standard for anonymity, so no controversion

<npdoty> ... FTC "reasonably unlinkable" a promising approach

Justin: for the rest, aligned with Shane's proposal

<npdoty> ... in a way that's economically feasible that you can do without a unique identifier, you should not use one

Justin: clearly state how long you retain stuff
... retention limitations

<npdoty> ... no problem whatsoever with Facebook providing a contextually-targeted experience based on visiting the Washington Post

Justin: market research and product improvement is too broad

<npdoty> ... Do Not Track signal should be a sign that users don't want to participate in market research

Justin: consent issue is important to us

<npdoty> ... unless of course there's a clear participation, like paying users to track them (misreported from Google?) or traditional Nielsen panels

<npdoty> rigo: why don't we need to define tracking?

jmayer: want some understanding what exactly CDT's threat model is.

<npdoty> justin: "tracking" is not operational in the document, it's just a question of what you have to do to comply

<fielding> I still won't implementt DNT without a definition of tracking. If this WG won't define it, I will fork the spec.

jmayer: we came from unique ID and cross site tracking

justin: same threats are there. There is value of uniqueID for debugging, but only on short retention

jmayer: are there use cases that would not work if DnT would be too restrictive?
... want to find out about balancing interests

justin: group settled on those purposes and those were broadly accepted

<npdoty> justin: to the extent that you can do that (purposes) anonymously, you should do so

<WileyS> I believe there is value in defining tracking - but then doesn't "Do Not Track" mean don't do anything that definition encompases? How do you avoid inadvertant inclusion/exclusion of rights in the "Tracking" definition? I believe that's why the group hasn't wanted to define it "yet". Perhaps once we've come to concensus on the rules and permitted uses, then a clear tracking definition will

<WileyS> emerge.

ifette: curious how far you take it the DNT over multiple sites

<aleecia> (yay for specific examples & use cases)

<WileyS> Roy - that text was for you (apologies for not starting it with your name)

ifette: can we include DNT users as a category?

Justin: fine

<npdoty> WileyS, fielding, I suspect that a lot of people like Justin would be fine with a definition of tracking that just refers to the other sections of the compliance spec

============================================

JohnSimpson: took Aleecia's template and answered the questions
... definition of party, but big fan of "user expectation" branding could be included

<jmayer> To be clear, I don't think the group at any point agreed that the candidate exceptions are particularly valuable, let alone valuable enough to trump serious privacy considerations.

JohnSimpson: concerned about long list of affiliates that could be included and want to have a cap there

<jmayer> The exceptions were suggested for discussion.

<aleecia> as a procedural point, that is correct, jmayer: we did not agree we would address all of them

<jmayer> I'm all ears if someone in the advertising industry could explain the use cases and economic value for each exception.

JohnSimpson: default rule required: If you don't know what you are then you should act like a third party

<justin> I was to some extent deferring to the DAA principles and the ideas that the group had previously idenitified. I obviously edited for those areas where I thought the privacy implications outweighed (market research, product improvement).

JohnSimpson: I think you can do whatever with unlinkable data, but some requirements on unlinkability
... logging is ok and auditing also
... but short retention
... contextual: if information is used only for context, but if you don't remember that's fine

<amyc> Justin, would be helpful to understand aggregation in your proposal

<Zakim> ifette, you wanted to ask if under this proposal, "Google Germany GMBH" and "Google UK ltd" and "Google Australia Pty Ltd." etc would all count towards the maximum number of

<justin> Immediate aggregation obviously is fine. The draft we put together says that aggregation within two weeks for the 7 listed purposes (including market research) would be fine too.

WileyS: how you came to the number?

JS: out of the air, but we should have a discussion on reasonable number

<justin> But I'm still working that out in my mind --- I don't like prescriptive numbers, but I also don't want t leave it unlimited since there's no logical data retention limit for market research as the value will always marginally increase in value.

<aleecia> & then closed queue

<Zakim> ifette, you wanted to ask if you can keep things like "A user saw this ad on this site and clicked it" but not which user

ifette: you could use info in real time to do contextual but not remember. How firm is the line: Can I have this add on this site without knowing hte user

JS: we served 100 diswasher adds on site? yes, can do

<npdoty> aleecia: "I want you to know that I adore you all" <laughter>

<npdoty> scribenick: efelten

Comparing proposals and finding important differences

Aleecia: comparing the five proposals
... setting aside David's for now

<tedleung> I am the backup scriibe

Aleecia: everyone agrees that co-branded, co-owned sites are the same party
... everyone thinks that Google, including AdWords and YouTube, are a single party

JohnSimpson: user expectation is the touchstone; users expect Google to act as a single party
... but some affils might not be known to users, such as Yahoo and Flickr, unless co-branded
... branding trumps uninformed user expectations

Aleecia: you're saying that most of Google is one party?

JohnSimpson: not sure about DoubleClick; would be closer if called GoogleClick

dsinger: Question for all: what if companies set up affiliate structures to isolate functions for liability purposes
... don't want to let sites get off the hook by separating themselves into separate parties
... principle is that if you pass data to an affiliate, responsibility must be clear

jmayer: Google analytics on a Google property is a first party; but G analytics on another site is a 3rd party
... Google becomes a first party when you click a Google ad
... practical effect is to require some siloing between Google's info about you as first party vs. data they get as a third party

Aleecia: Are jmayer and johnsimpson agreeing about this? (other than the 5 affiliates limit)

<enewland> it seems to me there is an overloading of notation here. "First party" and "third party" are being used in two difference capacities. First, to refer to the relationship between a party and partners it may have (Geico and See's). I think of this as the horizontal relationship. Second, to refer to the relationship between different parties that are "present" on a website. I think of this as the vertical relationship

aleecia: Is Google a 1P on sites that are not Google?

erica: Agree with jmayer and tl on this
... think of horizontal and vertical relationships
... Sees and Geico are horizontal relationship
... If I visit nytimes.com, Facebook on that site is a vertical relationship

tl: What we're asking is whether Google analytics on a Google site is a 1P.

jmayer: diff way of saying what Erica was trying to say:
... boundaries of a party are context-specific

<johnsimpson> test

jmayer: extent of Google as a party might vary based on context
... but our proposal, and the CDT one, did not make party-extent context dependent

tl: Does anyone agree with making the extent of a party context-dependent?
... that is, should be treat Google as multiple parties when they're a 3P, but as a single party when they're a 1P?

<tl> /me I'm so sorry ed.

tl: to be clear, I don't agree with that

rigo: Definition of party in privacy regulations, in Europe and APEC framework, which binds the US ...
... all talk about data controller (or info controller)
... How does party definition relate to the controller definition?
... If they're the same, this makes compliance and explanation easier.

wileys: Our definition is commonly owned and commonly controlled

<justin_> Accord.

wileys: meets the EU data protection requirements, also APEC and GLBA

Aleecia: Back to tl's question
... everyone agrees that all of Google is a single party
... suggested Geico and Sees Candy as an example because they are commonly owned
... but some proposal writers didn't know that
... Does that change anyone's position?

wileys: Our proposal should have said Geico and Sees are the same party, because commonly owned
... and discoverable by the user

johnsimpson: companies can get over this by using branding

bryan: Is there any assumption about discoverability?

aleecia: Can see that in the answers from the proposers

pde: If it's obvious to the consumer, then same party

aleecia: Careful about the word "discoverable", due to history in this group
... have had various definitions earlier

JC: Is copyright notice at bottom of the page included?

tl: Copyright notice is discoverable, but usually won't be noticed by users

JC: Is copyright notice enought to make them the same party

tl: Depends on which proposal you're looking at

ifette: When Bing was new, wasn't obvious to some users that it was Microsoft
... that's a good real-life example

wileys: Reminder: purpose of this session is to articulate agreement / non-agreement between proposals
... not to resolve the differences, just enumerate them

aleecia: Moperilla example, two companies form a joint venture; all the same party?

jmayer: All get 1P privileges for the current interaction, but don't get to funnel unrelated data through this relationship

tl: They're all first parties, but they're not the same party

jmayer: Sorry for going down the rabbit hole, but ...
... in principle, could consider this three parties, or two overlapping parties, or one big party
... if taking static view of parties, I would allow Moperilla to share data with Opera, Mozilla
... but Moperilla can't be a conduit for passing data between Mozilla and Opera

<efelten_> [scribe reaches for his nonexistent beer at this point]

ifette: MSNBC as an example. How relates to Microsoft and NBC?

tl: If it's obvious on MSNBC that it's a joint venture of MS and NBC, then everything I do on that site,
... MSN, NBC, and MSNBC are all first parties
... anything that MSNBC collects on its own site can be sent to MSN and NBC
... can customize MSNBC content based on MSN and/or NBC data

<hwest> Why are we talking about sending information between the parties? Why not specify that all three parties collect the information (since they can, if they're first parties) - much cleaner example, right?

tl: but can't be used to communicate between MSN and NBC

<hwest> In this example, it seems like it would be the same question, and simpler

<jmayer> Heather, the no-conduit issue stems from the recognition that some backend sharing does happen in these odd scenarios.

johnsimpson: consider these different parties

justin: Consider MS and MSNBC to be separate parties

wileys: but there's common branding, right?

<hwest> Then premise it on "you could collect it as a first party, so you can have it" rather than upstream/downstream

<jmayer> Mozilla, for example, can get from Moperilla only what it could collect itself.

justin: They're not commonly controlled, so not the same party.

<hwest> jmayer I think we are, just suggesting a frame

rigo: Question for Shane re MSNBC. Is MS the effective data controller?
... what if we have common branding, but only one of the partners is controlling the processing?
... what if control is narrower than branding?

wileys: Will need to consider this case further...

bryan: If two entities are considered separate parties, do users need to opt in separately?

justin: Depends on whether there is common control.
... "powered by Bob's Analytics" doesn't make it the same party as Bob

Aleecia: [summarizes the last chunk of discussion]
... moving on

<rvaneijk> The Jonhantan/tl/pde example in the EU would play out as a joint controllership, with two controllers jointly responsible. A controller determines the purpose and means of the data processing.

Aleecia: Definition of a first party
... johnsimpson and jmayer have essentially the same definition

<rvaneijk> s/Jonhatan/jmayer/

Aleecia: Any questions remaining on this concept?
... CDT adds a requirement that it be the site the user intended to visit
... wileys looks at ownership more than user interaction

dsinger: Question for all four: If I go to site A, which redirects me to invisiblelogging.com, which redirects me to Apple
... is invisiblelogging.com a third party?

aleecia: Will take that up when we talk about redirection
... Looks like this is not a point of difference
... general agreement on what makes a site a first party (site the user is visiting, or intentional interaction)

amyc: Agree, but have some concerns about the "high probability" language
... will need to resolve that

aleecia: agreed
... move on to requirements on first parties

<npdoty> basically all the same what first parties must not do

aleecia: seem to have agreement
... only differences are non-normative or best practices

<npdoty> basically all the same on what a 1st party may do: may profile and customize, and may voluntarily provide more privacy features

<npdoty> where the proposals agree, not necessarily everyone in the room agrees

aleecia: Acknowledge that if all of the proposals agree, the whole room might not agree
... moving on
... what is a third party?

<npdoty> agreement that a third party is not a first party or the user, although there are debates over wording

aleecia: all agree that third party is everyone who isn't a first party and isn't the user
... moving on
... What must a third party not do when DNT is on?
... all agree that there are user-granted exceptions and permitted uses
... jmayer and CDT proposals are similar
... others look similar too; any significant differences?

johnsimpson: Mine says no collection, wileys controls use rather than collection

wileys: Trying to avoid a debate about what constitutes collection
... would need to sort through definition of "collection" before we could all agree to use that term

npdoty: Would you say that sites shouldn't *retain* information?

wileys: probably ok

rigo: [questions about the details of what constitutes collection]

aleecia: Add Rigo's questions to the open issue on what collection means
... moving on
... what third parties must not do
... CDT says 3P should not retain info
... CDT says 3P must treat data of other parties with at least same level of protection ...

<npdoty> rigo, can you list your questions so I can add them to issue-16?

jmayer: yes

johnsimpson: me too

ninjamarnau: Want to understand treatment of data from past interactions
... CDT says should not retain; others say must not

aleecia: No actual difference, just a transcription error in the chart
... moving on
... Shane proposes a 3P must segregate data according to which 1P site is came from

ifette: Segregation should be by policy, or technical?

aleecia: Is that okay with the others?

wileys: [clarifying] If an ad network provides services on multiple sites, must segregate data collected on different first party sites.

johnsimpson: Thought the 3P wasn't supposed to be collecting data at all, absent an exception or permitted use. ??
... don't think that is what we intend

wileys: All comes down to definition of service provider.

pde: This is what we call outsourcing

wileys: When get DNT, need to treat each 1P context separately

rigo: Notion of controller is important here. Service provider is treated as first party, as long as has no right to process data for his own purposes

<npdoty> I believe Shane is suggesting that even with a DNT header and a non-service-provider relationship, an ad network could continue to build behavioral profiles and behaviorally target ads to a user, but only a behavioral profile based on the user's activity on that single first party

rigo: only on behalf of the first party
... is that John's issue

johnsimpson: No problem with concept of service provider; want to understand what else might be involved here
... suppose I go to nytimes.com with DNT on
... so ad networks can track me within the nytimes site?

wileys: yes

johnsimpson: That's a point of disagreement

justin: Key question is whether this is covered by service provider provision

aleecia: moving on
... [some confusion about how Shane's document corresponds to Aleecia's chart]
... moving on
... definition of an outsourcing partner
... what an outsourcing partner must or must not do
... some differences in language; how significant are these differences

amyc: Rigo and I have submitted some text on segregation

dsinger: Do any of the authors feel they have significant differences with the others?

WileyS: stated as the opposite (permitted v. prohibited)
... the "any" party kind of covers the selling perspective

<npdoty> WileyS: should combine our prohibitions for any party along with the prohibitions against a partner (which otherwise allows business uses as long as the data is scoped to a single first party)

fielding: don't expect any customers to represent that omniture complies (maybe that they claim to comply)

jmayer: lets explain this a little, then get a sense of the room.

<wseltzer> is the question here "assume liability for service providers' non-compliance"? or is that too strong?

jmayer: everyone agrees outsourcing party must represent compliance
... who can enforce against 1st and 3rd parties? regulators, end users
... seems that end user suits are probably not practical
... contracts may not be enforced (first v third parties) in case of DNT misrepresentation

WileyS: trying to expand the liability envelope

pde: test case -- imagine arbitrary state is an anti-privacy jurisdiction. certainly third parties there may not comply with DNT
... if that happens, what if any obligations would first parties outside that jurisdiction have to not use the offending third party?

aleecia: we disagree, are there clarifying questions?

<rvaneijk> The elaboration of jmayer on passing on the cbligation is the way enforcement works in the EU. Controller will be responsible for processor making a misrepresentation to DNT.

<justin_> Is there a middle ground here? Reasonable due diligence requirement?

bryan: we have a contract, but there's nothing in the contract that applies to failure to adhere to DNT
... is it reasonable to assume contracts have failure to comply clauses?

aleecia: moving on, we disagree
... define tracking... various differing views here
... not only do we not agree on the definition, but we don't agree if we should define it or not

<bryan> on the previous item, what contracts with 3rd parties would *not* include failure to comply clauses? Is that a reasonable/normal case? If not, it should be implicit that 1st parties represent that their 3rd parties will comply.

rigo: hard to compare dsinger's approach to the other approach because it's so different
... definition: if you store data over time, you create a profile, is this what you're addressing, dsinger?

dsinger: yes. trying to avoid building on a profile

aleecia: part 2, permitted uses. Unlinkable data
... (reads fields in spreadsheet row 20)
... seems column B and D are in agreement
... dsinger's is fundamentally different at the core
... sounds like there may be a way to meet together

<trackbot> Created ACTION-160 - Work with Shane on common ground on unlinkability normative/non-normative text [on Peter Eckersley - due 2012-04-17].

aleecia: potential llimitations (row 21)

<npdoty> action-160 due 4/24

<trackbot> ACTION-160 Work with Shane on common ground on unlinkability normative/non-normative text due date now 4/24

jmayer: "non-protocol info" means, that when it comes to collecting info from a browser (considering everything in the protocol) even in the absence of cookies there's enough data to track many users
... we wanted to be very explicit that in addition to protocol info (cookies, localstorage, etc) the data is not linkable

rigo: I want to know for all proposals whether they want to decide whether each individual bit (IP address, etc) is linkable or not

aleecia: that is a closed issue

rigo: we just reopened that issue

pde: (snark)

<tlr> aleecia: (next)

aleecia: fortunately I can't hear your snark

bryan: is non-linkable inherently non-personal?

aleecia: we're off in the weeds, moving on, running out of time. For frequency capping ...
... looking at possible acceptable uses
... (row 23 in spreadsheet)
... any questions before we flesh these out? Lots are the same through all of them.

ninja: question for shane's proposal -- do you intend some kind of purpose limitation such as "must not be used for other purposes"?

WileyS: yes, it tries to call that out. primary use only.
... please help me clean up the text

amyc: question about financial logging part of table -- I think proposal C row 25 (limitations) how do we think about the unlinkable data layered in there?
... would I be able to collect IP, UA string, unlimited amounts of unlinkable data?

<bryan> If we are not considering any data personal, why are we worrying about linkability? We believe that linkable data should mean non-public (i.e. personal, private) data that can be linked with reasonable effort.

aleecia: 23e and 25e should not be identical, right?

jmayer: they should be the same (?) since companies get to use protocol information and unlinkable data for all of these

amyc: have to be unlinkable in order to use it for frequency capping?

tl: there are two things you can do: collect unlimited unlinkable data, collect protocol info in short term. these statements are not exceptions. You can do it generally. For each of the exceptions, you can do this (?and perhaps more depending on the exception?)

aleecia: confirming that we can use short term protocol info for any use in the short term?

tl: yes

aleecia: what is short term?

jmayer: didn't get into it... uh, 7 days

pde: for purposes of communicating with user agent

aleecia: makes sense

johnsimpson: to clarify, most of what we're calling out as permitted uses probably don't need to be called out because they're necessary functions.

justin: if you receive data as first party, you can use it in third party context

alex: given limitations, is the exception actually doable? Given each proposal, can we still do what the exception is for?

aleecia: if it turns out we can't actually implement something that would be important
... may have to be differences in biz practices, but some things may not be implementable at all, and we should discuss that
... (reads 33. research/market analytics)
... dsinger allowed, johnsimpson allowed with aggregation and non linking, jmayer and justin similar, WileyS proposal much more broad
... product improvement/debugging similar
... debugging only allowed for justin/erica proposal
... fraud prevention called out separately by jmayer et al proposal

aleecia: I think all these proposals that survive will need to be revived

bryan: clarification -- seems like none of these exceptions for unlinkable data would allow a user to just not participate. seems to be consistent, there's no provision for that.

<npdoty> pde: EFF would want to go ahead when complying with law, and also you should fight and/or notify the user

aleecia: interesting to note, only one place where one group pushed back and said this should not be allowed

<npdoty> agreement among authors (and apparently the whole room) that DNT doesn't ever mean my data can't be used in an aggregate/unidentifiable form

<sidstamm_> yeah, what npdoty said

<npdoty> I actually think we mostly covered the two post-break sessions

aleecia: bummed that we're behind. what should we do next? pick up in entire group tomorrow and work out where we have agreements?

<justin> Agree with npdoty

aleecia: what's best use of our time tomorrow?
... also might be some things missing from the five proposals -- positions held by part of the group that was not captured by the five proposals
... quick show of hands. one section on permitted uses, one on "what is a party". are these linked to the point where we have to cover them together?

enewland: to clarify, are you asking if we can separate the "parties" bin from the "uses" bin?

<npdoty> "we like parties"

aleecia: yeah, can we bin the topics or do we have to do them together?

wileys: do see interplay, may not be able to solve them in parallel
... but allowing a little re-work, we can divide and conquer

jmayer: linkage as a policy matter or are there trade-offs that can be made?

aleecia: I really want to identify how to use our time best tomorrow. Can we separate?
... can we just tackle business uses and get it done?
... or do we need to allocate time differently?

<enewland> i'd like to hear a humm on separating

dsinger: for biz uses, we need to pull out permitted uses including more things than we covered here

WileyS: is there a way to possibly winnow down what we need to do to remove the interdependencies?

<npdoty> do we really want to walk out of here with a full 5 proposals? answer: no.

aleecia: once we agree on how big a party is, can we just do the rest?
... recursive or dependency chain?

fielding: wondering about definition of collection

dsinger: still don't know what is the "thing I'm not doing"

pde: would you like us to unlink the issues and discuss them separately?

aleecia: not sure, what do y'all think?

<fielding> I'd like to use the same definition that the regulators use/imply in their docs

enewland: split into the two bins, let's hum on it

dsinger: can some of the proposal authors join and combine into one proposal?

aleecia: I think we could, for the first part, not biz uses, do a mad libs style (phrases with a few holes/variables)
... we're getting close to that... exciting!

tl: volunteers for writing this up?

aleecia: mad libs style probably won't work for business uses

<jmayer> s/\?//

aleecia: I think we should start full-group on business uses and reconsider after 1.5 hours

bryan: how can we get through the schedule faster?
... how much can we reasonably do... these five proposals are pretty broad
... should we consider other alternatives?