W3C

Tracking Protection Working Group DC face-to-face

10 Apr 2012

Agenda

See also: IRC log

Attendees

Present
Attendees list
Regrets
SeanHarvey
Chair
Aleecia and Matthias
Scribe
npdoty, tl, Lia, KevinT, wseltzer, rigo, efelten, sidstamm

Contents


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

volunteering for scribes and introductions

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

Aleecia: 21
... tomorrow?

<pde> hi all

<npdoty> 34 for tomorrow at Lebanese Tanerva in Adams Morgan

Aleecia: 8pm both nights.

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> 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
... <timeline>
... 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

[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

amy: thanks matthias. that detail was awesome c.f. html5wg. surveys... records of decisions.
... right?

<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

Status of specifications

aleecia: go through review of status of first two drafts

dsinger: TPE doc

<npdoty> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html

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

<fielding> http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#expression-format

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

<npdoty> http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html

<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.

shane: 5.1

<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

none

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?

no comments

<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

showing slides http://www.w3.org/2011/tracking-protection/dc/CommunityGroup-comments.key.pdf

"community group comments regarding Compliance Document"

Aleecia: discussing Issue-8

<npdoty> issue-8?

<trackbot> ISSUE-8 -- How do we enhance transparency and consumer awareness? -- closed

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/8

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

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/26

<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

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/10

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> http://www.w3.org/2011/tracking-protection/track/issues/16

<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

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/92

<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

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/55

<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

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/52

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

issue-36?

<trackbot> ISSUE-36 -- Should DNT opt-outs distinguish between behavioral targeting and other personalization? -- closed

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/36

aleecia: agreed, closed

<trackbot> ISSUE-32 -- Sharing of data between entities via cookie syncing / identity brokering -- postponed

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/32

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> http://www.w3.org/2011/tracking-protection/track/issues/91

aleecia: agreed

<trackbot> ISSUE-39 -- Tracking of geographic data (however it's determined, or used) -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/39

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

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/15

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.

issue-10

<trackbot> ISSUE-10 -- What is a first party? -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/10

<trackbot> ISSUE-26 -- Providing data to 3rd-party widgets -- does that imply consent? -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/26

<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

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/49

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

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/5

<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

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/97

aleecia: still open

<trackbot> ISSUE-30 -- Will Do Not Track apply to offline aggregating or selling of data? -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/30

<npdoty> action-107?

<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

<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/107

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

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/54

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

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/59

aleecia: general agree, still open

<trackbot> ISSUE-30 -- Will Do Not Track apply to offline aggregating or selling of data? -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/30

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

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/50

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> http://www.w3.org/2011/tracking-protection/track/issues/51

<trackbot> ISSUE-81 -- Do we need a response at all from server? -- closed

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/81

matthias: header/URI proposal covering this, discussed THU

<trackbot> ISSUE-68 -- Should there be functionality for syncing preferences about tracking across different browsers? -- closed

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/68

matthias: out of scope

<trackbot> ISSUE-79 -- Should a server respond if a user sent DNT:0? -- closed

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/79

yes

matthias: yes

<trackbot> ISSUE-68 -- Should there be functionality for syncing preferences about tracking across different browsers? -- closed

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/68

<trackbot> ISSUE-95 -- May an institution or network provider set a tracking preference for a user? -- closed

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/95

matthias: no
... 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

Afternoon issues

<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 npdoty@w3.org

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

Issue-65

aleecia: How does logged in and logged out state work

<fielding> http://www.w3.org/2011/tracking-protection/track/issues/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

<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"
... [paraphrased]

<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.

hum indecisive

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)

<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.

<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
... 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

<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

Issue-34, Possible permitted use for aggregate analytics (and anything related on "non-linkable" data)

<trackbot> ISSUE-34 -- Possible exemption for aggregate analytics -- closed

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/34

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)

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.

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?

<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

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

<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

<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

<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

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> 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

<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

<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

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

<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

<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

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

<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?

wileys: Seems like a third party

<npdoty> issue-97?

<trackbot> ISSUE-97 -- Re-direction, shortened URLs, click analytics -- what kind of tracking is this? -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/97

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

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> issue-16?

<trackbot> ISSUE-16 -- What does it mean to collect data? (caching, logging, storage, retention, accumulation, profile etc.) -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/16

aleecia: jmayer, is that okay

<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: 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...

WileyS: same

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

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.

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

<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?

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!

Summary of Action Items

[NEW] ACTION: aleecia to update slide 6 to note "aspirational timeline" [recorded in http://www.w3.org/2012/04/10-dnt-irc]
[NEW] 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]
[NEW] 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]
[NEW] ACTION: lowenthal to revisit text on logged-in/consent to override DNT preference [recorded in http://www.w3.org/2012/04/10-dnt-irc]
[NEW] 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]
[NEW] ACTION: singer to draft shorter language to describe conditions for consent (with npdoty) [recorded in http://www.w3.org/2012/04/10-dnt-irc]
[NEW] ACTION: tl to revisit text on logged-in/consent to override [recorded in http://www.w3.org/2012/04/10-dnt-irc]
[NEW] ACTION: wiley to update logged-in consent proposal by April 24 [recorded in http://www.w3.org/2012/04/10-dnt-irc]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2012/04/24 05:40:16 $