See also: IRC log
<trackbot> Date: 22 May 2013
<Chris_IAB> is there a call today?
<Chris_IAB> I'm joining from 212-380-xxxx
<samsilberman> zakim aabb is samsilberman
<Chris_IAB> npdoty, thanks-- I'm on the East Coast today, so I guess I was just "early"
<peterswire> 301.365.0653 is peter swire's line today
<susanisrael> Zakim 917.934.1044 is susanisrael
<Lmastria_DAA> am on phone from 212.790.xxxx
<npdoty> scribenick: susanisrael
schunter: will run call in 2 parts, 1st, TPE, 2nd, compliance
<trackbot> ISSUE-194 -- How should we ensure consent of users for DNT inputs? -- open
schunter: I provided several
issues to discuss. 194. how decide content of users for dnt
... currently dnt tools have input 1 and 0 but so do many tools so hard to say if they compliance
one idea at f2f was to introduce tools ....including true and false ....there are legacy things that send 1, 0 and new ones that send 2, 4
<Mike_Zaneis> Zakim 202.344.aagg is me
if they receive true, false they must follow guidance, and if they get legacy signals they have to decide....
*tx e felten. having trouble hearing schunter
would like feedback and 2, 4/true/false.....
<WileyS> I don't believe there is much value for the true/false flags. The effort to update code to this area doesn't seem to buy us any protection
<WileyS> +1 to Roy
<Zakim> npdoty, you wanted to ask whether we didn't decide that legacy *wasn't* the problem
<sidstamm> yes, +1 to
...fielding: problem is that only problems we are having with UAs right now is deliberate mis-sending of signals and i don't want to send more data over wire, particularly more variations of same, doesn't solve anything
<rvaneijk> What did Roy say??
npdoty: was going to echo roy, but thought we decided at f2f that legacy not the issue.....
schunter: what to do?
npdoty: thought we decided to stick with 0 and 1
danauerbach: agree with roy and nick and it would create unhelpful clutter
<fielding> I said that the issue right now is UAs (and others) deliberately sending a signal that is not based on user choice -- adding two more signals does not solve anything.
<fielding> … and I really don't want to send more bytes on the wire than 8.
<sidstamm> not sure waiting will help
hefferjr: have no opinion on value of abandoning 0 and 1 but if we do let's delay until spec and responsibilities are finalized before we change signals
schunter: i think about signals, True can be abbreviated with "T" but if no one wants True and False in addition to 0, 1 we can close issue....does anyone want more signals?
<npdoty> is there anyone who wants to have more signals than 0 and 1, for any reason?
schunter: doesn't seem to be the case....
<npdoty> I think we wouldn't close issue-194, as it covers some other topics
schunter: so if you go back to the issue.....
<sidstamm> mostly non-user-agent http clients
wileys: i think roy caught this in irc, but want to reiterate this from f2f, we have many user agents sending signals without user preference so I don't see value in this approach, just as easy to game the system with new flags
<Chris_IAB> agree with Shane
<sidstamm> WileyS, do you mean user agents like browsers or things like firewalls?
<npdoty> I think "DNT: 1" is explicitly misstating in these cases, given our definition of DNT: 1
schunter: to some extent i agree, the argument i heard was that if bad agents are required to explicitly misstate what they do this creates a hook for legal action
<WileyS> Sid, all the above
<sidstamm> ok, so they would be noncompliant
schunter: naturally anyone can send these signals but they are misstating but if no one thinks this make sense or is useful we should not do it....
<WileyS> Sid, yes, if the final standard states sending DNT:1 without specific and express user action/preference setting, then they would be in non-compliance.
<sidstamm> makes sense, WileyS
<schunter> Sending "t" is as much bytes as sending "1"
peterswire: i have no view on right answers, but what mattias stated is what i heard from some people, especially on site side. for example, i heard that if anti-virus is sending signals this might help in legal action if people say they are sending false signals
<npdoty> peterswire, would you want to follow up with any of those people directly to see if they want to come forward subsequently with a text proposal or use case?
chris_iab: agree with shane, the problem is the signal can be hijacked. one of the fundamental problems with sending http signals. so i dont think this adds credibility to argument that this provides a legal hook of some sort
<dan_auerbach> everyone should use HTTPS so that network intermediaries can't hijack. i know this doesn't fully solve the problem, but it helps...
<dan_auerbach> npdoty, yes i am
sidstamm: made this point at f2f, but important so repeating. With TPE there will have to be some trust on both sides of protocol. sure, UAs who don't get consent "properly" are noncompliant.....
<dan_auerbach> apologies, didn't realize my # wasn't saved
but for purpose of TPE, we need to assume everyone is being honest. For TPE doc, let's just focus on protocol itself.
schunter: so we seem to have agreement to leave 1,0 signals. a related question i have is can we close issue 194? since we have no idea how to protect signals? or keep it open?
<sidstamm> yes, we can reopen if someone finds up with a way to guarantee authenticity of the signal.
<trackbot> ISSUE-194 -- How should we ensure consent of users for DNT inputs? -- open
npdoty: i am all for decreasing number of issues, but in this case i think issue 194 is intended to cover more than whether we would change syntax of dnt signal, so i think we should just add a note about sticking with 0, 1 to issue
<efelten> Who proposed this?
<sidstamm> we can re-open the issue if new information is provided
<Chris_IAB> Chappell was on this issue, but is not on the call
peterswire: i might be misrembering but some people i think i remember discussing this with are not on call today, so i am not sure of procedure, but I would be inclined to follow up with them and make sure they have no strong views
<npdoty> we can "close" this part of an issue, and re-open if we hear new concerns
<Chris_IAB> FYI- NAI Summit is today, so low attendance from industry
schunter: suggest following nick's suggestion of putting comment in issue, then suggest people post to mailing list if they have strong feelings, ok?
<WileyS> NAI Summit was yesterday
<WileyS> NAI Board Meeting is today - which I'm ditching for 90 mins to be here :-)
berinszoka: i don't know enough to have an informed opinion, but as to chris's point, it's a problem if signal can be hijacked. Everyone here wants signal to be legally binding, and wants to trust it....
<npdoty> issue-194: agreement that we would continue with DNT: 0 and DNT: 1 (rather than a change to obsolete legacy clients, or for other reasons), but issue-194 may cover additional things
<trackbot> Notes added to ISSUE-194 How should we ensure consent of users for DNT inputs?.
<sidstamm> I don't think we want any language about legal enforcability in a technical standard
berinszoka: so getting back to analogy of dock and ship, it might be a good thing for consumer advocates to make sure signal is robust. I think we may want to have a conversation about legal enforceability.
<schunter> ack Thomas Roessler (DNT)
schunter: i think we all want strong signal
<Chris_IAB> peterswire, Chapell just joined
<BerinSzoka> Thomas, could you just explain why you think we're meeting htt threshold?
<Chapell> sorry folks - i'm having trouble extricating myself from the nai board meeting
<Chris_IAB> peterswire, to your last point about not having the right folks on the call re the last issue
tlr: i agree with berin that signal should be reliable, and i think we are meeting that threshold in what we have,,,,but happy to reopen if we have actual technical means to strengthen it, but otherwise wouldn't reopen it.....
<BerinSzoka> I'm not saying we're not meeting the threshold. but some people seem to think we're not
<tlr> berin, I'm making a symmetry argument.
<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
schunter: nick pls add note to issue
<tlr> If HTTP is good enough to serve ads and information about ad impressions, then it's good enough for DNT.
<WileyS> Thomas, I respectfully disagree - the signal is simply far to easy to hijack in its current form. Its such a fundamental issue that I don't know how we resolve this without significant technical overhead.
<Chapell> +1 to shane
schunter: Issue 137 was David's
but it seems he is not on call.....
... so let's postpone this discussion
<WileyS> Or we accept the signal will be gamed in high percentages and attempt to find balance elsewhere
<BerinSzoka> I think we all need to look out for issues that could cause a #DNTFail in the future: as situation where all our work turns out for naught because, for example, some company starts hijacking the signal and servers stop respecting it.
schunter: we are trying to avoid having a chair decision, and so for now we are adding note and want to get to consensus, otherwise peter and i will decide with group input and call for objection.....
peterswire: is volume on call ok?
<Chris_IAB> peterswire, now that we have more folks on the call, do you want to go over the issue we skipped earlier
<schunter> WileyS: If you assume that most signals are gamed, you can still re-validate consent locally while using the exception API to record your state.
peterswire: i propose to do quick check on sunnyvale issues, then go through jonathan's comments on issue merger and redefinition, then go through fuller list of issues in agenda
<WileyS> Rob, I hope not - trying to find solutions going forward. As with de-identification not all solutions are purely technical in nature, so once the DNT standard becomes a standard, we'll be looking for ways to motivate compliant UAs to become compliant. Will be expensive and time consuming (whack-a-mole) but I believe it will be necessary.
peterswire: want to get full set of assignments today. I know tlr is on call only for a while. You are doing something on data retention.
<Chris_IAB> sorry, interested in what?
tlr: update is that i got about a dozen notes from people who said they were interested but haven't been able to schedule yet. Hope to do so in next day or two, apologies for being slow.
<npdoty> scribenick: npdoty
<WileyS> Nick, definitely want to be there <raises hand>
<Chris_IAB> got it. I'm interested, but I think I've already expressed as much :)
peterswire: susanisrael, update or new date?
susanisrael: I've had several
conversations, trying to follow up with Jeff Chester with Rigo,
but Rigo has been out [sick] for a few days
... don't like to delay, but might be able to get the language in next week
... need to go back and forth with Rigo
<jchester2> I look forward to hearing from Susan and Rigo what their proposal is.
susanisrael: owe jeff and justin a call. people have been very helpful, just scheduling issues rather than substantive issues
<trackbot> ACTION-404 -- Susan Israel to further Fact finding on scope of audience measurement and the DAA exception (one page of text) -- due 2013-05-15 -- OPEN
susanisrael: try for next week on audience measurement
action-404 due 2013-05-29
<trackbot> Set ACTION-404 Further Fact finding on scope of audience measurement and the DAA exception (one page of text) due date to 2013-05-29.
<scribe> scribenick: susanisrael
<trackbot> ACTION-402 -- Shane Wiley to work with Dan to follow up on defining the "yellow" to "green" transaction with strong enough measures -- due 2013-05-15 -- OPEN
<trackbot> ACTION-403 -- Justin Brookman to write language on red / yellow / green -- due 2013-05-15 -- OPEN
<dan_auerbach> I want to be part of crafting that language
peterswire: on red, yellow, green, shane you and i traded emails. I don't think i have an actual action item but I do have some things from f2f. I hope to have proposed normative text next week....
<tlr> dan, audience measurement or traffic light?
peterswire: proposed idea is never have full history with url....
<dan_auerbach> in particular, I'm hesitant to let any language get into even a draft spec without my signoff, given that this is a joint action item
peterswire: this would be on top
of normative text from daa and ftc, and would include examples
from dan and some new examples from nonnormative. should have
complete package next week......
... nick pls assign action item to shane
<trackbot> ACTION-402 -- Shane Wiley to work with Dan to follow up on defining the "yellow" to "green" transaction with strong enough measures -- due 2013-05-15 -- OPEN
wileys, i think the assigned action item with dan was for something different
tlr: your read, dan?
<WileyS> Okay, I'll take first stab
<npdoty> action-402 due 2013-05-28
<trackbot> Set ACTION-402 Work with Dan to follow up on defining the "yellow" to "green" transaction with strong enough measures due date to 2013-05-28.
dan: less concerned about dividing actions than whether we agree on text before it gets into a draft spec...on other hand if we want to hammer out text together happyp to do that....
<WileyS> I'll take first stab to get to the group quickly - we can iterate from there
<npdoty> action-402: text to group sooner rather than later is great, but might include Dan A. or Rob v.E.
<trackbot> Notes added to ACTION-402 Work with Dan to follow up on defining the "yellow" to "green" transaction with strong enough measures.
peterswire: one question, there
was traffic on list as to what to call various different
states, and it wasn't clear to some people from the sunnyvale
doc. labeling of 3 states somewhat important in my
... my current understanding of de-identification language in daa code is analogous to yellow, and if you go all the way to green, that is unlinkable.....that term "de-identified means something different under hipaa....
<WileyS> I believe de-identified data could be released to the public with little concern of it being reverse engineered
<WileyS> The risk remains with the key holder
<rvaneijk> WileyS that is a different discussion.
<WileyS> NOTE - if the de-identified data has been appropriately stripped of side-data (data minimization)
peterswire: where it means it is so de-identified you can put it on the web. so in u.s. this term means really de-identified in hipaa, finding a name for that de-identified state is important, in my mind. ok as part of assignment shane?
<rvaneijk> I am still screaming for a new def for de-identified, e.g. hashed pseudonym
<dan_auerbach> +1 to peter that de-identification is bad naming
<dan_auerbach> yes, agree with Rob
<npdoty> Wileys, your version of de-identified data without the key (which is the same as described Green/Unlinkable) could be released to the public, yeah?
<WileyS> Rob, I speaking in the context of HIPPA only
<rvaneijk> I know.
wileys: i think labeling should be a separate issue. I think our de-identified state actually meets hipaa bar. It's contentious and has legal ramifications so maybe someone else should do it.
<tlr> rob, can you take action item to propose different terms?
<npdoty> rvaneijk, would you take a separate action on proposing new names?
rob seems to have strong feelings so perhaps he would be willing to take an action item...nick will follow up offline......
<rvaneijk> @tlr yes, but see discussion on the list.
<WileyS> Nick, I believe so - as long as the public doesn't have the key and the de-identified data has been appropriately minimized, there should be little to no risk of reidentification in public hands.
<npdoty> ACTION: van eijk to propose a new set of names around red-yellow-green de-identification [recorded in http://www.w3.org/2013/05/22-dnt-minutes.html#action01]
<trackbot> 'van' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., rvaneijk, wvanhols).
<dan_auerbach> if it meets the HIPAA bar, will Yahoo release the data publicly? it would be an interesting and important test case for re-identification attacks to resolve our empirical disagreement
scribe: other action item from sunnyvale had to do with user education and user interface.....was this lou's action item.....
<dan_auerbach> WileyS, see my last comment
<rvaneijk> ACTION: rvaneijk to porpose a new set of names around yellow state [recorded in http://www.w3.org/2013/05/22-dnt-minutes.html#action02]
<trackbot> Created ACTION-406 - Porpose a new set of names around yellow state [on Rob van Eijk - due 2013-05-29].
<efelten> Shane, you keep saying that your proposed algorithm leaves data safe to release. What's your technical basis for that claim?
<dan_auerbach> if there's any way Yahoo would be willing to release data, we can revisit the bet you proposed to me about re-identifying a user
i think the browsers were going to work on this and alan wanted to work on it. I also offered to help.
<WileyS> Dan, we would likely not release it publically but perhaps release it to an independent org under NDA to test our assumptions of strength.
peterswire: i don't know whether we have a date for that language....
<Chapell> Yep, I've offered to help -- I believe there was a discussion but I did not partipcate as they wanted to keep the group relatively small
<npdoty> I don't believe we currently have that tracked under an action item
<Chris_IAB> Chris Mejia can help
<Chris_IAB> <---- this guy can help
peterswire: part of today's goal is to see when we will get some text for the full group.....
seeing that chris mejia can help.....
<Chapell> I'd like to help as well
<npdoty> hearing: Chapell, Chris_IAB interested
<WileyS> Ed, if the record has been appropriately de-identified (see the steps in the graphic Brad Kulick circulated) then releasing that to a 3rd party should come with little risk of reidentification. Something to be tested...
<dan_auerbach> Shane, that'd be a great thing to do, but hard to substitute for public release in terms of getting side channel data for effective attacks. still, feel free to keep me looped in on any release -- i am willing to be proven wrong in terms of the power of "yellow"
<efelten> Shane, I was asking for a technical rationale. Repeating the claim is not a rationale.
peterswire: seeking traditional idea of people having assignments with date, let's say 2 weeks from alan and chris mejia
* i do think david singer was working on this as well and alex
<npdoty> ACTION: Mejia (with Alan Chapell) to draft text regarding browser education as discussed in Sunnyvale (Item 6 in Draft Framework, also in consensus action summary) [recorded in http://www.w3.org/2013/05/22-dnt-minutes.html#action03]
<trackbot> Created ACTION-407 - (with Alan Chapell) to draft text regarding browser education as discussed in Sunnyvale (Item 6 in Draft Framework, also in consensus action summary) [on Chris Mejia - due 2013-05-29].
peterswire: going next to jonathan mayer's email. I hope it can be handled in a fruitful way despite his not being on.....
<WileyS> Ed, the proposed steps I'm referencing are technical in nature (secret hash of IDs, replacing IP Address, cleansing URLs, removing side-data facts). I apologize if I'm missing what you're asking for.
<paulohm> Shane, just curious: Is a URL "side data" to be scrubbed?
<rvaneijk> can someone paste the link to jonathan's email please?
<WileyS> Paul, yes, the URL must be scrubbed.
peterswire: we have proposed set of issues that yianni and nick sent to group and one set of comments/concerns came from jonathan.....so thanks to yianni for writing this up while i teach in the summer......legal ethics of washington lawyering....
<paulohm> Shane, not just "cleansed" but deleted altogether?
<WileyS> Paul, no - cleansing finds the middle ground of removing re-identification risk and maintain utlitiy in remaining data.
<npdoty> email from jmayer on issue cleanup: http://lists.w3.org/Archives/Public/public-tracking/2013May/0092.html
peterswire: first item was fraud prevention, item 24.......mozilla/eff proposal had more detail re: fraud prevention but we haven't had formal reaching of consensus on different approaches, and we have 2 diff ideas, could put it into pending review
<WileyS> Paul and Dan, I concede that deleting all data is the safest approach to de-identification. Can we please stop repeating that mantra?
<paulohm> Shane, because doesn't any user who knows a single URL they've visited + date + time become an adversary who can then reID all of their rows in the data?
<jchester2> I agree with Dan. No pending review now.
dan auerbach: just wanted to follow up on security cleanup, i agree with jonathan that this should not go to pending reivew yet. think we need to agree on how narrow this should be....
<npdoty> yes, I think both security and fraud are covered by 24 right now
<trackbot> ISSUE-24 -- Possible exemption for fraud detection and defense -- open
peterswire, this strengthens my recollection that security and fraud are under the same issue. Right? so i think there are at least 2 proposals
davidwainberg: i thought we had consensus at some point that we should not use term fraud bc of the way the term is used in ad industry
<npdoty> does someone want to take an action item if you don't want to move to pending review?
<WileyS> Paul, if I know my browsing history (I'm the only one who knows those details) and I view a de-identified record set to the point I'm able to recognize my own browsing history - no new knowledge has been gained. What privacy harm has occured in that outcome?
*I remember this same thing as david and think it preceded peter's joining
<fielding> The language is in the editor's draft already
dwainberg: nick,and justin and i had thread on this but it dropped?
<Chris_IAB> dwainberg, "disingenuous traffic" instead of fraud
<npdoty> current text includes "fraudulent" but also other categories, like "malicious activity"
npdoty: i do think david and justin and i had a discussion on list. I had issues with "invalid" but was wordsmithing, but i think text now captures david's intention.......
peterswire: david can you review text and report to group....
chris_iab: i remember conversation david refers to and think it was before you joined. at iab we tend to refer to the kind of traffic that may be called fraudulent as "disingenuous"....security and fraud not always related....
<fielding> we are only talking about data collection permissions, not about all security
<npdoty> personally, "disingenuous" is a new one for me, but I would prefer it over "invalid" which would seem to encompass a wider range of unintentionally incorrect traffic
<paulohm> Shane, I think it can be done with a single URL (+date +time). You don't need a "history." So it's something an adversary can know about a lot of people other than just himself or herself. I'm just confused about why you think the risk of ReID is so low.
<tlr> +1 to Nick
peterswire: when john callas first addressed group he thought security terms made sense, does that part of it work
<dan_auerbach> Chris, that'd be fantastic!
chris_iab: with respect to john callas, he may not have protected a publisher, we do that and though it's hard maybe i can bring in a speaker....
<WileyS> Paul, please explain how knowing your own records in a data set helps you re-identify other records in the same dataset?
<CraigSpiezle> Chris - happy to help on the security side vs fraud
dan auerbach: i think it would be fantastic chris if you could wrangle a speaker to discuss details
chris_iab: they don't usually discuss details, but can look at definitions, and talk at a macro level, won't open kimono on everything they do at major publishers.....
<paulohm> Shane, I'm assuming you want to keep a pseudonym that relates rows in the table as belonging to the same person. If you're throwing all such pseudonyms away, that's really great, and I am closer to agreeing with your claim.
dan auerbach: having worked in industry and been on front lines, i think that if opening kimono completely might be off table, they might be able to give some detail, and we could also tighten those defs and get language tighter, separate security and fraud......
peterswire: heard helpful raising of hands from david wainberg, chris mejia, dan so i would be inclined to give david the pen. would that take week or 2 weeks david?
dwainberg: should be quick, can do next week
<npdoty> ACTION: wainberg to review security/fraud text (with chris mejia and dan auerbach) [recorded in http://www.w3.org/2013/05/22-dnt-minutes.html#action04]
<trackbot> Created ACTION-408 - Review security/fraud text (with chris mejia and dan auerbach) [on David Wainberg - due 2013-05-29].
peterswire: can also look at separating security/fraud words
<npdoty> action-408: related to issue-24
<trackbot> Notes added to ACTION-408 Review security/fraud text (with chris mejia and dan auerbach).
<fielding> which action was that?
<fielding> … the action that tlr is talking about?
tlr: a few ancient action items pending review dealing with graduated response. were on ian fette, [? someone else?] and maybe shane. Does anyone know if this is still a live topic? should we start from clean slate or use text from last october or nov.....
<npdoty> ... among others
tlr: if clean slate, let's close action items....
<sidstamm> apologies, all, I have to leave early for another commitment.
tlr: my preference is to close. can look at same substance in new way.....
<fielding> +1 to deleting the sentence on graduated response.
<npdoty> I would be happy to ask the editors to integrate proposed text (a definition from Ian) as they find helpful
<dan_auerbach> I need a chance to look
<fielding> Ian's text is at http://lists.w3.org/Archives/Public/public-tracking/2012Oct/0506.html
<dan_auerbach> before coming to an opinion
peterswire: maybe nick and yianni and i can pull together and ask people on list what their view is. ok? that way not prejudging......
<npdoty> ACTION: doty to circulate (with yianni, tlr, peter) regarding "graduated response" and old actions [recorded in http://www.w3.org/2013/05/22-dnt-minutes.html#action05]
<trackbot> Created ACTION-409 - Circulate (with yianni, tlr, peter) regarding "graduated response" and old actions [on Nick Doty - due 2013-05-29].
<tlr> trackbot, link action-408 to issue-24
<trackbot> ACTION-408 (Review security/fraud text (with chris mejia and dan auerbach)) associated with ISSUE-24.
<WileyS> Paul, records would maintain a persistent identifier for a period of time in the de-identified state. Those identifiers don't represent anything in the real-world so I'm still struggling with how that helps you re-identify a record outside of those that you have detailed copy of the fact in a raw form through some other source. Is that what you're suggesting here? Could you please provide a
<WileyS> real-world example of how this would occur? Thank you.
<fielding> +1 also to adopting Ian's text on graduated response
peterswire: next on jmayer email had to do with issues 191 and 188 re: normative and nonnormative language re: de-identification.....had concerns re merging....staff thought we could work on both together. dan do you have aview?
<WileyS> I don't believe graduated response works in the real-world
<paulohm> Shane, since we're talking about something the call moved off 20 minutes ago, should we maybe take it offline? I'm happy to have a quick call about this later today. I think it can be a very quick call.
<WileyS> We already debunked the idea of adding new cookies during the Security discussion at the F2F
<efelten> Shane, as one example, the AOL data set contained user identifiers that were completely dissociated from any real-world identifier.
<efelten> Same with the Netflix dataset.
<efelten> Among others.
dan auerbach: no strong view but might have to look back at text, but suggest we heed jonathan's request not to merge if he had a concern....
<WileyS> Ed, the search terms were not cleansed. Next...
peterswire: next a whole bunch of issues that go to user consent. Some had no action items and no texts, if there is a way to flag dependencies that might be helpful.....
<Chris_IAB> combining issues, to narrow our work scope, seems like a good idea
<Chris_IAB> gotta start working to an end, right?
<WileyS> Ed and Paul, happy to take you through each of the public examples and point out how simple fact cleansing would have removed the risk.
npdoty: issue tracker does not have formal note for dependencies, but can add links back to others, narrowing down issues and flagging interdependencies......
<efelten> Shane, agree that experience shows it is easy to think your data is safe to release when it's not.
<npdoty> from peter, regarding 132, narrow those down, and just make sure we have links back to the "super issue"
<efelten> Question is what rationale you have for thinking that your method leaves data safe to release.
<Chris_IAB> npdoty, can you post the current issue being discussed?
peterswire: issue 184 re: 1st and 3rd parties.......whether website can condition access to website on consent to tracking. This issue has not come up since i have been chair though i am familiar with it in other settings.
<trackbot> ISSUE-184 -- 3rd party dependencies in 1st party content -- raised
<npdoty> does anyone want to take an action?
<jchester2> We need to hear from Walter. q
<jchester2> unmute me
peterswire: is this issue live? i think people are looking at it right now. I am not seeing anyone asking to take an action item or go live, so i suggest moving it to pending review and putting it on list with note that we did not get any live proposals
<WileyS> Ed, it depends on the details of the record set in question. If I send you a list of anonymized IDs and cleansed URLs with a noisy date/time stamp. Do you feel you can reverse engineer that to real people? Would love to understand how you think that is possible.
jeffchester: i think we need to check with Walter first, it was his proposal
<paulohm> Shane: (1) any first party with an apache access.log will know URLs (+date + time) for users; (2) any person who shares a computer with somebody else can extract URLs (+date + time) for other users; (3) any FBI agent who seizes a computer or an access.log file can do the same; (4) any person sitting in a cafe using unsecured wifi and a packet sniffer can get URLs. Given the low entropy of date/time, all of these people can probably match even against scrubbe[CUT]
<npdoty> we gave an alert when we announced issue reviews on the call last week, and an email with issue resolutions a week ago
<dan_auerbach> As a general procedural point, the process of moving things forward shouldn't require sustained objections
peterswire: fine. will do that before moving to pending review
<dan_auerbach> that puts undue burden on participants with fewer resources
<efelten> URL histories also tend to have high entropy, even if scrubbed.
<npdoty> ACTION: peter to review issue-184 with Walter and Rob before merging/pending review [recorded in http://www.w3.org/2013/05/22-dnt-minutes.html#action06]
<trackbot> 'peter' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., pkosmala, peterswire).
peterswire: issue 16, collection: has to do with transient retention, has to do with a permitted use for short term collection
<npdoty> ACTION: swire to review issue-184 with Walter and Rob before merging/pending review [recorded in http://www.w3.org/2013/05/22-dnt-minutes.html#action07]
<trackbot> Created ACTION-410 - Review issue-184 with Walter and Rob before merging/pending review [on Peter Swire - due 2013-05-29].
<Chris_IAB> npdoty, can you post the link to issue 16 please, being discussed now?
<tlr> trackbot, associate acton-410 with issue-184
<trackbot> Sorry, tlr, I don't understand 'trackbot, associate acton-410 with issue-184'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
<trackbot> ISSUE-16 -- What does it mean to collect data? (caching, logging, storage, retention, accumulation, profile etc.) -- open
<tlr> trackbot, link action-410 to issue-184
<trackbot> ACTION-410 (Review issue-184 with Walter and Rob before merging/pending review) associated with ISSUE-184.
<trackbot> ISSUE-134 -- Would we additionally permit logs that are retained for a short enough period? -- open
chris_iab: looks like what we were trying to do is create a use for transient data.....I have heard people say we should not collect data. this is impossible, since we need data to respond to request, but you can limit retention period......
<trackbot> ISSUE-184 -- 3rd party dependencies in 1st party content -- raised
chris_iab: however this may go away if we go down de-identification path
peterswire: so maybe put this into Thomas's data retention discussion
<WileyS> Paul, agreed that external attacks need to occur to gain access to non-de-identified data that may be used to help reverse engineer a separate entities de-identified data. The approach is not without risk. Do you have an example of where this is occured with a dataset that was not shared publically? How real is this risk in the broader spectrum? We're debating absolute positions - when I fully
<WileyS> concede this approach comes with some risk and needs to be bolstered by operational and administrative controls. Happy to state DNT:1 de-identified records are not allowed to be shared publically.
<WileyS> Ed, disagree - depends on the cleansing approach taken.
dan auerbach: but not moving to pending review, right?
peterswire: correct, part of ongoing discussions on data retention
<npdoty> peter: leave issue 16 open while discussions continue regarding data retention (which might address the "transient" part, which seemed the remaining open part of definitions)
<jchester2> I agree with Jonathan
<paulohm> Shane: Thanks for the concession. I didn't mean to be taking a vote in the "technical" versus "administrative" deidentification debate. I was just responding to your strong claims of confidence about surviving public release. If you're retracting that, I'm backing off too.
<Chris_IAB> can someone please post what JM wrote?
<Chris_IAB> post here, I mean
<rvaneijk> WileyS, the linkability aspect can not be overlooked, it is not just about external risk for reverse engineering a hash
peterswire: issue 10: has to do with issue of first party definition. jonathan says there was supposed to be a trade that never happened. what do people remember?
<npdoty> jmayer's email: http://lists.w3.org/Archives/Public/public-tracking/2013May/0092.html
<Chris_IAB> npdoty, thanks :)
wileys: jonathan's memory
accurate. talked about strict defs of first party originally
then moved to similar url, then to daa def of affiliated
websites...and this was part of proposal concession
... the advocate proposal conceded this as part of a trade but they reserved right to pull back if they didn't get other concessions across the board.....
<npdoty> if we want to avoid closing the issue until we have that agreement, that sounds fine (and compatible with the proposed pending review status)
jeffchester: think wileys described this accurately. I think this was wrapping up when this was happening.....
<dan_auerbach> I know the history: Shane is right on point
<WileyS> Rob, disagree - we've already reached the EU Legal bar of "likely reasonable" for non-re-identification.
<efelten> Shane, here is some data on entropy of URL histories: http://petsymposium.org/2012/papers/hotpets12-4-johnny.pdf
<fielding> And I should point out that I disagree with both sides regarding what should be defined as party, first party, and third party, since the way they are defined has nothing to do with reality of user expectations regarding intentional use of websites.
jeffchester: were willing to discuss responsibility of first parties in context of broader dnt standard and i have not conceded that first parties are exempt from dnt......
<jchester2> I move we keep it open for now, so the advocates can discuss how to address
npdoty: i think i understand shane's and jeff's views but suggest moving to pending review, which is intended for situation where we have text but have not reached consensus.....
wileys: i think we did agree that first and third parties would be treated differently because people understand they are interacting with a first party. scope of definition then became the issue
<WileyS> Ed, thank you for the link - I'll definitely read this.
dan auerbach: my understanding of pending review was like the new "closed" so i feel strongly that if there is an objection it should not get steamrolled...so I am hesitant to move these things to pending review......
scribe: ok if there will be an opportunity to object to things in pending review
<npdoty> dan wants to make it clear that issues can be objected to before we move to closed, without any prejudice
peterswire: one reason we are not using closed is that i realized how hard it is to get to agreement on these issues
<npdoty> (which I'm fine with)
jeffchester: shouldn't move
things to pending review before we (advocates?) move things to
... i will convene call with colleagues.....
chris pedigo: want to echo what shane said. Group really has agreed that first parties should be treated differently from third parties......re: affiliates I understand Jeff's perspective that this may be open
scribe: but this has been unchanged for a long time, and we need to move things to the parking lot now
<jchester2> at least we will have another lawyer in the room by next week!
peterswire: i have heard request from jeff to wait a week. Hearing stability but one week delay requested, I'm willing to wait a week.....
<npdoty> ACTION: chester to review action-10 on first party text before moving to pending review [recorded in http://www.w3.org/2013/05/22-dnt-minutes.html#action08]
<trackbot> Created ACTION-411 - Review action-10 on first party text before moving to pending review [on Jeffrey Chester - due 2013-05-29].
peterswire: that completes list of issues jonathan sent in about issue mergers etc. In agenda there are proposed closed and narrowed issues at bottom. .....
<npdoty> I would ask that we not only discuss this on the calls, or we can extend out a week continuously
first is issue 60, will a recipient know if 1st or 3d party, 102, short names and specs, 157 charter. I propose to send these to list with request for objections to closing.....
<npdoty> any objection to closing the very few issues to close?
<npdoty> issue 60, 157, 102
there is also a proposed narrowed issue on minimization. If this was in Jonathan's email i did not skip it in person.......
<npdoty> peter will send one final email about closing those issues
one issue addressed in sunnyvale was (in addition to disclosure of retention periods per tlr group) also should there be firm retention limits......
<trackbot> ISSUE-31 -- Minimization -- to what extent will minimization be required for use of a particular exemption? (conditional exemptions) -- open
<adrianba> how many of the proposed issue closing mails have been sent to public-tracking-announce?
the language in janathan's email did not, I think, neutrally capture this, but I think the general minimization principle could go into pending review and i am inclined to open new issue on whether there should be firm retention limits.
dan auerbach: in jonathan's email he said "how stringent is global standard" so please wait a week for me to review....
<npdoty> dan or others, is there anything we can do to provide additional confidence that pending review is not closed?
<rvaneijk> Their should be firm requirement for transparency on data retention per permitted use
peterswire: we are attempting to clarify where things are rather than surprising people, but we'll wait a week on issue 31 and create a new retention issue as discussed in f2f.......
<WileyS> + to Rob - we've already agreed to that
<dan_auerbach> Nick, I think more clarity around the process of how to get to last call given areas of disagreement would go a long way
<npdoty> wait a week before moving on issue-31, and create new issue regarding minimization or heightened transparency regarding going beyond certain retention limits
<fielding> If we are going to continue with this level of pushback, then I will ask the chairs to abandon this notion of STABLE and just formally close all issues according to normal W3C process. We do not need consensus to close.
<npdoty> dan_auerbach, I will do anything I can to do that
peterswire: there were no other comments on issue clarification. any other comments? [none] Goal was to get clarity and narrow the list of things that should get our attention......
<phildpearce> On the AVG user-expression override example... AVG also overrides the document.referral from google.com/?q=keyword to avg.com/?q=keyword when a user comes from organic search (in addition to inserting DNT=1) meaning that two changes are exposed in the DOM, increasing the chance that a server might use these 2 elements to differentiate tracking behaviour for AVG users vs other DNT=1 users.
<npdoty> ... spending several weeks on moving issues to pending review is not a path to anything, certainly not to Last Call
<phildpearce> Invalid click Expert suggestion: Dr Alexander Tuzhilin. http://www.businesswire.com/news/home/20090909005127/en/Search-Advertising-Fraud-Prevention-Expert-Joins-Click
<phildpearce> On the user-education piece here is a collection of useful videos: http://www.youtube.com/watch?v=A6fV2v7LLPo&list=PL45AABD8BB96D3785&index=4
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/2 and 4/true and false/ Succeeded: s/2, 4/true, false/ Succeeded: s/non-compliance/compliant/ Found ScribeNick: susanisrael Found ScribeNick: npdoty Found ScribeNick: susanisrael Inferring Scribes: susanisrael, npdoty Scribes: susanisrael, npdoty ScribeNicks: susanisrael, npdoty Default Present: schunter, efelten, npdoty, Thomas, Yianni, Chris_IAB, RichardWeaver, kulick, Fielding, jchester2, phildpearce, Peder_Magee, +1.415.436.aaaa, +1.781.482.aabb, Chris_Pedigo, +1.212.231.aacc, paulohm, +1.301.365.aadd, Craig_Spiezle, +49.431.98.aaee, ninjamarnau, vinay, peterswire, samsilberman, sidstamm, hefferjr, vincent, WileyS, +1.202.787.aaff, BerinSzoka, +1.202.344.aagg, [Microsoft], Lmastria_DAA, Wendy, adrianba, mecallahan, [FTC], WaltMichel_Comcast, jeffwilson, dwainberg, Mike_Zaneis, hwest, dan_auerbach, moneill2, +1.202.787.aahh Present: schunter efelten npdoty Thomas Yianni Chris_IAB RichardWeaver kulick Fielding jchester2 phildpearce Peder_Magee +1.415.436.aaaa +1.781.482.aabb Chris_Pedigo +1.212.231.aacc paulohm +1.301.365.aadd Craig_Spiezle +49.431.98.aaee ninjamarnau vinay peterswire samsilberman sidstamm hefferjr vincent WileyS +1.202.787.aaff BerinSzoka +1.202.344.aagg [Microsoft] Lmastria_DAA Wendy adrianba mecallahan [FTC] WaltMichel_Comcast jeffwilson dwainberg Mike_Zaneis hwest dan_auerbach moneill2 +1.202.787.aahh Jack_Hobaugh WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 22 May 2013 Guessing minutes URL: http://www.w3.org/2013/05/22-dnt-minutes.html People with action items: alan chapell chester doty eijk mejia peter rvaneijk swire van wainberg with[End of scribe.perl diagnostic output]