See also: IRC log
<aleecia> Review of action items: http://www.w3.org/2011/tracking-protection/track/
<tl> thank you, was that that so hard zakim?
<tl> zakim aaee is jsimpson
aleecia: Comments on last week's minutes?
No comments, take minutes as approved
aleecia: If you're drafting text, by end of today please send to those editing the text
aleecia: quick look through action items
... start with action 26; Karl not on call; 26 is overdue
... action 27, is that open?
tl: 27 is pending review; Tom trying to synthesize with Jonathan's work; will circle back
... can do by Friday
aleecia: action 31, shane et al
WileyS: have draft text, well thought through, will post today with some issues still open
aleecia: action 34, first party vs third party, Jonathan and Tom working together, related to previous
... action 37, Karl not on phone
... done with open actions
aleecia: look at text drafted by editors
<tl> sorry, action 27 is complete, action 34 is the current open action with jmayer
aleecia: start with definition of user
<hwest> I believe that I'm on the hook to help draft something about identity providers, but I don't see an action item - where do I find that?
aleecia: [reads definition]
<KevinT> Zakim Joanne is KevinT
aleecia: text is coming from other related W3C specs, or other docs seen previously on mailing list
<jmayer> tl, action 27 is not complete, nice try
<enewland> we used http://www.w3.org/2003/glossary/alpha/U/20 as a starting point
<enewland> for the definitions of user and user agent
<aleecia> thank you, erica
<jmayer> suggest marking this as pending review
WileyS: on defn of user, will be difficult for some of us to evaluate without knowing more about how used later in documents; might need to return to defns later as uses develop
<fielding> user agent is already defined in the TPE document
<tl> jmayer, action 27 was sent to the list, reviewed, and turned into the new and shiny action 34 for both of us
<justin> We should probably reconcile those . . .
aleecia: to re-open, need to have new information (could include interactions with new text elsewhere), also need proposed alternative
... Shane's suggestion seems consistent with this
<WileyS> link to the text?
aleecia: Any issues with defn of user?
<justin> Here is how it's defined in the other spec: This specification uses the term user agent to refer to any of the various client programs capable of initiating HTTP requests, including browsers, spiders (web-based robots), command-line tools, native applications, and mobile apps [HTTP11].
<WileyS> thank you
aleecia: This seems staightforward and is based on past W3C docs
bryan: Group of individuals acting as an entity. Would that include an enterprise / company?
<jmayer> rescind suggestion of pending review, closed sounds right
aleecia: Text could be read either way
<tl> yes, corporations are people!
bryan: Defn anticipates broad understanding of what a group is?
<dsinger> I think the definition applies, yes. Do we want it to?
<WileyS> What is the value of the "user" definition versus a "user agent"?
aleecia: apparently yes
... should flag this for clarification
fielding: unnecesarily complicating things; why not simple definition, user = person making request
<WileyS> Agree with Roy - User Agent is more important than "User"
aleecia: think we do need a defn of user
jmayer: agree with Roy, can simplify this
<tl> WileyS, user agents should do things for users, like deciding to send dnt only after the user has made it clear that's what they want
jmayer: propose that user should be only an individual person, not a group
<fielding> what requirements are applied to "user"?
<amyc> on IRC, but unable to dial in to conf call
<jmayer> suggestion: "User: An individual person."
<WileyS> Would a user agent be able to do anything on its own? Outside of direction from the user?
ninjamarnau: question about "on whose behalf ..." language. Covers e.g. mother accessing on behalf of children?
aleecia: if mother and child acting together, would be covered
... Do Ninja and Jonathan have different views?
<rvaneijk> Why not dropping 'acting as a single entity'
aleecia: mother is doing access so is user, less clear about child
ninjamarnau: this might be a misunderstanding
<tl> WileyS, i think we expect UAs to take care of all the tedious busy-work, leaving users free to enjoy the wind in their hair on the information highway
WileyS: ref email discussion with Jonathan
... not clear on where there is value in treating user separately from user agent
... seems redundant to have separate definitions, complicates text
... not sure why user is needed, why not just user agent
<fielding> for example, a browser user agent sometimes has profiles for multiple users, one of whom uses it at a time
aleecia: user agent is software, like browser. user is a person
<WileyS> one example please
aleecia: think we will need to distinguish them, can merge them if that turns out not to happen
<tl> WileyS, UA manages site-specific preferences on user's behalf
dsinger: see major diff between user and user agent. user is who we are trying to protect, user agent is software which doesn't have a privacy interest in itself
<ninjamarnau> thanks dsinger, this was the differnce I was referringt to
dsinger: mistake to write in passive voice here?
aleecia: others have used separate defns, but we can do otherwise if it makes sense to us
<WileyS> "An individual human" +1
aleecia: Is the suggestion to drop language about groups?
<WileyS> User Proxy should be defined separetely
<fielding> I prefer the CC/PP definition … "An individual or group of individuals acting as a single entity. The user is further qualified as an entity who uses a device to request content and/or resource from a server."
<bryan_> +1 to dropping "group of individuals" and "on behalf of"
<jmayer> agree with shane
<tl> WileyS, +1
dsinger: No. My concern is that "on behalf" language. Why not define more directly: individual, or group acting as an entity, who accesses a service
<dsriedel> Maybe this phrase just tries to acknowledge that a service might not be able to disinguish if the request comes from an individual enity or another network. More of a technical thing.
jmayer: Would drop "who accesses a service" language.
... probably will be covered by discussion elsewhere in spec
bryan: Definitely see distinction between user and user agent
... important to treat actions of user agent done on user's behalf as if they were done by the user
<aleecia> the user accesses or is accessed on behalf of the user?
<dsinger> got it. agree
aleecia: Might be good to avoid trying to distinguish between what user does and what browser does
<rvaneijk> wikipedia: A user is an agent, either a human agent (end-user) or software agent, who uses a computer or network service.
aleecia: Can we come up with text that does what we seem to want here?
<WileyS> wikipedia, +1
fielding: Typically talk in terms of activities initiated by the user; these might involve several steps done by the user agent
<fielding> An individual or group of individuals acting as a single entity. The user is further qualified as an entity who uses a device to request content and/or resource from a server.
fielding: pasted in text to IRC about this
<dsriedel> Wouldn´t it be easier to drop user completely and just referr to user-agent as this is the entity DNT works on/is implemented?
fielding: agree with dsinger, get rid of "on behalf of"
<aleecia> An individual or group of individuals acting as a single entity. The user is further qualified as an entity who uses a device to request content and/or resource from a server.
aleecia: Anybody want to argue for "on behalf of"?
<fielding> that's from the glossary for CC/PP
aleecia: glossary definition here seems pretty good
... group of individuals understood as including a company
... not sure we need "from a server", might be too specific/restrictive
<dsinger> we can add "including access actions by the user-agent on behalf of the user", if we want to be clear...
aleecia: Any suggestions on this text?
<rvaneijk> suggestion: replace from a servwer with: who uses a computer or network service.
<aleecia> sounds like an argument back for "on behalf of"
jmayer: Defn seems to require some state of mind of the user, or some knowledge
<fielding> fine with me to remove the second sentence
jmayer: but need to protect user even when technology is doing something the user wants, but doing it automatically
<aleecia> J: try some text?
jmayer: can break this down into a set of binary choices
... suggest starting simple, adding extra stuff only as needed
aleecia: jmayer, can you suggest specific text?
<WileyS> Roy, +1
bryan: Don't need to talk about user agent privacy concerns separate from the user's privacy concerns
<WileyS> Disagree with Aleccia (sorry :-( )
<bryan_> CC/PP had that language because it was addressing user-agent capabilities as something distinct from the user, but such a distinction does not exist for privacy concerns
aleecia: Move on, will circle back to this
<jmayer> Suggested: "An individual person." Open issues: 1) users acting on behalf of other users, 2) users acting as a group, 3) qualifiers on types of behavior (network interaction, device usage, mental state)
aleecia: discuss defn of "user agent"
<aleecia> A "user agent" retrieves, accesses, and/or renders, content or services on behalf of the user. Examples of user agents include browsers, plug-ins for a particular media type, and assistive technologies.
<fielding> An individual or group of individuals acting as a single entity to initiate requests on the Web?
aleecia: pasted text into IRC
<tl> also: robots
aleecia: seeing no suggestions, let's go back to "user"
... Jonathan suggested "An individual person", full stop
<WileyS> I'm fine with "an individual human or person"
bryan: has to be an individual person using this service
<WileyS> dogs have no privacy rights :-)
<eberkower> Why not just "an individual"?
tl: should say "human" rather than "person" since person might have unintended legal consequences
<eberkower> yes - a corporation can be a legal person
<dsinger> "An individual who accesses a service (who has the ability to express a legitimate desire for privacy)"??
<bryan_> boo hiss
WileyS: sometimes a corporate entity qualifies as a legal person, agree with Tom that we should use "human"
<tl> also: we disenfranchise robots
<ninjamarnau> why not "an individual" ?
<tl> and aliens
<jmayer> "An individual human or equivalent conscious entity."
<aleecia> an individual who access a service
aleecia: How about "an individual who accesses a service"?
<ksmith> There are several individual's working here whose human status I question:-D
<aleecia> (or on behalf of whom an service is accessed?)
<dsriedel> +1 to jmayer definition. Other details can be added to the definition of "user-agent", like accessing (et al.) a service
<jmayer> sidstamm raises the important issue of zombies
jmayer: Important not to put limitations on which people are covered, at least until we know that limitations won't have complicated consequences
aleecia: Don't want to parse apart different groups of people based on ability, age, etc
... Does this really have to be so complicated?
<dsinger> I agree to take a place-holder and refer to PSIG; too many legal nuances come up
WileyS: propose that we use "an individual human" for now, consider it as quasi-closed, and come back to it later
aleecia: Don't see full consensus now
... What is starting point for text? Language in draft; language from Roy.
... Questions: need "on behalf of"? need to cover groups?
... Those who care strongly, if any, should go off and talk about this, make a joint proposal
<ninjamarnau> I would be interested
<tl> pick me!
<tl> i am always serious
aleecia: ninjamarnau, bryan, tl have volunteered
<fielding> At some point we should decide whether it is okay to keep track of the ISP/Company that accessed a service even if DNT indicates the "user" is not tracked.
<tl> [except about the robots/aliens thing]
<ninjamarnau> okay, deadline?
aleecia: Ninja to take lead, work with bryan and tl, propose language back to the full group
<aleecia> ACTION: ninjamarnau to draft user defn language due next week [recorded in http://www.w3.org/2011/12/14-dnt-minutes.html#action01]
<trackbot> Sorry, couldn't find user - ninjamarnau
aleecia: Please do within one week
... Return to "user agent"
<tl> ACTION: ninja to draft user defn language due next wee [recorded in http://www.w3.org/2011/12/14-dnt-minutes.html#action02]
<trackbot> Created ACTION-40 - Draft user defn language due next wee [on Ninja Marnau - due 2011-12-21].
<WileyS> "including, but not limited to, "
aleecia: Objections? (with alternative)
<justin> The issue fielding brings up can be addressed within the exceptions
<aleecia> A "user agent" retrieves, accesses, and/or renders, content or services on behalf of the user. Examples of user agents include browsers, plug-ins for a particular media type, and assistive technologies.
fielding: Prefer to use definition already in the TPE document, which has been through years of standards review
tl: agree with fielding
<fielding> TPE says This specification uses the term user agent to refer to any of the various client programs capable of initiating HTTP requests, including browsers, spiders (web-based robots), command-line tools, native applications, and mobile apps [HTTP11].
Frankie: Should list of examples include smartphone apps?
aleecia: [reads defn from TPE document]
<Frankie> right +1
<WileyS> +1 for TPE definition
<jmayer> looks good
<jmayer> int rollover
aleecia: Differences: TPE defn drops language about rendering, accessing; seems to be fine
... Consensus on the TPE definition?
<tl> yay consensus!
aleecia: Nobody objecting, we have consensus to use the definition in the TPE
dsinger: Friendly amendment: change "including" to "including, but not limited to,"
aleecia: Nobody has objected to amendment, so have consensus to adopt it
... Closing definition of "user agent"
<WileyS> No issues with User Agent - just User
aleecia: Move on to issues 19 and 91
... issue 19: data collection and data use from third party [reads suggested text]
<justin> If the operator of a third-party domain receives a communication to which a [DNT-ON] header is attached: that operator must not collect, retain, or use information related to that communication outside of the explicitly expressed exceptions as defined within this standard; that operator must not use information about previous communications in which the operator was a third party, outside of the explicitly expressed exceptions as defined within this stan
<justin> [must not or should not] retain information about previous communications in which the operator was a third party, outside of the explicitly expressed exceptions as defined within this standard (second half)
WileyS: In email, asked to remove "retain"
... want to separate handling of previously collected data from how to treat new data
<jmayer> this text is very clear in its treatment of historical data
WileyS: otherwise generally happy now that exceptions are mentioned explicitly in core definition
<WileyS> Agree David - will address in exceptions
<WileyS> Operational Purposes
dwainberg: "use" is extremely broad, hope we will address this in exceptions
<bryan_> believe that "use" includes "retain"
dwainberg: think that requirement to delete previously collected data would go too far
<justin> Is there an example outside of the exceptions that we're going to enumerate?
<WileyS> Agree with David
dwainberg: can be legitimate to retain old data in some cases
aleecia: use case?
<ninjamarnau> this will be addressed by issue 71, I guess
dwainberg: If user engages DNT for limited time, e.g. for one session, but then wants to switch back to DNT-off
<bryan_> DNT should work like privacy mode in browsers - turning it on does not clear all history
dwainberg: user might want old data to be held and used after DNT is turned back off at the end
aleecia: Let's look at existing adopters of DNT.
<amyc> will have Issue 71 draft to Ninja tomorrow, which addresses issue
<WileyS> Holding out AP as a solo example isn't very helpful - too early and its directional of industry concerns
aleecia: Some worried that user might turn on DNT for five minutes, force provider to throw away five years of data
... (example is AP)
<dsinger> I think the definition is clear about data *connected with the communication on which DNT-ON is present*, only, isn't it?
aleecia: AP initially kept the old data
<amyc> agree with dsinger, DNT signal is granular
aleecia: Turned out to be a PR problem, because users were worried when they saw tracking cookies persisting even when DNT was on
<WileyS> Did they delete logs that were tied to financial activities?
<WileyS> Should be a "May" - not should or must
aleecia: Could take this as SHOULD, MUST, best practice, or not mention at all
... Shane asks about data tied to financial activities, but don't think that's relevant for this
<dwainberg> adding to Shane's point -- auditable logs of served ad impressions may need to be retained
tl: Have concern about "in which the operator was a third party" in second part. Why limit it to case where operator was third party?
<ninjamarnau> agree with tl
aleecia: Let's defer that, take it up at end of discussion of this issue today
<hwest> +1, I like jmayer's proposal - very similar to what I would suggest
jmayer: Want to suggest a middle ground: can keep old data, but only in a way that can't be associated with a specific user
<justin> The Facebook example was the reason for the language, tl --- if you're customizing content based on first-party data, that's not really tracking as we've discussed.
<aleecia> session based for DNT or not: that seems the crux of this
<jmayer> i agree with tl on 2
<jmayer> justin, if we decide to do that, it should be an explicit exception
<dsinger> agree with the speaker; 'treat me as someone about whom you remember nothing and record nothing" -- that doesn't say you *delete* old data, you just ignore it for a while
<jmayer> don't pack it into the high-level definition
ksmith: Have always thought of DNT as session-based, should mean "don't recognize this individual now", no implications for other sessions
<vincent> jmayer, even if data can not be associated to a specific user it could still be associated wieth a specific user-agent (i.e. browser) and that would be ok
ksmith: PR issue in AP case shouldn't influence us, that's up to each company
<jmayer> vincent, i would say both, good point
WileyS: Want to manage retention/deletion issue outside of this definition
<justin> I don't feel terribly strong either way, but it seems like DNT is about collection and use of third-party data ---- I don't see why we would not try to encompass first-party data as well.
WileyS: Have operational need to prove that ad impressions actually happened
... Will need some other operational-driven exceptions
<jmayer> when facebook reads your facebook.com cookies as a third party
<jmayer> that falls into (1)
WileyS: Except for these cases, would agree with MAY or SHOULD not retain
... Don't want to go all the way to MUST
<jmayer> in fact, i could do without (2)
aleecia: There is discussion in Europe about consent applying only to new data collected
... requirements may differ between Europe and US
<bryan_> DNT should work like privacy mode in browsers - turning it on does not clear all history - this could cause real problems for users that lose all personalization mistakenly. if we really need a clear history action, it should be explicit, and operator compliance based upon best effort (some info is not technically feasible to forget).
aleecia: setting aside "eraser" proposals
<justin> If someone turns on DNT, they're not going to want tailored ads based on historical x-site data. I'm ambivalent on actual deletion, but usage should be within scope.
<jmayer> to the extent a company can use old data in personalizing to a user, that has to be explicit in an exception anyways
bryan: Should work like privacy mode in browsers. Active when it's turned on. More like privacy mode than like delete-all-history.
<jmayer> because we have to say the new data can be used to link up old data
bryan: Deleting more would hurt user experience for users who want to toggle DNT on and off over time
<rvaneijk> EU context: consent is for new data collection.
hwest: Retrospective deletion would require extra tracking in order to comply
<jmayer> could add language here like "make reasonable efforts" to cover cases where deletion isn't possible
hwest: agree with last several speakers
... should be okay to keep data if severed from that user's profile
<fielding> +1 to what hwest said
<Zakim> dsinger, you wanted to say that we need to be clear it's about *use* of historical data, not deletion
dsinger: definition is fine, but would be clearer to say you shouldn't *use* historical data when DNT is on
<vincent> if a user has DNT + InPrivate mode then only his current session will not be tracked, if user has DNT only then it means that he asks to be forgotten, would that be ok?
<WileyS> Agree with David - use application (not a "retention" application)
dsinger: but shouldn't require retrospective deletion
ksmith: Difficult in practice to purge old data based on DNT hit
... much more practical to avoid using old data while DNT is on
... also worry about race conditions if, e.g., see the same logged-in user on different browsers that send different DNT signals
... would cause bad user experience
<fielding> No server/collector that I know of would implement a "forget me purge" without a complete form-based specific request with anti-forgery protections.
aleecia: Not clear on why this would be a problem
ksmith: Could make it work, but would provide strange user experience
... consider same user at work and home, where work has DNT-on policy, but DNT-off at home
<WileyS> Ninja + 1
ninjamarnau: When user sends DNT on, operator should not combine new data with existing data about that user.
... Do we have agreement on this?
<Frankie> +1 Ninja
<WileyS> (+1 Ninja) Again, "use" application, not a "retention" application
aleecia: Comments re Ninja's proposal?
<Zakim> bryan_, you wanted to point out that DNT does not mean "do not personalize"
bryan: Need to be careful not to rule out all personalization when DNT is on
... suppose user has told site to provide high-contrast viewing
<ksmith> lets not claim to know exactly what the user expects
bryan: I see tracking as "don't remember what I'm doing" but not "don't personalize"
aleecia: Let's set this aside until Ninja suggests specific text
jmayer: Reasoning about this starts with the general definition which says don't use unless exception
... so question is whether there should be an exception for this
aleecia: Pop the stack, return to third point in proposed language
<ninjamarnau> I think if we say MUST not use, then associating with old data is also "use"
WileyS: If drop concept of retention, just talk about "collect or use", would block use of old information too
<jmayer> agree with shane that, unless an exception explicitly allows it, the current text already prevents use of historical data
<jmayer> don't agree on retain
WileyS: dropping "retain" could get us to consensus, or close to it, can come back to retention questions later
... propose to drop retain and leave that as new open issue
tl: Setting aside whether "retain" requires deletion of old data, current definition says server shouldn't remember current access, nor use old info about same user
<bryan_> Talk about "breaking the web"!
tl: principle is you should act like you don't recognize the user
<bryan_> we need a much narrower definition of DNT intent
aleecia: Have some good standards language here, but not much about the intent of the language
<dsinger> I assume if the user chooses to also send a cookie that expresses a preference, the service is welcome to act on it *in that transaction*, but (as usual) not remember anything
aleecia: Tom, can you suggest specific language about the intent?
<Zakim> bryan_, you wanted to point out that "we need a much narrower definition of DNT intent"
<justin> Exceptions for volume controls and comparable settings can be carved out as an exception, but I'm not entirely sure of how many people set these settings on a third-party basis!
bryan: Need a much narrower definition of the intent. If turn off recognition of the user, would break the web
<WileyS> Capture these in exceptions
<jmayer> completely agree, shane
bryan: Should allow personalization
<tl> when a user turns on DNT, they expect that the service will treat them like someone about whom they know nothing, and not remember anything about the current interaction going forward
aleecia: Think we can all agree that DNT means user is expressing a preference for privacy
... Want to hear more about how to reconcile that with personalization
... in a third-party setting
bryan: Am talking about personalization primarily by first parties
<fielding> I think most of the comments so far have confused parties
<tl> [in the third party context, of course]
aleecia: Expectation is that first parties will have relatively few obligations under DNT
dsinger: DNT is a wall between the current transaction and the server's database
... logically orthogonal to any other cookies that might be present
... if user has cookie requiring, e.g., captioning in ads, that can be sent and server can caption ads accordingly, when DNT is on
... Does that make sense?
aleecia: Not sure I followed it entirely
<justin> Do people agree with jmayer that we should kill (2) because it's already subsumed by (1)? Or is there sufficient ambiguity about the use of old data that (2) is still useful (with or without the revision that tl has suggested)
dsinger: Data that user chooses to put into transaction is actionable within that transaction
... but server shouldn't remember the transaction, shouldn't use past transaction data
<jmayer> justin, i think there should be an explicit line about whether historical data may be retained
<jmayer> since i think the first line says nothing about it
<bryan_> The concern I was expressing still stands depending upon what the intent of the 3rd party site access is. If the site provides data presented in the 1st party site through a mashup, it is acting for the same purpose as a 1st party site.
<jmayer> i hope that solves shane's concern
<bryan_> However if the site is purely about advertising, the intent of the access is different.
<fielding> IOW, cookies can store user preferences on the browser that are actionable by the server even if DNT is turned on (I assume dsinger is excluding cookies that are just user IDs)
<WileyS> It solves my concern if you drop "retain" from the proposed definition. :-)
dwainberg: Confused by introduction of "personalization" which isn't the same as tracking
<jmayer> shane, even if the next sentence explicitly says whether you can or can't retain historical data?
dwainberg: "information" and "use", especially together, are very broad, so will need strong enough exceptions
<justin> jmayer, but if we end up not requiring deletion, I think people could read (1) to allow for old use. Retention doesn't matter for immediate personalization based on old data.
dwainberg: need to think through implications for personalization
aleecia: agree that should be addressed
<jmayer> justin, how do you read (1) that way?
<jmayer> to use old data, you need new data
aleecia: suggest that we remove "retain" and treat retention as an open issue
aleecia: that gets us fairly close to consensus on what remains
... return to issue 2, as promised earlier; Tom?
tl: Not comfortable "in which operator was a third party". Should also limit operator when operator is third party now.
<jmayer> (2) is both ambiguous and undermines the meaning of (1)
<jmayer> recommend striking it
aleecia: proposal to strike "in which the operator was a third party"
... any objections?
<jmayer> if we want to allow linking a first-party database in a third-party context, that's an exception
justin: Don't feel strongly, but not sure this would be tracking.
<bryan_> no, data provided to the 1st party should still be usable when acting as a 3rd party
<jmayer> justin, then let's talk about making an exception for that
justin: want to allow more use of data provided voluntarily by user
WileyS: Definition applies to entity acting as third party. Don't want to allow loophole. Seems like a drafting issue.
bryan: Need to think more about implications of how we treat data provided in first-party setting, when same entity is a third party later
<tl> i propose the following alternative language:
bryan: users will often want that data used for personalization, even if server cannot log that interaction
aleecia: Time's up. Next week, same time.
<tl> If ta third-party domain receives a communication to which a [DNT-ON] header is attached:
<tl> that operator must not collect, retain, or use information related to that communication outside of the explicitly expressed exceptions as defined within this standard;
<tl> that operator must not use information about previous communications ioutside of the explicitly expressed exceptions as defined within this standard;
efelten: Scribing is easy--be sure to volunteer next week!