See also: IRC log
<trackbot> Date: 07 May 2013
<npdoty> Meeting: Tracking Protection Working Group f2f
<jmayer> Regrets, have to participate by the phone for morning sessions today and tomorrow, will be in person in the afternoon sessions.
<schunter> Since I am remote, too, this means that we can communicate clearly with each other ;-)
<npdoty> scribe volunteers: Alan, JC, Rigo
<npdoty> (scribing one hour at a time)
<wseltzer> Chair: schunter
<wseltzer> Meeting: Tracking Protection Working Group
<wseltzer> Date: May 7, 2013
<npdoty> scribenick: Chapell
... we begin with....History of the weather(?)
... blizzard at MIT, and now.... rainy in (always sunny) sunnyvale...
<npdoty> "weather gods have been smiling on us"
<sidstamm> we're supposed to have a sunstorm today
Peter: progress made yesterday. How we can bring this together...
Consumer Groups - 2 priorities.... must be do not collect...
scribe: Peter and others have expressed concerns with the DAA code --- DAA has interest in addressing these concerns. If we address these concerns, we can address the concerns around do not collect
... 2nd concern from privacy advocates: the UID issue.
... If I turn DNT on, you don't set a UID --- this sounds acheivable to Peter....
... How do we get there? We get as far as we can this week. Understand WHY we need a UID.
... if we create structure where it looks like there's convergence, and credible promises, then Peter believes we have a chance to address the UID issue as well.
....Re: Advertising Industry: want's DNT default off and meaningful explanation of DNT functionality
... if it turns out that we meet priorities of both advocates and advertising industry, then that's a really good reason to come together enough tomorrow and continue....
... conversely, if we don't have agreement on these issues, it may not make sense to continue.
... re: Where is the Normative language?
<jmayer> I sent an email to the list that reflects my understanding of yesterday's conversation of browser user interface. I think we have a "convergence" / "are in the ballpark" on informing users. We don't have agreement on non-browser UAs, defaults and UI specifics, and ignoring DNT: 1.
....Re: All the contingencies make it difficult to close issues. This is the reason that we've gone to a framework approach. This allows a high level view. And the text will follow.
<npdoty> jmayer, do we not have agreement on unset-by-default?
....Re: If we have the stakeholder priorities set by Wed, then we can address on subsequent Wed calls.
<jmayer> Nick, I believe we have agreement on a silent default in a mainstream browser. I have not seen any indicia of agreement on other implementations, nor agreement on who decides whether a UA is noncompliant and what websites can do about it.
LouMastria: Some reason to be hopeful. The famework is more holistic. All of this is good. One of the issues discussed yesterday is the concern about cookie blocking. DAA sees this as a material issue.
<justin> Is there anything about cookie blocking in the draft framework?
<jmayer> Justin, no, there isn't.
<npdoty> justin, no.
JohnSimpson: It seems to be possed that there are two sides: DAA and privacy advocates. There are many more stakeholders. He's not sure how all the other stakeholders fit in here.
<npdoty> ... but it's something we've heard of interest from both DAA and from browsers
JohnSimpson: Moreover, the room is filled with lawyers and policy wonks --- but few implementers. That's important to consider.
<dsinger> I think that last-call is where we ask for implementation and feedback, and we'll get it from implementers...
PeterSwire: Hasn't heard of a deal breaker from other members of the ecosystem -- but has heard from advocates and DAA. Peter hopes that others will let him know if they have deal breakers.
<npdoty> +1 to dsinger, Last Call and CR both are about getting more implementers and testing
PeterSwire: Peter has tried to bring in many experts into the discussion in order to have a fact based approach.
Jmayer: 3 points
Jmayer: 1. What was agreed to --- We have reaffirmation of what we've long agreed to. This is seperate from the details of browser UI, what is required of non-browser UA's and browser defaults....
... moreover, we haven't built consensus on what happens if the browsers send a signal that violates the standard.
2. Many participants in the group put lots of brainpower into these discussions. There is a tendancy in the way that this has progressed that lack of objection = consent...
scribe: many entities have expressed concerns with the framework.
... glossing over long-standing disagreement isn't productive
3. This framework is a giant horse trade... industry gets movement by browsers.
scribe: regulators and advocates get movement on permitted uses and uid's. Compromise is important.
... given all the discussion around browser interface, JM believes there needs to be significant givebacks re: UID and permitted uses.
Matthias: Via phone (wishes he could be here)
Matthias: Slide 2: summarized the status
Matthias: pleasantly surprised how much progress has been made.
<JC> Matt we lost you
<rigo> continent isolated
<fielding> you are back
<npdoty> schunter, apologies, for our phone issue, we hear you again
Matthias: 6 open issues. Plan during this meeting is to address these issues.
... minor issues can be addressed down the line via phone.
... Agenda (slide 3) structured the session in 2 parts:
,,,, Roy will give an update on what has changed in the draft, then
scribe: discussion of preference collection, transmission and acceptance
... Session 2: review pendig proposals. Discuss and assign changes.
... then we look at item 6 of the draft framework
... Dsinger will co-moderate and manage the que
<jmayer> A recap of my three points: there remain deep divides on browser user interface, we cannot ignore longstanding and well-considered ISSUE positions on account of high-level framing and silence, and for the framework's horse trade to work there needs to be significant movement on collection and retention.
Fielding: A number of changes.... slide covers the changes from previous drafts. No surprises....
<moneill2> <doctypemissing again
... trackig status values: a number of proposals were added.
... 5.2.2. None (N) --- left this in as an option because it wasn't clear whether we decided to keep it in
... most of the differences are reformatting. Very few text changes.
<wseltzer> [fielding scrolling through http://www.w3.org/2011/tracking-protection/drafts/diffs/TPE-WD3-to-WD4.html ]
Fielding: main new things are: "!" means "not-compliant, "D" disregard....
<sidstamm> and P means "potential consent"
<dsinger> Notes that some of the re-organizations and section movements make this look scarier than it is.
@JC, can you take over? Some of this is beyond my tech understanding...
Fielding: trying to address multiple first parties and indicate who is listed as the responsible data controller for that service... the domain may not indicate this
<schunter> IMHO: I believe that no scribing is needed; the DIFF speaks for itself.
<schunter> ;-) The code is the documentation ;-)
@schunter: works for me
DSinger: Exceptions changes...
... look scarier than they are.
... worth repeating: the challenge of getting consent from the user lay with the site. The duty of explaining the exception is left to the site.
Fielding: list of acknowledgements at end of the document. If we missed anyone, please let us know
Schunter: Any questions on spec?
SWiley: how do we handle c-name parties? Do we need to name them seperately?
Fielding: use the name of the controller.
Swiley: is controller optional or required?
<jmayer> Question: are we discussing objections now?
<jmayer> Or just clarifying questions?
Fielding: optional in some instances, required in others.
<schunter> Clarifying and understanding.
<jmayer> Ok, thanks.
Swiley: this is the work around service provider -- trying to address transparency concerns over who has control over data.
Justin: the spec doesn't include "disregard".....
Fielding: There are two options: 1) you have consent, or 2) data must be deleted.....
<schunter> Clarification: If you choose "P", you can not later disregard. As a consequence, if you do not like a signal/user agent, you need to send disregard immediately.
Jmayer: Wants to hear more about use cases for the "P" flag -- how does this play out in practice. Why is existing consent flag inadequate?
Fielding: the main goal of the "P" flat is to allow services that collect in real time but do not process data in real time to function.
... this allows those entities who process data on back end to adhere to DNT. These entities throw away data within 48 hour period if they find that they don't have consent.
<npdoty> we have a thread with Ronan on the mailing list which might explain the detail, jmayer
<dsinger> answering Jonathan, we asked…and we were assured it was hard
<npdoty> I don't think it has to be done in 30 ms, since it's the loading of a separate tracking status resource
<schunter> for status resource: yes. AFAIR, it can also appear on a response header.
<npdoty> I really think reading the email from Ronan will help, if you want more info, jmayer
Fielding: doing a lookup requires a significant capacity.
<sidstamm> jmayer, I think the issue is that many systems do batch operations to identify out-of-band-consent, and don't do it in realtime
<jmayer> Alright, now I'm even less comfortable with this. A site's crufty implementation doesn't allow dynamic checking for DNT consent (e.g. a "Consent=True" cookie)... so it gets to prospectively collect short-term browsing history from users.
<JC> Chapell, we can switch in 5 minutes
<jmayer> Sid, I get that some implementers may want to go that route. But the tradeoff is a substantial impact on privacy for users who haven't actually given consent.
Schunter: if other questions, please post to mailing list
<justin> I think I prefer P to 3. At least with P you get an indication that there's an open question about whether there's consent or not.
<jmayer> Justin, I'm fine with a signal that a site thinks it has consent. But if it's not sure, it should become sure, not get to make an assumption and start collecting.
Schunter: sites want to ensure that preferences are coming from users in a reliable way.
<wseltzer> [slide 5]
<jmayer> The problem is false positives: what about all the users who didn't actually consent? That could, potentially, be almost everyone.
<JC> Chapell, I'm ready
<JC> scribenick: JC
<jchester2> I agree with Jonathan. This has an impact on privacy and we need to fix this.
<Chapell> JC, sounds good
Schunter: What is okay an install dialog for a browser requesting user DNT preference
<Chapell> scribenik, JC
Schunter: it is not okay to set a preference without contacting user
... how do we enforce this
Efelten: This seems to focus on products instead of getting informed consent
... why would the group be against a router getting informed consent
Schunter: To be clear we are against a product coming preset with a value
<justin> jmayer, yes, for presumably nearly everyone getting the P signal there would not be consent. I don't like this approach but I don't see a better alternative (ending use of census data for non-DNT:1 users, , exception for market resesarch)
Schunter: I don't have a clear decision if the spec covers whether an organization can set the default for a router
... DNT 0 or 1 should not come in firmware
<schunter> ac Chapell
Chapell: I am under impression that request for prefernce during install shouldn't be in spec
<jmayer> Justin, we covered this yesterday—privacy-preserving implementations, service provider exception are also options. And even if we give an exception here, let's not pretend it's about consent.
<rvaneijk> my question was not scibed: what about the alternative of not having the P flag. We had the discussion on the call that if you can not determine in realtime whether you have consent you should't be collecting data. The discussion on the call then went into a possible permitted use for short-term retention to determine consent.
Dsinger: it is not covered in the spec, but it is in the DAA principles
<rvaneijk> Roy explained that this is reflected in alternative 2. Is up for the compliance doc to address this.
Fielding: I believe section 3 discusses first use and the request cannot be done at install time because user may not be installer
<jmayer> Ok, so what if the installer is the user? Or the installer is someone acting on the user's behalf?
Schunter: If the user is installing the PC or browser then the user can set the DNT prefernece. The same for IT department.
... preference should be explicit and informed
<dsinger> we say "Key to that notion of expression is that the signal sent must reflect the user's preference, not the choice of some vendor, institution, site, or any network-imposed mechanism outside the user's control; this applies equally to both the general preference and exceptions. The basic principle is that a tracking preference expression is only transmitted when it reflects a deliberate choice by the user. In the absence of user choice, there is no tracking
<dsinger> preference expressed."
<justin> From Section 3: a user might select a check-box in their user agent's configuration, install an extension or add-on that is specifically designed to add a tracking preference expression
Schunter: according to the framework we do not want to allow install setting
<dsinger> so Roy is right; the IS dept installing it is not OK. The user doing his own install might be
<jmayer> Wondering how we'll have time to reach any agreement on contentious issues when we're still working through clarifying questions this late into the conversation.
Adrianba: It is not clear why this discussion is in the TPE. We don't need to cover the consent experience when it can be covered in compliance spec
<schunter> People are discussing my intro slides ;-)
Adrianba: are we trying to cover this area twice?
Fielding: how the preference is set changes the meaning of the protocol
<bryan> The key point about the router case is that unless it was selected by the user (or whoever is responsible for the user, e.g. a parent), a router-inserted DNT flag is not a "preference". So default DNT:1 without control is in violation, I agree.
<aleecia> Telling IS depts they cannot set policy is unlikely to work in practice
Fielding: changing who sets the value changes the protocol
... The UA on the protocol side is in TPE. What to do is in the compliance spec.
<johnsimpson> I'm reading section 3 explicit;y allows the user agent to ask at start up what their preference is. I am very very confused.
Fielding: we should not change the separation unless we want to change who the editor is. I'm happy not to be the editor.
Schunter: I would like to close the queue and move on
<schunter> John: Point is that if an UA is installed by the IT department then the preference entered would not be OK
<schunter> I will re-open later.
Sidstamm: I don't see the first run statement. We should focus on what we want the protocol to do. There needs to be trust on both sides for this to work
<aleecia> How do we test that (IT dept)?
<justin> How can you determine "user preference" on shared devices? fielding's analysis would imply that DNT could not be persistent across sessions.
Sidstamm: let's be overly prescriptive on what types of products are okay
<schunter> We have similar corner cases if I install and my spouse uses.
<Wileys> I trust web browsers vendor far more than the numerous UA "add-ons" and network intermediaries that are turning on DNT:1 today.
Sidstamm: if the user make the choice during or after install it should be okay
<schunter> Or one kid sets a preference (using the dialogue) while my other kid then surfs.
<aleecia> I think we cannot deal with the spouse issue -- and ought not to
Sidstamm: having it set by a router or other device is not okay
<Wileys> The cost to turn on DNT:1 (to "spray" the signal to quote Matthias) is amazingly low compared to the cost of websites and servers to implement their side of DNT.
<johnsimpson> The current spec clearly says "The user-agent might ask the user for their preference during start, up...
Efelten: What is justification for ruling out install time dialog when it is the user's choice?
<sidstamm> schunter, this kid v. kid problem is not something we can address with this. It's currently not addressable via adChoices either if they share a browser
<dsinger> Peter and I think the 'limited to browsers' discussion is on the agenda for later, by the way
<justin> I agree aleecia, just don't understand the logical difference between "at install" and "in the settings." I get the business rationale for it, but I don't understand why "at install" is any less of a user preference.
Schunter: I would like to permit this question as I have same question.
<fielding> justin, each user has their own profile for any browser, including their cookies -- that is persistent
<aleecia> I'm with you, Justin
<justin> (Stu discussed this on the last call.)
<justin> I literally asked this precise question a week ago, and Stu gave us a long answer.
<rvaneijk> issue 194 is much more about compliance then about technical building blocks. On the call it was addressed that TPE:3 should be cleaned up, to not contain compliance elements.
Chapell: One path forward for simplification was to let the browser set the DNT setting.
... one of the challenges doing this at install is the user may not be installer.
<aleecia> (disagree with Alan, but will take it up later)
Dsinger: The discussion has been about UA when that isn't always the case.
<justin> fielding, I'd be curious to see what % of people use profiles on shared devices. I have never seen them used.
Wileys: We need to discuss the introduction of signals and have the policy discussion this afternoon
<sidstamm> we shouldn't limit to particular types of things, lets define the desired effect ("reflects user intent") and go from there. Software that doesn't introduce the signals right is non-compliant. We don't have to make a list of valid/invalid things -- we'll miss many.
<peterswire_> +1 on shane's comment
Johnsimpson: I am amazed based on section 3 why we are having this discussion.
Fielding: First use is not install. The reason this is here is that by default DNT is not set
... cannot have user set if value is set for user.
<aleecia> What we have learned: someone who has talked about this for 2 years does not understand the text as it is.
<aleecia> This suggests the editors give it another shot to clarify the difference.
<aleecia> Could be all of half a sentence
Dsinger: systems often ask the user for setup values and may include DNT. This is okay, but IT department should not choose
<jmayer> What about a browser that is very often installed by users?
<justin> It is clear there is disagreement on this issue that needs to be worked out. We don't need to debate what the existing text means because there are still decisions that the group has waiting in the parking lot. Let's use this time productively.
Schunter: The underlying difficulty is that the software should ask the question if the user can respond.
<aleecia> Suggestion: take an action to update it.
<BerinSzoka> I also have a question I'd like to ask before we move on
<aleecia> Shouldn't take long, but let's update based on John's very reasonable reading, so other people not in this room have a chance to understand.
<efelten> Is there a justification for that position?
Lmastria: The draft framework indicates that DNT is not set during installation.
... I believe first run is similar to install
rvaneijk: There should be a cross-reference or cleanup to indicate connections between TPE and compliance docs
<npd> There will certainly need to be final cleanup.
rvaneijk: we should not over complicate the TPE and disentagle the compliance segments from TPE
<wseltzer> [slide 6]
Schunter: we assume there are UA that comply and other devices may send a signal. How do we know the difference
<trackbot> ISSUE-194 -- How should we ensure consent of users for DNT inputs? -- open
<wseltzer> [slide 7]
Schunter: a site needs to be able to do something if it feels it received an invalid setting
... there are UAs that will send the signal in compliance or out of compliance
... how can a site tell if a signal was properly generated or noise?
<wseltzer> [slide 8]
Schunter: there are three alternatives. 3. Do nothing, rely on existing data, UA string or something else
... 2 use an authenticated channel to send the signal
Schunter: 1 change the signal definition to determine how the signal was set. For example, adding a 'U' to indicate that user set value based on spec
<dsinger> [dws] or we change the signals as we publish, so we can distinguish the historical UAs from those that actually read the spec
Schunter: to make sure site is not overwhelmed by signals the site should be able to distinguish between valid signals and act accordingly
BerinSzoka: Important to have compliance signals on both sides. Let's come back to that later
<schunter> Proposal: "N" for non-browser
<aleecia> How will that work in practice?
Wileys: With alternative 1. I would like to see the use of 'N' for non-UA device setting signal. That would tell us that something other than UA set value
<aleecia> Specifically, IE reads a registry setting from IE, or not from IE.
Wileys: I think that would make it simpler and cleaner
<schunter> "f" for "framework-based UA/browser"
<npd> Wileys, maybe 1N or 0N, to clarify which signal that agent is setting?
<bryan> how do you trust the UA string? are you going to limit DNT to a known set of UA headers?
<aleecia> Shane can you help me understand your proposal over IRC, or shall I add myself to the queue to ask how you imagine that would work?
<schunter> 2 Problems (A) Truly legacy signals and (B) things that try to send signals that appear valid
Efelten: Why are we ruling out non-browsers? We can't stop parties from misbehaving, just like we can't stop servers from sending something invalid
Wileys: I'm not disagreeing with Efelten, I'm just saying that we should be able to know how the signal was set
Schunter: The legacy problem is something that is easily solved by changing the signal.
... Forged signals is something that we largely cannot solve
... I don't see how the protocol can solve this
... we should be able to distinguish between legacy signals
<dsinger> +1 to JC; we can't close this door without digital signatures and so on. We can orphan the legacy, which may be prudent...
<bryan> why would it considered invalid if the extension etc that set DNT could be proven to be serving user choice, just like any browser?
<npd> If a browser extension complies with all requirements, does it help if it adds an extra "N" to the DNT header?
Jmayer: What solutions do people have in mind. Non-browser software that modifies DNT could be an extension, which have nearly unlimited ability
<schunter> I think that the dialogue how to prevent forgers is one that is similar to a dialogue to prevent sites that pretend to follow DNT without doing so.
Jmayer: how would you prevent that. The other major way is via a proxy and similarly how would one stop a proxy from setting DNT 1.
... There is not much one could do to stop it.
<Wileys> Jonathan - understood we cannot prevent (unfortunately) - looking to separate UA direct setting from in-direct setting through add-ons and 3rd party software packages.
<npd> I think Shane is suggesting *not* trying to prevent fraudulent signals
Schunter: We are not looking for a bulletproof solution, but swithching the signal will tell us if someone pretends to follow the spec
<aleecia> Shane I'm listening, but how do you do that?
Schunter: If the browser states that it follows the spec then we should be able to see this and they will get into trouble
Dan_auerbach: Quick suggestion, to the extent is network intermediaries, https would prevent that
Schunter: I agree that https would prevent modification of signals
Dsinger: Question to Wileys, what does the change in signal do for us
<schunter> I prefer affirmative statements "I promise X".
<Zakim> dsinger, you wanted to ask why we need to distinguish the non-browser UA?
Wileys: If I received an 'N' i can determine the source of the signal
<justin> The draft Framework seems clear that third parties could ignore N DNT signals.
Wileys: we talked about sending an augment UA string, which would to be too heavy
... the simpler signal helps me separate where the signal came from and who is lying.
<dan_auerbach> shane, are you saying https won't work as a solution particularly for preventing inteference from network intermediaries? if so, why?
Wileys: From there I can make a decision on how to respond
<amyc> not sure that I understand what problem new signals are solving, regardless of new signals sent by UA, site may still disagree with how signal set based on existing data (for example, if it doesn't like signal set during first run)
Wileys: I may decide only to respond to UA set signals
<npd> They are lying if they send dnt: 1 while not following the user requirements, right?
Fielding: The technical decision between a UA set the signal or not is difficult to determine
<npd> "I really mean it" :-)
Fielding: I really want this to work, but using "i really mean it" pushes everyone to say "I really mean it" everyone pretening to be a UA
<schunter> We may be constrained (by technical possibility) to only orphan the legacy (without solve the forgery problem).
Fielding: I cannot overemphasize enough that there is restriction to adoption on the server side and the more the UA side sends invalid signals adoption will be affected
<jmayer> We have now heard from an editor of HTTP, a Princeton professor, Mozilla's security lead, and others that there isn't a viable technical solution here. Time to move on.
<BerinSzoka> Amen to that but I doubt persuasion alone will suffice. there needs to be legal consequences to gaming the spec by sending non-compliant signals
<npd> +1 to fielding, it's on us to convince that it helps users not to send invalid dnt signals
<dsinger> +q to Roy also
<vinay> I agree, Berin
Rvaneigk: Referring to DAA framework, the host controls what data is shared and to whom. Will the SafeFrame help protect the user from unwanted sharing?
<Wileys> Jonathan - we all agree there is no air-tight solution here - that's understood. I don't believe it harms the standard to have non-user agent string DNT setters to send a separate signal. Will some lie - yes! Will some tell the truth - yes.
<npd> Chris to think that over, thanks Chris
Aleecia: For a test signal we can say we can use old signal to say I am testing and new signal can be I am compliant
<schunter> Aleecia: DNT:1 may be declared as "testing DNT"
<sidstamm> Aleecia, kind of like an X- header that, when standardized, drops the X-?
<dsinger> so '1' on a UA is like '!' on the site-side; we are in pre-deployment. nice. then you switch to DNT:True or whatever we say. nice
Aleecia: Second point, as long as IE has a registry setting that anyone can set it will be a problem unless IE changes that
<schunter> Problem (technical): Non-browsers can tweak registry to make browsers send dnt signals.
<rvaneijk> referring to IAB Safeframe as a possible solution? would like to hear more about that. (https://www.iab.net/safeframe)
<chris_IAB> rvaneijk, re your question to IAB about SafeFrame, can you please elaborate on your idea? Not sure I understand yet where you are going?
Aleecia: Does Microsoft have plans to have two different settings
<jmayer> Is the aim to provide a hook for deceptive business practice litigation? That we could do (though unsure we should do).
Adrianba: We won't have two settings because we have one setting for us.
... the purpose of the store is to store our setting and having a second value serves no purpose
<justin> WileyS, why would anyone ever send an N signal if no one is respecting those signals? I'd not necessarily averse to the signal, but trying to play out what will happen . . .
<chris_IAB> rvaneijk, SafeFrame uses a form of post message to communicate between the host and the 3rd party.
<npd> Jmayer, I think that is the aim.
Wileys: in response to question, many of modifications of signals happen in flight and not based on a registry setting
... AV and routers set the value on the line and we probably wont go to https tomorrow.
<rvaneijk> chris_IAB: and could carry the transmission of user preference, right?
<jmayer> Nick, then let's be honest about it. This is about a legally enforceable representation of compliance, not a technical limitation.
Wileys: using 'N' is not airtight, but we are attempting to add balance to reduce ability to game system
... implementing code is not hard. Implementing work on the server side is hard.
<justin> WileyS, OK, I understand now.
<npd> I don't think anyone is hiding that. Is there anything we can do to facilitate legal compliance/enforcement?
<bryan> it's not a lie if user choice is actually being expressed through the header, regardless of how sourced
Peterswire: Ship and dock scenario, ships have things to invest in and if it won't work they won't invest
<johnsimpson> +1 to Bryan
Peterswire: is there a structure where we can encourage the investment.
... Secondly, there is no airtight technical solution. If a commerce company makes it business lying on a massive scale, they are taking a risk
<Wileys> Bryan - the key question - is it a user choice? If I don't know who is setting the signal, then I can't tell.
<npd> Bryan, but you would agree that it's a lie if it wasn't a user's choice?
<dsinger> for the record, I am totally sympathetic to Shane's concern. But like JC, I can't see how to address it (apart from 'moving the goalposts' by changing the final signal)
Peterswire: that is not a technical answer, but the muckiness of law gives a reason for there to be discipline in the system
<Zakim> rigo, you wanted to suggest not adding new strings with reference to Ed's example running watch with web interface
Rigo: The cost for having another signal is too high compared to the gain that we get
<Lmastria_DAA> peterswire_ is right. gaming of the system is a concern and having non-tech solutions has to be part of the solution
Rigo: We have to produce a future proof idea that addresses the web of things, I don't see how something other than 1, 0 or unset is useful.
<bryan> Shane - all we need is a mechanism to tell who it setting the signal. That's something IETF could address, if needed.
<schunter> How about 2, 3, unset.
Rigo: on the server side we can use heuristics or baysian functions to analyze the signal
... very low gain and high cost to adding signals
<npd> Lmastria, is there anything we can do to facilitate those legal / market measures?
<bryan> nick - I would agree that a verifiable violation of user choice would be a lie.
Schunter: Firstly, are people are okay with changing the signal to find legacy signals? Only user agents that follow the rules can send a preference.
<efelten> It's not enough to say you want enforceability. You need to explain how this proposal makes the system more enforceable.
Schunter: Secondly, no solution is perfect. Shane wants to distinguish UA from other tools, and legacy tools from tools that follow spec.
<adrianba> when does new start?
<npd> Bryan, Lou, if we document that very clearly, as an industry consensus, that could help with FTC or lawsuits, right?
<schunter> After first call.
Schunter: We should creat an issue to address how to determine if UA foloow spec
<rigo> efelten, enforceable towards user agents or sites?
Fielding: I would rather go down this right. I would want to determine if UA follows the spec.
<aleecia> I'm hearing two issues intertwined.
<efelten> Rigo, the discussion here is about enforceability w.r.t. user agents; but similar principle applies on the server side.
Fielding: If an intermediary always send a DNT 1 we may be able to find that out
<bryan> nick - i would hope, so, but IANAL. A clear indication of compliance expectation should be applicable to any implementation.
<schunter> If we change the characters, then disregarding the legacy should be permitted.
Dsinger: what does the room think about changing the signal. Okay.
Dsinger: Hum on the negative indicates changing signal probably not helpful
... maybe we can come up with better idea
Schunter: Should we take a break?
<aleecia> coffee :-)
<rigo> I still think requiring the exception API to work for conformance would work
Dsinger: Going to break Rigo will scribe
<npd> 11:15 back.
<jmayer> Off to class, will be back for the afternoon.
<jmayer> In anticipation of the upcoming topics: I strongly object to the "D", "!", and "P" proposals as written. My thinking on "D" and "!" is on the mailing list, and I articulated my view on "P" earlier.
<justin> schunter, are you on? We can't hear you.
mts: welcome back
... no intro
... slide 
... reaction to unreliable signal, e.g preconfigured signal from a router.
... my belief is that the signal is not conformant, site does not have to react
... 3 options:
<efelten> To clarify: the suggestion is that sites have the *option* to reject, or ignore, right?
mts: a/ sending D back
... b/ saying nothing, not responding
... c/ rather safe than sorry, apply DNT:1
mts, these are the opinions I saw on the list
<bryan> matthias - how do you know the signal is not conformant, that it was not set by the explicit choice of the user?
ed: your alternatives, the sites would have the option to ignore, or required?
<aleecia> To add a 4th option we have discussed: site can ask the user to confirm.
mts: the option, they can react on signals from routers
<dan_auerbach> +1 to aleecia
<aleecia> So the site does not have to blindly accept, but can also make sure they do not ignore valid.
mts: after determining that signal is unreliable, they can decide what to do with it
npdoty: d/ be silent on this, just not having feedback
... signals should be so reliable that every signals will be respected
<dsinger> does anyone want a change to the document, or is this an exploration of where we are?
<justin> Is there anyone actually arguing in favor of Alternative 2? I thought there was universal agreement that was not viable?
<npd> I agree that D is a useful signal for when you're not complying with a potentially unreliable signal
mts: take step back, protocol discussion. What should you do on the wire. You can feedback, redirect user, clarify the signal. First signal on the wire, what should the response say
<fielding> a first party can clarify -- not so easy for a third party
aleecia: understand distinction, lets clarify, sending back "I'm not sure" and re-direct to disambiguate
<npd> aleecia, would that be implemented differently than "D"?
<Wileys> Aleecia - 3rd parties would likely not have that option
<npd> We even indicate 409 as the status code?
adrianba: common for protocol to have signal for error case, here signal sent in incorrect situation, dnt:73, currently D comes with URI that explains why it was rejected, seems like a reasonable thing to have
<schunter> Jonathan at some point promoted Alternative 2 (AFAIR)
moneill2: option to reconfirm an unreliable signal,
<justin> schunter, I somehow doubt that jmayer is advocating that third parties could disregard signals deemed unreliable without feedback.
mts: if you reconfirm, it should reconfirm both ways
... agreement that the UA should be told that something went wrong
... not silently swallowing the signal is agreement. Nobody is for alternative 2
... after telling UA 'something went wrong'. Now what behavior to assume, 0/1/unset? After assumption do we want to require sites to reconfirm?
hefferjr: third parties will not be able to reconfirm, Most websites will not allow that to happen
dsinger: we introduced this to have transparency
... reason of disregarding. Not an invitation to disregarding signals
<npd> Is it possible with tk:D and an edit link to handle confirming signals?
dsinger: concerned that we don't say anything
<hefferjr> small correction to what I said: it is not that 3rd parties will not be able to reconfirm; 3rd parties will not be able to ask the USER to reconfirm.
<dsinger> [dws] is concerned we don't say that the compliance of "D" is indeterminate, and this is not an invitation to be capricious about what signals you respect and what you disregard
<schunter> Similarily, user agents have the option to mitigate once they have been disregarded.
<dsinger> to roy: we could say that this signal can only be used in response to non-compliant signals or under court order or similar duress
<npd> If you're not complying with the spec, you don't have any requirements.
mts: if you disregard than you have to say so
fielding: protocol is saying disregard, explanation is in the policy
<schunter> Silence should not be an option.
<aleecia> right, users have no way of knowing which 3rd parties are on a page at a given time (reload, world changes)
<npd> Noncompliance with the spec will always be an option for implementers, of course.
<sidstamm> can the context for the D be optional?
ChrisPedigoOPA: not overload signal, default is probably biggest issue.
<Wileys> Anyone in the WG arguing against option 1? Matthias - can you please ask the room so it'll be possible to close this issue?
mts: people are feeling comfortable by having a signal back to UA
<Wileys> Apologies, "Alternative" 1
sidstamm: D = disregard because something went wrong. Let's make context optional.
mts: good point
<dan_auerbach> +1 to sid
<npd> Less confusing than no response. +1
<Marc> Sid, why is it valuable to the UA?
<sidstamm> Marc, it gives us feedback
<aleecia> problem: define "clearly"
<Wileys> +1 to Sid - context/explanation is optional
mts: anybody having trouble with option 1?
<sidstamm> Marc, it's better than absence of reply
<justin> Mandatory D, optional explanation.
<aleecia> if you define "clearly" in a way I agree with, I can agree with the rest, but that seems unlikely
ChrisPedigoOPA: if disregard, will it be required to send D
mts: required to send D
fielding: requiring D would be a thing for compliance, able to send is TPE
dan_auerbach: concerns about what unreliable signal means in practice
dsinger: there are many cases why you need a D signal
<npd> I suggest we are silent as to why you send D, but adopt the ability to send D
<aleecia> sounds like an action item to add to compliance?
<aleecia> just in case we're still doing action items :-)
johnsimpson: are we saying that option 3 is off the table.
<schunter> Agreement: (A) if you receive a incompliant signal, you may reject it by sending "D"
<npd> I think the question of 3 is Compliance (and I have suggested we just be silent)
fielding/dsinger about what is normal approach in protocols and how do they fail
<schunter> I agree.
<sidstamm> npd, you mean make it available but don't MUST it?
hober: you can see that they reject
<npd> But the TPE question is whether we should define the ability to disregard with a signal
<npd> I think available is the only thing we can require, sidstamm, because entirely non compliant servers won't reply at all
fielding: under alternative 3 we would not implement DNT
dsinger: agreement on option 1 and figure out the details.
mts: how to develop guidance for unreliable signals should be described be done in TCS
<npd> Isn't the D the response from the 3rd party?
mts: if IP address from third party, could i discover?
<jeffwilson> it seems unrealistic from a ux perspective to have every third party confirm every ie10 signal
fielding: they could check TSR before retrieving
<sidstamm> can we agree to accept D and push the design of the "optional context" to an issue?
<npd> Aleecia, I think alternative 1 is that agreement, yeah?
<aleecia> This is discussion of how to make 1 at all possible, and we still have issues with it, but this is one of two to solve
dsinger: 2 issues: compliance rules aroudn the D signal and how does the user clarity on why they received D to do immediate action
<peterswire_> as compliance co-chair, I'm glad to have those items added to our list
<aleecia> (The other is: uh oh, a user set DNT:1 under IE 9, upgraded to IE 10, and is being ignored. That's lawsuit central and make my head throb.)
<aleecia> either way of those can work
<schunter> If "D" is sent, the the "policy" member of the WKR should be mandatory.
<aleecia> either Matthias' mandatory, or the optional
<npd> Dominique is representing eBay.
Dominique_: 183 class actions against privacy policies because criticized by FTC
mts: keep D signal and iron out subissues?
<npdoty> issue: compliance requirements about when disregarding a signal is allowed
<trackbot> Created ISSUE-196 - Compliance requirements about when disregarding a signal is allowed; please complete additional details at <http://www.w3.org/2011/tracking-protection/track/issues/196/edit>.
<aleecia> DNT will apply to more than your companies, but if you have best practices to point to, that's great!
<npdoty> issue: how do we notify the user why a Disregard signal is received?
<trackbot> Created ISSUE-197 - How do we notify the user why a Disregard signal is received?; please complete additional details at <http://www.w3.org/2011/tracking-protection/track/issues/197/edit>.
<npdoty> issue-196: for Compliance
<trackbot> Notes added to ISSUE-196 Compliance requirements about when disregarding a signal is allowed.
fielding: object to create ISSUE-196
<npdoty> issue-197: might already be covered, in TPE, by existing text
<trackbot> Notes added to ISSUE-197 How do we notify the user why a Disregard signal is received?.
<npdoty> if someone wants to fix typos in my issue titles, I welcome that
<npdoty> issue-196: Roy wants to re-title
<trackbot> Notes added to ISSUE-196 Compliance requirements about when disregarding a signal is allowed.
mts: going through current issues: slide 
... ISSUE-112 Cookie matching rules
<trackbot> ISSUE-112 -- How are sub-domains handled for site-specific exceptions? -- pending review
mts: important to provide text. If you complain you can only do so by providing text
mts ... explaining issue-112
<npd> Optionally, if you use the domain parameter
<npd> If you don't, its fully qualified
mts: if ok, will send reconfirm before closing.
no questions on issue-112
<trackbot> ISSUE-147 -- Transporting Consent via the Exception / DNT mechanisms -- raised
<npd> 112, no objections in the room
Do we need a service provider flag?
<trackbot> ISSUE-137 -- Does hybrid tracking status need to distinguish between first party (1) and outsourcing service provider acting as a first party (s) -- pending review
<npd> Controllers, not same party, right?
<sidstamm> -phone disconnection-
mts: current flag would only work with same-party element in well-known resource
<aleecia> Matthias, we're working on it
<schunter> I thought silence means agreement ;-)
<aleecia> talk really fast!
<schunter> NPD: It is same-party (not controller)
<Zakim> dsinger, you wanted to distinguish 'as a matter of course' from 'ever'
<npd> They can signal tk:1
<aleecia> +1 to dsinger, plus also non-browser UAs
<dwainberg> How does this work for service providers to 3rd parties?
<trackbot> ISSUE-196 -- What compliance requirements apply when a signal has been disregarded? -- raised
<aleecia> When do you need me to once again say we need a SP flag?
<aleecia> Because I can repeat myself. Again.
<npd> I think Tk: 1 is a clear response
<aleecia> Great, ok:
dsinger: need to clarify that the service provider flag is possible, will provide text for clarification
D.wainberg: how does that work for 3rd parties
<npd> Tk: 3, with a controllers element in the TSR
dsinger: have to refresh my memory and write it up
<tlr> +1 to nick
mts: service provider will perhaps not be visible to end users...
npd: no objection from the room
aleecia: say the things that I always said, service provider is not a first party, need transparency, invisible parties are a deal breaker, can deal with them lightly. Not fair.
<aleecia> Roy and I could write each other's points :-)
mts: aleecia has sustained her objections
<schunter> Roy, too.
fielding: sustaining objection against the objection
<aleecia> We must be as bad as things in the past?
<aleecia> That's absurd.
mts: not ready to close issue-137
<aleecia> I'll take that as a reasonable next step, without withdrawing my objection here.
<aleecia> But I think that moves forward.
dsinger: wait for my writeup before. Roy has it mostly covered, but not visible
<npd> Maybe we can then run though the decision policy on this? Call for Objections, etc.
<dsinger> ACTION: dsinger to explore how service providers (to 1st and 3rd parties) can provide transparency, and work through the use cases [recorded in http://www.w3.org/2013/05/07-dnt-minutes.html#action01]
<trackbot> Created ACTION-400 - Explore how service providers (to 1st and 3rd parties) can provide transparency, and work through the use cases [on David Singer - due 2013-05-14].
<trackbot> ISSUE-152 -- User Agent Compliance: feedback for out-of-band consent -- pending review
mts: aleecia, not being able to express SP, but requiring as a MUST to have SP declared. But have at least the option to do so.
... objections against optional service providers
<aleecia> It serves a useful purpose :-)
<aleecia> By that logic, there is no need for transparency to 3rd parties of any type
<aleecia> We do not have data controllers in the US
<trackbot> ISSUE-152 -- User Agent Compliance: feedback for out-of-band consent -- pending review
<aleecia> dsinger: heh
<aleecia> "It's none of their business" where their data goes?
<trackbot> ISSUE-152 -- User Agent Compliance: feedback for out-of-band consent -- pending review
<aleecia> We're not going to agree Roy...
fielding: does not serve any purpose. As long as the controller is identified that is sufficient. Not possible to express how many service providers are involved in every request is impossible and beyond what we could do
mts: so waiting for David's text
<aleecia> I think it very much is users' business who collects, uses, processes their data.
<trackbot> ISSUE-152 -- User Agent Compliance: feedback for out-of-band consent -- pending review
<vinay> Aleecia -- if the website is using a service provider, their data is managed/used/controlled by that website. If the user needs to do anything with that data, they need to go to the website (controller)
<aleecia> If we cannot even agree on that after two years, well, that explains a lot
<aleecia> Vinay -- we don't have controller liability in the US
<aleecia> it's not how our legal structure works
<aleecia> and w3c cannot shift legal liability
<vinay> but there are (in most cases, and we're including it in the spec) to require a contract
<vinay> which brings legal liability to comply with the terms outlined in the contract
mts: we must require UA to always be clear about signaling UI for out of band consent. Currently optional
<aleecia> but does not shift all liability. Also, call me crazy, but I'd rather resolve things other than via lawsuits.
johnsimpson: seems we have in TPE we have the ability to send C.
npd: is about must signal in UI
<aleecia> Users should have visibility. SPs are just third parties.
dsinger: puzzled we have to disclose this one thing and not everything
<npd> I think we could have long closed 152.
<aleecia> (not that I know of)
<trackbot> ISSUE-153 -- What are the implications on software that changes requests but does not necessarily initiate them? -- pending review
mts: johnsimpson is still right if we still require "C" to be sent. If a site uses OBC, it should say so to the user, and wonder if we have that in the compliance spec
<fielding> aleecia, if that were true there would not be a category for service provider and requirements (like siloing) that one would have to obey to be a service provider. You can't have it both ways.
<hefferjr> issue 195?
<trackbot> ISSUE-195 -- Flows and signals for handling out of band consent -- pending review
<aleecia> Roy, I'd be fine with killing SP as a different class.
mts: similar to D signal, compliance guidance on OBC
peterswire_: if this is something we have to do in compliance
<npd> Agree, 195 is relevant, consent signal back to the user has otherwise been long settled.
dsinger: if you have consent to signal it
justin: there is an existing task for justin and dsinger
dsinger: justin is taking the lead
mts: can we close issue-152
npd: no objections
<trackbot> ISSUE-153 -- What are the implications on software that changes requests but does not necessarily initiate them? -- pending review
<npd> I might check when you send your email that we have the right language already in 153
mts: network tools and registry tools.. we do not want those to interfere, this is now discussed in issue-195, so want to close 153
=> no objections
<trackbot> ISSUE-167 -- Multiple site exceptions -- pending review
mts: explaining issue. Shane was not happy but could live with it
Wileys: discussion in cambridge, who does the weight to process the multi-site processing. Currently in iframes, we will figure that out in CR
<npd> Great, close for now, and ask for implementation experience
dsinger: we should postpone
<Zakim> dsinger, you wanted to suggest 'postponed' rather than closed
<aleecia> last call does not require all issues closed
mts: want to close it
adrianba: process lawyering aside, add a comment to what Wileys said. In Boston we agreed that it could be part of a larger solution, but wanted to stabilize the spec
<aleecia> Incidentally, the idea of "let's try to implement it and come back" sounds like a very helpful approach. Take note: I'm violently agreeing with Shane's approach.
<tlr> +1 to that. I think it's fine to say "we don't know how to handle this", and revisit as we actually move to last call.
<aleecia> I hope this doesn't change Shane's mind :)
peterswire_: question of macy's having a page on facebook. Muti-site on who is first party, multiple first parties
<npd> You could imagine using this for a series of sites operated by the same pair of first parties, but it's not so different.
mts: this is about multiple first parties on the site. so orthogonal. Calling exception API for 5000 uris? is there a short cut. Haven't found a way. Not multiple first parties on one site
<trackbot> ISSUE-195 -- Flows and signals for handling out of band consent -- pending review
moneill2: you can have one shared iframe, probably best left to CR and implementation, refine it in implementations
<aleecia> We handle normal agreement with +1 :-)
mts: close issue-167
<trackbot> ISSUE-155 -- Remove the received member from tracking status -- closed
<trackbot> ISSUE-195 -- Flows and signals for handling out of band consent -- pending review
mts: text written last week?
<BerinSzoka_> We *are* going to stop at 12:30 for lunch, aren't we?
dsinger: don't understand. If you have OBC you have to signal it
fielding: this is the P - issue
<justin> I have a clarification, but we decided it's appropriate for the compliance spec.
mts: don't need to discuss, people need to discuss issue 2.5.7
<rvaneijk> agree with Matthias, I proposed silence already on the list: http://lists.w3.org/Archives/Public/public-tracking/2013Apr/0202.html
mts: will not close this issue
<BerinSzoka_> good one, Ed
<BerinSzoka_> then let's stop
mts: now discussion of section 6 of draft framework probably too longto start
peterswire_: talked about this yesterday afternoon, talk about it this afternoon, e.g. UA vs browser
... how to handle split between TPE / TCS and who does what
mts: suggest to go lunch for now
<dan_auerbach> +1 to matthias and rob that silence on OOBC might be fine
<moneill2> when do we reconvene?
Reconvene in 90 minutes.
<moneill2> @npd, thanks
<moneill2> neat trick
<npdoty> scribenick: npdoty
Jon Callas hear to talk about security
financial auditing discussion
could be room for more parking lot discussion this afternoon
<Yianni> Nick, I can scribe
<scribe> scribenick: Yianni
Peter: Dan wanted fo follow up with the case of unique ID cookies, got in touch with Jon Callas
... the use of unique ID cookies for cybersecurity and fraud permitted use
Jon Callas: I should go to questions a little bit
scribe: value of cookies for a unique identifier
... they do not have a lot of main use for it
... I have seen from bad actors that they are using sophisticated malware
... actively adapting what they are doing. Organized like a business
scribe: against an attacker like that, a unique ID does not provide useful information
... it tracks the good guys
... bad guys delete them, remove them, swap them, occasionally send a spam message from grandma's computer
... occasionaly does one bit of click fraud, take a legitimate users cookie then hand it back
... on receiving end, you do not get much unique information from a unique id that is useful to track them down
Shane: Our security team looks at slightly differently
... attempts to use unique identifiers in different ways can be a signal
... can be differentiated from a normal use pattern
... sometime the identifier is a key signal in differentiating against normal traffic
Jon Callas: anything you can do to identify a bad actor is good
Shane: Just one signal to identify bad actor
Jon Callas: Is a unique ID useful for security, not very
scribe: not saying not at all
<rvaneijk> The question on the table is whether unique IDs are proportiate, given the fact that unique IDs are not very useful for security !
<moneill2> you would not need it to be a true unique identifier. Low entropy mult digit would do
Shane: In the battle of security, ever increasing arms race, any incremental value is helpful
<rvaneijk> helpfull is not the same as necessary
Shane: is it an important or critical element of overall picture, leaning yes
<rvaneijk> what surfaces in this q&a is that the underlying problem isn't clear
Shane: just a matter of degree, very not very, but anything that helps is important
<moneill2> so long duration UIDs not necessary
Roy: agrees with Shane, most common use of cookie is not the identifier, does not catch the most sophisticated but catches easy things
Mayer: if a cookie is transmitted from a server, could that be used in an anti fraud?
... does that have any value? Yes
<fielding> moneil2, correct, depending on what you mean by long duration
Mayer: If a cookie has been set by the user, you could read that user
Mayer: can you perspectively cookie a user for security? are you suggesting that is neccesary?
Shane: What do you mean by prospective?
<moneill2> cannot hear
Mayer: what do I mean by prospective. Adversary may swap cookies. You could keep those cookies for fraud prevention
<tlr> who joined?
Mayer: User turns on DNT:1 and don't and cookies set (no adversary), questioning the value of dropping the cookie because it may be valuable later down the road
Peter: permitted uses in compliance spec, permitted use to take action for anti-fraud and cybersecurity
... should there be a unique ID cookie for DNT:1?
... assertion by Mayer, is this cookie for DNT:1 users a very low security value
... if that is true, then use of cookie ID would not be that important for security?
... then unique ID cookies, would not be need for the permitted use?
Peter: for click fraud, it may be that unique ID cookie would not be that much help. So that could change how we view permitted uses
Shane: core premise of moving to idealist world
<moneill2> i switched my mike off, sorry
Shane: unqiue IDs in cookies do help
... could discuss efficacy, but it is a net positive
... with understanding that, then questions becomes, why wouldn't you immediately turn on DNT:1
... you just gave yourself an edge in that battle
<jmayer> +q response to the question
Jon Callas: want to make a privacy friendly system, and one that is good for security
scribe: does it justify tagging everyone?
<aleecia> Roy, I'm trying to understand the point you raised.
scribe: for security purposes, you could do something else that is as or more effective
<aleecia> I think you were saying what matters is if cookies can be set & read, rather than the content of the cookie. Is that correct?
<rvaneijk> now we are talking, security can be done in other ways, that are more effective.
scribe: If you saw something that was security related, you set on an alarm, I have far less problem with tagging
<rvaneijk> tagging everyone is not proportionate.
... works much better then tagging everyone
<aleecia> who's calling from NY?
<aleecia> New caller, please id
<fielding> Really hard to have this conversation in public (or even minuted)
<moneill2> you could use localStorage, but that would need JS to execute and can be detected
<jmayer> Just to get it in the notes: some participants from the advertising industry are presently chortling. How professional.
Jon Callas: Get some people to turn off ad blockers
Chris: you are in a world in a black and white scenario, we want to do things like security and fraud protection
... we need a way to track bad actors
... back to what is the definition of tracking
... if consumers understand that they can still track to stop bad actors that becomes part of the definition of do not track
... not setting cookies for security reasons, set cookies to operate business, and cookies are used for security and fraud
<moneill2> any crim would purge their cookies anyway
Jon Callas: okay with setting cookies for security purposes
<Wileys> Note: Jon Callas stated he'd be okay with setting cookies with unique IDs for security purposes (to keep the full statement in context)
Peter: Chris Pedigo raised this point, not discussing overall removal of permitted use of cybersecurity
... there is a side piece of unique cookies, and whether they would a big or small hit on securities
... may be a small hit on security because anyone can block cookies
<npdoty> ack jmayer
Peter: facially plausible that unqiue id cookie part may be very different from how it looked in prior statements
Mayer: it sounded like cookies were of limited value for security
... some interpreted what you said as the opposite of that view
Jon Callas: I find prospectively setting a cookie ironic or counterintuitive
scribe: if you saw behavior that warranted tracking, if you had cookies as part of you system, that seems reasonable
<Zakim> jmayer, you wanted to respond to the question
scribe: part of security system that you do in tracking down the bad guys
... incident response is a good way to put it
Mayer: Maybe it would helpful in framing thinking as security people think
<Wileys> Important to note Unique IDs in cookies are helpful in discovery - not only tracking - so all discovery value would be loss with only setting cookies once a user has been deemed "suspect" and then setting a cookie.
Mayer: from that perspective, cookies are easy to delete and swap. Do Not Track are no worse out that current opt out cookies
... anti-virus get rid of cookies, and lots of ther reasons cookies get deleted (up to 30% of users do not have cookies)
... there are all sorts of tracking technologies that are part of a more robust incident response
Jon Callas: we will do tracking in a certain way for an incident response is reasonable
Mayer: if and why do industry folks have a different view?
Peter: one, it would be helpful, for a version of what Jonathan just said
... second, reason to discuss this in not an open discussion
... offline we could have a discussion for things that are not appropriate for public discussion
Jeff Chester: I agree with Jonathan
scribe: I'm disappointed, I want to hear more from industry, given what we have just heard from John
... spirit of this meeting is to move away from polorization. I'd like to hear about other ideas and thoughts
ChrisM: when talking about security we use every means available
... we have a fiduciary responsibility to protect our uses, part of that is using the information that we gather to protect them
<justin> Do you have a fiduciary obligation to respawn cookies using HTML cookies?
ChrisM: the gentleman said that if you take away cookies, you would use other methods, which I agree, we currently use other methods
Jon Callas: it is hard to say a piece of information for security purposes, it is all useful
scribe: can you replace this one item with something else that gives as much or more security than a unique ID, I could do that
... I would get as good or better security
CHrisM: How would you get better security?
Jon Callas: I do not want to design the system right here and now, unique is already in the hands of bad actors to use
scribe: it is a public bit of information and attackers are free to set own cookies for own purposes
... part of mine it's not that useful, attackers can use as a weapon
<amyc> interesting article on fraud detection http://finance.yahoo.com/news/ebay-worked-fbi-put-top-120500693.html
Aleecia: I had a couple things
... not talking about security for first parties, we are not talking about keeping users safe
... just talking about third parties only
<Wileys> 3rd parties are equally interested in looking to protect against injection, malware, take overs, drive bys, etc.
Aleecia: anything that is a first party this is not an issue around security, this is a smaller scope problem that we pretent it is
... we are talking about view fraud and a couple other things
<moneill2> UIDs must not be shared though (if DNT set to 1st party)
Aleecia: this is for Roy, if I understood Roy correctly, they need to set cookies to see how cookies are set and read, rather than the content of cookies
... I wanted to understand that, and if that is what Roy was saying
Roy: not unique to Adobe and may not be what Adobe do
... most high end security monitoring is by third parties
... first parties do not have vision to distinguish bots from users
... what you are looking for are patterns to distinguish bots from humans
... over time bots are becoming more sophisticated and have longer conversation
... eventually does something that does not behave as a user
... third parties are doing this monitoring
... this looks like a 70% chance of an attack, third parties do not have definitive answer
... websites do not have access to that same data
... we do not expect that third party to be adhearing to that DNT signal
... it is happening for security purposes
Aleecia: that is already breaking do not track
Peter: security vendors who look accross sites
Jon Callas: when you hit a threshold, you are raising the quesiton is this fraudulent, then using a cookie
scribe: now its a unique ID that has raised some flags
Roy: means of identifying if they are a bad actor is the behavior on normal cookie
... those all add into patterns
... under normal operating procedure that is how you do security detection right now
<npdoty> I don't think we have any exception in the current draft for first parties to share data with third parties for security purposes
Roy: what we are saying is that we are not changing those regardless of DNT
Peter: how much does unique ID cookie contribute to the pattern?
Mayer: Roy is discussing, there are certain companies, third parties, that are in the business of providing security services
<moneill2> tracking via tracing IP addresses though the ISP (to get a crim) is different from tracking everone using UIDs
Mayer: we have talked about having an exemption for companies like that.
... that is very different from the conversation we are having thus far about third parties providign security services for themselves
<npdoty> ... though there might be a lot of people who think we need to adjust First Party Compliance to allow stated business purposes, which might include sharing security-related data
Mayer: as opposed you are a security company hired by first paty websites
... a seperate discussion
... line between prospectively setting cookie or looking at cookies already set
... if a browser sends a coookie, there might be value
... discussing value of a cookie when there isn't one
<moneill2> a pseodomised UID - I like it
<amyc> i thought we had discussed precise issue of security service providers as part of permitted uses discussion, where we discussed ability to use data across sites for security purposes
Jon Callas: you have cookie with field with unique identifier, may put something in the field for a specific incident
Roy: no one tracks you for more than 2 weeks for security, retention area we could work on. Just turning off cookies doesn't work
<jmayer> Recap, clarifying point 1: We're not talking about outsourced first-party security services right now. That should be a separate ISSUE. Clarifying point 2: The question here is whether setting unique IDs has marginal value, and if so, how much. We're not debating collection of cookies that have been set/modified by a user.
Chris: question for John, trying to understand when you said earlier that you could find other means to track bad actors. What other means are there that are not tracking?
Jon Callas: very narrow thing of tracking people who says DNT
scribe: if there was a cookie that went to everyone (opt-out cookie), those are part of the whole thing
... I'm talking about one field, the unique identifier
<npdoty> to amyc, we do have a second option in the Service Provider list, which would specifically allow service providers to share data across first parties for "integrity, security, and correct operation"
<moneill2> it can still be unique but its fine if it expires <X hrs. Bad guys will delete them anyway
<amyc> thanks npdoty, glad I wasn't making that up
scribe: we want to seperate good from bad actors
... may take longer to find bad actor if they do not have that specific cookie
Chris: if you enable DNT:1, you would enable do not track
... cookies are one mode, device fingerprinting is another
... timing correlation
... we are being asked not to use any of those things, all of those are off teh security table
Peter: not where the discussion is right now
<npdoty> amyc, I'm not sure if that still prohibits a first party from volunteering sharing data with others for security analysis
Peter: what I had heard is a set of discussion about unique ID cookies, and a specific request that those not be put on at time DNT:1 is on
... I have been told that unqiue fingerprinting is not unique but in buckets
... one of the topics that is a specific proposal or goal is to see whether we could get unqiue ID cookies taking out when DNT:1 is on
Chris: could we use other forms of tracking?
Peter: gets back to 1024 buckets
ChrisM: you don't use low entropy buckets to do security.
... trying to get clarification
<moneill2> unique identifiers as a term covers more than cookies, it also covers fingerprinting using JS
Peter: this request came in part from Mayer
Mayer: for over a year, there has been a proposal to allow companies, when they have indication of potential behavior, you could use any tracking
Mayer: if you see weird cookies from a browser that didn't set, you could use
... we are talking about, prospective use for all users, this idea has been floating around for over a year
Shane: back to statement you made 20 minutes ago
... a goal of a fraudster is not to get caught
Shane: way not to get caught is to look like everyone else
... showing up without a cookie, immediately suspect
... not an ideal outcome for a fraudster
... with that understanding, you begin finding elements of fraud
<moneill2> people who delete cookies are suspected of being crims?
Shane: 1. discover, 2. defense
... setting cookie, tells me that I now suspect them
... by prospectively setting, I remove one of the clues that I may be on to them
Shane: setting a unique ID once you suspect them, you are telling the fraudster they are suspecting them
Jon Callas: convincing a bad guy to go away is a win
Shane: best way is to lock them in to existing pattern
... don't want to tip them off
Jon Callas: without any identifiers, use of fonts and other techniques can identify
Shane: the concept of the overal GS call, they can use other avenues to block
... not saying we do not use that as well
... you said you could build better security, that assumes that they are not already at level of maximum security
... we already have multiple PhDs working on security
... lose of ID is always a lose
Jon Callas: trade off from privacy discussion
Alan: majority of this room are not qualified to have this discussion
ChrisM: adding to what Shane said, one other phase, prosecution
... there is defense and then prosecution
<peterswire> close Q
ChrisM: when handing over records, they have used unique id based off cooking to show harm based on a particular bad actor
ChrisM: how do you go backwards, how do you go back and issue a credit for fraud
Jon Callas: something that has occured to me, what if what you had was a field in a cookie that was encrypted in a way that was unique
scribe: it had some other things in there
... If you had something that was there, where everyone gets a new one, unique per transaction
<moneill2> low entropy pseudo unique ID
scribe: It sounds to me to not be a unique identifier, but has a security value
... we have been trying to understand definition of tracking
Roy: other aspect of security, accounting
<Chapell> Folks: most of us are not qualified to have this discussion. Many of those who ARE qualified are unable to talk in specifics. If we're still arguing over security and fraud exceptions, it does not bode well for our progress. Can we PLEASE move to a more productive discussion?
Roy: large campaigns, find out about click fraud after the fact, have to go back look at accounts and remove them from billing
... contracturally required to do so, hard to do if you do not know who they are. Most done by IP address, not sure percentage
Mayer: high level thinking, question before group: marginial value of propsectively setting unqiue IDs for lots of users
<susanisrael> isn't the whole point of a permitted use that it is a case where tracking is permitted because it's necessary? The argument is not that this is not tracking but that it is a case where tracking is necessary.
Mayer: based on discussion, there are serious questions
<dsinger> I am disturbed that we're talking about technology -- cookies, unique identifiers -- when we have done much better when we talk about principles and trust -- retention of data that can be linked to a user, and so on. If we trust a site is abiding by the principles, then yes, be slightly (more) concerned if they set a unique ID, but it's not -- by itself -- something we need to forbid, is it?
<jchester2> Alan. I disagree. This is a conversation on fundamental values, doing privacy for DNT in a meaningful well. It doesn't have to do with privacy expertise.
Mayer: have not heard from ad industry security experts, why there is so much marginal value
... burden has shifted to ad industry of why these cookies have so much value
... I would love to hear more about it, off the record
<Chapell> jchester2 this is not about privacy, its about security.
Peter: couple items of potential action items
<Wileys> I have done my best to channel ad industry security expert concepts in this area to the very edge of not oversharing IP specifics. This has been based on many hours of focused discussion on these topics. So while I'm not personally a security expert, I believe I've fairly represented their views on this topic.
<aleecia> We hadn't addressed that
Peter: point raised, not sure about what is said in current compliance spec, third party security services that get IP address accross a lot of websites
<Chapell> jchester2 we've heard a number of plausible arguments for in favor of security.
<jchester2> Alan C, we just heard from an expert you don't need to do this for security purposes, given the privacy issues. But we will continue the dialogue.
Justin: added language based on Roy's description. Roy could you look at language
<jmayer> Shane, after nearly two years of conversations, the advertising industry has produced nothing more than second-hand observations. Meanwhile, world-class security experts have suggested prospective ID cookies have limited value. The ball is squarely in your court.
Peter: I am not aware of objecting to that language, if someone has an objection look at that part
<Chapell> jchester2, we've heard from an expert that cookies can be replaced with other forms of tracking.
Peter: heard Mayer discuss marginal value of unique ID cookies
Peter: Shane explained loss bad actors at beginning and honey pot
<Wileys> I can write down all that I've said - I believe that more than clearly showed that UIDs are of real value to the security/fraud battle. The current expert could not disagree with any of those points.
Peter: response back was that privacy implications were greater
... we did clarify what as in and out of discussion
... I have not heard why the things Shane said were de minimis
... we clarified issues, I will consider this part of the discussion closed
<jchester2> Shane, I disagree with your interpretation. But the debate will continue
Peter: we have a short other piece of unique IDs with financial accounting
<Chapell> jchester2, we've also heard from other experts on needing market research for advertising to continue to foster internet growth. But, we will continue the dialogue. (:
<Wileys> Jeff - the discussion is scribed - not sure what there is to "interpret"
Peter: step 1 - permitted use of financial auditing and accounting
<aleecia> This is not meant to sound snarky -- did we make substantive progress on this discussion?
Peter: variety of statements of how information was needed in the permitted use
<justin> fielding, I'm not sure your language was added. I think I held off because someone else was working on text too (perhaps amyc?). I don't know that that ever got done, so I will incorporate your language.
<fielding> aleecia, I heard consensus on the text in 188.8.131.52 ;-)
Dan: As part of doing research, cookie data on impression was not part of financial accounting
<npdoty> justin, fielding, amyc, we have language (perhaps from amyc) in the Service Provider section
Dan: safari users cannot possibly be breaking financial reporting and auditing
<aleecia> we should define tracking in section 6.6.6
Dan: real world were unique IDs are needed
... happy to get into details
Peter: there is a cost per action advertising
... someone takes actions, clicks, and then they get paid
... user has taken an action, so would become first party, allows collection
... second, cost per click add, when you click there is a meaningful interaction
... those important things would not be affected by DNT
... third is cost per impression
... here the user did not have a meaningful interaction
... that is the core piece going forward because still a third party
... whether that piece, cookies get saved in accounting system
Dan: I would say mostly right, cost per click, they are a first party
<justin> npdoty, right, it's in Service Provider (or at least on the options). fielding had also suggested a change to 184.108.40.206 I thought, but perhaps not necessary now?
Dan: for conversion event, maybe not that clear
... haven't seen any evidence, interested in needing information from user for CPA
DavidW: I think there is another model, you are assuming the CPA that the attribution comes after a click
... the attribution could come after an impression or multiple impressions
Jeff Chester: discussion about attribution model, series of actions
Peter: want fact finding, area where more knowledge could clarify the issue
Brooks: echo David's question, much of the backend analysis is a two point measurement event
... when you are in two different contexts, you are a third party in one of them
<fielding> justin, I can't remember exactly, but I think my suggestion predated the current security text … it looks fine to me as is.
<justin> fielding, excellent.
Joshua: for CPA, people are correct that saying it is a linking of event to prior events, possibly impressions
<npdoty> justin, fielding, yay!
Joshua: not a single linking, attribution is about series of events
... attribution model may be validation model
<Wileys> Will be discussing frequency capping / pricing when my turn comes up. And address the loss of revenue on Safari 3rd party cookie blocking.
Joshua: want an effective cost per action
Dan: Is there a real world place, where I can see these attribution models in effect
... want to learn more about how it works
<dwainberg> tlr, don't know why that happened
<tlr> dwainberg, we're tracking you
Dan: if there is an ad netword that uses this model you talking about, I would love to see it
... for Safari uses without cookies, what happens with that
Shane: Ad pricing CPM, CPA, CPC
... Safari has hit revenue
Shane: we have been moving toward CPM, impressions
... some advertisers may give you more attribution for view through, general ranges
... we also lose on frequency capping
<moneill2> firefox 22 tomorrow
Shane: I cannot demonstrate to an advertiser only show this ad 3 times
... I cannot prove in an audit that I did that because I do not have a cookie ID
... generally we will lose on that side as well
<npdoty> I'm curious about moving away from CPC -- Safari users can more easily be tracked when there's a click, right?
will be priced down due to Safari blocking cookies
Shane: lower percentage based on market share
... with Mozilla, percentage becomes much more significant
<moneill2> then firefox os
Shane: then it really does begin to destroy business models
Dan: frequency capping, will have discussion elsewhere
... important to distinguish between breaking business model, and where financial audting won't work
Shane: Yes, I can't bill CPC, CPA, or frequency cap, and I cannot prove that I did that in audit then I lose that business
<jchester2> Can we have someone from Apple speak to respond
<moneill2> firefox, safari, etc. could be back in play if we have a tracking consent aka exception API
Shane: Already lose in Safari, magnify that in DNT setting
Peter: I think I heard Shane say, all I can do is bill for cost per impression
<justin> Still don't understand why CPC doesn't work, but I get why CPA has problems without unique cookies.
Shane: one of the things I said, even impression level billing is difficult, how do I seperate non-cookie ID and fraud
<jmayer> Justin, there is no problem with CPC and Do Not Track.
Shane: cannot defend with an audit that it is not fraud
<npdoty> justin, I think Wileys is suggesting that cost-per-click is hard to distinguish from click fraud for Safari users if they don't have a cookie history of the impression (and maybe for some reason they can't do this through other means)
<peterswire> close q
DavidW: backup for a second, purpose for these models
<moneill2> the ad industry needs consent
DavidW: role of advertising is to support free content, these models allow advertisers to understand value
... we would create more ad inventory, race to the bottom, bad user experience
<jchester2> But there is a way to do attribution that also protects privacy for DNT:1 users
Rigo: If I understand, you put something in fraud bucket, you have exception for security and fraud
... we have a clear purpose limitation, for your reporting, you can use but for nothing else
... if you collect for reporting, at the end of reporting, just get rid of the data
... for frequency capping this is a convenience. How fast are you willing to innovate?
<justin> npdoty, Got it, doesn't seem that black-and-white, but if cookies are useful for combating click-fraud, I get can see why CPC would be marginally less reliable (but not unauditable or usable, since I think it was clear from last speaker that cookies were of relatively limited value).
<npdoty> dwainberg, if the concern is any decrease in revenue is too harmful to the user experience to allow DNT:1, then is there any restriction (like against behaviorally targeted advertising) that's acceptable?
Mayer: In thinking for this permitted use. What information do you need, action counting. Let's see if there is a way to do if there are not unique IDs
<rachel_n_thomas> rachel whispers at zakim that she's been very quiet today and would like to speak
Mayer: make sure to flag, one reason that I have reservation about permitted use, we built a system that allows attribution from an ad
<Wileys> Many technical solutions that work in a small lab break at scale because the smaller implementation typically doesn't take into account all of the additional variables that come into play at scale.
Mayer: want to hear from industry why this doesn't work?
Brooks: question is not about what happens in Safari, or 10% of the market
... what happens to that value
Brooks: if it drops portion of the market by 10%, that's 1% of the market
<BerinSzoka> I'm no expert but even if it were true that you can do CPA without cookies, what about CPM? they serve two completely different market needs. CPM ads are about building brand awareness
Brooks: We are talking about huge numbers
<justin> BerinSzoka, uh . . .
Brooks: It is all about a valuation model, not a pricing model, which dictates how much people are willing to pay
... real money that pays for real websites
Lou: I think that David W made a good point
<jmayer> Berin, CPM is easy - you just count the impression.
Lou: this is about return on investment, that is the justification for supporting websites
<jmayer> Same goes for CPC - count the click.
Lou: if we cannot value an advertising impression there is no reason to spend money there
... advertisers have done is treat data responsibly, that is the balance
... cannot believe we are still having this conversation
... advertisers get to support content, users get to use content, that is a balance
Dan: it sounds like we are talking about a permitted use for advertising
... there are a couple issues on the table
... will this break business models
... is this needed for this permitted use. just trying to get clarity about
<aleecia> We're here for notice and choice. If you are not in favor of users being able to make choices about where their data goes, let's get that clear.
Dan: trying to understand what is going on now. Want a name of ad network where I can see how this works
<aleecia> Roy has been clear :-)
Dan: just trying to figure out what is there, to find out how you can do what you want in a privacy protective way
Peter: Dan's request seems to be a reasonable thing
<BerinSzoka> Right, CPM is easy--except for the fraud problem
Peter: reasonable that he gets the same view of commercial advertisers if they are clients
... An advertiser eye view
Break until top of the hour
<moneill2> cannot hear anything
<moneill2> thats OK, thought it was the phone system
<npdoty> plan is to restart in just a couple minutes.
<adrianba> scribenick: adrianba
tlr: describes the end of the princeton workshop
... said lots of the things that were said in the last year
<npd> here's a basic structure,can people live without, can't people live with it, silence at that time
tlr: this is the f2f where we need to make progress
... and drive to last call
... need to start talking about the things that it takes to get agreement
... some people think there is no way to get to agreement but i don't think that is helpful
... that shouldn't take over the discussion
... let's figure out the things we really care about
<justin> The original CDT proposal that people didn't hum they couldn't live with in Princeton: https://www.cdt.org/files/pdfs/20110447_DNT_v2.pdf
tlr: build something useful on a credible schedule
<wseltzer> scribenick: wseltzer
peterswire: Yesterday afternoon, we were talking about provisions in the draft framework
... item 6; there was an interesting point of agreement, more work would have to be done, but there's a bunch we can work with
... This morning, we identified priority pieces for many stakeholders;
... privacy: unique ID cookies; industry: stability for investment
... this afternoon, the tone shifted, talking past one another
... Now, time for all of you to think: What does it take to move forward?
... What can you live with? or if not, what happens then?
<npd> ... privacy: do not collect and unique id cookies
peterswire: It may be, the people who don't come together, you don't get a standard.
... We have on the screen the draft framework.
... I'm going to try calling on Shane, to talk about some ideas,
... and then some privacy ideas about unique ID cookies
... let's hear from people, including those who haven't spoken much: What does it take to move forward?
... then we go home for the night, and tomorrow, we reconvene to see if we have enough to get to last call.
... Shane, can you tell us about handling of data?
Wileys: This isn't a formal proposal, but a thought experiment
... Continue to use unique IDs and cookies
... upon collection of a record with DNT:1 associated
... would immediately separate out the few permitted uses
... all other material would be de-identified
Wileys: Dan and I have agreed on normative text, not yet on the technical detail
<rigo> de-identification = combination of technical and administrative measures
Wileys: if we look at where that would leave us, meaningful outcome for consumer privacy and put organizations on the hook, accountable for follow-through, get broad adoption
... Starting point, not nirvana for advocates, but implementable
peterswire: explain de-identification?
Wileys: a raw record and a de-identified record
... raw record security, frequency capping, debugging
... open debate on finance, (double-verify audit for a short time)
... other permitted uses we've discussed should be able to use de-identified outcome
... reporting and analysis can occur
... de-identification: a record comes in, you look at unique IDs and either remove or one-way secret hash
Wileys: IP addresses => geolocation; side data limited or removed
... removing information that would allow linking record with other records
... URL cleansing, for username, userID, password
<moneill2> so not unlinked
Wileys: things you'd see in query string, filter those out
... at some point in time, that key would be rotated
peterswire: this is a series of concrete steps
... things not done widely across the ecosystem today
justin: sounds similar to something I put on the mailing list
... three states: red, yellow, green
... red: security, yellow: financial reporting; green, de-id, use as you like
<johnsimpson> Shane, can you please recap the proposal in writing at your convenience?
Wileys: the delta is from three-state to two-state
... de-identified data is safe to use
... with promises it wouldn't be used to represent an individual
justin: what's modeling?
Wileys: e.g. if I want to see which link position gets more usage, look at group behavior
justin: is that a permitted use?
Wileys: not "permitted use" -- reporting is done with de-identified data
<moneill2> if uids are persistent then tracking occurs. Do Not Track is being ignored
Wileys: if an organization is de-identified and you can be confident it's not re-identified, more uses are acceptable
... accountability or trust component, the pledge that the organization wouldn't re-ID
peterswire: mapping to discussions: product improvement - is that debugging? A/B testing?
Wileys: For product improvement I can test buckets of people, not individuals
... I think you can get to all of that with de-identified data; buckets, not individuals
... e.g. homepage-test-123 vs homepage-test-124
... compare outcomes across buckets
Wileys: the panel elements survive in de-identified data
... but would need someone from market research to say whether it meets their needs
ChrisPedigoOPA: with your de-identification definition, URL history is still there
Wileys: if you promise you'll never reverse engineer, you can look at cleansed URLs but never correlate to actual user
<moneill2> there is a 1 to 1 correspndance 123 == abc
ChrisPedigoOPA: you couldn't re-target
Wileys: Right, no retargeting, only reporting, e.g. how many people saw this ad.
... doing everything possible to prevent myself from re-identifying
peterswire: let's pause the queue, put back into terms of draft framework
<sidstamm> I was going to bring it back to the framework (via queue comment)
<aleecia> Shane would you kindly write this up so we have text to talk about
peterswire: Where can we move forward?
<Wileys> Aleecia - yes, its on my to do list
<efelten> This approach would require having a precise, technically actionable definition of "de-identified data".
<aleecia> thank you
peterswire: Let's read through the framework; comments or questions to ask
... what would it take to live with this
<rigo> Wileys: but you could still single out user ABC and you have a profile of user ABC?
<Wileys> Ed, agreed - and I've tried a bit in the email list but look to guidance on what specific elements you'd like to see.
<rvaneijk> This thought experiment is nothing more than a linkable pseudonym
<Wileys> Rigo, yes - but this is not a real user anymore - just a ID that links to nothing in the real-world
<efelten> Thanks, Shane. Do you have a specific definition (e.g. from email) that you like at the moment?
peterswire: reads draft point 1
<rvaneijk> WileyS, would you consider this to apply to first parties and service providers?
<Wileys> Rob, disagree - a pseudonym can be linked to in the real-world. A de-identified record can not.
peterswire: for "browser", read "user agent where the consumer has activated DNT functionality"
<JC> Wileys, does hash rotate over time?
<aleecia> Shane, you say "cannot" when that is not actually true.
<rvaneijk> WileyS, it is hashing, one way, re-identification is not as relevant when data is still linkable.
peterswire: narrow set of permitted uses; Shane, did you imagine a time-limit?
Wileys: there'd be a retention requirement, transparent to consumer
<dsinger> to shane: in your framework, could someone come and insist that you answer 'did user 123 see URL Q' where URL Q was stored against ABC. Is that answerable?
<aleecia> Great, I'll state my retention time is 55 years.
peterswire: don't have a definition of tracking, but multiple sites over time
<Wileys> Aleecia, it is not purely "technical" true in isolation, but I can in combination between technical, operational, and administrative controls have a reasonable assurance this is true.
<rvaneijk> WileyS, would you consider this to apply to first parties and service providers?
<rigo> ok, you take a snapshot of the realworld and transform to a pet world. I logically come to the same conclusion then Peter. When do you move this into k-like buckets?
peterswire: permitted uses? is that in the compliance spec now?
<Wileys> Aleecia, good luck surviving industry scrutiny with that retention rate.
<Chapell> Aleecia, if you choose to state your retention time as 55 years, I'm sure some of your colleagues may have something to say about that - as will members of the press and potentially, regulators
aleecia: you don't need separate siloed data, but you can only use it under controls for so long as necessary for that use
... you might have people from a department lose their access to the data on a certain date
<moneill2> if data is not unlinked then plug-ins and browsers will
peterswire: are there pieces of DF#1 that people can't live with?
<aleecia> Alan & Shane, we all know social pressure is not sufficient for data retention
<npd> Aleecia accurately reports the state of the group, and I believe that's written in our sections on Secondary Use and Minimization
<Wileys> JC, yes - but to keep a consistent level of longnitudal consistency in data, this approach would require re-de-identifing the data again at its retention limit and then throwing away the key on a consistent frequency (daily, weekly, etc.)
<Chapell> Aleecia, I think we both know that this is more than mere social pressure
peterswire: non-comlliance woudl be a DAA violation; that is very different from what's in the compliance draft
<aleecia> Uh, we're not planning to writing "non-compliance is a DAA violation" into a W3C spec, right? That's on DAA to do, not us...
<dan_auerbach> shane, would a company have to be transparent about its deidentification process?
<jmayer> I'm confused. Is this an opportunity to ask questions? Or just a walkthrough?
<dsinger> to be clear, DAA enforcement is 'additional' to the statements in the compliance document, not a change to them, I assume
peterswire: DF#3, DAA would modify its current codes ...
<dan_auerbach> trying to get through my clarifying questions before my substantive comment on the queue
<rigo> jmayer: walkthrough I assume
<Wileys> Dan, yes - to some degree - I believe there would be IP specifics that wouldn't be disclosed.
peterswire: DF#4, no persistent IDs if no permitted use
<tlr> dan, you're on the queue for clarifying and then substance?
<aleecia> Alan, I would like DNT to be more than social pressure. That is why we need more than Shane's proposal.
<npd> I take it that #3 would not be a change from current Compliance spec
justin: standard today says no collection if no permitted use; EFF's says no cookies if no permitted use
<aleecia> for scribe purposes: Jeff asked for a meta discussion here, and was told we will continue through the document.
<Wileys> Aleecia, could you explain "social pressure"? We're working on a voluntary standard - what are you envisioning?
peterswire: data hygiene, continue to make progress over time, not in draft spec
<dsinger> this one? "Data retained by a party for permitted uses must be limited to the data reasonably necessary for such permitted uses," (compliance current draft)
<rvaneijk> for scribe purposes as well, I lost the connection between Shane's thought experiment and the DAA framework. Those are two different discussions. The thougtexperiment has not completed yet.
<rvaneijk> .. and is worth furter looking at.
<dsinger> does it mean 'adapt' (meaning change)? or 'adopt
peterswire: DF#6, talked through many pieces yesterday
<dsinger> ' (meaning add on to it)?
<npd> I believe "adapt" is intended
peterswire: that's an approach to structure our discussions,
<aleecia> X would need to be something fairly short.
peterswire: I believe it's an improvement from the status quo for all stakeholders and good public policy
... How to get to something tomorrow that shows us reason and way to move forward
<dsinger> question: I read 1+2+3 as basically "do not retain" (with the exception of permitted uses). fair?
peterswire: I've gotten wildly divergent advice, often strongly voiced, incompatible
... how do we take Monday afternoon's convergence, today's discussion, see a way to move forward
<justin> I think this discussion is actually probably more useful than having the same fight over Shane's definition of deidentification that we've had on the mailing list and in the last two face-to-face meetings.
peterswire: I promise to listen to the priorities of consumer groups, advertiser groups, site groups, browsers, government
<aleecia> Why, Justin? It's the same discussion
peterswire: You have to decide overnight what you want to do, and how to find a way to do something tomorrow
<aleecia> Shane is suggesting we replace a random unique ID with another random unique ID
<aleecia> Removing the side channel data *is* an improvement.
peterswire: one of the thoughts I've had is that good data practices in the ecosystem will help
<aleecia> But swaping a rand with another rand does not improve much at all
<Wileys> Aleecia - one that the key is now gone. NOW you have NO TECHNICAL WAY to reverse engineer the resulting dataset - even if you wanted to.
peterswire: doesn't address all the concerns, including consumer groups to move away from unique IDs
... how do we create something now, and then come back and revisit unique ID cookies
<rvaneijk> Shane, where did the key go, in a store/vault, or actual random rotation?
<aleecia> This assumes key rotation, which if you're suggesting doing every 2 weeks, I can listen further, but right now - I'm not hearing that.
<rvaneijk> Shane, to be frank, I am open to the approach, and want to explore further.
peterswire: hope that people in industry, people outside industry, can see whether glimmers of alternative can turn into something that could be adopted.
... So we start with the framework, leave an opening to return and use the next-generation efforgts
<aleecia> You cut off discussion of retention
<aleecia> (over lunch)
<Wileys> Rob, destroyed
peterswire: How do we take the work that's been done, then return to do more.
<aleecia> If there's more to the proposal, I look forward to reading it
peterswire: I can report good conversations, not yet sign-off
<rvaneijk> Shane, ok, that is better then we discussed before, we are talking actual unlinkability then.
<Wileys> Aleecia - I cut off discussion of arbitrary retention. Companies would be required to publically disclose their retention periods per permitted use
peterswire: I'm asking those of you who are silent, who want something to happen, to think about tonight,
... what's the best path here?
<justin> aleecia, it's an important discussion that needs to get resolved eventually. But 30 minutes of that queue replicating the same exact arguments against Shane's definition would not be a good way to end the session. (For the record, I am sympathetic to the arguments.)
peterswire: I came in optimistic on Monday; I'd like to see if you can do something with that.
<Wileys> Yes - at some point to lower risk it would be recommended to eventually destroy the key (but that is not required to reach de-identification)
aleecia: As former co-chair to current, ask for a round of applause for Peter for the last two days
<vincent> rvaneijk, I think the same key is used over a couple of weeks at least (am I right Wileys ?)
<BerinSzoka> "The Quest stands upon the edge of a knife. Stray but a little, and it will fail, to the ruin of all. Yet hope remains while the Company is true." -Galadriel