See also: IRC log
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
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
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
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