See also: IRC log
<trackbot> Date: 24 January 2012
<npdoty> scribenick: npdoty
schunter: we've achieved a lot, established our group, lively discussion, made progress on solving issues
... so far good progress
... produced several documents
... happy about the atmosphere in the group
... still a lot of issues to resolve
... at a make or break point of this venture
... time to identify solutions that fulfill our requirements
... now have to start moving on our positions, don't go for the perfect solution
<johnsimpson> +1 to consensus
schunter: efficient to implement and increase privacy
<johnsimpson> =1 to perfect consensus
aleecia: fantastic hosts (European Commission)
guiseppe: head of policy development unit in electronic communications
... we are responsible for the ePrivacy directive
... happy to host
... we will attend all sessions, can provide assistance on European regulatory framework
... wish you every success
introduction video from Vice President Kroes
buhr: VP sends her best wishes for a good event, wanted to attend the opening session, has to be in two Parliaments todays, sends her apologies
... more technical remarks in context
... managed finally to provide hosting
... we think this work is important because we think it can help with our policy goals
... we have a different legal framework in the EU
... a common approach and tool, rather than having every provider scramble to respond to a particular law
... DNT and things like it can be a solution to the problem of fragmentation, if they are good enough
... doesn't distinguish between tracking/non-tracking activities, or between 1st and 3rd, requires explicit consent for many types of cookies
... what is the concern that they want to address in using DNT
... our plea is that we keep in mind EU compliance
... we don't think a solution that isn't 100% is somehow worthless
... please feel free to contact me to discuss further
... wish you a great event
video (with audio!) of Neelie Kroes,
kroes: impressed with the quality of this group, breadth of representation and technical expertise
... if we don't have trust and privacy, people will shy away from the online world
... something that users can instantly understand and easily make a choice
... Do Not Track can help us get there
... four things: principles of transparency, fairness and user control
... second, must be rich and relevant
... third, must be flexible enough to work in different legal frameworks
... fourth, we need this standard soon
... Do Not Track today is still an aspiration
... called for agreement by June of this year, to turn DNT into a reality for Web users
... if we get it right, DNT can become the standard way to comply
aleecia: lucky to be hosted here
... introduce the chairman of the Federal Trade Commission
Jon Leibowitz, audio and transcript
leibowitz: joined by efelten, whom you all know; and thanks to EC for hosting
... long time and always productive collaboration with Neelie Kroes
... sometimes we take slightly different approaches, but we very much take the same goals, "strike the right balance"
... 13 months ago the staff report (final report in the next 6 weeks or so)
... a few pages on Do Not Track seemed to resonate the most
... users want to have a choice, especially when it comes down to third parties which track users
... giving users choice won't solve all privacy problems, but it would be a step forward
... browsers rolled out tracking protection features, thank you Mozilla; and I saw Mike Zaneis here, thank you Mike
... I think going forward no one will follow the SOPA approach (that was a joke)
... in the US, we don't usually first just set down laws/rules for everyone to follow
... in general, we take the position that stakeholders are in the best position to solve problems
... industry can sometimes very quickly come up with solutions
... but those solutions don't always do the best in protecting consumers
... the third approach that we really like is a multi-stakeholder process, with open public international process
... and that's what we're doing here
... perhaps it can even help with the complexities of the EU regulation debate
... extraordinarily broad participation from industry sectors (analytics, advertising, social networks), consumer groups, multiple countries
... so impressed with the progress made thus far
... I know there's a lot of work left to do
... not everyone gets everything that they want, but all invested in the outcome as we all share the goal that a Do Not Track standard is within reach
... thank you so much for letting me participate
aleecia: thank you all very much for being here, some traveling a great distance
... Matthias at IBM working on privacy and security
... I'm at Mozilla half-time who have made it possible for me to participate in this work
please don't lose your badges
aleecia's slides: http://www.w3.org/2011/tracking-protection/brussels/TPWG-belgium2.pdf
aleecia: privacy as a three-layer cake
... some data required to be kept
... some where there's user choice
... some where data collection is prohibited (for certain data and certain communities)
... without user choice, the other categories tend to grow, like policymakers prohibiting more data collection
... theme of a loss of user trust
... can lose a lot of revenue if users lose trust in things like advertising
... privacy is very contextual
... reasonable people differ on preferences, users not a singular block
... give users a voice
... why Do Not Track in particular?
... arms race of different tracking methods and opt-out techniques
... Do Not Track originally goes back multiple years
... DNT can solve new problems, like redirects
... here at W3C we create technical standards
... preference expression as bytes on the wire, and compliance as the meaning of those bytes
... tracking selection lists we've gone back and forth on
... to determine if we're going to publish something on that
<applause for the editors>
aleecia: successive drafts of these documents
... FPWDs as extended outlines
... Last Call would mean that we have addressed all the major issues and move to an issue freeze within the group, and gather external feedback which can turn up new issues
... Candidate Recommendation after we've responded to all that external feedback
... this stage we Call for Implementations
... this has to be something that works in the real world
... Proposed Recommendation we should have at least (and probably more) two working interoperable implementations
... first phase was really identifying issues, then exploring them
... now entering a phase of resolving, we need to close these issues, come to a resolution for them
... now have 17% of our issues closed, but still increasing the number of open issues
... we've also done a fair amount of work proposing text
... "Getting to Closed"
... can re-open issues when we have new information and a new text proposal at the chairs' discretion
... try to find consensus, the 80%, the least-strong objections, something we all can live with
... with votes, your company gets one vote
... Invited Experts also get one vote
... if we have formal objections, we give a group response and can then finally end up with a Director decision
... laughter not yelling
JC: what about monitors/observers?
aleecia: observers cannot vote
... must help privacy, must be implementable by user agents and by sites
... confirmation bias sometimes (remembering everyone agreeing with me)
... our process is to get to consensus
... our goal for this meeting is to get issues closed
agenda for today: welcomes, overviews of drafts, discussing of Tracking Selection Lists, move to Centre Borschette (and get lunch)
scribe: presentation from comments of the Community Group
... then take up some of the meat; 1st and 3rd parties, tracking/cross-site
... reserve some time for unresolved issues
<laughter on that joke>
scribe volunteers: bryan, rvaneijk, AlanC, dsinger, efelten, jeffC, ninjamarnau
please help the scribes find your names!
<bryan> scribenick: bryan
matthias: Roy will present the TPE first
... goal is to get an overview not discuss all issues, ask questions, note issues for later sessions
roy: a lot of progress up to and in Santa Clara
... defining comms between UA and servers is the goal. Its all editors text so far.
<npdoty> bug request for Tracker that we should distinguish between closed and duplicate issues
<jmayer> +1 on the issue tracker recommendation
roy: some issue management is needed, to triage and address the issues. input is needed on what is expected in the text
<jmayer> also, hierarchy would help
roy: if you disagree with the intro section, recommend text
... input that is received is reflected in the text, so get your voice in
... overview: explaining what user preference means, how UAs determine what to send, how it is sent, and what do servers send back in response
... user-managed site exceptions is for users to opt-back-in etc, so user can manage site-specific exceptions for tracking
... still unsure what tracking means, but we will get there
... main changes are in section 3 and 6
... section 3, determining user preference
... we addressed the role of intermediaries
... for section 4 there is some text that does not have consensus, on expressing tracking preferences, we need to discuss here
... last part is UA managed site exceptions - nick, shane, and sid offered to provide input
... those are all the highlights
<npdoty> there are a couple of issues tracked regarding site-specific exceptions that aren't included in the draft, I think, because I'm behind
<npdoty> like http://www.w3.org/2011/tracking-protection/track/issues/67 should we have a user-agent-managed technique at all?
<npdoty> and http://www.w3.org/2011/tracking-protection/track/issues/118 we should make it asynchronous
<npdoty> we're now looking at: http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html
sean: I work for Google, co-editor Justin has worked in privacy for a long time, also support from Erica and Heather who are not here today
... a lot of text is not consensus yet, but it is here so that we can look at it holistically and have a discussion starting point
... at a high level there are 3 goals and success criteria
... enable awareness of data collected, be simple to control, be verifiable in terms of compliance
... definitions are based upon a lot of input but no consensus yet on many of them
... parties, we are done with (not though 1st and 3rd)
... branding needs discussion to reach consensus, e.g. what constitutes corp affiliation and branding
... will be a lot of discussion re 1st and 3rd parties, i believe there is close to consensus on widgets
... hope to come to resolution this week wrt the role of corp affiliation and common branding, to come to a clear definition of 1st party
... tracking definition has been proposed, we can debate and seek consensus
<npdoty> I thought we did have some tentative definition of tracking on the calls from discussion between WileyS and jmayer
sean: most obvious aspect is that tracking is about collection of user data
... beyond cookies, fingerprints and other methods are also to be considered
<jmayer> Agreed npdoty, all collection and use.
sean: 3rd party collecting data, and 1st party sharing data with 3rd party are also in scope
<jmayer> ShaneW and I had a few differences on drafting, but agreement on meaning.
sean: exemptions for operational use need significant discussion, privacy folks have discussed need for minimization
... definitions are further explained and requirements for 1st and 3rd parties follow
<npdoty> ShaneW and jmayer, can we dig that out and write up some text today?
sean: close to consensus on 3rd party and intermediaries, and somewhat on 1st party
... focusing on 3rd party compliance. (reads the current text)
... there is a general discussion with open issue re sensitive information. so far we are not heightening protections based upon info category
<jmayer> See the thread "High-level text on third-party responsibilities."
justin: location is a relatively under-discussed topic
<trackbot> ISSUE-39 -- Tracking of geographic data (however it's determined, or used) -- open
sean: it would be good to address location in this meeting
aleecia: we have a lot more to discuss
<npdoty> I think we're now looking at: http://dvcs.w3.org/hg/tracking-protection/raw-file/tip/ED-tracking-tsl.html
aleecia: we have a tracking protection list draft that has not been discussed, but closely follows the input from microsoft
karl: we asked f we could put this draft online since its easier to work with, but this is not a wg draft, just an editors draft. it will stay in this stage until the group agrees to work on it
... we went thru a round of comments from our companies and put the issues in boxes. its far from final form, but good for discusson
... we need list discussion to avoid missing things
... the approach needs to be simpler than 1st/3rd party distinction, just related to blocking for specific sites
... what happens when the servers don't comply, what is the user choice... is TBD
... what is the final defense mechanism for the user - they need to be able to say no, but can't right now
... its very preliminary, some issues noted in the intro
<aleecia> Rigo, thanks
<aleecia> Second in queue is Shane
karl: 1st/3rd party URIs are a technical issue, it is not handled right yet
roy: suggest a paragraph clarifying this is not a consensus document, remove the product of the WG boilerplate
<aleecia> ACTION: karl to edit document to make sure there's no confusion this is not a consensus document based on WG boilerplate [recorded in http://www.w3.org/2012/01/24-dnt-minutes.html#action01]
<trackbot> Created ACTION-46 - Edit document to make sure there's no confusion this is not a consensus document based on WG boilerplate [on Karl Dubost - due 2012-01-31].
<fielding> just a small addition to the SOTD to clarify the special status of this document (as opposed to a normal ED)
<aleecia> it will come up as soon as Karl finishes the overview
shanew: how does this relate to ad blockers (scribe: not sure I got the question)
karl: the document is about blocking URIs
<ShaneW> JMayer - definitely a clarifying question
karl: the document defines the rule and how the UA selects and applies the rules. its very technical, no policy aspects
aleecia: we will move on to the points e.g. from Shane
... its been controversial, we have spent an hour each time, and this is the 3rd tome to consider it
<fwagner> delete pls wrong window...
aleecia: there are a couple of things going on... this does not have the same timeline as the other docs
... timeline for DNT is very short as we need clarity about what happens when user clicks a DNT buttone
... one approach for TPL is to have a subgroup that can go off and work on it
... objections on whether the WG should tackle this has also been raised
... currently there is no mechanism around the policy of how TSL are managed... browser companies doing this on their own... it might be good to help shape that
... we can do it, but we need to consider the member submissions that led to this proposal
... in the next half hour we need to come to consensus on who will support this work
roy: feel that this is not the product W3C should produce - mechanized removal of content from sites is not legal. if driven by a user is OK, but IMO selection lists published by someone else is illegal
aleecia: if you had TSL scoped for users to white/black list is that OK?
ShaneW: from a W3C support perspective, I recognize the tech can be used for many things, but its primary purpose to date has been ad blocking. as the chief monetizaton for the web it does not make sense to move in that direction.
aleecia: so the purpose of the web is to serve ads?
ShaneW: not the purpose but the chief use is to delivery ad-supported content
aleecia: differences exist on that but a good statement
jmayer: ad blocking is not the chief use - it's protecting users from security risks
<ShaneW> Look at the list of domains in TPLs available in IE9
jmayer: browsers that interact with services that rate sites however the data is collected - that is a great tool and a good place for standards to go
... ad blocking was going into chrome but got yanked... we should now settle on one approach instead of having unnecessarily conflicting standards
<rigo> support from JMayer
<rigo> support from Andy(MS)
<fielding> thanks karl
<rigo> opposition from Roy
<rigo> opposition from Shane
andyzei: this is a tech feature that can help users until DNT is ready. no matter the jurisdiction there will always be noncompliance, some illegal. but this solution is globally flexible.
<npdoty> karl, "published by the undefined"?
andyzei: some jurisdictions will be legislated, others not and this can help there also
<karl> npdoty, yup in the meantime I have found the way to setup Respec for it ;)
<vincent_> npdoty, couldn't a TSL like format be used by "user managed site specific exceptions"
tl: that TSL are illegal is a strange view, and that they will break the Web need to be validated also
<rigo> vincent, TSL is just an interoperable recording format for those decisions IMHO
tl: te main use is blocking malicious software... this group was formed to define list management, and is a majority of the founding chartetr
<ShaneW> I did - read Yahoo's paper presented at Princeton
<jmayer> Would support renaming from "Tracking Selection Lists" to something more purpose neutral, e.g. "Content Selection Lists"
tl: those who want to work on DNT can do so, but we should work on TSL
<tlr> clarification: TSLs are one of several elements of the charter.
<ShaneW> JMayer - how about "Security Protection List"?
adrianb: echo what Tom said, and remind about disposition of comments on the charter. comments from the team at the time was there was strong support for standardizing some type of lists. this does not require all the room, but can be addressed by a task force
<schunter> ackn dsinger
<Zakim> dsinger, you wanted to talk about recusing and hostility
<tlr> member-confidential link to the disposition of comments: https://www.w3.org/2011/09/privacy-ac.html
dsinger: concern about this is that it is an overtly hostile move, and sites will respond e.g. with DNS tricks and hiding domains etc with a war resulting
... I can't work on this myself, but I am OK stepping aside while others work on it
<jmayer> ShaneW - would prefer to stay neutral. I fully acknowledge that ad blocking would be a use. I don't think W3C needs to (or would) take a position for or against that use.
<tlr> also for reference, the charter: http://www.w3.org/2011/tracking-protection/charter
sean: wrt TSL primary purpose, it was an ad blocker. thats ok and MS can use it for IE as they choose, but that purpose is why we are uneasy
<ShaneW> Supporting the lists knowing their core purpose will be for ad blocking hardly seems neutral
<npdoty> some have referred to the disposition of comments, which is here (Member-only, sorry): https://www.w3.org/2011/09/privacy-ac.html
sean: in Santa Clara is was clear the consensus was not to move forward, and surprised to see it coming up again.
<schunter> sean concerned about ´pay to play´ usage of lists: Pay or be blocked.
sean: when TPLs went out, pay to play moves led to what seems like not clean solution and W3C should not work on that
<ShaneW> Truly malicious sites domain rotate regularly to avoid these lists - so the only truly harmed entities are the good actors. This seems up-side down to where W3C attempts to support from a voluntary standards perspective.
<jmayer> ShaneW - I just explained how ad blocking isn't the primary purpose I'm concerned with, and quite possible won't be the primary use of such lists. And setting aside that, W3C can explicitly not take a position on the merits of ad blocking.
aleecia: we had a straw poll in Boston, and in Santa Clara we discussed editors if we moved forward, and at the end we weren't sure if we would publish, but had no consensus
sean: the impression of some members is different coming out of Santa Clara
<ShaneW> JC - we've already built-in that capability into DNT via Site-Specific Exceptions
<dsinger> ...wants to confirm that the W3C would only publish the FORMAT spec., not an actual list, right?
<jmayer> WileyS - would you support the proposal if renamed "Security Selection Lists"?
JC: consumers must be able to say who they trust and not, and some way for parties that can be trusted to be conveyed. it should not be an ad blocker, but allow users to manage trust.
<npdoty> from the minutes last time: "Aleecia: we have a disagreement in the room. split in half. we will continue to discuss this"
zaneis: if this was primarily an ad blocking tool, it would be less problematic. there are certainly legitimate concerns and challenges. content being blocked just because its from a different domain is something users don't understand.
... if we move forward, we should split this from DNT as they don't work together well
<fielding> Actual member survey results "https://www.w3.org/2002/09/wbs/33280/privacy/results" demonstrate that only 12 members responded, most of whom are not here.
<ShaneW> JMayer - It would still be difficult to support due to true use not being security specific but at least that draws optics closer to the intention I feel is defendable (security is important - but unfortunately the real outcome here is exactly NOT that)
zaneis: most TPLs are for ad blocking and mostly whitelists. we should put out two standards that work together
aleecia: re legality, we need a 101 session
<npdoty> on the scribing, I think Mike's point was that ad blocking was less problematic than free speech issues, right?
<jmayer> ShaneW - hypothetical, if the text made clear security is the primary purpose, then would you support it?
johnsimpson: this is another tool that empowers users, akin to lists of good things e.g. books that people put out. its not about ads, but about other ways of giving users control
... the notion that the web is about ads, and content is made possible due to ads. most places I go are not ad supported. so the web is not all about advertising, and we need to get out of that mindset.
<ShaneW> JMayer - again, as this concept has already been tested in real-life and we can see the outcome is chiefly ad blocking, it's difficult to support it at all. I wish there were a way to focus a result only on security (which I believe in strongly) but this approach doesn't offer that.
johnsimpson: those users that want to use ad-supported sites can do so
aleecia: there are different perspectives being expressed here
<tl> ShaneW, The main use of lists of this sort is Safebrowsing. By far the largest and most-used lists
justin: we envision TPL to also send out DNT headers, and blacklisting bottom feeders.
<ShaneW> Site-Specific Exceptions ALREADY cover this need - and do it in a transparent manner.
<justin> I've been tasked to supplement my comments by the scribe --- my final point was that I'm not worried about third-parties evading TPLs and DNT signals because I think most of the techniques that have been motted to do that would be illegal/deceptive under existing law
ksmith: if we go forward, a minimum is that websites must know if they have content that is blocked, or that their content is being shown without being paid for
<jmayer> justin, could you elaborate a bit on that preference circumvention view?
<ShaneW> The largest IE9 TPL is AdBlocker
<npdoty> I think that's an excellent point (ksmith, notification to a site that some resources were blocked), we could add that to this draft
<andyzei> Shane, that is factually not true
vincent: couldn't we use this also to block 1st parties?
<justin> Sure, if a third party were to try to mask itself as a first-party domain, I think that would be a deceptive practice in violation of Section 5
<ShaneW> tl -> the largest IE9 TPL is AdBlocker
<johnsimpson> + 1 to knowing that you as a site have been blocked.
<andyzei> shane, the largest IE9 TPL is the EasyPrivacy list
<ShaneW> Andy - could you point to a public document from MSFT stating TPL marketshare?
rigo: the lists are dual-use tools. you can use them for ad blocking, but the ad blockers don't need W3C. the use of TSL is not in our hands for that.
<tl> ShaneW, but IE9 TPLs aren't the largest set of lists of this type. Google's Safebrowsing list is far larger than any IE9 TPL.
<andyzei> Shane: The easylist guys have published some stats you can take a look at.
rigo: wrong use of a tool is not the tools fault
<ShaneW> Please post here so we can review.
rigo: if i have different browsers how do I manage preferences among them and across devices etc
<tl> dsinger, No: we're talking about defining the *format* for lists.
<justin> jmayer, it's a tougher argument to say that shuffling domains is deceptive, but I don't think that's scalable for ad serving companies
<andyzei> npdoty, sorry -- thanks
rigo: can we live with this dual use tool and preserve interoperability with DNT?
<jmayer> Ok, thanks justin.
rigo: transparency is also important, but it is a useful tool
aleecia: a lot of interest in this topic - a quick show of hands?
... appx 12 people out of ~34 wg and experts - 1/3 of the group
... there is at least enough interest to do the work, which answers an open question
<jmayer> My lab's research on TSLs in the wild: http://cyberlaw.stanford.edu/node/6730
aleecia: at this point, what can we live with? why do we do? I suggest to break off a small group, and work on something concrete that can be discussed
... straw poll: who thinks we should not work on this, and want to block the work? 6 people, plus probably some tired of the discussion
<npdoty> half a dozen people that don't want us to create a sub-group for it (or continue at all)
aleecia: at this point I think we should have a small group go off and work on it
... anything new to discuss?
jmayer: possibly expanding the scope... downloading TSL is not the only way. various forms of sync/async determination of what you can trust on the web can be considered
<npdoty> speaker is Hannes Tschofenig, an observer from Nokia and IETF
Hannes Tschofenig: also include methods for spam blocking, trusted provisioning protocols
<npdoty> thanks for scribing, bryan!
<rvaneijk> John: community group comments on W3C DNT
<npdoty> scribenick: rvaneijk
<scribe> scribenick: Chapell
<rvaneijk> documents has not kept up with reality, is an ongoing proces
John: doc is designed as a broad based group
<rvaneijk> includes various contibuting organizations
<rvaneijk> Lie TIen was co-editor
John: EFF, CDT and other orgs
... PRC and WPF
<rvaneijk> started to react op first working drafts
John: The doc is considered a draft - they started to react to the first published working drafts - which evolved while they were being commented on
<rvaneijk> identifies issues on the mailing list editors felt need to comment about
John: The form of the document -- high level bullets, general comments and open issues and issues for further consideration
... assumed comments would evolve over time as the WG lanugage becomes clearer
<rvaneijk> When LC paper comes out, editors will be more specific as documents become more and more clear
<fielding> Is the community group discussing this somewhere other than the mailing lists? http://lists.w3.org/Archives/Public/public-dntrack-contrib/
John: The idea is that the WG would reach consensus, and their doc would provide a consensus statement in favor or (or opposing) the WG statement
... The current practices should not necessarily be enshrined - status quo is not normative
... believe meeting user expections should be driving this -
<rvaneijk> 1st party 3rd party paradigm as a way to approach the problem at hand
John: Tracking Pref doc - page 3 -- we think that the document is written from the industry point of view and believe that is a mistake
... it is important to acknolwedge the rights of consumers to privacy - the point of the process is to enhance users ability to express their preferences when it comes to privacy
<rvaneijk> ... include the notion not everything on the web is commercially driven
John: A successful DNT mechanism should be able to send a message to all sites that the user doesn't want to be tracked
... Issue 8 - page 7 -- first and 3rd party definitions from Tom and Jonathan make sense and could provide a basis for solid consensus
... offered a definition of tracking that is different from the W3C doc
<rvaneijk> ... the approach is to get comments on the document
<rvaneijk> Jeffrey: try to reach out
Jeff: tried to get multiple perspectives internationally
<rvaneijk> ... to give consumers internationally a voice
Jeff: want to align consumer ngo's on these issues
<rvaneijk> jchester: align consumer organizations globaly is a goal of this effort
Aleecia: we will evaluate the comments, see where they make sense
<rvaneijk> aleecia: TPWG will go through comments and determines to respond or not
Aleecia: we will see many different perspecitives come into play
<rvaneijk> ... there will be many different perspectives to come into play.
Aleecia: what are the three main issues of concern?
Jeff: 1. User expectations -
John: 2. Philosphical idea - the rationale for doing all of this should be in the intro of the compliance document - and wherever it goes, it should have
... a substantial recognition of the importance of privacy rights
<rvaneijk> john: current documents reflects privacy right not enough
John: should reference article 19
<rvaneijk> ... referents to art 19 , declaration of rights etc.
<jmayer> To clarify, John is reacting to the current introduction of the TPE document.
John: 3. the definitions of first and third parties -- they are in favor of the language they suggested
<rvaneijk> aleecia: nick will do live editing
Aleecia: taking us to way back machine - how did we get here?
... in Santa Clara, 1st and 3rd party was discussed
<rvaneijk> ... flowchart of 1st/3rd party path
Aleecia: anything under EXAMPLE.com is a party
... if you're a website and have other domains, you could spell out those domains - not thoroughly discussed
<rvaneijk> ... analytics issue not been discussed in detail
<rvaneijk> ... other route is base don interaction of a user
Aleecia: base this upon user expectations driving the interaction
<rvaneijk> ... depends on whether a party knows it is a 1st or 3rd party
Aleecia: our approach depends upon whether or not a first party knows they are a first party
<rvaneijk> ... Q: what is a 1st or 3rd party
Aleecia: two paths 1. jonathan & Tom's - branding plus approach -- but it is testable, and too costly
... 2. affiliate model - is the cost too high for users to figure out what counts as a first party?
... also, some discussion on email threads about cross-site tracking
<rvaneijk> ... if we do not come to a good definition of 1st 3rd parties, we wil go a different route
Justin: conflating "party" determination with determination of 1st vs 3rd party
Shane: there are merits to the cross-site and 1st / 3rd party - and both may get us to the same place
<rvaneijk> WileyS: proposed a more hybrid solutin
<rvaneijk> ... list concept
<rvaneijk> ... well known location (URL)
<rvaneijk> WileyS: to give transparency on who will be part of the 1st party group
WileyS: wants to get us out of the more subjective measures
<rvaneijk> ... if you are not on that list, you are a 3rd party
<dsinger> thinks that an easier and maybe better solution for 'are sites X and Y the same party' is to have well-known URLs at X and Y that redirect to the 'owner
<jmayer> A means of communicating party status is independent of how we determine party status.
Aleecia: questions / concerns with sec 3/2 (?)
<jmayer> No need to link this to a corporate affiliation test.
Aleecia: trying to define who a party is
DSinger: still we're conflating "party" with 1st vs 3rd party determinations
<rvaneijk> dsinger: we are discussing what is a party
<rvaneijk> aleecia: we are discussiong 3.2.1 defs
Aleecia: Corporate ownership constributes to, but is not determinative
<rvaneijk> ... A "party" is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person, that an ordinary user would perceive to be a discrete entity for purposes of information collection and sharing. Domain names, branding, and corporate ownership may contribute to, but are not necessarily determinative of, user perceptions of whether two parties...
<rvaneijk> ...are distinct.
<trackbot> ISSUE-117 -- Terms: tracking v. cross-site tracking -- raised
Rigo: Meta argument - should documents agree?
Aleecia: Yes - docs will agree
<rvaneijk> aleecia: tracking def immediately after def parties
<rvaneijk> rigo: entity is a well know def in legal which we could re-use
<npdoty> rigo, can you provide citations of the well-settled legal definition?
<rvaneijk> jmayer: agrees with shane
JMayer: @SWiley - its a nice idea to have some list based, but this is independent of how we define parties
<rvaneijk> ... nice way to define what is within a 1st party.
<WileyS> JMayer - agree they are different as my proposal was meant to support more the Affiliate concept - but now in a very easily discoverable manner
<rvaneijk> ... a lot of the concern about the party def is that it is not predictable enough.
JMayer: @rigo - disagrees that the idea that entity definitions are clear in multiple jurisdictions
... bright line rule re: party
<rvaneijk> ... negating of all of the possible tetst. if no corp affiliation no shared name no common branding then forget talking about user expectations
JMayer: 1. test - if its not commonly branded, NO shared ownership, then this is not part of the same party and and can't foresee consumers expecting otherwise; 2. test - if not corporate affiliation
<dsinger> would add 'no shared liability for privacy violations', maybe?
<WileyS> Actually agree with Jonathan on this point - a multi-test minimum standard feels right - but still feel a list should accompany this to make the outcome objective
Aleecia: what is one party
<rigo> BTW, Wikipedia (as allways) has the most comprehensive definitions of person/party/entity
<jmayer> Didn't mention - we can also use tools like safe harbors here.
<jmayer> E.g. if there's common branding, we'll give a rebuttable presumption of same party.
Rigo: BCR in the EU
<rvaneijk> please add your point to irc :)
<npdoty> BCR, "binding corporate rules"
Rigo: should we use the term 'affiliation' in our definition?
Aleecia: two companies - diff domain names, are they the same party?
<rigo> AM: shared domain names. foo.com and bar.com can be the same entity
WileyS (and others) YES!
<rigo> Brian: how is it useful in terms of compliance
<rvaneijk> bryan: usefulness in terms of compliance?
Roy: I thought we were talking about the spec, where are we going?
<rigo> Roy: we are talking on spec, where is this going
<rvaneijk> fielding: relevance of definition?
<rvaneijk> aleecia: user expectations not conrete enough
<bryan> it may be a valid test, but how is it useful in compliance? can it be tested in real time in some way?
<rvaneijk> fielding: focus que on def of parties 3.2.1
<rvaneijk> ... the user is a party
<Zakim> karl, you wanted to ask "what is a list and how long the list will be? How many times it would be downloaded? etc. It looks like the white list TPL :D"
<rigo> user expectatiion is not testable at all, so this is a red flag for me
Karl: User expectation is not testable and will not be able to have an easy implimentation
<rvaneijk> karl: user expectation is not testable.this is a pitfall
<fielding> Each legal entity engaging in communication on the Web is a "party". In some cases, two parties might be treated as one party if it is acting as an agent of the other.
<WileyS> Karl +1
<fielding> The user is the second party.
<jmayer> How are user expectations not testable? In the rare cases that aren't close, can survey.
<rigo> roy, there are no second parties
<rigo> only first and third
<rvaneijk> karl: shane's list resembles the TPL (joke)
<dsinger> the user IS the 2nd party, aren't they?
<rigo> second party is mainly your wife :)
<WileyS> Karl - but defined by the first party - not an AdBlocker!
<WileyS> Rigo - LOL
<rvaneijk> ... if there is no way to describe user expectations, we will hit a wall at some time
<johnsimpson> I understand the user o be the second party
Karl: Y! Japa is diff entity than Y! U.S,
<Zakim> dsinger, you wanted to ask for some clean 'can be' and 'can't be' tests
<jimk> Can I be in the queue, not sure of protocol - Jim Killock
Dsinger: wants a bright line test re: single party to deal with 95% of the cases
<justin> +1 to David
<WileyS> Y!US owns a minority share of Y!J and has BCRs in place - hence "same party" in some senses from a Legal perspective
<jimk> :npdoty thanks
Dsinger: we can deal with vast majority of use cases with a brite line test
<rigo> +1 to David
<tl> +1 David
<rigo> DS: part of privacy policies are very different, than they can't possibly be one single party
<fielding> the domain discussion is not relevant to the definition of party -- it is relevant to the definition of first and third party
<karl> jmayer - re:user expectation - not testable in a way, that they will not lead to the same answers depending on the users. It is not an objective critera
JC: doesn't want people to feel that a list is sufficient outside of the rules
<rvaneijk> JC: the list isn't sufficient outside of the rules
<bryan> I believe that definitions based upon what a "ordinary user would perceive", are not testable. However a semantic affilation discovery method would be helpful and may resolve the dependence upon user expectation (e.g. similar to the objective of Web Intents?). Re JMayer's list of test criteria: it may be a valid test, but how are those things useful in compliance testing? Can they be tested in realtime, or will such a test only be done in an audit process or in th
JC: msft has sites go up and down every day and its a process to get sites on and off any list
<rvaneijk> ... eg list can be very fluent and it takes days to have it up to date
<jmayer> karl, it is not deterministic, sure. Why does that matter?
bryan: a method of semantically discovering affiliation could be helpful, but the list of test criteria is going to be a red flag
<rvaneijk> bryan: how can the list be used in a realtime way?
bryan: in order to work in the web, we'll need to rely upon an audit process
... how will a test be actionable without some third party to enforce?
<WileyS> JC - I hope MSFT has a few days heads-up before you buy, sell, or close a company :-) Just kidding - we'd have to have some fair "lag time" built in so lists are up-to-date.
<rvaneijk> aleecia: policy based versus technically enforced approach
<karl> jmayer - because to implement you need a deterministic criteria in order to decide what message you send back. In Normandy, we say Maybe yes, maybe not :)
<bryan> If we are to use parties in any way in DNT, we need a technical means to determine affiliation that is usable for browsers and servers.
<rvaneijk> jchester: focus on user expectation
<JC> Which user?
chesterj: we need to focus on user expectations - happy to discuss how one tests this
<npdoty> fielding, I surely think it (criteria of domains, legal affiliations, branding) is relevant to the definition of what a single party is and it'll be most relevant when we get to the 1st/3rd party discussions
<jmayer> karl, The user agent responds based on the server's assertion. If the server gets it wrong, it will face liability.
chesterj: it is impractical for a user to know what the rules are
<WileyS> Scribe - please be sure to capture the "difficult for a user to know where they are on the Internet" comment
chesterj: to lose user expectations would place users in a difficult situation and limit the effectiveness of dnt
<Mzaneis> I think Jonathan has proposed a smart, valid approach. How do you technically implement?
chesterj: they can show how websites are structured to process user expectations and uses have know knowledge of those techniques
<rvaneijk> chesterj: could show that users have no knowledge of underlying structure of a site
<fielding> npdoty, domains have nothing to do with legal affiliation ... if we were talking about a definition of what a service is, then yes, but we can't define "party" in a way that assumes the user is not one of the parties.
<karl> jmayer, so far we have defined the behavior of the server with regards to the user agent, but not the user agent response/behavior with regards to that.
<jmayer> karl, ok, failing to see the issue there...
jimk: distinction between 1st and 3rd parties gives lots of leeway to first parties to look at user info
<rvaneijk> jimk: 1st parties collecting and profiling is already beyound user expectations
<karl> jmayer, the user is powerless.
jimk: 1st party profiling is more intrusive than most users would expect
<rvaneijk> aleecia: we are still figuring out who parties are
<WileyS> Jim - are you suggesting that TOS agreement equals first party?
jimk: user expectation must be related to a narrow definition of 1st party - if we broaden the definition of 1st party, then we should limit what that party may do
<rvaneijk> jimk: user expecttions should be bound to a def of party. so scope on what parties may or may not do
<rvaneijk> ksmith: user experience use case
<rvaneijk> ... Yahoo - flickr
ksmith: I don't know Y! and flicker are the same party
... I know about Google and YouTube
... supports a list of methods to approximate user expectations
<rvaneijk> ... supports proposal of jmayer: approx ways to meet user expectations
<rvaneijk> ksmith: 1. how you define parties and 2. how do you convey that message
ksmith: rather than create a list of related parties, (maintenance nightmare) he wants to have a group ID or entity ID (e.g., Disney)
<rvaneijk> ksmith: instead of list of domain names, but an intity ID eg. Disney with well known URL
<johnsimpson> can we please respect the Q????????
<rvaneijk> WileyS: is testable, 1 time per domain
<rvaneijk> WIleyS: list is methaphorically
Aleecia: User goes to website which is part of 50 sites owned by umbrella entity
<rigo> DS: have a redirect that redirects to the mother corporation, technically easy and sound..
<rvaneijk> Aleecia: undestanding of where the dataflows are
Aleecia: what is my user interaction so that the user understands the ownership and data flows between parties
... having trouble seeing how this can work for users in real life
<dsinger> a simple idea is 'For two sites to be considered the same party, they must maintain a redirection from the well-known URL at their site /X, to the same URL of their 'master' site'
<rvaneijk> ksmith: is user interface related
ksmith: has to some way to convey information -- see this as a UI issue
<rvaneijk> ... we have to define it and relay is.
<bryan> We need to avoid creating a lot of additional traffic to taste a site to test if its affiliated with someone. These things do change, and the data can be lost in many ways. So I would not be in favor of a metadata on a site, unless that data is embedded in the HTML of the site (no additional request).
Aleecia: is this an argument for user expectations
dsinger: for two sites to be considered as part of the same first party, they need to make some kind of redirect link to the same larger entity.
<dsinger> ...as ONE of the conditions to be considered a single party
ksmith: Y! can't meet his expectations -- expectations are based upon experience
<karl> these are just list of acquisitions not even services and they are already big 50 to >200
ksmith: there has to be a way for a user to discover the connection between two (otherwise) seemingly disperate parties (e.g., Y and Flicker)
<rvaneijk> johnsimpson: focus is on marginal cases
<rvaneijk> johnsimpson: usually an entity knows how it is behaving
johnsimpson: 98% of the situations are covered by our definitions abnd we may be spending too much time on edge cases
<rvaneijk> johnsimpson: when in doubt, take it out..
<WileyS> John - I don't think we're arguing that point
johnsimpson: if you as as site don't know which party you are, then that website should be honorable
... and err on the site of being a 3rd party
<rvaneijk> rigo: we dicussing from the wrong angle
<rvaneijk> ... if you are in the 1st of 3rd party. THe adressee is the contentprovider.
<rvaneijk> ... what we invent here is a recipe for a site to classify themselves
<rvaneijk> ... user expectation it the wrong angle.
<meme> The party itself knows whether or not its part of another company, its the user that doesn't know
Rigo: we are addressing our text to the sites. and if you discuss under this angle (rather than user expectation)
... this gets pretty simple. Advocates the idea of a list of tests
<rvaneijk> ... expression exchange protocol
<fielding> A party, for the purpose of Tracking Protection, is an entity that takes part in (sends or receives) a sequence of requests related to accessing a service on the Web.
<rvaneijk> tl: 1. hard to know for a corp to knwo where edges are
Schunter: been some suggestions for a coproration to manage its knowledge of its own edge cases.
<WileyS> Tom - who defines "typical"?
<rvaneijk> tl: 2 start with reasonable person approach
TL: wants a reasonable user standard
<schunter> my point was: If two entities cannot tell whether they are part of the same party, they should assume that they are not.
<justin> fielding, so entity = anyone within corporate family?
TL: if the affiliation of the site isn't obvious to a User, its unreasonable to expect that the browser will be in the position to do so
<rigo> Matthias, this would be one more of the criteria, David is suggesting for consideration
TL: sites should have communication strategies to ensure clear linkage
<fielding> entity = legal entity (person, company, org)
<johnsimpson> User expectations can -- and should -- change over time. If enough people don't
<rvaneijk> ninjamarnau: web today is a few mayor players
<schunter> yes. It is an anti-criterium: If you cannot tell, then consider yourself separate.
nijamarnau: a few major players have thosands of sites - most users can't keep track
<rvaneijk> ... hard to keep up what services belong to which party
<johnsimpson> ... excpet what the site wants, then it's time for a brading campaign
nijamarnau: this suppoorts a small party distinction
<tl> WileyS, As with the legal standards based on a "reasonable person"...?
<johnsimpson> meant accept
<rvaneijk> ninjamarnau: consent of users might be cosly for a UI
<tlr> s/except what/accept what/
nijamarnau: it may be costly for bigger companies, but its not possible for the user to understand who is sharing data with whom
<rvaneijk> schunter: 1. user expectations: do not take it too narrowly
<tl> s/"1. hard to know for a corp to knwo where edges are"/"1. If its hard to know for a corp to know where *its* edges are, just think how hard it would be for users!"
Mattias: If User thinks that two sites are related but they don't share data, that's not a big problem
<justin> fielding, I think that's too naive. What if one FB shell company owns facebook.com and another owns cdn.fb.com --- user expectations (however we define) would deem them one party, but the precise corporate entity test wouldn't allow.
Mattias: so, we need to err on the safe side
<rvaneijk> @schunter please put pointin irc
MZaneis: supports Jonathan's unity provisions test
<fielding> justin, that isn't relevant to the discussion of "party"
MZaneis: many publishers have many, many domains on their network of sites
<tl> tl: 3. I love the verifiability of the upstream/ownership link, and think that there are some great UIs that this can enable. However, I still think that sites should be clearly representing their ownership: if a site itself can't communicate its affiliation to users, why should browsers be able to?
MZaneis: concerned with the long tail that will be affected by what we implimented - many of the long tail have multiple domains
<rvaneijk> Mzaneis: has bigger concern. millions of website will be effected when implementing dnt
<fielding> If we want to define "service", I'm all for that.
<justin> fielding, if two closely related corporate entities that are clearly in the users' eyes one party can't share data as one party, that would seem to be relevant, yes?
MZaneis: it is unlikley that long tail will be able to implement these types of solutions
<ninjamarnau> to add to rob's scribing: I support the approach to restrict the scope of "party". The major players own a large number of services. If they want share data between theses services they can ask for the user's consent
MZaneis: without a major resource outlay
<rvaneijk> Mzaneis: if too technical approach risk is that companies will not understand and therefor not implement
<fielding> users don't care about the legal affiliations ... they care about the service being used.
Aleecia: If we move to something tech defined, the long tail may find itself impacted
<fielding> two different services owned by one party are just as much an issue
TL: Many sites can become compliant with DNT without breaking. doesn't see it as an issue
<rvaneijk> WIleyS: we do want to meet user expectations.
<bryan> "we are all" is perhaps too strong...
Wiley: idealogically, we're on the same page. we do want to meet user expectations, but we need objective tests.
<johnsimpson> use of fickr, yahoo as se case may change user expectations...
<schunter> The goal to meet user expectations should be in the text as a preamble for the tests.
Wiley: likes JMayer's tests - an appropriate test and we can work through the edge cases
<rvaneijk> ... 3 test of jmayer are appropriate, good baseline
Wiley: Agrees that once we get agreement, we need a technical signal
<rvaneijk> ... we need to make it testable.
Wiley: tech signal helps us test our compliance with DNT
... any domain should have a simple place to say where its parent is.
<johnsimpson> +1 Matthias for text in preamble
<fielding> My point is that "party" is not a relevant distinction for tracking protection aside from the normal meaning of the term as a party to the communication. Service (which is probably a better term than site) is a ddistinction that is testable and what the current document refers to as "party".
<rvaneijk> aleecia: EXPERIMENT on the flipover..
Aleeca: if we have two sites with diff names
... EXAMPLE.com (skiing site) and SAMPLE.com (cooking site)
... can we talk through a user case
<justin> I would be fine with the "service" model, fielding, but it would prohibit Flickr from being deemed the same party with Yahoo! --- I don't feel strongly, but the co-brand proponents might.
Aleeca: use case to determine what it would take for a reasonable user
JC: Branding: some type of graphic, signin
<npdoty> fielding, if you have a testable definition of "service" that matches user expectations and works for corporations' data sharing practices, that would be helpful to us right now
jeffc: different privacy practices
Sharvey: same privacy practices lead towards the same entity
<fielding> justin, yes I would consider them different services owned by the same party, which is why I don't think party is a useful term.
<fielding> And the fun thing is that Y! calls them different "properties"
<npdoty> fielding, if you want to run s/party/service/ in your head for the next 30 minutes, would that work for us? ;)
Aleecia: a user looks at two sites and can see that those two sites are sharing data
... trying to create the criteria
<justin> fielding, but under your "service" test, Yahoo! could not correlate individual user data from Yahoo.com with that user's interactions on Flickr.com because they're different services, Am I understanding you correctly?
<rvaneijk> WIleyS: how to deal with the corporate affiliation. How do you make BCR's visible
WileyS: wants to deal with corporate affiliation in a non-common branded approach
<rvaneijk> ... common legal terms
<fielding> justin, you understand me correctly, though the specific case of Yahoo! may not exactly match that model because they have user accounts with a shared authentication service.
<justin> right, got it
Dsinger: the user things the sites are distinct, but they are not distinct - sees that as the big issue
ksmith: sees some kind of obvious synergy or intergration between the sites
<npdoty> dsinger's point is that where ambiguous, it's dangerous for the user to assume they're distinct when they are sharing data
<rvaneijk> Mzaneis: common ownership point
Aleecia: factors are: Branding, shared signin (tho it gets complicated in an era of OpenID)
<rvaneijk> jkillock: login is not a good test.
<dsinger> It doesn't matter if two sites that seem to be the same for branding are in fact distinct and don't share data; it matters hugely if two sites that the user thinks ARE distinct are not, and are sharing data
<rvaneijk> aleecia: is single sign on sufficient?
<meme> does anyone disagree with jmayer's test?
<WileyS> +1 for JMayer's tests
<karl> "The Web is complex"
<rvaneijk> troessler: signing is a good place to find out about affiliation
<npdoty> here's my text of jmayer's min bar test: At a minimum, if there's no common corporate affiliation (or binding corporate rules or corporate family), common domain name or shared branding, then those entities are not the same party.
<npdoty> and a suggested addition from dsinger:
<npdoty> If two sites don't both redirect the well-known URI to the same umbrella company URI, then those entities are not the same party.
<dsinger> thinks it is time for a Small Group to write a draft definition of ' for two or more sites to be considered a single Party, one of the following conditions X must hold and none of the following conditions Y must hold'
<rvaneijk> dsinger: break up in smaller group to write a draft paragraph
<npdoty> +1 for a small group that includes dsinger
<jmayer> -1 on small group, at least without more progress
jchester: each IAB rising stars have different collection practices and are evolving
<jmayer> no more punting
<WileyS> +1 for separate group that includes JMayer - as I believe he already wrote the appropriate list in real-time at the beginning of this conversation.
<justin> as long as we retain the floor for corporate ownership/control for same partiness, I'll defer to the group --- can't be here at lunch tomorrow (dsinger, jmayer, npdoty)
<rvaneijk> aleecia: spent time tonight and meet tomorrow at lunch
<rvaneijk> WIleyS: do we need this seperate group, as there is support for jmayer's approach
<npdoty> "At a minimum, if there's no common corporate affiliation (or binding corporate rules or corporate family), common domain name or shared branding, then those entities are not the same party."
<ninjamarnau> I would like to add David's suggestion on liability and privacy practices
<rvaneijk> dsinger: in essence jmayer's test is a 'faillure test'
<ninjamarnau> okay my comment was the positive test
<karl> then we will go down the hell of definitions of "affiliation", "shared branding", etc.
Aleecia: Baseline agreement on Jonathan's test
... this is a fine floor, but there is additional work to do
<bryan> Can we ask that the small group also explain how the test will be used? As a test it may be reasonable, but how is it actionable?
<tlr> Strawpol: Use the following language as a floor as a set of tests:
<rvaneijk> aleecia: current test is a fine floor, but additional work to do
<npdoty> resolution: the quoted text above is a floor of tests that determine what isn't a single party (no objections)
<justin> To reiterate: my floor is corporate affiliation plus one of common domain name or common branding
<rvaneijk> WileyS: microsite example with it's own domainname but clear common branding but without common affiliations => 2 first parties
<npdoty> "Corporate affiliation is necessary but not sufficient for two entities to be a single party."
Aleecia: two parties with no corp affiliation can't be the same party
<rvaneijk> aleecia: half hour break
<npdoty> resolution: "Corporate affiliation is necessary but not sufficient for two entities to be a single party." <no objections>
<WileyS> jmayer - you've always been "that guy"
<trackbot> ISSUE-117 -- Terms: tracking v. cross-site tracking -- raised
<npdoty> coming back
<dsinger> scribenick: dsinger
aleecia: we start on 3rd party exceptions
<trackbot> ISSUE-49 -- Third party as first party - is a third party that collects data on behalf of the first party treated the same way as the first party? -- open
scribe: could do with some best practices text on point 4, maybe?
<Chapell> Aleecia: four tests
18.104.22.168.1 Normative Discussion
A third-party site may operate as a first-party site if all the following conditions hold:
the data collection, retention, and use, complies with at least the requirements for first-parties;
the data collected is available only to the first party, and the third party has no independent right to use the data;
the third party makes commitments to adhere to this standard in a form that is legally enforceable (directly or indirectly) by the first party, individual users, and regulators; data retention by the third party must not survive the end of this legal enforceability;
the third party undertakes reasonable technical precautions to prevent collecting data that could be correlated across first parties.
scribe: any objections?
WileyS: wants to improve point 2
jmayer: the way this works, it doesn't 'stack': you cannot take outsourced data and add on another exception
WileyS: we allow others to use, contractually, aggregated/anon data for specific, constrained uses and times
Meme: we allow common screen data, number of users on tablets, etc.
... purely aggregate, anonymous
<justin> Can we just say aggregate and avoid the poisonous term "anonymous"
<dsinger_> (thinks that anonymous/aggregate is a separate exception)
<ninjamarnau> the use of anonymous data isn't critical but the process of anonymisation. How do they do this. On which stage?
<jmayer> Current text: "A third party acting within the outsourcing exception, for example, may not make independent use of the data it has collected even though the use involves unidentifiable data."
aleecia: easier on summing after aggregation, than aggregate then summarize
<justin> +1 to what aleecia says
tl: shouldn't have the same exception for 3rd party and anon
wileyS: use anon and aggreg in combination
fielding: two specific texts: (3) should be 'consistent with adhering to the standard' (don't need to revise standards)
<npdoty> proposed change for 3: "the third party makes commitments that are consistent with adhering to this standard in a form that is legally enforceable (directly or indirectly) by the first party, individual users, and regulators; data retention by the third party must not survive the end of this legal enforceability;"
fielding: and on (4) prevent *retention* rather than collecting across 3rd parties
<jmayer> "consistent with the requirements of this standard"?
<jmayer> concerned "consistent with adhering to" is a little ambiguous
<npdoty> fielding, how do you feel about jmayer's text?
rigo: sharing and retention; you cannot immediately share and then not retain
<npdoty> agree that the proposed change is awkward or ambiguous
<karl> forgetful services
rigo: two aspects in the same phrase: do not retain
... defers to Roy for exact text
npdoty: should we examine all use of 'collect' and see if it should be 'retain'?
jmayer: not comfortable with changing 'collect' to 'retain'
<karl> all of these 22.214.171.124.1 is a MAY
<fielding> on part 4, replace "prevent collecting data" with "prevent storage or sharing data"
<rigo> the third party undertakes reasonable technical precautions to prevent retention or sharing of data that could be correlated across first parties.
jmayer: companies should not have their hands on info that can be correlated across sites
<rigo> aka siloing
<justin> karl, it's many ONLY IF
<justin> karl, may ONLY if (that is)
jmayer: in particular some web security primitives apply to this problem
... ok revising to clarify, wrt non-protocol info (not IP addresses etc.)
aleecia: we may need a 'best practices' section for this?
<karl> justin, still a MAY is optional. What happening if none of the all happens
aleecia: suggests jmayer writing the non-normative discussions, run past fielding
<scribe> ACTION: jmayer to write discussion on best practices for 126.96.36.199.1 [recorded in http://www.w3.org/2012/01/24-dnt-minutes.html#action02]
<trackbot> Created ACTION-47 - Write discussion on best practices for 188.8.131.52.1 [on Jonathan Mayer - due 2012-01-31].
<justin> karl, the default for a third-party is that they MUST NOT do anything unless certain sections come up. This provision is an exception to that otherwise rule.
bryan: doesn't understand, it's on behalf of the 1st party
<npdoty> point of agreement between jmayer and fielding seems to be that collection (but not retention) of protocol information might be fine as long as non-protocol data isn't collected at all
bryan: putting limits on the data seems un-nessacrily restrictive
<karl> maybe it is a question of reformulation of the MAY statement.
<justin> karl, complying with these provisions is certainly optional, but you would have to meet all the optional requirements in order to be treated as a first-party
schunter: e.g. use different cookies, silo the data
<npdoty> fielding, on 3. are you okay with "consistent with the requirements of this standard" which is the change I've just made?
bryan: 'could be correlated' is very broad set
aleecia: this seems to be a usability test of the document
... have you read the rest of the section?
<fielding> npdoty, not really, since there are a lot of requirements that are not relevant to us ... would prefer what I said "consistent with adhering to this standard"
karl: malformed conformance statement? could it be better phrased for compliance?
... it's a negative conformance statement
<rigo> +1 to karl makes the rules easier
karl: change from 'may operate' as.. to something less confusing?
bryan: thinks that 'product improvement' Should be allowed
<bryan> Acting as a 1st party requires abilities that conflict with the conditions, e.g. retention.
<bryan> "right to use the data" must include actions that the 3rd party takes to improve the service it provides to the 3rd party.
<bryan> "could be correlated across first parties" is too loose a requirement. Many non-PII items can be correlated, and methods of doing so are evolving all the time. This would severely limit the types of data that could be collected.
sean: seconds product improvement issue, we should be careful about excluding that
<npdoty> "consistent with the requirements of this standard" vs. "consistent with adhering to this standard" -- do these mean different things? /cc fielding, jmayer
sean: are they technical or operational precautions?
amyc: also shares point 4 production improv. concern
... on (3), say I have a contract with the provider, now...legally enforceable to the user and regulator?
rigo: concerned about this also, finds it unclear
tl: tries to read the mind of the author: we have screwyou analytics, and some 1st party example.com contracts with them. the analytics company now sells all the data, and example.com doesn't care. but the users and regulators DO care.
<justin> any public statement by screwyou would fix that
<fielding> npdoty, the commitments that we make are not protocol requirements -- they are behavioral limits on us. Hence, we have contractual commitments that are consistent with adhering to the standard even though they have nothing to do with the protocol requirements.
meme: agrees with the concern, but not sure what can be enforceable by parties, users, and regulators? would love to solve it,
dsinger: should be actionable by the user if the analytics company lies like this
shane: this creates legal complications; example.com now becomes legally liable for the analytics
<karl> hmmm "184.108.40.206 Exemption for Outsourcing"
tl: clarifies liability is on the THIRD party, not the first
rigo: wants the lawyers to get into a corner and achieve that effect
dsinger: why not leave it to the requirement that it's legally enforceable?
jm: we try to document the 'end state' that it's enforceable, and not state why
rigo: there is a loophole here. EU has a privacy law applying to everyone, but contracts are two-party
... you are inventing something to close that spot
<justin> I don't think we can require "legal enforceability" in the spec --- who knows what is legally enforceable in Zambia and Palau?
<npdoty> fielding, the commitments you make are consistent with the requirements in the Compliance spec, right?
rigo: one way to turn it around is to make the 1st party liable
aleecia: who would find it acceptable to put the liability on the 1st party?
jchester: this seems to back into the EU 'data controller' concept
aleecia: yes, but we felt that is too far for the group
rigo: this seems complex
<jmayer> Was there ever discussion of first party diligence in outsourcing to a third party?
<jmayer> E.g. if a first party has reason to believe a third party is sketchy, but does business with them anyways?
jimk: two situations, the USA doesn't have [so much] data protection concepts, the EU does. I don't see how I would NOT expect the 1st party to be involved
... you shoveled my data around, and I want to take you to court.
schunter: we seem to agree on goals, and the lawyers think they can improve the text
<fielding> npdoty, which requirements?
<rvaneijk> I will touch on issue14 tomorrow in a short presentation, addressing controller-processor and third parties
meme: doesn't know what is legally enforceable around the world; it might never be in some jurisdictions for all 3 parties
<scribe> ACTION: rigo to re-phrase 220.127.116.11.1 to re-draft (3) [recorded in http://www.w3.org/2012/01/24-dnt-minutes.html#action03]
<trackbot> Created ACTION-48 - Re-phrase 18.104.22.168.1 to re-draft (3) [on Rigo Wenning - due 2012-01-31].
aleecia: we note other lawyers agreed to help rigo
<justin> rigo, I already suggested language to meme
<efelten> scribenick: efelten
<npdoty> rigo will follow up with meme, amyc, jmayer on ACTION-48
dsinger: Don't know what point 4 is supposed to do. Previous points should rule out this possibility anyway--could never do this on behalf of a first party.
<dsinger> jmayer: can explain. (4) is intended to get at what the 3rd party has to do with the data while it is in its possession.
<scribe> scribenick: dsinger
<ShaneW> Proposal: "The third party undertakes reasonable precautions to prevent data correlation across first parties."
<tl> s/tl: can explain/jmayer: can explain
UNKNOWN_SPEAKER: (4) is the technical dual of rule (3). The 3rd party may have some information that could be used.
... technical siloing that goes beyond 'this belongs to A, this belongs to B'
<npdoty> ShaneW, you agreed with having a MUST requirement for technical siloing at Santa Clara, right? as long as we didn't specify what the technical measure was?
<meme> how did we (or did we) resolve the anonymous aggregated use of the data in 2?
<ShaneW> Correct - but in my mind, "technical" may manifest as a "technical operation" approach to maintain separation. Now the language feels like that wouldn't be supported.
aleecia: think that 3 and 4 should be separate.
<justin> meme, we haven't yet
<justin> meme, but aleecia proposed allowing the outsourcee to use aggregated data for each first-party buckey, and then you can combine the buckets, and I think that makes sense
jmayer: it is NOT siloing the two first parties separately, it is making it so that the 3rd party CANNOT ever later re-correlate
JC: operational as well as technical
... jmayer seems to be worried about govt agencies
jmayer: initially had technical and legal precautions; rogue employees, data breach, govt intrusion
<npdoty> oh wait, it was sean that said that jmayer was worried about govt access
<rvaneijk> Using the 3 elements of jmayer: in order to comply legally a company needs to take technical and organizational mearures
jmayer: we want to make sure the 3rd party gets it right
aleecia: suggests that we ask the editors to separate 3 and 4 from 1 and 2
ksmith: under the product improvement, it's difficult for the 3rd party to fix bugs if they cannot see the data
bryan: doesn't understand how it can affect the capability of sites that don't have integrated advertising, as opposed to those that do
... seems to create a non-level field for outsourced advertising
<bryan> The basic problem with this section is that it will inordinately affect the capabilities of 1st parties without integrated advertising (and who thus depend upon 3rd party Ad networks), as compared to 1st parties with integrated advertising. Why should the requirements be any different, if the objective is to protect the user from unwanted tracking based upon cross-site sharing of info?
rigo: 1 and 2 express everything, and 3 and 4 are supporting
... implementation details to fulfill 1 and 2
<fwagner> in some cases correlation of the data is part of the service - re-targeting ?
<npdoty> bryan: "unlevel situation" between 3rd-party advertisers and large 1st parties that do their own advertising
<karl> 3 options in Google about Data Sharing http://support.google.com/analytics/bin/answer.py?hl=en&answer=1011397
<karl> for analytics
wileyS: on (4) I believe that is overly prescriptive, and there are operational approaches to keep data separate. e.g. some companies scrub within a week such that users are no longer identifiable, but not at the moment of collection. The data analysis services may need it, and you need to be crash-proof. there are also the bug tracing problems
... is it a user-specific or environmental issue?
<bryan> +1 to Shane's suggestion of focusing on cross-site sharing, rather than collection/retention of data by 3rd parties
wileyS: even after considering all the issues and doing the right things, things can go wrong
<ShaneW> "The third party undertakes reasonable precautions to prevent data correlation across first parties."
<karl> could we remove reasonable
<meme> justin, seems that even aleecia's suggestion isn't allowed as written
wileys: still concerned about debugging
<justin> meme, you are correct, and I think we need to get back to the text and revise it, but we got off on this topic
aleecia: if we go down this path of allowing the 3rd some use (e.g. debugging) we should write it down and balance the case against the risks
<scribe> ACTION: wileys to propose what the operational carve-outs for 22.214.171.124.1 (e.g. debugging by 3rd party) are [recorded in http://www.w3.org/2012/01/24-dnt-minutes.html#action04]
<trackbot> Sorry, couldn't find user - wileys
<npdoty> ACTION: wiley to propose what the operational carve-outs for 126.96.36.199.1 (e.g. debugging by 3rd party) are [recorded in http://www.w3.org/2012/01/24-dnt-minutes.html#action05]
<trackbot> Created ACTION-49 - Propose what the operational carve-outs for 188.8.131.52.1 (e.g. debugging by 3rd party) are [on Shane Wiley - due 2012-01-31].
jmayer: we're looking for text to critique and work on, not agree (agreed)
<karl> "undertakes reasonable precautions" is not applicable.
jmayer: one conversation has been "we have these needs, some proportion of users will have DNT enabled; those that don't still enable you to debug, don't they?"
<schunter> meme: With the no-retention rule, the DNT is easy to distinghuish from the massive data since the massive data will not contain DNT data.
wileys: agrees with Jonathan, some of this applies whether DNT is on or off. what the % is doesn't matter. there are operational purposes (e.g. masking fraud), just as for the 1st party.
<ksmith> schunter: not once it is aggregated
<trackbot> ISSUE-22 -- Still have "operational use" of data (auditing of where ads are shown, impression tracking, etc.) -- raised
aleecia: we move to issue 22
<ninjamarnau> I would be interested in what frequency/importance we talk about for this "cross-site debugging"
(exemption for operational use of data)
scribe: 5 things have been proposed (184.108.40.206.1). we need detail
wileys: introduces this text, and notes there is a (6) coming
<rigo> seeing the 5 exceptions, I wonder about the delta to the current situation
WileyS: Aggregated reporting might be written as "aggregated and anonymous" if the group prefers
... Need a flexible exception for security so bad guys can't hide by turning on DNT.
... new, 6th point is research. Needs to be appropriately scoped so it isn't too broad.
<bryan> +1 on the need to do research and market analytics on aggregated/anonymous data
WileyS: Purpose of research is insight into user population in aggregate, not (e.g.) redlining.
aleecia: How is this different from point 3?
WileyS: Some research could be non-aggregate, e.g. how users switch between desktop and mobile
... Research is for public benefit
jchester: We need specific language for this.
<npdoty> would it be shorter to say the cases where data can't be collected under DNT?
<bryan> there are many distinct service domains where generic web analytics and standards are inadequate and need to be supplemented by analytics
aleecia: Is this the right list of 5/6 points? Need more? Drop some?
... Does this cover every part of operational use that we want to include?
amyc: Should include product improvement?
fielding: Does point 2 include referral tracking?
WileyS: Assumed it would include typical http log data, which would include referrer
<ShaneW> + Debugging (which could be an easier path than "Product Improvement")
sean: Add sequential ad rotation (i.e. showing a set of ads in pre-planned sequence)?
bryan: How can this list be future-proof? How to add new ideas as they develop?
... Aggregate, anonymous data should be off the table.
dsinger: Aggregate, anonymous is already covered -- this list is mostly for non-aggregate, non-anonymous.
<dsinger> (see 220.127.116.11 -- still to be written)
<npdoty> 18.104.22.168 is "Exemption for unidentifiable data"
jchester: What about real-time bidding?
<justin> Industry has already agreed that collection and use must meet one of a few enumerated buckets as part of the DAA definition.
WileyS: Challenge is how to allow RTB, with third parties closely involved, while maintaining DNT compliance.
<bryan> I don't see that the enumeration of allowed exceptions can be definitive, we will always find that we left something important out or did not clearly include something in how the exceptions were expressed. As long as aggregated/anonymous data is used, why should there be any problem with any operational use?
sean: Couldn't do RTB based on user profile under DNT anyway.
fwagner: Not sure point 3 covers analytics clearly.
(some confused chatter)
<sean> In a DNT setting the user profile would not be allowed to be used (and the user would not be allowed to be added to a data segment). Any rtb setting would have to let buyers bid on the impression without any specific user information (page context, etc)
<KevinT> RTB/DNT reference: OpenRTB spec has placeholder for DNT (http://code.google.com/p/openrtb/) see v 2.0
dsinger: Should separate aggregated/anonymous data from the exceptions that apply to fully or partially identifiable/linkable data.
johnsimpson: Have been skeptical about whether any exceptions should exist at all
... Would be easier to persuade me if there are short limits on retention
<ShaneW> Data Retention is a much broader discussion and should be addressed separately (but absolutely agree it should be addressed)
aleecia: Any objections to these points--are any of these unsalvageable?
... don't speak up if these are flawed but fixable
rvaneijk: Is this MUST, MAY? How prescriptive?
aleecia: Let's defer that
mzaneis: Is there a way to amend the standard later to incorporate new practices?
aleecia: standards can be versioned, things can change in version 2
... Call for objections to each specific item (is it bad and unfixable)
No objections to 1 or 2
aleecia: Group wants to take out aggregate-data point, as covered elsewhere
tl: How do financial logging and 3rd party auditing differ?
sean: There are differences, it's clearer to specify them separately
WileyS: Companies like DoubleVerify illustrate the difference
aleecia: Set aside research for now, pending more specific text
jchester: Object to product improvement point
<karl> I do not understand "Frequency capping" or more exactly I understand it as an escape for serving diverse ads to users. What are the financial implications for the ads network?
aleecia: no objection to ad sequencing nor debugging
... Let's focus on frequency capping now
<npdoty> just to clarify, this "no objection" is the style of "no way this could be addressed in the spec"
<karl> dsinger, why should they remember that?
tl: Current text doesn't have any minimization aspect. Q to advertisers: can you use per-ad cookies?
justin: Minimization language is already there.
WileyS: per-ad cookies for frequency capping requires too many cookies, or too-large cookies
... not feasible today
... more feasible to use unique IDs for this process
<schunter> \ack tl
tl: Is sequential rotation very similar to frequency capping?
<jmayer> If sequential rotation includes targeting, then it's more like retargeting.
jchester: To the extent DNT is enabled, how can frequency capping be done? How to balance against user desire not to have actions correlated across sites?
WileyS: Essentially keep a mini-profile that is only used to do the counting for frequency-capping.
sean: agree with WileyS
<scribe> ACTION: WileyS to produce text clarifying implementation of frequency capping and seq ad rotation, with use cases [recorded in http://www.w3.org/2012/01/24-dnt-minutes.html#action06]
<trackbot> Sorry, couldn't find user - WileyS
<npdoty> ACTION: Wiley to produce text clarifying implementation of frequency capping and seq ad rotation, with use cases [recorded in http://www.w3.org/2012/01/24-dnt-minutes.html#action07]
<trackbot> Created ACTION-50 - Produce text clarifying implementation of frequency capping and seq ad rotation, with use cases [on Shane Wiley - due 2012-01-31].
<schunter> Goal (as far as I understood): Data stored can only associate the frequency count with a specific user agent. No other information can be associated.
WileyS: Sequential advertising means showing you a specific sequence of ads to a user, in order -- keeping the "plot" in the right order
aleecia: More comments on frequency capping?
ninjamarnau: Quite critical of cookies with unique IDs. Can live with 24-hour lifetime, otherwise would oppose it. If must show DNT user repetitive ads, so be it.
WileyS: Frequency capping improves user experience
... users might turn off DNT if annoyed by repeated ads
tl: Frequency capping data can be interest-based, if some of the ad impressions were contextual.
... Fact of having seen ad X conveys fact that user was on site Y
WileyS: True, but that's corner case, would be very rare in practice
dsinger: Not sure that's true. If ads are targeted well, list of ads you have seen implies your interests.
<dsinger> but you cannot use that database of 'ads shown' as a way of targeting, of course
dsinger: As a safeguard, must be clear that you can't use the frequency-capping data to target anything, etc.
aleecia: How often do users actually hit the frequency cap?
WileyS: Many users don't. But heavy users will see the most common ads repeatedly and will likely hit the cap.
karl: Agree with tl. Don't understand why frequency capping is needed.
... It's creepy to see sequential ads after disabling DNT.
... Don't see the need for frequency capping, would rather see repeated ads.
WileyS: Advertisers will pay less for ads without frequency cap. Users are annoyed by repeated ads. Site gets less revenue. Lose-lose-lose.
karl: Question to WileyS: Why do you need frequency capping?
<ninjamarnau_> sorry if I repost this, but I lost connection to IRC: I understand the aim of frequency capping. I just want to know if you could do this in a less invasivway than a long-living cookie with unique identifier
sean: Most users will encounter freq cap at some point.
... Business model is aimed to advertiser who wants prominent (e.g.) home page ad, pay premium for that level of visibility
... Benefit to advertiser and brand impression rely on not showing ad to the same user too often
... Not willing to pay top price for repeated impressions
... For publisher, significant revenue comes from those premium impressions
<schunter> Premium CPS pays around 40$ (masthead, high profile site, ...) while low CPS is around 1$
aleecia: What about ninjamarnau's suggestion to limit lifetime of frequency capping cookie? Would that enable sean's business model scenario?
WileyS: Most campaigns would be unaffected by 6-8 week lifetime, some are as long as 90 days
aleecia: Why not limit retention to lifetime of campaign?
WileyS: That's likely practical, given some extra time to carry out the necessary operations.
<schunter> Yahoo would be OK with limiting retention (for frequency capping) to the lenght of the campain bu tnot more than a fixed time (say 90 days).
WileyS: might need to keep data longer for other exception-purposes, such as security
aleecia: Slightly more complicated if you're using the same cookie for multiple campaigns that have different lifespans.
WileyS: Some implementation challenges here...
tl: Could you scrub out data about a campaign when it's over? Change identifiers in an unlinkable way?
(crosstalk, seems to be some agreement with tl)
jchester: Bottom line question: What is collected about the user in this scenario?
... need to articulate the limitations in this scenario
<sean> i would like to withdraw sequential creative rotation as an exception. i agree with karl dubost on this one now.
<rvaneijk> WileyS: addresses purpose limitation
WileyS: In this context, only permissible use is to count and check frequency caps.
aleecia: Take additional discussion offline.
... Karl, could you live with this if there is a time limit?
karl: Yes, if the details are right.
jmayer: Don't think we would create this exception if there weren't already a business practice here.
... Many of the threat models I and others worry about stem from the existence of unique IDs plus database of user actions across websites.
... even if companies are well-intentioned
... Exceptions like this cause companies to place tracking cookies, making it hard for users to check whether companies are complying
<ShaneW> JMayer - you state that the "reason we are here" is to "prohibit the collection of data" with DNT - I would argue many in the room don't agree that is the "reason we are here".
<npdoty> <my paraphrase>: creation of a unique id passed around from the browser is always an issue that I would be skeptical of; the harm is in the collection (even if unintentional) and possession of profiles of browsing histories across sites, not their use
jmayer: Worry that companies will mess up and data will end up getting used for purposes outside the standard
<karl> the risks of screwing up and cross-sites makes it indeed a no go. I might change my "yes" in a "no"
jmayer: Don't see time limits as resolving the problem. Difficult for client to verify, easy for site to mess up and retain too much
... Companies here are capable of getting this right, but others maybe not
... Researchers have shown this can work with client-side storage. An ad network out there (Mochi Media) is using our technology.
tlr: Remember that all of this is under a data minimization framework.
... so if practical ways to do (e.g.) frequency capping without unique IDs become clearly available, companies' obligations would change
<schunter> This implies SHOULD language.
tlr: jmayer may be describing the future; WileyS and sean are describing the present
<rigo> Ninja said one day, Shane said 90 days. Aleecia said 7 days without getting a response
aleecia: jmayer, would (say) a 90-day timeout address your concern?
jmayer: First, they would have to make the cookie-IDs actually unlinkable between generations. Anyway, reduces but does not eliminate the problem.
jchester: Can live with counting-only use. Want to see specific text.
<rigo> I think there should be some merit to opt-back in. If everything works with DNt=1 there is no incentive to work on "opt-back-in"
<schunter> Once you set a cookie with a persistent ID, then restoring privacy (in case a party may disbehave) is hard.
justin: Agree with jchester. Question to ad networks: For frequency capping, is it enough to remember how many times each ad was seen, and referer?
<karl> the more exceptions the more difficult it will be to implement.
WileyS: Cap is on an ad across all sites, don't need to log where the user saw the ad. (But that comes up for another exception.)
sean: In reply to karl, agree that sequential rotation is contrary to spirit of DNT and should not be an exception.
<ninjamarnau_> regardless of the life span of the cookie, it violates the ePrivacy Directive without consent
aleecia: Sense of the room? Is freq capping fundamentally inconsistent with DNT, or is it a business practice that we should accomodate?
... Pretty even split, slightly heavier on should-accomodate.
... Having specific text would help. Volunteer to write text?
<scribe> ACTION: WileyS to Propose specific text for frequency capping exception, including extended discussion. [recorded in http://www.w3.org/2012/01/24-dnt-minutes.html#action08]
<trackbot> Sorry, couldn't find user - WileyS
<npdoty> ACTION: Wiley to Propose specific text for frequency capping exception, including extended discussion. [recorded in http://www.w3.org/2012/01/24-dnt-minutes.html#action09]
<trackbot> Created ACTION-51 - Propose specific text for frequency capping exception, including extended discussion. [on Shane Wiley - due 2012-01-31].
schunter: How much does this discussion have in common with the other exceptions? Is there some general text that would help?
... Can we say that sites should avoid using unique IDs where that's reasonably practical?
WileyS: Yes, we should agree to do that.
bryan: Can we say that data collected for one of these exceptions shouldn't be used for other purposes?
aleecia: Already have that, perhaps could be clearer.
<rvaneijk> ShaneW addressed purposed limitation
aleecia: Out of time today. Lots of fruitful discussion, would like to see more issues closed.
(lots of talk about food)
<dsinger> at 7:30
<npdoty> trackbot, end meeting