W3C

Tracking Protection Working Group Second Face-to-face

31 Oct 2011

Agenda

See also: IRC log

Attendees

Chair
Aleecia McDonald, Matthias Schunter
Scribe
karl, npdoty, asoltani, rigo, JC

Contents


the meeting has not started yet. People entering the room and choosing seats. Quite full.

rooom is really packed today.

9: 02am not started yet

*THE GONG*

Matthias, WG co-chair, is introducing the group and welcome messages

The goal of this meeting is to have a draft we agree to publish as a 1st public WD

We want to nail down some of the issues we already identified.

matthias is organizing how to scribe

<Mike> Mike Zaneis from IAB is on the phone

schunter: look at the agenda, assign scribes, go through the timeline
... introductions around the room, who they are and what they're trying to get out of this meeting
... Roy (fielding) will walk us through the Tracking Preference Expression draft
... goal is to determine whether we can publish a First Public Working Draft

aleecia: keep this a civil conversation, even when we disagree
... so far I've been thrilled, a lot of laughter but no screaming, would like to continue that
... Lee Tien has started up a Community Group, mostly privacy-focused NGOs
... they will make comments on our drafts, that we must respond to in some form

http://www.w3.org/community/dntrack/

aleecia: a few five-minute introductory tutorials on basic topics

no objections

aleecia: looking forward to a productive and intense session

<dsinger> ...thinks it might be good to have a FAQ explaining the difference between the working group, the interest group, and the community group...

<aleecia> Let me see if I can find the W3C docs, it's up

Introductions

schunter: introductions

RobVanEijk: work for the Dutch Data Protection Authority but speak for myself

<aleecia> This may help: http://www.w3.org/community/

Vincent: from Alcatel-Lucent, but also speak for myself

Karl: working for Opera, my goal is to have something clear to understand and easily implementable and matters for the user

AndyZei: work on privacy for the Internet Explorer team, love to see progress on Tracking Selection Lists

Erica: from CDT, co-editing the compliance draft

tl: Tom Lowenthal, I work for Mozilla and I fight for the user

sid: engineer at Mozilla

efelten: from FTC, speaking for myself

adamphillips: from ESOMAR, looking for coordination between Europe and US

JC: from MSFT on Bing privacy and advertising

Kevin: from TRUSTe, balancing consumer trust and advertising

JoanneFurtsch: also TRUSTe

Jules: from Future of Privacy Forum, advance the ball for Europe and still support the basics of analytics and privacy

BrianTs: from Microsoft, balance the users and technical aspects

<amyc> Nick, just be aware that chairs are coming through loud and clear on call, but participants are a bit garbled. Might help to if chairs repeat key points at times

Ninja: from the German privacy authority, looking forward to big step for the user

<aleecia> (Thanks Amy)

Ashkan: an independent researcher in this space, matching user expectations

Frank: from BlueCava, my first f2f meeting

<rigo> harlan, have you joined on the phone?

npdoty: I'm the staff contact from W3C!

WileyS: from Yahoo, enjoying the process so far

Heather: from Google, co-editing the compliance spec, want to get that going

JohnSimpson: from Consumer Watchdog, a consumer advocacy organization with a history in California, give users transparent control of their data but doesn't interrupt the economic necessity of the Internet

EliseBerkower: from Nielsen, a coherent and cohesive standard

Alex: also from Nielsen, software engineer so here for the technical part

<harlanyu> Yes, I

<harlanyu> 've joined on the phone

Kai: a primarily advertising finance business, Deutsche Telecom

rigo: an old-timer from W3C, with experience from P3P

dwainberg: from AppNexus

<Frankie> Frank Wagner, Group Privacy of Deutsche Telekom

aleecia: half-time at Stanford and half-time at Mozilla, who are supporting me to be here, looking for consensus

fielding: from Adobe, also a role at Apache Software Foundation

<Kai> Kai Scheppe - Deutsche Telekom, specifically the ISP section of DT

jmayer: from Stanford, looking for something that puts users in the driver's seat now

TonyR: from MSFT, corporate standards group, just an observer today

ChuckCurran: director of the NAI, compatibility with the existing cookie opt out

AshokMalhrotra: member of the TAG, just observing

HenryGoldstein: from CBS, representing the Online Publishers Association, content and consumer trust

KarenMyers: with the W3C involved in Member Relations, learn about a hot topic

dsinger: from Apple, excited about the quality of the conversation, hopeful for a specification that consumers, regulators, industry all think they can support

schunter: seems like the group more or less agrees on our goals, which is not always the case
... a balance between advertising, user choice, usability

Tracking Preference Expression Editor's Draft

schunter: roy has started with a great spec already.

(APPLAUSE)

schunter: the specification is the current state of our discussions.
... not everything is solved yet
... we have to identify what we are comfortable with to publish it as 1st WD.

fielding: it is only a 1st draft. I focused on what we want to put in the public.
... more than what we will finally be.

(a big show of hands for people having read it)

<npdoty> we're looking at: http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html

fielding: The document is split into sections with regard to who will implement what.
... sections for browsers
... sections for servers
... there is an introduction about the Web.

Simpson: reading the introduction, I have the feeling that it is only about third party tracking.
... not taking into account first party tracking.

aleecia: you will see more in the other document, Tracking Preferences Expression.

schunter: at this point, we have not yet a full consensus.
... but if something is new and different in the future, we might need to update one of the two documents.

<npdoty> ISSUE-17, ISSUE-51 for example, consider the question of whether first party tracking would be impacted

fielding: You may comment on old ISSUES or add new issues.

schunter: The specification will reflect what are the current issues.

fielding: I have been user agent instead of browser, because Webapps are not browsers and might act as a client.

lowenthal: An app would be in compliance or not?

fielding: An app doing a browsing activity would not be mandated to be in compliance but could be.
... I didn't put the requirements in that specification.

rigo: what if the webapps is transmitting information?

fielding: I do not think it is in scope if someone agrees to install the app.

singer: I think we should limit ourselves to what people choose to implement or not.

felten: It is tied to the 1st party, 3rd party interactions.

mayer: You might have exactly the same issues with webapps than a browser. It is the exact same problem.

schunter: reminding the goal - do we have issues putting that into public?
... if you have issues you can keep in the back of your head.
... and we can put the issues in the next version.

fielding: do we have an issue with ISSUE-13 right now?
... can we publish it?

<npdoty> jmayer: for example, you might have a 3rd-party analytics provider in a web app that phones home about the user's use of a web app

rigo: we are just trying to decide if we can publish the document as is with the issues inside.
... have you found anything we do not want publish.

<jmayer> Recommended reading on mobile app privacy: http://appanalysis.org/ and http://online.wsj.com/article/SB10001424052748704694004576020083703574602.html

Jules: can we include prose about webapps?

fielding: what I did is to define apps as user agents. that's all.
... "do not get upset with me" because I'm using it only in the browsing context of the web apps.

West: keeping it neutral is a good idea like it is now

Singer: The last sentence is an issue.

wagner: not all communications between the server and the client is tracking

lowenthal: I sent to the list a revision text to the list. We can review the text and continue the discussions later

<npdoty> dsinger: I'm not crazy about the idea of publishing a spec that implies that the spec judges whether a specific class of applications should implement/comply with this protocol

<npdoty> right now we're looking at http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html

fielding: there are many other issues with privacy which are not necessary tracking issues.

rigo: first party are excluded?

<tl> s/"a revision"/"a small revision addressing this issue"

aleecia: it is an open issue.

<tl> s/"this issue text"/"this issue"

schunter: Pending review means we are in the process of discussing it

<asoltani> fyi

<asoltani> an example of what 1st and 3rd partys apps talk to: http://dl.dropbox.com/u/3077/ms.pdf

<JC> okay

fielding: 3 Determining User Preference - ISSUE-4
... this part of the specification is to specify what does that mean enabled or not enabled

lowenthal: I would change the user's choice by user's preference.

<asoltani> actually a better way to visualize: http://dl.dropbox.com/u/3077/ms%20-%20collusion.pdf

<asoltani> ^^ note flurry 'tracks' app activity across multiple apps (using an HTTP protocol) identical to 3rd party tracking on the web

aleecia: I do not want to have this as a yes or no only.

fielding: I was trying to avoid the "how" in this section.
... I wanted to separate the concerns. Put that in an email so I do not forget.

felten: I imagine a case where an employer, or a library would turn on the system without users consent.

<tl> lowenthal: i suggest that the phrase "reflect the user's choice" be replaced with the phrase "reflect the user's preference", to cover high-level privacy preference presentations to the user. i also suggest (here and in following sections) the use of the passive voice i.e. "DNT is enabled" rather than the active voice "the user has enabled DNT". i will follow up in an email.

fielding: indeed
... If you have a suggestion to change this.
... it is what we are saying right now.

wiley: We should capture as an issue when the user is not choosing by himself/herself

singer: how do you write a performance test for this kind of issue.
... so it is a problem.
... Where are the protocols endpoint?
... I think it is server and client

fielding: I disagree in the sense that we are shipping softwares

<npdoty> proposed issu: may an institution or network provider set a tracking preference for a user?

<jmayer> I think we do not have a consensus on 1) whether user agents can set DNT on or off by default, 2) how intermediaries, including businesses, libraries, and other organizations, can change DNT status.

<jmayer> Those are open issues.

singer: there are many situations where the choice is not made by users, but by a corporation, organisation

rigo: I agree it is a large issue
... whatever activates the DNT header, it is difficult to know what it means for the server.
... You can't determine from where the DNT comes from.
... All the rules are falling apart in some cases if we do not have this information.

fielding: this section is about browser configuration.
... not sending, or sending the DNT header.

<jmayer> Reminder: we could disambiguate whether the DNT flag was set explicitly by the user or implicitly by another entity.

schunter: do we have an issue with this section as a first public WD?
... can we ship and move on?

<jmayer> Not saying the protocol should, but it is technically trivial.

<npdoty> ISSUE: may an institution or network provider set a tracking preference for a user?

<trackbot> Created ISSUE-95 - May an institution or network provider set a tracking preference for a user? ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/95/edit .

schunter: I recorded the larger issue

(no disagreements)

fielding: 4 Expressing a Tracking Preference

<npdoty> if anyone has objections with my naming of that issue, feel free to edit or to add a comment to it

fielding: I specified the syntax of the header field and took care of eventual extension for the future.

lowenthal: the last paragraph makes me uncomfortable.
... They might not wish to communicate the header when private browsing mode.
... I want that to be a legitimate browsing experience, aka being conformant

fielding: do you have a way to phrase that?

kai: is it about to express what is not forbidden is authorized

lowenthal: I'm willing to take an action to soften the text
... there is nothing to say I do not have a preference.

<amyc> I am, can type question or ask via phone

lowenthal: I'm happy to take this offline.

mayer: This is a clarification, this is not a substantive issue.
... A sentence in there explaining the value it is a scope exception.

<amyc> Clarifying question: this section on server header 0 does not eliminate other options between user and site for recording override, correct?

aleecia: I do not think it blocks what you are expressing.

<hwest> In re jmayer's comment, I think that's worth thinking about, but it's a very hard thing to ask of service providers to somehow know what '0' means in an given context

<amyc> IOW, site might ask user to consent via registration and stores override

fielding: I understand lowenthal issue.

<jmayer> I don't see any significant technical challenge in a 3P understanding the scope of its DNT exception.

<amyc> thanks roy

fielding: in this section, we are not prohibiting other mechanisms such as cookies

<amyc> and nick

fielding: (answering to amyc)

<jmayer> Can use the exact same mechanisms as for signaling 3P DNT status to 1P.

fielding: (going on through the 4.1 section)

Solani: if I subscribed to a 3rd party service to enable it

fielding: yes that covers it

singer: what about super private ISP?

fielding: yes

ndoty: we have the example from Ed about a public library where we might want to allow this, shall we mark an issue for this?

rigo: it is the same issue with the user consent we had before
... should we in the specification here put a note, issue here.

fielding: not supported extensions are ignored.
... (section 4.2 HTML DOM Interfaces)
... The definition comes from Microsoft specification
... are the browsers fine with it?

browserPeople: seems fine :)

(missed it)

fielding: it is not as fined grain as the HTTP one

<npdoty> pde: setting the value for the domain might not work if you're sending different DNT messages to different domains

yyy: It should be similar to the HTTP one.

singer: why would not it return the same thing?
... because we will run into the same issues.

fielding: it was the input document but I agree.

schunter: I added an issue for this that we should come back to it.

<npdoty> we would want the extensions to be available in the DOM property as well, right?

mayer: I think there is a consensus, that JS should be aware of it.

<npdoty> ISSUE: the doNotTrack attribute should mirror the value of the header (potentially empty, extensions, etc.)

<trackbot> Created ISSUE-96 - The doNotTrack attribute should mirror the value of the header (potentially empty, extensions, etc.) ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/96/edit .

fielding: I have never seen that JS would get the value from the server.

mayer: Mozilla implementations shows it

fielding: give a link to it, please. :)
... 4.3 Plug-ins API
... we need to have the information to put into the specification.
... I do not have that much experience with plugin/extension.
... so we need to ask information from browser developers

schunter: could you put a note to explain.

fielding: alright.
... (section 5 )
... I tried to summarize the discussions and include everything we said.

schunter: this section is really in an open state
... everything is quite open for discussions
... we haven't figured out the best mechanisms

<pde> pde: and this problem could be solved by making the DOM property a JavaScript object that is indexed by domain

<pde> pde: or a function to which the code's origin is passed as a parameter

<asoltani> pde, that's also benefitial from a security standpoint since there are cases where you wouldn't want third_party_domain_A to know the TPE setting for third_party_domain_B

<asoltani> pde, or even if the exitence of third_party_domain_B on the page

<pde> asoltani, I agree that there are fingerprinting issues to consider

<pde> asoltani, fingerprint-resistant browsers need to avoid these kinds of granularity

rob: are there issues linked to this part of the document?

fielding: not really, if it's just an input.

rigo: if we publish this WD without the issue in 5.3, it will be a problem

aleecia: we should then at least create the issue for it describing it

fielding: does it apply to this document or the other one or both
... I have no answer.

Jules: it should be addressing "legal and regulations"

<hwest> Just a general note - we're calling out a lot of compliance issues that are likely/definitely will come up in discussing the compliance doc. I think we can integrate them there - how many of these are technical rather than policy?

schunter: we should document it.
... specifically for people not in the room.

fielding: 5.4 machine-readable tracking policy
... 5.5 tracking response header field
... 5.6 status code
... for non human browsers
... open questions

lowenthal: for 5.5 the responsewhat do you think the header should look like?

fielding: it is in the abstract but I didn't write down in that section.
... there are issues around cookies vs DNT.
... how do we manage it?

singer: this is a long discussion.

aleecia: the intent is not about saying that you should not respect it.

fielding: note the text is excerpt from IRC

schunter: we need to clarify or soften the prose in these sections

fielding: I'm happy to remove that

<tl> also: that is not an exact quotation

singer: do our names stay in the WD?

fielding: I'm happy to remove it.
... (5.7 opt-backi-in)
... so far we do not have a mechanism, maybe the cookie mechanism which is specific to any sites.

schunter: the mechanism is not defined yet. So can we publish with this issue.

<hwest> Looks like everyone is getting bumped - the consensus is to rename "opt-back-in" to "site specific user exceptions" or something similar

<hwest> "Site specific user preference"

<fielding> and title update in B.1

<hwest> Similarly, the B.1 title should reflect the title for "opt-back-in"

<fielding> sec 5.7 change to site-specific user preferences

rigo: I'm very reluctant to talk about opt-in, opt-out

aleecia: we have a consensus on the bad title.

fielding: we can change the issue titles.

schunter: should we use the use cases in that document.
... B1 we should update the title

fielding: C. closed issues

npdoty: issue-42 there is no consensus yet

<NinjaMarnau> if we call it site-specific user preferences, do this still include third party-specific user preferences?

fielding: D. postponed issue

schunter: (explaining the postponed issues)

fielding: I will do the updates sometimes today.

schunter: obviously by tomorrow we can check the snapshot

(for the logs we had a brief interruption of IRC, some of the minutes are missing for 5 minutes toward the end of the first session)

<npdoty> aleecia: Jules will give a high-level overview of advertising ecosystem if you come back early from the break at 11:10

<karl_> I would love a diagram with HTTP transactions in between the different entities that Jules is showing and how the DNT changes thing inside that network/graph.

<asoltani> karl, most of that is http/https

Compliance Editors' Draft

aleecia: goal is to see how we're doing in the editing process

<rigo> merci Karl

aleecia: no objections to the abstract

rigo: is 1st party/3rd party disctinction worthwhile if we don't discuss what sharing means

aleecia: lets add a question as to whether '1st/3rd distction is a useful one'

<dsinger> maybe we should have the rough definition of 1st, 2nd and 3rd party (that the user is 2nd, the intended site is 1st, and someone watching from the sidelines is 3rd)

JohnSimpson: should we change the term to 'tracking' vs 'behavioral'

<amyc> I believe that the term "transactional data" is potentially confusing and suggest that we use something that is more descriptive such as passively collected browsing data; transactional makes me think of purchase data only

ninja: question about specifically-expected purposes.

david: uncomfortable with having an adjective in the title/definition of the document

amyc: the wording of transactional data seems confusing

<amyc> thanks JC

<rigo> AM: come back to this soon

<npdoty> amyc, does this address your question?

<rigo> transactional data meant in a geek way, want to leave it this way

<rigo> amyc, okay with this?

<amyc> still believe that we can use a more descriptive term, rather than trying to redefine

aleecia: changing definitions of tracking as examples

kevinTrilli: can we state what are the 'principles for exemptions'

<rigo> list under 3.4 discussion:

<rigo> everybody ok with the list under the condition that the list is still open and just a discussion list

JC: current examples are the 'result of tracking', not the actual tracking itself

<rigo> EdFelten: second list exemption of exemptions?

<rigo> HW: this was the purpose to enumerate things that we are sure are in scope

<NinjaMarnau> I support use-cases or uses

aleecia: activities associated with tracking

<rigo> JM: tracking definition is bleeding into first vs third party tracking

hwest: section 3.4 should be dependent on 1st vs 3rd party definitino

<enewland> jmayer is right - there is an inconsistency

<enewland> in that the definition draws on terms, here commonly-branded, that are not the terms of art we are using

<enewland> in other definitions

<enewland> and that replacing commonly-branded and non-commonly branded sites with first and third parties

rigo: we should highlight 'use cases' as a way to shape the drafting

<enewland> would make sense

tom: we should highlight that this is a working draft

<rigo> Rob: using the terminology the same way as in 95/46/EC

<rigo> ... wants to have this added as an option

<npdoty> rigo & rob, want to create an ISSUE for that?

efelten: section 4 definitions conflict

shane: intention of definition was 1) first parties dont have a requirement 2) transmission of that data becomes a concern

<rigo> JC: change websites to entities

<rigo> AM: ok, make it as options will have the big discussion in the afternoon

<npdoty> can someone find me the issue number we just created?

<npdoty> issue-95?

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

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

<npdoty> rigo, can you create an ISSUE for that or some sample text?

rigo: strongly suggest language for special treatment for children's data

<rigo> Issue 15 should read what special treatment should there be for especially sensitive data such as children's data or data as enumerated in Art. 8 of Directive 95/46/EC

<efelten> Re issue 15: another possibility is simply to note that there will likely be legal or regulatory requirements relating to children and sensitive data, which are beyond the scope of this document, but with which compliance is of course required by law.

<rigo> Roy: please editors make a global search/replace on Do Not Track header to DNT header

<amyc> +1 on efelten approach for known children's data; safety concerns with identifying children online

<npdoty> is there an open issue for User Education and Communication?

tom: if section 6.3 is closed, can we open it?

<rigo> ed, I think this is rather helping people

<rigo> in that we may give some hints in this document on how to deal with sensitive information

<rigo> like children, politics, religion

<npdoty> fix the issue 14 in the tracker to refer to collector instead of controller

<karl> ACTION: karl to do a review of the Tracking Protection WG deliverables according to http://www.w3.org/TR/qaframe-spec [recorded in http://www.w3.org/2011/10/31-dnt-minutes.html#action01]

<trackbot> Created ACTION-26 - Do a review of the Tracking Protection WG deliverables according to http://www.w3.org/TR/qaframe-spec [on Karl Dubost - due 2011-11-07].

<rigo> I changed Issue 14

<fielding> Julian Reschke suggests we exclude comma from the DNT-extensions to avoid confusion with HTTP header folding. I agree and will make that change.

<aleecia> Thomas demoing Collusion plugin

<rigo> who just joined?

<rigo> scribenick rigo

<aleecia> For those playing our home game, you'll want to take a look at http://www.w3.org/2011/tracking-protection/track/issues/open

http://www.w3.org/2011/tracking-protection/track/products/1

tracker open issues

this is issue 17

<vincent> http://www.blaeu.com/uploads/tracking/110827%20gossip%20.html exanple of my research

http://www.w3.org/2011/tracking-protection/track/issues/17

AM: do we want to distinguish between 1st and 3rd parties
... distinguishing, the user has already made a decision
... goal is to get this done by the end of the day

<vincent> code is at http://www.blaeu.com/uploads/main.pl (Rob)

TL, we use this since some time and we wanted to distinguish between the party that the user believes he is interacting

scribe: and other parties

Rob: first and third party are technical terms as from a legal perspective, is a different question
... and it would be good to meet in middle

JP: good to learn from the data processing term
... in limited way to interact with 3rd parties

DavidSinger: we have to start from the perspective of the sites that the user believes he is interacting with

ShaneWiley: we are attempting to define first party in a social way, not only the domain. Intent is to try to observe the user's intent
... data processor is a legal contract, agree with Jules, the data processor construct is good as dp has no independent right to use the data
... facebook like button is different

HeatherWest: should work on something that is technically feasable. User intent is not something, we could implement

JCC: sometimes third party gives me what I told him to deliver me

<npdoty> JC: a third-party weather widget might be something I want that tracks me

TL: like buttons issue, if I interact with the +1 button, I want to communicate with Google, if I don't click on it and it communicates than its third porty

<tl> i also want to make clear that i don't like this 1st/3rd party terminology

AdamPhilipps: EU data protection is about data collector making assertions on what they gonna do with the data. May have multiple collectors
... first party is not helpful except for people know where to complain to

<tl> the eu data collector/controller/processor is useful, provided we attempt to identify who the user is trying to communicate with

ShaneWiley: First party acting like a third party. Beginning to look at interaction vs impression, to qualify as a first party

AM: terminology FB like button is rather as a widget,

<npdoty> ShaneWiley: think there is agreement that impression of a widget shouldn't count the same as an interaction with the widget (which would be a first party context)

FrankWagner: Doesn't matter first or third party, user goes to website and there is one entity responsible for the site
... challenge is to make transparent to the user the network

@@Facebook: widgets are also used to provide content

AM: it may be acceptable to break things for people have DNT=1

JP: sites have been certified as privacy friendly despite sharing on the unders

RW: not entangling the definitions of parties in technical and social way, not doing the distinction

AM: first vs third party poll
... user's view or first party and third party

Shane: want a third option

<amyc> think we need both approaches

12 people user are interacting with elements of a site and we should deal with it

edF: deliberate interaction and going to a website is that expression

many more want first party and third party and want to look into the interactions on that fact

AM: discussing more

Rob: Tom showed interaction, I want to cover those secret interactions that take place in the background

Alex_Nielsen: are we trying to assign responsibilities?

AM: we try to assign requirements
... and first party has less burden than third party

dwainberg: First party visit to assume implied consent

KaiScheppe: new to discussion. Have large site, have 250 partners and deliver content is like from one site
... user doesn't care about 3rd party, want to know where their data is going
... keep it simple as much as possible
... sports portal of soccer results.

MS: do they do tracking?

KS: more specialised now

Rob: difficult to start with bottom up approach, perhaps start with top down. Perhaps start with ICO website where you're asked wether you want preferences

AM: make future proof
... everything from example.com is first party
... others would have increased responsibility.
... if user clicks on FB button, has affirmatively interacted with. This is more robust to distinguish between affirmative and secret interactions
... have primarily discussion on how we talk about things

??: customize edit buttons...

Tom: create feature like comment box, one way with DNT and once with tracking.

<karl> I wonder what it means if we allow for DNT based on a domain list. a bit like cookies.

<suegl> I have a question about Aleecia's example. What if nytimes.com keeps the photos they themselves take on nytimesphotos.com? The user didn't intend to visit nytimesphotos.com, so if the user has indicated DNT=1, then no photos?

FW: pixel graphics for web measurements
... in addition the same root domain is used

<fielding> a.k.a., web beacons

<npdoty> suegl, is nytimesphotos.com also run by the New York Times and just happens to use a different domain? (I think Aleecia and Rigo discussed this)

<suegl> npdoty, yes

AM: beacon is part of site and is setting cookies on behalf of first party

David: counterexample of interaction is URI shortener. User 1 has interaction, user 2 just clicks on teh link and redirects

<suegl> npdoty, what was the resolution/answer? My apologies - it's hard to hear on the phone sometimes

AM: please create issue on redirection

<npdoty> suegl, I thought that Aleecia had summarized that we all agreed that different domain names that are functionally the same, then it wouldn't be an issue

ShaneWiley: redirection is bigger than shorteners, click analytics is redirect on own site
... wouldn't count that as first party

<npdoty> ISSUE: re-direction, shortened URLs, click analytics -- what kind of tracking is this?

<trackbot> Created ISSUE-97 - Re-direction, shortened URLs, click analytics -- what kind of tracking is this? ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/97/edit .

ShaneWiley: interactive ads, rich media, has reach interaction, is that collecting information in the first party context?

DavidSinger: redirect is the same as the framing of example.com If the top level domain the actual content site would be first party

BilCorry: example.com does not realize that they are third party

<karl> sometimes the content/tracking is coming from a server-side client

JM: overlaying information, content data over maps e.g
... site that is co-branded, who is the actual first party
... what about 5 redirections to circumvent 3rd party cookie blocking - we should be explicit about different use cases for redirection

Ashkan: enforcement side of it. Trademark multiple step test. Setting guidelines, make reasonable steps to fulfill user expectations about use of third parties
... so that the case can be enforced by having that test

<karl> webapps store with the web apps staying in the store when using it

AM: recollecting: site has a certain policy and if they can honor it, fine, if they can't are treated as 3rd party site

HW: do like more technical definition, easier to determine whehter I'm first/third party

<karl> I think that most people do not know that Youtube == Google

<karl> or Flickr == Yahoo!

Roy: vote for mushy site of things

AM: if you have general comments, quick feedback

<hwest> Here's another idea around a first party: the entity that decides what else ends up on the page, ie, places the script for analytics or embeds the widget

AM: very quick feedback, no more than 10 min

KaiScheppe: unifying aspect is user, if you adapt user centric view, the user's expectations should be taken into account

<fielding> focus on compliance in terms of user expectations instead of trying to define all of the mechanisms -- let the implementations worry about mechanisms as long as they comply with the user's expectations

AM: comment; one way to get the information is not to use DNT

KS: user may change their mind

Sid: important to distinguish between things that we call and those that are automatic

RW: distinction between first and third party will get you into legal nightmare and suggest to only scope by actual http request

<npdoty> Vincent: in cases of prefetching, as with the Google Chrome feature, what should we do when a browser fetches the content of a page before the user affirmatively chooses to look at it?

KD: set header per site, dependent on domain name
... bla.analytics.com will sent DNT but not to example.com being in the same site

JP: using cloud services and those still in the same hands

Rob: want to remain on user centric view that looks at one site, keep it simple

David: want to support that we should scope by http
... but have to discuss further

Ashkan: we have to be careful on what the sites do so that they don't circumvent the browser controls
... what
... s the right thing to do on the server side

<fielding> This topic is going in circles. We have the issue of implied consent. Rigo's point is that there should not be any implied consent and instead have browsers maintain domain lists. The browser developers have previously stated that they do not wish to implement such lists. Sending DNT selectively (only to third parties) denies the first party from adjusting their content to be DNT-amenable (paid for).

Andy: David did a good job on capturing
... support that

<karl> fielding, it is not true. at least three browser developers said they were positive

we will reconvene 3:15

<schunter> queue will be shelved until after the break

<karl> Microsoft, Mozilla, Opera

<aleecia> Propose, conceptually: 1. We continue with 1st v. 3rd parties. 1st parties must be sites that users intended to visit: a series of five re-directs does not make all five into 1st parties, only the site the user intended to visit. 2. We layer user interactions as: when users affirmatively interact with 3rd party content on a 1st party site, we promote that 3rd party to the 1st party standard for data use/collection/DNT compliance.

"the only way we can get consensus is if no one can write it down"

aleecia: for ISSUE-10, can someone translate my high-level language into specific language?

<scribe> ACTION: tl to write-up the consensus for what is a first party on ISSUE-10 [recorded in http://www.w3.org/2011/10/31-dnt-minutes.html#action02]

<trackbot> Created ACTION-27 - Write-up the consensus for what is a first party on ISSUE-10 [on Thomas Lowenthal - due 2011-11-07].

pde: when we make a decision, it's only partly concrete, if we reveal something else we can come back to this decision

ACTION-17?

<trackbot> ACTION-17 -- Shane Wiley to write a concrete proposal re 3rd party response. -- due 2011-10-28 -- OPEN

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

aleecia: what restrictions should we put on the first party?

ISSUE-17?

<trackbot> ISSUE-17 -- Data use by 1st Party -- open

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

WileyS: repeat of jmayer's proposal, first parties in the context of a first party (intending to have an interaction with that party), they would have no responsibilities

<pde> pde: I just reminded WG members that consensus on X now does not mean X is fixed in stone for all time come what may

Shane: 1st party has no responsibilities to DNT
... 1st-party cannot share user data with 3rd party

<npdoty> "would not share information about that user with a third party"

<npdoty> WileyS: no such sharing should occur, unless there was explicit permission from the user

Shane: unless there is explicit consent from user

Aleecia: Want to add offline sharing as well

Shane: need to cover what is meaningful consent

Rigo: Does it include "as required by law"?

Frank_BlueCava: Does this include sharing with ad servers?

Ninja: What about necessary sharing as in working with cloud services?
... service providers should have same protections as 1st party

Shane: We need to explore cases where services are using other services.

Aleecia: If a site is using a third party and that party is not compliant then the first party is not compliant

<npdoty> WileyS: we are responsible for what our vendors do

<WileyS> More specifically: 1st parties are responsible for their Service Providers with respect to honoring DNT.

asoltani: might want an exception for COPPA cases, need to disclose to third parties that a particular user is a child and needs to be treated as such (or not)

<hwest> I think that COPPA stuff could be covered when parents opt kids in to the services, etc

<jmayer> Just to put it in IRC - I think the generalizable rule here is that if a first party shares with a third party, the same restrictions and exceptions apply as if the third party had collected the information itself.

schunter: what about making a bank transfer?

<dsinger> suggests that IF a first-party does (accidentally?) relay user-data to a third-party that is under a DNT obligation, the third-party SHOULD discard that information ("I didn't want to know his name!!")

tl: we should have an issue/exemption for the current transaction

proposed_consensus: A first party that receives a DNT:1 signal should not further share info about that user with other parties, unless there's an exception.

TonyR: passing on credit card information on to the payment site? -- current transaction exemption

<rigo> npdoty: may take this as users preference for better privacy dealing (less logging)

npdoty: could we also note that a first party may (not an absolute requirement) choose to respect a user's preference by logging less

rigo: resolution 17 establishes general prohibition of sharing, you must provide for exceptions, either an enumeration or a general rule, like every necessary to carry out the transaction

<jmayer> To be clear, some of these exceptions might be high-level standards.

<Frankie> ISSUE 17 Is it possible to describe what is allowed to be done by a first party is - instead of describing what its NOT allowed ????

npdoty: suggesting an additional but non-binding suggestion that first-party sites may take additional protections

tl: I had some text on that in an earlier draft, will send to Shane

<NinjaMarnau> I see the problem that if state "MUST NOT" we need to have so many exemptions we get lost, or otherwise we will have blanket clause exemptions which basically enable the first parties to do whatever they want

<rigo> exactly

<rigo> but speak up Ninja, otherwise this will get lost

<rigo> you're mainly arguing against issue 17

jmayer: as a generalizable rule, there are classes of data that don't bring any risk of eventually re-inferring pseudonymously identifiable browsing histories

ISSUE-30?

<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

dsinger: if you remember anything about a transaction, the onus is on you to be sure that it can't be reassociated with the user

<tl> hear hear

<jmayer> - and we need to be very careful about what we allow to come within this exception, assertions of statistical aggregation aren't nearly enough

<NinjaMarnau> rigo, I'm not opposed to issue 17 in general, I just think the must not - approach may be far too ambitious

jules: with aggregation there's always some risk (HIPAA and other examples), given that there's scales of risk and value to society
... how do we deal with it here?
... the measure of what you need to do with every type of data, we should reference some appropriate level of deidentification per the type of data

<rigo> Ninja, issue 17 was closed with consensus that general prohibition, now discussing 1001 exceptions

<dsinger> I think the point is that if you don't know if you can manage the risk of de-identification, don't record data. The more you record, the more granular it is, the better you need to understand what you are doing.

<rigo> this is the way to make things so complex that it resolves by itself

aleecia: your data might seem innocuous but it reidentifies someone else's data set

<hwest> I don't think we should get to the techniques used to deidentify/aggreagate data

<NinjaMarnau> yeah, I was too late in the queue ... and missed the point to jump in

tl: aggregation needs to be not just stripping identifiers but aggregating a number of users so that it isn't reidentifiable, and if it is reidentifiable, then it's your fault (you weren't in compliance and if you said you were you were being deceptive)

alex: what about the geolocation case where we might aggregate successfully for most locations, but some geographic areas might be reidentifiable, am I liable for that?

<dsinger> remembering that there were 20,000 californians, and separately that there were 40,000 men, and separately that there were only 10,000 over-50's, and so on, is fine; but remembering that there was a male, californian, over-50's, etc. -- dangerous. be careful.

<tl> and saying that you were in compliance might include sending a dnt header

efelten: it's not fuzzy in the sense of unknowable, it can just be difficult to determine in some cases, which suggests being conservative
... it is a technically precise question whether something can be inferred from a dataset or not, rather than giving the exact means we could just say that they should achieve that reasonable result

aleecia: what bar is reasonable?

<karl> location of someone in the desert and location of someone in the city do not have the same impact on privacy/tracking

efelten: that it can't be used to infer something useful about a particular user or device [scribe is paraphrasing]
... not reasonably possible to infer information

hwest: to make it future proof, we shouldn't identify specific numbers of users, just set a generalized rule

<hwest> We can set a policy rule that the data should not be reasonabliy reidentified

dsinger: if you don't know how to handle data, you shouldn't record it

<hwest> We can't determine that it's definitely safe

<karl> privacy in aggregation of data is highly dependent on the data context

jmayer: we could have both a high-level standard and a specific rule that implements that standard that you could use right now (and different rules in the future)
... I think we do have to give some guidance and rules, even non-normative, as we hear over and over again from companies that are confused about anonymity/pseudonymity/aggregation

<karl> if we are 20 john during the meeting and I'm aggregating John... then the aggregation is not very harmful. If we all have a different names. it suddenly become more "harmful"

jmayer: if we don't give a good practice to those two guys in the garage, then we shouldn't expect them to [paraphrasing that last part]

tl: fine with putting a pointer to guidelines, but should standardize on results

robvaneijk: in a way we're coming up with a new definition of "personal data", which is very tricky and has been worked on for many years, could look at the one in the Directive

aleecia: summarizing points

<NinjaMarnau> I agree with rob

aleecia: 1. If you are selling or otherwise distributing aggregate information, it's your responsibility that it can never be re-identified.

<NinjaMarnau> but there is no good (understandable for everyone) definition in the Directive either ...

aleecia: 2. Sliding scale of risk/value -- but what if you release data that re-identifies some other data?

tl: only responsible if the data was collected when data was sent with DNT:1

<jmayer> I don't think we should get into how valuable data is.

<jmayer> If it can reasonably be identified, then it's covered.

<jmayer> If it's valuable, the entity can ask for consent.

aleecia: do we agree that multiple parties, all parties, responsible for re-identification?

<hwest> This distinction between public and private data on sites needs to be reflected somewhere in the spec - this is not reflected right now.

<asoltani> agreed

<asoltani> we're stepping into data sharing practices that should be covered in privacy policies

<NinjaMarnau> exactly

WileyS: what about data that's collected (posting a name and data on marathon web site) and then a search engine and the Wayback machine also collect it?

tl: if you posted it publicly on the site, then the user has given consent

<hwest> This has to be a balance between reidentifiability and the data - as long as there's a good faith effort, reasonable standards, etc

<hwest> If there is no measure for reasonable efforts, then all innovation disapears and/or no one uses the standard

JC: what if I had no way to reidentify, but someone else with an additional dataset could? I shouldn't be liable for that

<rigo> this will be so complex that first parties will just refuse to use DNT and send back "we don't do DNT"

<jmayer> I think we should define aggregation such that this sort of re-identification isn't even possible.

<karl> it is not tracking protection but tracking preferences so far

ISSUE-73?

<trackbot> ISSUE-73 -- In order for analytics or other contracting to count as first-party: by contract, by technical silo, both silo and contract -- open

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

<jmayer> We should be conservative - data that has rich pseudonymous records or limited k-anonymity is not going to fly.

<hwest> De-identification will continue to evolve, so will re-identification.

<rigo> now comes the re-invention of data processor in a loser way

aleecia: the idea is that I'm a first party and I'm sharing data with someone who's working on my behalf, and they're not sharing the data with anyone else

<asoltani> clarification, there are numerous guidelines we can point to on the de-anon issue such as those created by HHS http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/De-identification/deidentificationworkshop2010.html

<asoltani> would suggest just linking to best practices, etc

jmayer: more than just a contract, legal enforceability by multiple actors (regulators and/or users in addition to the company they contracted with)

aleecia: I propose enforce technically, or by contract, but the agents must not share the information

jc: if there's no contract, then what could stop them? there should be a contract in place

WileyS: a "must" on the contract and a "should" on the technology
... but we agreed that there must be some contractual structure, but jmayer and I had disagreed about how specific or prescriptive we should get with the technology

aleecia: could say "must technically silo" but not go into details on the technology

rigo: could each agent just contract with all the other parties as agents on their behalf? and reconstruct the complexity of the ad network that Jules showed earlier?

WileyS: but there would be a limit on using the data for anyone other than you

aleecia: remaining disagreements?

WileyS: on how specific the technical limitation should be

jmayer: might have a disagreement on the legal means
... a legal means that's enforceable by the User and Regulator and the contracting Company
... and a minimum set of technical protections, based on the same-origin policy for siloing data
... same-origin policy should be a MUST, it's important, a low technical impact, does a lot for users, lots of companies do this already

aleecia: couldn't using the same identifier be prohibited in the contract?

jmayer: [sent long list of requirements for the contractual relationship to the mailing list] but I wouldn't include different identifiers as a legal requirement in the contract
... prevent companies from shooting themselves in the foot, making a common mistake

aleecia: Shane, why shouldn't it be a MUST?

WileyS: just seems very prescriptive, could use something like physical separation (different data on different servers), seems like an overreach of the standard

aleecia: what about -- must do same-origin siloing or equivalent or better

WileyS: just think a standard shouldn't be that specific

dwainberg: I think both the contractual and technical provisions are both overly prescriptive

<hwest> jmayer, do you have an example of what you would consider a must for the standard on a technical level?

dwainberg: instead should just take reasonable measures to assure

<WileyS> Specifically: Standards should not cement technical prescriptive measures when multiple valid and appropriate alternatives may exist.

<jmayer> yes, different first-party client = different identifier

<jmayer> + other information stored

<rigo> Ninja, Frank just says this is the annex to Article 9 BDSG combined with standard contract clauses

<NinjaMarnau> rigo, yes it is - I don't get why we are reinventing European privacy laws

WileyS: must have a technical measure (and should do this different-identifier policy)

jmayer: I could live with that as well

<hwest> Another point where I feel the need to point out that being technically prescriptive here may in fact have a negative impact on privacy in the future

aleecia: jmayer to go back and make a change on the text, we're very close but it will help to have text to agree on

dsinger: specifying a result rather than a means has advantages (in the same way that we want governments to let us choose means)

ifette: examples should be non-normative

<rigo> sharing with agents on non-normative clauses is cool

<jmayer> ACTION: jmayer to write section on outsourcing exception by Monday [recorded in http://www.w3.org/2011/10/31-dnt-minutes.html#action03]

<trackbot> Created ACTION-28 - Write section on outsourcing exception by Monday [on Jonathan Mayer - due 2011-11-07].

meet aleecia at 6:15 if you'd already arranged with her about dinner

Summary of Action Items

[NEW] ACTION: jmayer to write section on outsourcing exception by Monday [recorded in http://www.w3.org/2011/10/31-dnt-minutes.html#action03]
[NEW] ACTION: karl to do a review of the Tracking Protection WG deliverables according to http://www.w3.org/TR/qaframe-spec [recorded in http://www.w3.org/2011/10/31-dnt-minutes.html#action01]
[NEW] ACTION: tl to write-up the consensus for what is a first party on ISSUE-10 [recorded in http://www.w3.org/2011/10/31-dnt-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2011/11/08 07:44:49 $