See also: IRC log
<npdoty> Chair: schunter
<aleecia> thank you!
<npdoty> scribenick: jmayer
<npdoty> (if you're calling in now, please associate your name with Zakim)
schunter: any comments on minutes?
aleecia: have been working on dc meeting agenda
... still more to nail down
... tuesday: where we are, where we're going; compliance
... wednesday: compliance
... thursday: preference expression
... any comments?
aleecia: location soon, expect to be able to announce today
schunter: review of overdue actions
... ACTION-26 review
... Taking off since Karl isn't on calls anymore.
<JC> Amy is out today
aleecia: amy's thinking is no text
alex: need more time
<aleecia> thanks, Jeff
<npdoty> action-120 due April 4
<trackbot> ACTION-120 Write a proposal on web-wide exception API (for ISSUE-113) (with npdoty) due date now April 4
schunter: recommend getting done before f2f, start with an outline
<npdoty> alex, great!
<ksmith> I have been out for a couple of weeks. Has the dial in # changed? I keep getting a 'disconnected' error
jchester2: working, will report back
<tl> unmute me
tl: working on ACTION-139, ACTION-145
<aleecia> Jeff, again due wednesday for 123?
schunter: no rigo, will reach out
<tl> Apologies for audio zakim, mute me
<aleecia> Jeff, action-123 is now a week out
<aleecia> Note that 2 weeks is during f2f
<aleecia> You could do 1 week, or 3, and I'd believe it
<WileyS> Ninja - agree that this should be handled in the companion document
ninjamarnau: need more time to work with shane
<npdoty> Ninja, can we try to do this in 1 week so we can discuss text at f2f?
schunter: done with review of action items
<ninjamarnau> ndoty, yes. thank you. I forgot that the f2f is this soon.
<tl> Netlag is the new jetlag, for all the cool kids.
schunter: handing to aleecia to work on compliance
<schunter> Voice quality is also poor for me (incoming)
aleecia: sent template for cross-issue proposals to list
... idea is combination of proposals around parties and operational use
aleecia: questions? things to add?
... first part: parties
... ok to copy and paste from other proposals
... issues: how large is a party? what is a first party?
... what a first party must/must not do, what a third party must/must not do
... unless anyone says otherwise, to be clear, the section on third parties only applies to third parties
... reviewing points of decision
<ninjamarnau> why is B only referring to retention limitations?
jmayer: thinking about this set of design decisions, I very much like the approach
... not quite a "business use"
... talk about an exception for data that can't be linked to a user's browsing
... a lot of support for that
... not a list of blanket/narrow exceptions, but purposes you couldn't accomplish with unlinkable data
<tl> Makes sense to me
jmayer: for financial logging, for example, which people are talking about as being very useful, would also want to see why it can't be accomplished with unlinkable data
<amyc> can we get definition of unlinkable with examples?
aleecia: looking at A through C, could add another category for "allowed but only if unlinkable", or add an 8th exception
jmayer: a cross-cutting exception because it doesn't raise serious privacy concerns (whatever purpose is fine)
<bryan> can we define unlinkable?
<alex> Can you define unlinkable
<bryan> i hope that is not the def...
jmayer: and second noting it as a design choice for each point on the list
<ninjamarnau> unlinkability could be a sufficient option. But I do not agree that ANY purpose would be fine. Purpose limitation is still necessary imo.
jchester2: What are the impacts for legal compliance?
<bryan> the term unlinkable does not yet exist in the TCS. "unidentifiable" is used but not defined.
<jmayer_> bryan, then let's define it - see FTC report, DAA multi-site principles
<npdoty> jchester2, are there particular problems you see that you think will trip us up for EU jurisdictions?
jchester2: Need clarity on what EU law requires.
<bryan> is there some text you could propose and reference?
aleecia: have asked several times and haven't had pushback from EU that 1st/3rd won't work at all, just perhaps that there would be additional requirements
<ninjamarnau> jchester2, I don't think that our 1st and 3rd party approach is generally not acceptable. But it sure is a problem that our 3rd parties are controllers as well as processors.
<aleecia> huzzah IRC back
<npdoty> scribenick: npdoty
<dsinger> if we mean by "unlinkable data" data that can't be associated with a person, it's not an exception, it's not even in scope, surely?
<jmayer> dsinger, why wouldn't it be in scope?
tl: I like the idea, having a first exception be unlinkable data can really improve the clarity of the document
<jchester2> Ninja, Thanks. We need EU clarification on so-called first parties.
bryan: we would need to define unidentified and unlinkability
<dsinger> because if it's data that's not associated with a person, it's no longer 'tracking' anyone
bryan: jmayer pointed to FTC and DAA documents, but we need to be sure we have an understanding and a definition
ifette: Art29 v FTC and these definitions
ifette: get something out the door that offers users meaningful choice, if that satisfies regulatory requirements then great, but our primary goal shouldn't be satisfying such a regime
<tl> +1 to: we're building a tool for users. If that satisfies some regulatory regime, great.
<jchester2> The meaningful benefit should be an effective DNT regime
<dsinger> let's be mutually informed, but not wedded!
aleecia: agree, regulatory requirements are useful to have in mind, but not determinant of our work
... implications of different regulatory regimes are large and so we should talk about them, but we may choose to go our own way
dsinger: in Brussels we had a discussion of alternative models to 1st/3rd
... we don't seem to have explored these further since, when should we do that?
aleecia: this is a great time to write up those alternative proposals (in this form) if interested
... in Brussels moved to walk down the 1st/3rd path unless/until it fails
<dsinger> ok. thx
aleecia: if you want to write an alternate proposal, go right ahead
fielding: 3rd-acting-as-1st important to me in the template itself, hard for me to evaluate otherwise
aleecia: case to bundle one more piece, though I've been trying to keep this as simple as possible
<fielding> jmayer, because I won't agree to third party restrictions on outsourced services
jmayer: three options for each business use, could add "allowed under the unlinkable exception"
jmayer: but rather than just a retention limit, there might be other limits -- part of a broader design space
... not so rigid that retention limits are the only limits on an exception
aleecia: can use Part C of the template for that, restrictions may vary across each business use
jmayer: buckets of 1) never do it, 2) do it without limits, 3) unlinkable only, 4) customized set of limits
<ifette> Maybe we should just see a proposal and what people write they write...
<aleecia> here's what I think I'm changing to the template: (1) "unlinkable" to the list of 7 uses; (1) "unlinkable" as a method similar to retention; adding agent of a first party
<aleecia> and adding a note that proposals that are not 1st/3rd party are also fine
<jmayer> my pragmatic concern is that it'll be difficult to compare proposals
<jmayer> they'll be text-heavy
amyc: want to support what jmayer said, don't want to get too rigid about A/B/C, may include A/B/C just to make it easier to compare
<jmayer> scribenick: jmayer
aleecia: circling back to unlinkable data
<npdoty> did jmayer volunteer?
<tl> I think jmayer volunteered?
<npdoty> ACTION: mayer to draft a permitted use/definition for unlinkable data [recorded in http://www.w3.org/2012/03/28-dnt-minutes.html#action01]
<trackbot> Created ACTION-153 - Draft a permitted use/definition for unlinkable data [on Jonathan Mayer - due 2012-04-04].
<ninjamarnau> unlinkable is the same as unidentifiable
<bryan> I would ask that the definition address these questions: Does "link" mean an association with a specific individual or device (whether the identity of that individual/device is real or not), or a limited group of individuals or devices, or a class of individuals or devices, etc? How far away from an real individual or device is the ability to "link" significant?
dsinger: Is unlinkable data in scope?
<ninjamarnau> unlinkable is the NOT same as unidentifiable
<bryan> How is unlinkable is the NOT same as unidentifiable?
aleecia: We've been discussing the boundaries of unlinkable data, will work on text.
<WileyS> Breaking up badly
<johnsimpson> tl, breaking up badly
<ifette> tom, more bandwidth!
<tl> As we said in Santa Clara: you can have data about people, but which cannot be linked to a particular person. This is hard.
bryan: need precision in the definition
<Lia> pages 20-22 of the FTC report discusses de-identified data
bryan: question: how unlinkable?
<scribe> ACTION: draft an unlinkable data/unidentifiable data/pick favorite term exception [recorded in http://www.w3.org/2012/03/28-dnt-minutes.html#action02]
<trackbot> Sorry, couldn't find user - draft
<scribe> ACTION: jmayer to draft an unlinkable data/unidentifiable data/pick favorite term exception [recorded in http://www.w3.org/2012/03/28-dnt-minutes.html#action03]
<trackbot> Created ACTION-154 - Draft an unlinkable data/unidentifiable data/pick favorite term exception [on Jonathan Mayer - due 2012-04-04].
<trackbot> ACTION-153 -- Jonathan Mayer to draft a permitted use/definition for unlinkable data -- due 2012-04-04 -- OPEN
<bryan> is "ease of linking" really a factor in linkability?
ninjamarnau: some possible different meaning in eu
<laurengelman> what about the ftc text?
aleecia: another thing to think about - aggregation at the time of collection
<bryan> if I can break SSL I can probably correlate data... is a prohibition against linkability really achievable ?
<alex> ninja: is there a size related with the buckets you mentioned?
<ifette> Depends on the data being collected -- e.g. cookies may be set to "optout" but IP addresses still sent, etc
aleecia: will work on revisions to template
<npdoty> volunteers to write proposals?
<dsinger> I hope to write up "issues with 1st/3rd that are different or gone with x-site"
<johnsimpson> i plan to something
<jmayer_> sure, i'll paste together what i've already written
<npdoty> thanks to volunteers!
<johnsimpson> should be different views :)
<Lia> Bryan, according to the FTC the ease of linking is a factor - based on whether data can be "reasonably" linked
aleecia: not defining compromise by who gives up what, instead looking for something that everyone can live with
... would like to see some details on use cases
... example: research and surveys split apart
schunter: moving to tpe
tl: a problem when working on response header and uri
... first problem: opt-in status
tl: response header will handle per-request, static status resource can't
<npdoty> I assumed that agents would continue to send cookies on fetching the tracking status resource
fielding: don't think there's a problem
... browsers will still send cookies
tl: ok, resolved
tl: second problem is related, solved
<npdoty> valid for *at least* 24 hours, in many cases the caching would be much longer, right?
tl: must have a status resource, could be static or dynamically generated, expect it to be an upper bound on tracking, valid for at least 24
<fielding> dsinger, we already do
tl: if parameter changes, have to reload the resource
... anything we're missing?
tl: for fingerprinting, could use ip + ua, more would be difficult
<WileyS> In mobile
<npdoty> WileyS, do you have specific details on the mobile context?
<jmayer_> easy fix - allow loading html/js/etc. as part of the status resource
<npdoty> jmayer, that's certainly one way, though it seems dramatic
schunter: is there agreement on approach?
tl: working on text
<jmayer_> npdoty, background pages are nbd
schunter: any objections to the hybrid approach? comments? expect more in future
schunter: question: should a site be able to get an exception for all the third parties it chooses to use?
... another question: should widget providers (and similar) be able to get a web-wide exception for all the first parties it appears on?
... yet another question: should a site be able to get an exception for specific third parties?
... want to give publishers flexibility and practical accommodation, but also want to make sure users are informed
<Zakim> tl, you wanted to talk about something he wanted to remember
<npdoty> current API doesn't support the Web-wide exception case, we're still waiting on alex to draft text here
<jchester2> Can the IAB, DAA, NAI etc on the call explain their view regarding this issue, on web wide exceptions.
<WileyS> Jeff - I can explain the "MyBlogLog" scenario again if you like
<WileyS> As one example...
<tl> We want a mirror image API too. Right now, you can only ask about opting *in* to getting DNT:0, not opting *out* to getting DNT:1
<npdoty> jmayer: take the approach of handling all 3, don't need to answer whether the * exception satisfies EU law, sites that handle EU users can make that determination on their own
jchester2: would like to hear where industry trade groups are
... concerned about users accepting a list of companies they don't know
... want to make sure there's meaningful information available about what's going on
<npdoty> jchester2, are you arguing that we shouldn't allow a "*" exception at all, because users wouldn't be informed?
<jmayer_> it seems to me these aren't mutually exclusive
<npdoty> marc, want to respond directly?
<jmayer_> a "*" exception allowed, with a transparency requirement
<jchester2> What is the DAA doing now on its own DNT system, including this issue?
marc: We shouldn't draft with an eye towards any particular legal regime or specific browser implementation. Would allow all three options to exist.
<jchester2> Neither the NAI or DAA offers the kind of real transparency a consumer requires.
<chapell> @Jeff, you prob want to ask the DAA directly - as I don't believe they are on the call
<jchester2> Marc as head of NAI is on the DAA.
schunter: What sort of transparency is available about the companies on a page?
Marc: Icon gives some information, some interstitial pages (not currently required) give a list of companies involved in displaying an ad.
<aleecia> While it's interesting to learn what DAA is thinking about, once again, we may go off in an entirely different direction from what any external party might prefer
<chapell> @Jeff - I understand that it is your opinion that neither the DAA or NAI "offers the kind of real transparency a consumer requires"
<jchester2> When you look at Aboutads, the information provided there doesn't reflect how the companies really collect data, who their partners are, etc.
Marc: At opt-out page, get list of companies. Most users choose to opt out of all companies.
<aleecia> We might want to take this offline soon?
<jchester2> Comsumers don't have the granularity they require--so any exception must convey what really goes on.
<jchester2> Look at this and tell me how this helps users and their privacy: http://www.networkadvertising.org/managing/
<schunter> My understanding: Marc says that DAA does not offer per-thirdparty transparency or control but rather categories/groups of entitites.
<chapell> We are at loggerheads on this point I believe - Jeff is unlikely to think that the disclosure that the industry comes up with will be sufficient -- industry will think that jeff's standard is over reaching. We may want to take this offline
<WileyS> +1 to what Alan said!
<aleecia> I think Ninja's points here are helpful, once we understand where things stand.
ninjamarnau: We want first parties to carefully select their third parties. Especially given considerations of liability.
<Zakim> npdoty, you wanted to note that the current proposal handles both * and an enumerated list
<aleecia> And thanks for Marc jumping in to help us understand
npdoty: Current proposal handles "*" and list.
<jchester2> I also appreciate Marc speaking out--although we don't agree!
<npdoty> an array of domain strings OR a "*"
<aleecia> revised template -> dlist; please let me know if I've missed or mangled anything
ksmith: Want "pretty name" option in exception API.
tl: Already included.
<vincent> imho users are more liklely to have a blacklist of exceptions not to grant
<dsinger> is willing to explore in email (which I sort-of tried and failed) his concerns with the JS API in general, as time is running out, and why I wonder whether both sites and UAs will both prefer what we call "out of band" over this in-band JS API and dnt:0
schunter: We'll make an action.
ksmith: Agree that lack of transparency is a problem with a blanket exception.
<npdoty> I think currently the pretty name parameter is just a single param for the first-party site, it would be a new option if we want to do it for every 3rd-party domain (which I could see being useful or not)
ksmith: existing ad chains are problematic for exceptions
<jchester2> Or the ad exchange like business model needs to be changed to better protect privacy.
<jmayer_> I continue to think Kevin is completely wrong on this. See the list.
<fielding> where is the F2F?
<npdoty> dsinger, yes, please note on email; I am still very optimistic about user-agent managed exceptions
schunter: Next week - last before f2f.
<dsinger> npdoty: huh?