See also: IRC log
<tl> Oh Zakim, how could you have forgotten me? I am truly offended.
<aleecia> Zakim's memory is shorter than a goldfish
<tl> I suspect dark Magicks.
<ifette_> i have a great tshirt for that
<ifette_> remind me to bring it to seattle
<aleecia> Asking us to remind you about a tshirt about lack of memory...
<ifette_> somewhat ironic, i know
<aleecia> I just for the first time figured out who BrendanIAB is. Hullo, Brendan.
The only time I don't get emails about DNT is during the conference call. It's amazing :)
<tl> ifette: I'm just working on one.
<ifette_> i'll volunteer
<scribe> ScribeNick: ifette
aleecia: will go to overdue actions
aleecia: what about unlink ability with peter? shane?
<trackbot> ACTION-160 -- Peter Eckersley to work with Shane on common ground on unlinkability normative/non-normative text -- due 2012-05-23 -- OPEN
shane: included with things for seattle, also sent to tom and peter
... believe his part is completed
<npdoty> great, we can close this one?
<jmayer> This ACTION was intended to get consensus on unlinkability.
Aleecia: will mark pending review
<jmayer> That consensus doesn't seem to exist just yet.
Aleecia: probably helpful to update proposal to have the action number, can worry about that later
... next is ian
<trackbot> ACTION-187 -- Ian Fette to write text for ISSUE-99 around identity providers as first or third parties, DUE May 5 2012 -- due 2012-06-06 -- OPEN
ifette: this is done
... 208 is also done
aleecia: ninja, you have two
<trackbot> ACTION-150 -- Ninja Marnau to analyse EU legal implications of exceptions to (thissite, *) -- due 2012-06-06 -- OPEN
ninja: propose to combine 150 with 174
... basically the same, both pending review, sent suggestions to ML with ongoing discussion
ACTION-150: related to ACTION-174
<trackbot> ACTION-150 Analyse EU legal implications of exceptions to (thissite, *) notes added
aleecia: marking pending review
... next up is Jonathan for 209
<trackbot> ACTION-209 -- Jonathan Mayer to draft a definition of DNT:0 expression -- issue-148 -- due 2012-06-06 -- OPEN
jonathan: slipped my mind
ACTION-209 due 2012-06-14
<trackbot> ACTION-209 Draft a definition of DNT:0 expression -- issue-148 due date now 2012-06-14
<susanisrael> Susan Israel joined from number 917-934-xxxx
ACTION-205 due 2012-06-18
<trackbot> ACTION-205 Open a new issue on UAs due date now 2012-06-18
Aleecia: action 195 will be done today
ACTION-195 due 2012-06-14
<trackbot> ACTION-195 Clarify action items needed for issue-65 due date now 2012-06-14
<trackbot> ACTION-169 -- Rigo Wenning to create text describing "if your privacy policies don't match, don't claim an associated domain" -- due 2012-05-09 -- OPEN
Aleecia: rigo, wru?
... will harass him via email
<trackbot> ACTION-207 -- Shane Wiley to follow-up with Peter or otherwise post current draft to the list for Unlinkability due 6/4 -- due 2012-06-06 -- OPEN
scribe: is a dupe of the previous
<trackbot> ACTION-207 Follow-up with Peter or otherwise post current draft to the list for Unlinkability due 6/4 closed
Aleecia: will have many more actions post Seattle
<Chapell> chapell joined from +1.917.318.bbff
Aleecia: moving through agenda
<tl> There you go ifette, now you even get email during the call!
<ifette_> tl, lovely
Aleecia: lots of people from DC on the call unidentified
... aleecia calls out people
<tl> efelten, So there are two phones at the FTC dialing in?
<efelten> I am on one line, Chris and Peder on another.
<Chris_IAB> Aleecia, Shane and Alex - A BIG THANK YOU from the IAB and DAA for your presentations yesterday at our Town Hall DNT Meeting!
Aleecia: please mute thy self
... as a quick reminder, today is the last day for registration for f2f
Aleecia: if you want to come / suggest observers, need to do that immediately
... again, last chance
Aleecia: Have an opportunity to hear from Frederik, a legal scholar in NL
... would like to get a summary in english
Frederik: Hi everyone, here from institute for information law
... 11.7a of information act.
... copies eprivacy directive
<aleecia> We'll do Q&A briefly after
Frederik: says storing and reading of cookies is only allowed after informed consent of a user
<aleecia> please add yourself to the queue if you'd like
Frederik: dutch legislator didn't implement the recycle
... consent with current browsers cannot be inferred from browser settings
... also added legal presumption about tracking cookies
... companies using tracking cookies or similar technologies are presumed to be processing personal data, codification of what most DPAs say
... the scope of the provision, much broader than cookies, like e-priv directive
... made clear it applies to LSOs and device fingerprinting
... placing of these applicable on smartphones, tablets as well
... general rule is prior informed consent of user
... consent is defined as four steps. freely given, specific, informed, expression of will
... current browsers not sufficient to imply consent mainly because most browsers accept cookies by default
... legislative history, if an ad network has placed a cookie it doesn't have to ask consent again when it reads the cookie later on
... dutch regulatory authority (OPTA?) has given guidance saying popup window would be a way to comply with this
... legal presumption added, in telecoms act
... use of tracking cookies and similar technologies implied the party using those is processing personal data. is a legal presumption, a company operating a tracking cookie could prove that it does not process personal data
<aleecia> (what does process mean here, I wonder)
Frederik: but because of the presumption, unless proven otherwise, it's processing personal data and data protection act applies
... in most cases, means consent has to be unambigous
... legal presumption only effective from 1/1/2013
... rest in effect since 5 june
... exceptions for functional cookies like in e-privacy directive
... needed to carry out communication, etc
... "strictly necessary" to provide service requested by user
... main points informed consent, cannot be inferred from browser settings, and legal presumption
aleecia: thank you, valuable in understanding
... first person is nick
<Zakim> npdoty, you wanted to ask if analysis of current browsers included an analysis of early DNT implementations
<aleecia> thank you for scribing this ifette
npdoty: said group had looked at current browsers and said browser settings alone not sufficient. does that include DNT implementation in firefox? has group addressed how DNT would apply?
frederik: talking about dutch parliament / senate
... said "current" browsers are not sufficient
... but explicitly postponed tracking cookies to 1/1/2013
... senators hoped that useful DNT system will be in place by then
<rvaneijk> the senators explicitly referred to DNT !
aleecia: not yet evaluated browsers in light of DNT and not about FF's implementation, correct?
<amyc> would "current' browser include Safari because 1st party cookies allowed, but 3rd party cookies are not set?
frederik: correct. There are browsers around that accept any cookies so clearly the current browsers are not sufficient, but explicitly referred to DNT
... only dropped the name, didn't go in detail
... hope a system will be in place that might help the industry to comply
... presumption kicks in 1 january 2013
(amyc's question read)
<BerinSzoka> Question: What does it mean for consent to be "freely given"?
Frederik: Dutch senators didn't go in so much detail
jmayer: defaults weigh heavily on this group. want to understand the extent DNT could facilitate compliance in light of defaults
... would DNT if not set to prevent tracking by default facilitate compliance
... or would it have to be a default of no tracking with exception mechanism
frederik: a browser that doesn't say anything (no option clicked) default would be no tracking
... because tracking only allowed with consent
<rvaneijk> ... BUT havind DNT on by default is already a step in the right direction
aleecia: if i understand, what you said is that if a browser were to send DNT:0 by default that would not be ok?
... a person using a browser that hans't made any choices w.r.t. DNT cannot be tracked
<BerinSzoka> I was hoping to hear from Frederik whether, for example, consent to be considered "freely given" if access to the site were conditioned on consenting to the cookie
frederik: default in holland is that without consent, no tracking
Aleecia reads Berin's question from IRC
Frederik: good question, legislation hasn't addressed in detail
<npdoty> would a DNT:0 (if the default is unset) then imply consent?
Frederik: one short sentence suggesting that indeed you can condition access on accepting cookies
<rvaneijk> NO.. purpose needs to be clear
aleecia: pop up dialog, saying "in order to use you must accept cookies", click yes, and then you have consent for... that time, forevermore, unclear?
... cannot enter the site if you don't accept cookies is allowed
... does it imply "yes you can place a cookie and track forever" is unclear
<fielding> "freely given" is typically associated with forced will or leverage (i.e., you won't get paid if you don't agree to employer's "request" --> not freely given)
aleecia: reads rob's question, asks if you must list purposes of cookies
aleecia: seeing no one else in queue, please add yourself if you have questions
... one issue aleecia has is that there' smuch nuance with specific words
... for example, "process" is used a lot
... a presumption that if there is a unique identifier, that that is PII
... but you could rebut if you do not process PII
... what does "process" means
... hold in log file?
... what does it mean
frederik: you forwarded the translation earlier
... read what the article actually says
... will explain in human language
... "any activity as referred to in preamble with the view to collecting, analyzing or combining information about the users use of various internet services for marketing purposes is presumed to be the processing of personal data as defined in data protection act"
... basically, europe definition of processing
... anything you do with the data
<eberkower> "processing" includes simply storing
<aleecia> thank you
frederik: main point is that tracking peoples use of different internet services is assumed to be processing
... includes simply storing, yes
<aleecia> ifette, dnt may or may not succeed in that time frame
<aleecia> ... if you seen implementations on websites that would meet this standard?
ifette: DNT may or may not succeed, have you seen any webistes that would comply with this legal requirement
Frederik: have seen some popups, not sure if they would comply / how clearly they identify purpose
Aleecia: two paths that seem possible for consent
... throw up popup window, explain what data and for what purpose
... works regardless of DNT
... other is DNT might be sufficient as consent mechanism, TBD
frederik: agreed, DNT has only been name dropped, not evaluated in any detail
<Zakim> tl, you wanted to point out that the UK ICO has a "good" design.
<npdoty> presumably there are compliant sites that don't set 3rd-party cookies?
tl: UK ICO has request/notification before sending cookies
<amyc> Nick, if Safari is noncompliant, it seems like accepting any cookies is not sufficient
<johnsimpson> Does the Financial Times Page http://www.ft.com/home/us meet the standard from the Netherlands?
<rvaneijk> @john, no way.. there is no choice.
Frederik: FT looks reasonable but I'm not a regulator
<ninjamarnau> amyc, the ePrivacy Directive makes no difference between first parties and third parties as this Working Group uses the terms
<aleecia> ifette, sites set cookies before popup, is ok?
frederik: consent has to be prior
aleecia: how would that work
<amyc> thanks ninja. Nick, does that help your q?
<jmayer> Low-entropy cookies that control popups etc. seem to get a free pass.
Aleecia: 1/1/13 is date to start bringing enforcement actions?
Frederik: two relevant regulators
... telecom regulator can enforce dutch telecom act
... and this act says exactly what privacy directive sys
... only after informed consent
... telecom can enforce already
... on 1/1/13 data protection authority can also enforce
... from 1 january the assumption kicks in
... and burden would be to prove that you don't process personal data
Aleecia: if i'm a us company doing business with an office in london
... do i need to worry if i have customers in amsterdam?
... because the customer is in amsterdam?
frederik: yes. similarly, company without office in london would also have to comply
... if you have NL users you should comply
aleecia: if instead i say based on IP address, I say "service not available in NL go away" I would be in compliance?
<npdoty> 'if you target users and other devices in the Netherlands, you should comply'
frederik: I haven't thought of that scenario yet
... only partly relevant for 5/3 e-priv directive
... can already be enforced, but an extra layer put in
aleecia: one more question
... my understanding is that in the UK they have a completely different approach now
... implicit consent is OK
... how would that interact with dutch law
Frederik: guessing a bit now, but
... don't really see it working
Aleecia: what does that mean
Frederik: Implicit consent would be rarely OK under dutch law
aleecia: different standards
... if i were based in the NL with customers in the UK
<jmayer> The UK's implicit consent has to do with first-party cookies -- so it doesn't affect this group much.
aleecia: would I need to do the NL or UK standard?
Frederik: think it's about the customer, but saying by heart, don't pin me down here
<npdoty> thx Fborgesius
Aleecia: thanks Frederik
... turning to remaining unidentified people
Aleecia: will have a short call, one issue
... Roy suggested new text around collection
Some IPR related discussion omitted. —Nick
Aleecia: failing to get to this for last two calls
<aleecia> A party collects data if the data comes within its control.
<aleecia> A party retains data if the data remains within the party's control.
aleecia: two issues around collection and retention
... pasted options in IRC above
<aleecia> Data collection" (for the purpose of DNT) is the process of assembling data from or about one or more network interactions and retaining/sharing that data beyond the scope of responding to the current request or in a form that remains linkable to a specific user, user agent, or device.
aleecia: roy was unhappy with definition of collection, pasted in IRC above
... not seen a lot around roy's thoughts for why this was necessary
... will note our current definition would apply to a router that has data that goes across it fleetingly
... perhaps we can tighten
... not sure that was roy's concern
... roy, what were you trying to fix?
Roy: find with collection being not defined at all, frequenty used consistently in regulation without being defined
... problem is that one option in compliance doc is that it defines collection as receipt
... don't believe in applying requirements on servers for the act of receiving data
... if i receive data it's because client sent it to me, nothing to do with compliacne/non-compliance
... won't accept requirements merely on receiving dat
... will see jonathan's proposal that collection has been replaced with received
... nice to have clarification but still unacceptable, i can't control what i receive
... basic problem i was trying to solve
... one solution is to constrain collection, not receipt
... fine with me
aleecia: use case for where it's relevant
<dsinger> I offered that 'receipt' was passive, 'collection' active (I went out to get it) and retention was (as Roy says) after the transaction
<jmayer> embedded img's
roy: info within the URI
<npdoty> is there a single definition that's commonly understood in the art? (I thought that there wasn't, which is why we ended up here)
roy: say you promise that with DNT on you won't retain personal info about user
... but user goes to your site and for some bizarre reason includes their address as part of the request
... query parameter of URI
... gets stored with all the other info from that request
... that's PII we've received
... but we didn't collect, had no idea the user would send that info
... if we had collected, would have been in a way that included a consent mechanism
... if it just comes in off the wire with no reason, nothing we can do
... it's PII
... but we made no effort to receive it
... and yet if the requirement is that we do not receive PII data
<rvaneijk> @Roy, you are not an ISP. Data is not in transit.
roy: we would no longer be complaint with DNT
<npdoty> for roy, the key issue is that collection would have been intentional? "effort to receive"
Aleecia: understand better
jmayer: in latest revision, have provision that goes to this concern
... exempts from DNT practices where a company doesn't know or have reason to know it's getting data
... in support of that
... does that allay the concern?
<aleecia> please mute yourself
Roy: that concern yes, but i'm not going to sign up on any requirements on what i receive
jmayer: specific disagreement may be "what if you don't' cause a UA to send something but you get it or know you're getting it"
... suppose you find out that for whatever reason, some resource gets embedded all over the web
... you don't want that data, not authorizing that use, but you know people are doing it
... I think a company in that position should have to take steps to be in compliance, even if they didn't want to be in that position
<Zakim> dsinger, you wanted to suggest receipt/collect/retain
dsinger: suggested treating receipt separate from active steps to collect
... have to otherwise have exceptions around ability to scrub logs etc
... running JS to collect something
... different than receipt
... agree with Roy, can't have same restraints on receipt/collection
ifette: +1 dsinger, roy
<aleecia> David proposes
<aleecia> 1. "is exposed to": data that the service sees without taking any specific action,usually, the data arrives whether the service wanted it or not;
<aleecia> 2. "collects": the service takes specific action to acquire the data;
<aleecia> 3. "retains": the service holds the data after the immediate transaction is complete;
<johnsimpson> What is the impact on the spec if we do not define?
<jmayer> Didn't I just explain that?
roy: why do we care, what is not covered from data collection that we're trying to get in here?
... definition of data collection int he spec does not have connection to definition in real life / regulation / understanding in public
<jmayer> So is the objection to word choice or substance?
roy: if we remove or use a definition consistent with regulations / dictionary that's fine
... we are only constraining act of collecting/retaining things that have been collected
<dsinger> I am suggesting we put constraints solely on *retention*, and those constraints are different for *received* data and *collected* data
roy: think that's applicable to DNT
... stuff merely coming within your control is not
aleecia: not sure if everyone would agree with your understanding as is evidenced by this discussion
... "we won't define it and everyone will knows what it means" may not be productive if everyone in this group doesn't even understand
dsinger: get out of the box by putting limits on _retention_ of data
<ninjamarnau> I would argue that there is a common meaning of collect in international legislation
dsinger: limits are different for received data vs collected (intentional) data
<ninjamarnau> that there is no common understanding, sorry
dsinger: as roy says, disentangle later from logs of received, not true for collected
aleecia: could imagine a definition around "took active steps"
... not sure we're there yet
... any other discussion
ifette: believe we should only be talking about things you intended to collect
... incidental data is what it is
npdoty: would tom, jonathan accept limits instead on knowing collection / knowing retention
... transient data not a problem
jmayer: scale based on what the problem is
<dsinger> (notes that if a server sets a cookie, and then it comes back in a transaction, the original classification of the data in the cookie applies (it doesn't become 'received' suddenly))
jmayer: if it's everyone decides one day to send some data in their referer to some social widget that the widget doesn't claim to collect
... and the widget now has to strip stuff on case by case basis
<aleecia> please mute yourself if you're not muted
jmayer: then that shifts to a 'you have problems of retention'
... guess it all defacto shifts to retention
... can't cause receipt of data to stop
... from the get go if you realize you're receiving and can take action to not set cookie
... that's example of something ???
<npdoty> are the only limits that jm and tl want: intentional reception/collection and knowing retention?
jmayer: fair point that as a defacto matter much of this will look like retention limits
i have no idea wtf that meant
<Zakim> tl, you wanted to say that if you are accidentally collecting data, you should not do that?
<jmayer> That was me thinking and changing my mind on the fly.
tl: in response to nick, i don't simply want to restrict intentional collection and reteention
... want to restrict retention whether knowing or not
... lots of web servers ship with log everything by default, that doesn't make it good
... if it's accidental you should stop it
Aleecia: I'm having problems with the concept that "You shouldn't have accidents"
tl: if you just hold on to whatever anyone sends you we have a problem
<WileyS> Tom, that's 99% of the default settings on web servers out of the box
aleecia: if i understand correctly, under this definition, if someone is shoving data at you, you are still on the hook for collection just because it came to you
<jmayer> The current compromise proposal language looks at both receiving/collection and retention. And I think that's right. On reflection, it occurs to me that, in practice, most of what will be problematic is retention.
aleecia: what jonathan is saying is there needs to be some notion of intentionality / reasonably understand this is going to happen
... whereas tom is saying it's your problem in all cases
<dsinger> only if you retain it (after the transaction), and it falls outside a 'permitted use' (e.g raw logs)
aleecia: don't think your suggestion solves roy's problem as it is
dsinger: yeah, you can write stuff into logs files, that's a permitted use
... but when you do analysis you will have to scrub
aleecia: last few weeks we did not get a grace period
... this might be a place where people want to think about interactions here
dsinger: real time is optimistic
<fielding> Note that the server doesn't even know what is personal information and the server might not process it, ever
<npdoty> aleecia: we had a discussion over the past few weeks about a grace period for log files, some people thought that we shouldn't have one
ifette: if you have no grace period, have to deal with "accident" in real time
jmayer: extent to which we need a realtime requirement up for debate
... don't believe many would realistically push for that
... at same time, not some fundamental incompatibility between having some unintentionally type requirement here and same time ...
... no reason we couldn't do both
... you get some grace period
... such and such reason to believe unintentionally receiving
... before you have to act
aleecia: reason could be useful but may not satisfy everyone
tlr: wondering how productive it is to go down into layers upon layers of error handling
... there is a useful conversation to be had about what the practices are that we expect could happen
... e.g. around design
... at the moment we are talking about recovering from design error
... infinite argument
... goes to a place where it gets difficult to come to useful consensus
... what is the main aspect of collection
... what do we suppose companies are engineering their system for
... as opposed to a genuine engineering mistake to recover from
<fielding> I still don't understand Tom's desire for a constraint here. Why does W3C want to constrain something that no regulator has even requested? Could Tom send more info to the list?
aleecia: don't think that's what we're talking about here
... different terms. looking not at technical issues so muh
<tl> fielding, We are not regulators.
aleecia: but legal liability from someone taking actions you weren't expecting
... e.g. in US if you get child porn in your inbox you're in for a world of hurt
... don't want to set up the same thing with DNT
<jmayer> Proposal: we have a new issue surrounding unintentional collection.
<jmayer> Let's go to text.
<jmayer> And make good on the promise to Ian.
<ifette_> +1 jmayer
aleecia: text is good idea, better understand roy's issue
... am i getting what you are concerned with>?
roy: i think so
<amyc> these collection definition issues also apply to definition of sharing too
roy: also concerned we were using a common term in a bizarre way, but yeah
aleecia: can live with bizarre way, that happens, but the other is definitely an issue
<npdoty> and in most of our drafts now we're using "receive" and "retain" to avoid any ambiguity on "collect"?
aleecia: maybe you could take a look at jonathan's text nd see if you would be happy
<tl> npdoty +1
<dsinger> wonders why we need both 'collect' and 'retain'?
<Zakim> ifette, you wanted to say i would not be happy
<jmayer> I would much prefer to not load definitions with so much substance.
ifette: given the amount of data google receives, we could at any point in time reasonably expect someone is giving us random crap and filter out 100%
jmayer: something along the lines of pervasive patterns
... getting info about lots of users in systematic way, not one off episodes
... that's my concern
<fielding> happy to iterate on list
<scribe> ACTION: jmayer to draft text perhaps with roy and ifette around notion of filtering out data that is received in large amounts that should be required to be filtered out [recorded in http://www.w3.org/2012/06/13-dnt-minutes.html#action01]
<trackbot> Created ACTION-213 - Draft text perhaps with roy and ifette around notion of filtering out data that is received in large amounts that should be required to be filtered out [on Jonathan Mayer - due 2012-06-20].
aleecia: want to talk briefly about f2f
<johnsimpson> How do we fell about David?s proposed language?
ACTION-213 due 2012-07-15
<trackbot> ACTION-213 Draft text perhaps with roy and ifette around notion of filtering out data that is received in large amounts that should be required to be filtered out due date now 2012-07-15
aleecia: number of texts to read before f2f
... compliance proposal from tom, peter, joathan
... revised proposal from shane and others
... combined doc that aleecia has worked on and sent
... would be useful to read and look at within your company
<npdoty> ifette, July 15th? jmayer, how many weeks for this action do you think?
aleecia: also look at prior proposals
<ifette_> nick, next week is f2f
<ifette_> then 4th of july
aleecia: understand where you are before you walk in the door
... looking for big decisions to come out of f2f
... reminder, if you're not registered do so immediately
<JC> Send me an email if you need help with logisitics!!!!!!!!!!
<npdoty> register here: https://www.w3.org/2002/09/wbs/49311/tpwg-belle-f2f/
<johnsimpson> JC any advice on transport from airport?
<efelten> See y'all in Bellevue.