See also: IRC log
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
tl for first session
lia for draft review
ninja for community group comments
kevin for first session after lunch
rigo for proposals overview
ed with ted for marginal differences
sid with tlr for final session
<tl> scribenick: tl
schunter: Introducing newcomers.
<everyone says their name and affiliation>
schunter: Agenda wrangling!
... any concerns?
... consensus on agenda!
Aleecia: Dinners: tonight & tomorrow.
... show of hands for tonight?
<npdoty> 21 for tonight across the street
<pde> hi all
<npdoty> 34 for tomorrow at Lebanese Tanerva in Adams Morgan
Aleecia: 8pm both nights.
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> slides: http://www.w3.org/2011/tracking-protection/dc/DC-f2f.key.pdf
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 charter: http://www.w3.org/2011/tracking-protection/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
... we have only been slightly behind schedule
... we are aiming for april (june latest) for 1st last call
marc: what happens after last call?
aleecia: that's... interesting
... want to avoid IP
... input from other working groups
tlr: last call means that we think we're ready to go
... peanut gallery gets to throw popcorn
<tl_> [not a direct quotation]
tlr: maybe we learn something
... hopefully, we make everyone in the world happy
aleecia: tracker stops having our issues, starts having the issues of outsiders
... acronym review
jeff: during public comment period, everyone can weigh in? aleecia: damn straight.
aleecia: please help with scribing
tlr: network trouble? <sadface>
marc: who addresses public input? aleecia: we do.
<npdoty> that is, we the group, not the chairs alone
aleecia: we should be able to remove duplicates and have structure.
<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
aleecia: this schedule is aspirational
<scribe> ACTION: aleecia to update slide 6 to note "aspirational timeline" [recorded in http://www.w3.org/2012/04/10-dnt-irc]
<trackbot> Created ACTION-155 - Update slide 6 to note "aspirational timeline" [on Aleecia McDonald - due 2012-04-17].
<npdoty> ISSUE: what should implementations look like to satisfy our exit criteria for CR?
<trackbot> Created ISSUE-131 - What should implementations look like to satisfy our exit criteria for CR? ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/131/edit .
schunter: implementations from cr to pr are to test the spec and give feedback
jeff: will be interesting to see tests from people outside this room too, like daa
shane: realistic yahoo timeline. after 1lc several steps to build. takes at least a quarter+ even with full executive signoff.
... certainly not going to happen before sept/oct
aleecia: yahoo may not be the sample from cr to pr
ian: insight from small companies is valuable but not transferable to the giant behemoths of the intarwebs. think large implementations are critical
aleecia: have been talking to people in secret. watch this space
jmayer: this has different implementation challenges from other w3c spec
<bryan> A year from requirements to code running in production, is a realistic minimum. Any faster risks the stability of services and the quality of the implementation.
jmayer: this is different from tech specs. this is policy, yo. this doesn't have bugs the way that technology does. policy doesn't have an unexpected consequences
tl: policy can have bugs
rigo: policy can have bugs. c.f. eu directive
...timeline: politicians are watching. it does not matter how slow you move as long as you do not stop.
<jmayer> um, tl, i would never argue that policy can't have unexpected consequences
...timeline: timeline is not critical. let's not filibuster
<jchester2> I agree with Rigo. Let's keep making progress--the public is expecting it.
mattias: different things take different amounts of time
<npdoty> I think jmayer's point was that the Compliance doc may not have the same sort of corner-case technical issues that we often use implementations for in the CR exit criteria
<jmayer> the point is that we don't have to be ex post as sensitive to unexpected behaviors and corner cases as we do in a pure technical recommendation
pde: we may see bugs at scale, that'll be interesting. perhaps your load balancer isn't compliant. different orgs will see different problems.
<jmayer> i agree that there could possibly be some bug-squishing work to do on preference expression - but not necessarily with compliance
<jmayer> i think peter's point is quite right - many of the bugs will be implementation-specific, not protocol-related
shane: agree with matthias. we have an issue. lets move on. smaller implementations should inform larger implementations along the line, but would like to see large implementations before progressing.
aleecia: trudat. ian, plz halp.
<WileyS> +1 with jmayer - I'm more interested in protocol-specific issues, not unique organizational implementation issues
rob: commissioner Kroes & art29 isn't going to follow our timeline. we need to convince them
<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
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
amy: thanks matthias. that detail was awesome c.f. html5wg. surveys... records of decisions.
<npdoty> ... not just done during a Wednesday morning call, records of the objections and decisions, etc.
aleecia: time to respond based on text complexity, and what wg says we need. if we're looking at 30pp, 2wk would not be enough.
<npdoty> ... but if someone asks for 6 months, that's a problem
aleecia: if we say "6mo plz? " that's a problem
amy: in tracker?
aleecia: yes. not just for us, but for the world to see!
tlr: openness is critical. have not operationalized every component. whether on tracker or another page: unsure. we shall see
john: but we don't want to go there.
<npdoty> tlr: needs to be visible and discoverable from the issue tracker and the record of the WG
aleecia: no <shivers, as if in fear>
<Lia> aleecia: any other qs comments?
matthias: this is the stick to encourage natural consensus. nobody wants this process. agree!
... you must submit text to make suggestions
<Lia> matthias: will ask if want to close the issue and will keep issue open if people have comments
matthias: process rather informal
<Lia> moving towards a room consensus
aleecia: when we have really old issues and nobody submits text, and issue owners don't show up, we can work on "good standing". that's another stick
<Lia> aleecia: if issue open someone hasn't been working on it after long period of time, then may remove member
aleecia: let's talk about formal objections!
... happen at decision points
<Lia> explain what changes that would resolve the objection
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.
marc: thanks for clearing this up. so: technical arguments. one technical doc, one policy doc...?
rigo: for process, no distinction between tech & policy docs
... have w3c experience with applying process to policy too
tlr: wording artifact, doesn't distinguish
aleecia: this slide is straight w3c
<ifette> Rigo, could you give examples of previous w3c "policy" documents?
<npdoty> section of Process doc on Formal Objection: http://www.w3.org/2005/10/Process-20051014/policies.html#managing-dissent
matthias: not "i don't like it" more "this breaks my implementation".
aleecia: thanks for these questions.
... good to see feedback.
... check out our issue resolution rate
... we are at 48% closed (were briefly at 50, then we opened new stuff)
<npdoty> 48% closed
aleecia: most issues against compliance
... overtime, yo
... let's gitterdone
<npdoty> scribenick: Lia
aleecia: go through review of status of first two drafts
dsinger: TPE doc
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
matthias: send an action preference to action user to website
jmayer: make clear if the current proposal is to say no default- need user choice here
<fielding> Matthias was talking about section 3
<amyc> From Boston meeting thought we agreed that defaults out of scope
jmayer: second, not necessarily accurate as to where the group is
<npdoty> we also talk about intermediaries inserting headers in 4.2
aleecia: suggest we address on thursday
matthias: are there other people that are unhappy with idea that can only send dnt if user expresses his wishes?
... section 3 and jonathan referring to 4.1
rigo: discussed in brussels but not on the round table
heather: quick outline of def and compliance spec
... where each sections stands
<WileyS> Link to latest compliance spec Heather is speaking to?
heather: 20 open or pending
<npdoty> Kevin: we've discussed a best practices document, that might be useful to discuss on Thursday where we can share those ideas
heather: intro may be to long
<WileyS> Thank you Nick!
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
heather: right now exemptions in compliance doc is defined as...fraud detection, outsourcing, unidentifiable data
nick: not in the doc now
aleecia: now "permitted uses"
shane: can we all agree with user granted exceptions?
<npdoty> everyone can live with "permitted uses"?
jonathan: not just in some cases going to be permitted uses
... might have various components of collection limitations
david: can call blue and yellow, as long as clear, don't care
aleecia: permitted use agreed on- great!
<jmayer> In other words, wanted to be clear that "Permitted Uses" != "Use-Based Exceptions" as some have called for.
<jmayer> And it seems we're in agreement on that.
<npdoty> accept that we can have "permitted uses" although it may also refer to collection/minimization
shane: want agreement on top title and can work through the details
<npdoty> 5. User-Granted Exceptions
aleecia: so suggestion is user-granted exceptions?
david: can get two concepts consistently labeled
aleecia: can we agree, any objections
david: can fiddle with exact term later
rvaneijk: chapter 3 note, in line with chapter 5
aleecia: last call
<npdoty> npdoty: again, we can agree on "User-granted exceptions" but wanted to note that that doesn't mean that a user was always specifically involved
aleecia: fantastic, we have terms on these
<hwest> ACTION: compliance editors fix the language in the spec to reflect "permitted uses" and "user-granted exceptions" [recorded in http://www.w3.org/2012/04/10-dnt-irc]
<trackbot> Sorry, couldn't find user - compliance
aleecia: anything else on compliance doc?
<npdoty> ACTION: heather to fix the language in the spec where necessary to reflect "permitted uses" and "user-granted exceptions" [recorded in http://www.w3.org/2012/04/10-dnt-irc]
<trackbot> Created ACTION-156 - Fix the language in the spec where necessary to reflect "permitted uses" and "user-granted exceptions" [on Heather West - due 2012-04-17].
<KevinT> matthias: Community Comments section begins
<npdoty> scribenick: KevinT
"community group comments regarding Compliance Document"
Aleecia: discussing Issue-8
<trackbot> ISSUE-8 -- How do we enhance transparency and consumer awareness? -- closed
ifette: concern that DNT should be addressing local law...in particular unsent preference
aleecia: slide is not clear, we agree with that concern
... will point to document with exact text
npdoty: this could enhance transparency but we are not necessarily taking this on
<trackbot> ISSUE-26 -- Providing data to 3rd-party widgets -- does that imply consent? -- raised
<npdoty> specifically, the response header/well-known-URI/whatever we use for responses should enable increasing transparency, even though UI is out of our scope
aleecia: merged issue-26 with issue-10
<trackbot> ISSUE-10 -- What is a first party? -- open
dsinger: what is definition of tracking by community groups?
jc: users should be aware when they click on something it is first party and they know they are clicked on
... sticking point for him
asoltani: sometimes when you click on a button there are multiple tags on it, which might not be clear to user
jc: facebook button is obviously fb
<trackbot> ISSUE-16 -- What does it mean to collect data? (caching, logging, storage, retention, accumulation, profile etc.) -- pending review
<trackbot> ISSUE-92 -- If data collection (even very specific with IP address, user agent, referrer) is time-limited, with very limited retention, is that still tracking? -- raised
<Chapell> Asoltani: can you provide an example of a button with mult tags?
aleecia: collection vs. retention definitions in progress, needs response formalizatiojn
... minimization discussed later today
<trackbot> ISSUE-55 -- What is relationship between behavioral advertising and tracking, subset, different items? -- closed
<Chapell> .... are those buttons labeled as something? (i.e., sharethis, FB, etc)
<trackbot> ISSUE-52 -- What if conflict between opt-out cookie and DNT? -- pending review
aleecia: merging issue-55 with issue-52
... dnt and opt-out cookie interactions
mzaneis: clarification from DAA on collection vs. oba
aleecia: needs higher level input for DNT, not DAA
jmayer: doesn't feel like this is issue-52, some drift
<npdoty> more around ISSUE-5 and ISSUE-10 ?
ndoty just did, thanks
<trackbot> ISSUE-36 -- Should DNT opt-outs distinguish between behavioral targeting and other personalization? -- closed
aleecia: agreed, closed
<trackbot> ISSUE-32 -- Sharing of data between entities via cookie syncing / identity brokering -- postponed
aleecia: cookie-synching, didn't understand text, too technical as written
... will come back to this after more discussion
<trackbot> ISSUE-91 -- Might want prohibitions on first parties re-selling data to get around the intent of DNT -- closed
<trackbot> ISSUE-39 -- Tracking of geographic data (however it's determined, or used) -- pending review
aleecia: can't block all geo since we need to know which countries for compliance determination
... keep geo from being hyper-specific
rigo: needs more explanation to define reasoning, will take ACTION
<npdoty> dsinger: we should make the distinction between real-time and stored location; not that they're resolved but important separate concepts
bryan: suggesting this is not api level blocking of geo
aleecia: strongly agrees that is not the case
<trackbot> ISSUE-15 -- What special treatment should there be for children's data? -- closed
aleecia: closing for local govt's
<rigo> we should tell them that real time data is different from remembering and collecting. So filtering geolocation may fall into but is not necessarily the same.
<trackbot> ISSUE-10 -- What is a first party? -- open
<trackbot> ISSUE-26 -- Providing data to 3rd-party widgets -- does that imply consent? -- raised
<bryan> any potential restriction on geolocation was not intended to block API access at the device, to clarify - there were no disagreements in the meeting to that
<trackbot> ISSUE-49 -- Third party as first party - is a third party that collects data on behalf of the first party treated the same way as the first party? -- pending review
aleecia: discussing later today in detail
... issue-49 is pretty close, but discussion on agenda this week to address
jmayer: siloiing topics - gradation of technical effort and objective of siloing
... doesn't feel like we are not close enough on objective of siloing
wileys: he and jmayer agree to disagree
<trackbot> ISSUE-5 -- What is the definition of tracking? -- open
<jmayer> I don't agree to disagree. I'm Mr. Compromise.
aleecia: lots of debate (187 messages!), still open
<trackbot> ISSUE-97 -- Re-direction, shortened URLs, click analytics -- what kind of tracking is this? -- raised
aleecia: still open
<trackbot> ISSUE-30 -- Will Do Not Track apply to offline aggregating or selling of data? -- open
<trackbot> ACTION-107 -- Amy Colando to with Peter & MeMe, Draft text on Will Do Not Track apply to offline aggregating or selling of data? -- issue 30 -- due 2012-02-15 -- OPEN
aleecia: getting close to agreeing, but not done 100% (needs explicit discussion)
<npdoty> amyc, pde, any updates on that action about offline data?
<amyc> Yes, submitted recommendation from Amy and MeMe to Aleecia that additional text is not needed
ifette: is this real-time data use vs. persistent collection?
<amyc> as we believed covered by existing text on do not profile (3rd) and do not share (1st)
aleecia: needs refinement (geo-ip lookup example)
amyc: She and MeMe worked on this
<rigo> I think the distinctions of realtime vs collection and offline would benefit from a tracking definition
amyc: didn't think additional text was necessary as it was covered sufficiently
rigo: agree with Ifette
<npdoty> amyc, I can't find your email about action-107 and extra text being unnecessary
rigo: tracking definition can help here
<trackbot> ISSUE-54 -- Can first party provide targeting based on registration information even while sending DNT -- open
aleecia: appears to be confusing discussion, needs to be picked back up
... still open
<trackbot> ISSUE-59 -- Should the first party be informed about whether the user has sent a DNT header to third parties on their site? -- raised
aleecia: general agree, still open
<trackbot> ISSUE-30 -- Will Do Not Track apply to offline aggregating or selling of data? -- open
Exemptions (many issues)
<justin_> Exemptions = permitted uses. Come on, Aleecia!
aleecia: agreed needs to be defined concretely, will be discussed later today
<amyc> Nick, just sent email to you that I previously sent to Aleecia on issue 30
<amyc> that recommended no additional text
<trackbot> ISSUE-50 -- Are DNT headers sent to first parties? -- closed
matthias: yes, if enabled
"what is meaning of DNT?"
matthias: CG wants default to be 1
... position is to leave it open to individuals to turn on and set
<trackbot> ISSUE-51 -- Should 1st party have any response to DNT signal -- closed
<trackbot> ISSUE-81 -- Do we need a response at all from server? -- closed
matthias: header/URI proposal covering this, discussed THU
<trackbot> ISSUE-68 -- Should there be functionality for syncing preferences about tracking across different browsers? -- closed
matthias: out of scope
<trackbot> ISSUE-79 -- Should a server respond if a user sent DNT:0? -- closed
<trackbot> ISSUE-68 -- Should there be functionality for syncing preferences about tracking across different browsers? -- closed
<trackbot> ISSUE-95 -- May an institution or network provider set a tracking preference for a user? -- closed
... issue-68 was out of scope
wileys: wordpress example
... the standard should not deal with this
rigo: doesn't feel like this is an issue
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?
<trackbot> Created ISSUE-132 - Should the spec speak to intermediaries or hosting providers to modify any responses/statements about DNT compliance? ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/132/edit .
aleecia: commitments to CG for responses....but maybe timing should be later
... could be feedback for W3C overall, as this is a new process
jchester2: appreciate oppy to weigh in early
... will iterate as process moves forward
tlr: requirement is MUST respond to final call comments
... pre-FC is negotiable and flexible
<npdoty> ... but that it's still a very good idea to respond to public comments even before Last Call
johnsimpson: suggests just shipping slides vs. formal written comments to save time
... will share with WW groups
adjourned for lunch
<npdoty> come back at 12:40
<npdoty> scribenick: wseltzer
<npdoty> jchester2: Joey Wender here from Rep. Markey's office
aleecia: thanks for the interest, visitors, say hello
... tech issues, see Nick
<asoltani> overheard (after coming back from lunch): 'oh wow, my tent grew'
<ninja> wseltzer, I offer to be backup scribe
aleecia: if you don't know how to associate your phone # on the bridge, see npdoty or email email@example.com
dsinger: we might start dropping anonymous callers
<npdoty> identifying participants instructions: http://www.w3.org/2001/12/zakim-irc-bot.html#callers
aleecia: ashkan's privacy happy hour Wednesday night
ashkan: non-sponsored drinks
aleecia: How does logged in and logged out state work
<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
<aleecia> so issues with transparency (Rigo) & user expectations (Ninja)
dsinger: "remember me" is not "logged in"
<justin> Does anyone actually want an exception for logged-in state? It sounds like "no" at this point. This just has to be dealt with in "consent."
dsinger: we're just discussing the normal rules, not an exception to them.
<npdoty> +1 to Justin, just an elaboration on consent, I think
WileyS: this could be non-normative text
pde: non-normative; shouldn't be extensible to 3d-party tracking
<aleecia> I do have the question of why companies wouldn't prompt explicitly as Peter suggests
<npdoty> pde: a good time to pop up a little UI to ask what the user really wants
JC: logged-in state does not change ability of Website to recognize you; just changes their ability to respond to preferences
jmayer: disagree with JC; we can build tech to not recognize user
<aleecia> closing the queue
<pde> pde: (summarising myself) DNT should not be a specific exception/permitted use. And being logged in should not change the expected dynamics for actors that are both 1st and 3rd parties
jmayer: users don't often remember if they've logged in, don't know implications of login, don't know tradeoffs
<pde> ... which is to say, if those sites want to do tracking of logged-in 3rd parties, they need explicit consent
jmayer: instead, ask for user consent.
... logged-in exception would strip users of choice.
ifette: "remember me but don't remember me" is confusing to users.
<pde> ifette, agreed -- which is one more reason for this standard not to depend in any specific way on whether the user is logged in :)
<Zakim> tl, you wanted to say: sites may be *able* to recognize you, DNT is about when this is/not acceptable.
aleecia: study of dozens of ways sites use these terms
tl: logging in doesn't mean I want the site to know everything I do online (track me everywhere, just because I haven't logged out of Facebook)
<aleecia> queue is closed
<fielding> people don't lose privacy by being logged in ... it just means that whatever the user consented to with that site is prior consent. If you don't want to consent to something, then don't.
tl: login != consent
aleecia: 2 approaches. 1 pasted into IRC, needs to be fleshed out more
<npdoty> fielding, if I consent to something and then I change my mind, am I just out of luck?
aleecia: 2/ if logged in state turns off DNT, should prompt the user explicitly
<fielding> the only thing login does is associate the user with an account profile and preferences/consent
<dsinger> I mostly agree that separate consent is needed; however, I did imagine a "trackMyReading.com" example where the ONLY point of being logged in is to enable the tracking...
justin: logged in is irrelevant
aleecia: that's case 2, prompt the user
<WileyS> Nick, absolutely - your recourse is to cancel your account with the entity that you had originally consent to those activities with.
aleecia: say, e.g. "logging in requires DNT off. Turn it off or go away"
<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.
<justin> TrackMyReading.com I think qualifies and clear and prominent consent under our proposed text.
dsinger: imagine trackmyreading.com, being logged in is the consent
aleecia: hum. 1/ JC/Shane logged-in/logged-out matters
<npdoty> absolutely (fielding and wileys), but aren't we talking about cases where you consented to a Terms of Service on one site and then don't even realize you're being tracked elsewhere?
<jmayer> I think David's proposal is totally compatible with a consent exception.
aleecia: 2/ logged-in/logged-out does not matter; prompt.
<jmayer> So long as the company is very clear about what logging in does.
aleecia: if you can't live with proposals
... Some hums for both.
<npdoty> +1 to WileyS, that this is a question about consent trumping a DNT preference
dsinger: Shane is clarifying existing rules, not changing them
... how can you agree with current text and object to his proposal?
aleecia: but we can change the current text
<fielding> npdoty, generally the requirement is prior, explicit, and informed consent (for that reason)
jmayer: we're both seeing this as a species of consent.
<npdoty> fielding, don't more recent agreements generally trump older agreements?
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)
<tl> WileyS: You're okay with sites MUST send a response header whenever the user is opted in?
<enewland> that separate forced choice is essential
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
... response header or well-known url applies across both
hum inconclusive between prefer option 1/2
<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
<npdoty> ACTION: tl to revisit text on logged-in/consent to override [recorded in http://www.w3.org/2012/04/10-dnt-irc]
<trackbot> Sorry, amibiguous username (more than one match) - tl
<trackbot> Try using a different identifier, such as family name or username (eg. tleung2, tlowenth)
<justin> Someone please make a compelling argument why clear and prominent notice is burdensome.
<pde> I believe it is necessary for Facebook and Facebook-alikes to have a setting somewhere that allows the user to be logged in, but not tracked by that site as a 3rd party
aleecia: two weeks. Tom Lowenthal and Shane Wiley volunteered to write text
<npdoty> ACTION: wiley to update logged-in consent proposal by April 24 [recorded in http://www.w3.org/2012/04/10-dnt-irc]
<trackbot> Created ACTION-157 - Update logged-in consent proposal by April 24 [on Shane Wiley - due 2012-04-17].
<npdoty> action-157 due 4/24
<trackbot> ACTION-157 Update logged-in consent proposal by April 24 due date now 4/24
<npdoty> ACTION: lowenthal to revisit text on logged-in/consent to override DNT preference [recorded in http://www.w3.org/2012/04/10-dnt-irc]
<trackbot> Created ACTION-158 - Revisit text on logged-in/consent to override DNT preference [on Thomas Lowenthal - due 2012-04-17].
<npdoty> ACTION: singer to draft shorter language to describe conditions for consent (with npdoty) [recorded in http://www.w3.org/2012/04/10-dnt-irc]
<trackbot> Created ACTION-159 - Draft shorter language to describe conditions for consent (with npdoty) [on David Singer - due 2012-04-17].
<npdoty> action-159 due 4/24
<trackbot> ACTION-159 Draft shorter language to describe conditions for consent (with npdoty) due date now 4/24
<npdoty> action-158 due 4/24
<trackbot> ACTION-158 Revisit text on logged-in/consent to override DNT preference due date now 4/24
<trackbot> ISSUE-34 -- Possible exemption for aggregate analytics -- closed
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
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)
jmayer: language-preference cookie v unique-id
... vs information that get retained
<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.
<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?
<tl> WileyS: Nowai: portmanteu of "no" (a negative) and "wai", a misspelling (and mispronounciation) of "way".
pde: sure. offering a framework, feel free to substitute other non-normative examples
<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"
aleecia: Google approach to aggregate data: "opt-out" cookie creates one giant profile for all opted-outs
<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
<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
<fielding> the prior, explicit, informed consent permission still applies
tl: silo means tl has so many like buttons and like buttons served on that site but not both
MS: discussing the baseline and have to still discuss what that means
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
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
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
<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
<pde> ifette, I think I'll amend the draft to define "standard protocol logs", which would be typical verbose web server logs
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
... 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> justin: might be unfortunate that CollegeHumor and OKCupid share data in ways that users don't expect
<npdoty> ... but that's something that we're willing to compromise on
<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
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?
<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
<aleecia> and I'm eager for actual defns; we're thin there
JohnSimpson: restrictive provisions on outsourcing: contractual obligations are key here
<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
JohnSimpson: market analysis please only with aggregated data
<justin> Amyc, Yeah, I'm still working on that!
ifette: affiliated all those LTDs all Google?
<aleecia> (so the text doesn't quite match what John's saying right now)
JS: yes, mostly branded the same way, the expectation is kept
<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
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
<tedleung> ... responsibility and liability should follow the data
Erica: our proposal is clear on that
Shane: ours too
... don't know real-world example of that trick working
johnsimpson: newspapers, e.g., create subcompanies as firewall against liability
aleecia: open this as an issue, start with CDT text
... jmayer et al proposal said analytics with no visible branding could be the same party; why?
tl: analytics is never a first party; but will often be acting on behalf of the first party
<npdoty> ISSUE: what effect does legal liability or consistent data practices between affiliates have on the definition of breadth of a party?
<trackbot> Created ISSUE-133 - What effect does legal liability or consistent data practices between affiliates have on the definition of breadth of a party? ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/133/edit .
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
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
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
aleecia: Copyright in footer is enough: tl no, wileys yes, justin yes, johnsimpson no
rigo: Concerned about using branding. Would restrict beyond European directive
<npdoty> "subtly implanted in the user's mind" - pde's alternative to discoverability ;)
rigo: shouldn't do this by accident, only after deliberation
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
justin: Not commonly owned, so not the same party
<jmayer> I think we're in agreement, Heather.
amyc: Question for CDT: on Moperilla example, assuming it's easily discoverable, what's your position
<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
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?
wileys: Seems like a third party
<trackbot> ISSUE-97 -- Re-direction, shortened URLs, click analytics -- what kind of tracking is this? -- raised
wileys: we need to deal with this use case (redirection) more fully
ifette: Difference between invisible redirect vs. user going knowingly to a URL shortener
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
... 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 ...
<trackbot> ISSUE-16 -- What does it mean to collect data? (caching, logging, storage, retention, accumulation, profile etc.) -- pending review
aleecia: jmayer, is that okay
<npdoty> rigo, can you list your questions so I can add them to issue-16?
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?
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: Re my discussion with jmayer earlier, one issue is policy vs technical measures to separate
johnsimpson: My must is very close to what wileys accomplishes with his must not
jmayer: Distinction between saying "don't combine the data" vs "prevent the data from being combinable"
... everyone requres both, right?
wileys: yes, but differences in details of how to require / implement the separation
jmayer: agree. One reason for difference is in how much latitude third parties have to make independent use of data
... If no indep use, then makes sense to require more stringent technical measures
<johnsimpson> I meant my "must no"t accomplishes Shane's "must..".
fielding: connection between requirement of first party segregation and treatment of third parties
... can't prevent e.g. collection of IP addresses, which allow some linking sometimes
ifette: Can 3P's use data cross-site for permitted uses?
... e.g. fraud analysis
aleecia: And do you need that for DNT users?
ifette: Probably all users, so fraudsters don't hide behind DNT
jmayer: Want to better understand use case
ifette: Ad network is doing outsourced advertising across multiple sites, wants to attack click fraud that is cross-site
wileys: Some ad networks act as service provider for a large publisher, data is siloed
ashkan: logical or technical separation?
wileys: It's complicated
<scribe> scribenick: sidstamm
<npdoty> I was surprised, perhaps not alone, that there would be ad networks that are considered service providers for a particular publisher
jmayer: fraud and security possible candidates
... another being product improvement. Principle ok, scope might be important
... this can subdivide out into (three?) issues?
... (1) product improvement across sites
... (2) security (3) fraud
aleecia: reads partner must line
fielding: a little vague. what data are we talking about here?
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)
aleecia: first parties must row
fielding: "represent outsourcing service providers" doesn't make sense...
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.
npdoty: does what's denied being defined as query string parameters etc break functionality in compliance?
wileys: you break SEO, analytics, affiliate programs, etc
npdoty: unless there are exceptions for those things
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
pde: I'll share an action with WileyS
<npdoty> ACTION: peter to work with Shane on common ground on unlinkability normative/non-normative text [recorded in http://www.w3.org/2012/04/10-dnt-irc]
<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
<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?
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.
pde: may be some lurking demons, but good generalization
tl: I like to consider myself a lurking demon
<jmayer> jmayer: he considers himself wrong
aleecia: some restrictions from johnsimpson (reads row 25)
... pretty similar to prior rows
... changes up with security (row 29)
... (reads contextual/ad serving rows) some differences
<rvaneijk> 29. security jmayer/tl was: E, collect, retain, and use data, if reasonable grounds to believe user user agent attempting to breach security at time of data collection
aleecia: column A, retention not allowed. Column b similar. Column C same as normal jmayer response.
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
andrewclearwater: might be missing permissable use, unless it fits somewhere else
aleecia: adds public purpose row
amyc: we had some wrangling about legal compliance, but this ended up in a permitted use
aleecia: is there something different than "you must comply with law"?
johnsimpson: appears to call out specifically location data for E911, isn't that public purpose?
... and intellectual property protection?
aleecia: murky here
npdoty: proposers, more detail on intellectual property protection (?) please
pde: (brings up closed issue)
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
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?
aleecia: hum test -- non-binding -- hum for your first choice of the five proposals
... first choice, dsinger's proposal. [no humming]
<npdoty> well, very quiet, anyway
aleecia: first choice, john's proposal. [quiet humming]
<npdoty> very quiet on John Simpson
aleecia: first choice, jmayer, peter, tom proposal. [a bit of humming]
... first choice, cdt proposal. [quiet humming]
... shane's proposal [shane humming in scribe's ear and some others humming too]
<npdoty> excellent scribing of the hum, Sid
<sidstamm_> I thought about typing "hmmmmm"
aleecia: discuss possibilities of combining proposals at dinner... and other ideas.
<npdoty> it might be that CDT's proposal is getting fewer hums for first choice, but would get a lot more for second choice
well, order probably matters too
<justin> Would be curious for second-choice hums . . .
<npdoty> "or we could just arm wrestle..."
WileyS: arm wrestle for dominant proposal?
pde: hacking contest?
(focus rolls down hill)
jmayer: I think there might be value in keeping the cdt propsal around
<npdoty> XBox Connect Live battle
jmayer: (many others agree)
<npdoty> +1 to WileyS, CDT proposal is in many places between the alternative proposals
aleecia: I think the "parties" part is where the dichotomy is coming from, and we need t ospend time more on biz purposes
efelten: fielding sent proposal for definition of first party... can we consider adopting this as an amendment? we should think about his proposal tonight.
aleecia: (mentions of forward progress)
... tomorrow lets continue with business uses. you are all awesome, thanks for being so engaged.
<npdoty> "awesome today, this is a hard and kind of brave thing to do"
<sidstamm_> looking for my spare set of hands
<npdoty> thanks to efelten and sidstamm for excellent and challenging scribing!