<mikeo> +44.186.573 is mikeo

<tl> Thank you for remembering me again this week, Zakim.

<aleecia> Any volunteers to scribe?

<jmayer> I'll volunteer - but have to drop at 55 past.

<npdoty> scribenick: jmayer

<susanisrael> aaii is susanisrael

<eberkower> aajj = eberkower

aleecia: Reviewing overdue action items.
... ACTION-245 and ACTION-248 with schunter, not on

<Chris_IAB> just joined on a blocked number

<WileyS> I'm on now

<WileyS> Yes

<WileyS> Although I believe the text can be collapsed to "any party representing another party"

aleecia: ACTION-226, dsinger worked into draft form

<dsinger> notes that the integrated text and question from my action are at http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#transitive-exceptions

aleecia: ACTION-161, wileys working on now
... comments on editors' draft - please send

<npdoty> http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html

aleecia: want stable version for Amsterdam
... many options remaining, be sure to note what you can't live with

<npdoty> http://www.w3.org/mid/5FA89E36-87CA-4396-AE92-0333894249AF@w3.org

aleecia: asking npdoty to review ACTION-235 text

npdoty: This was an attempt at a possible compromise or consensus position.

<damiano> 813 is tampa, but i'm calling from google voice and not sure what my number is

npdoty: Basic principles: flexibility and implementability. Motivations: focus on third-party data retention about user browsing history.
... Not new, just an attempt at compromise.
... Allows short-term logging.

<jchester2> I don't think we have consensus on personalization, so we should fully discuss

npdoty: Tried to expand on frequency capping proposal in Seattle.
... Broad "reasonably necessary" exceptions for financial reporting, security.
... Potential change: language about particular tracking technologies.

<npdoty> I've tried to talk to several people in the group about this, thanks for all of your feedback and if I got things wrong I'm sure it's my fault

aleecia: Expect many will want other proposals to stay on the table.
... We've discussed all this many times, not new territory.
... Will move towards a decision process of comparing texts side-by-side.
... Starting with discussion of short-term logging.

<WileyS> Aleecia - want to confirm that within this timeframe only permitted uses or preparation for permitted uses is permitted.

aleecia: Similar to discussion in Seattle.

<WileyS> Finance/Audit Permitted Use would cover that

Richard Weaver, Comscore: Need to retain data longer for auditing.

<npdoty> Richard mentioned a specific organizational requirement but I missed the name, can someone fill that in?

<robsherman> Media Ratings Council

<susanisrael> MRC-Media ratings council

<Brooks> is conference bridge at max capacity? Can't seem to get in on 3 different lines

aleecia: You get six weeks to figure out what you've collected, then retain for permitted uses.

<justin_> Right, but you wouldn't be able to extract value from it past 6 weeks (i.e., correlate user 1234 from eight weeks ago with what they user does today). For better or worse.

<Chris_IAB> Brooks is trying to get on, and he may have relevant input to this issue

<Brooks> Brooks is in

<justin_> At least that is my understanding on npdoty's proposal.

<WileyS> Okay - permitted uses, preparation for permitted uses (data minimization), and unlinkability to move data out of scope.

npdoty: (As the scribe understood it) - Can use for permitted uses, prep for permitted uses, or prep unlinkable datasets.

<WileyS> Justin - agreed - there was some confusion that BT was allowed within that timeframe and wanted to remove that thought off the table

John Simpson: proposal is n weeks, have discussed 6 on the call, might want that to be shorter

aleecia: starting with n weeks

<aleecia> Operators MAY retain data related to a communication in a third-party context for up to 6 weeks. During this time, operators may render data unlinkable (as described above) or perform processing of the data for any of the other permitted uses.

<justin_> WileyS, my comment was not about BT (if you mean behavioral targeting), but aggregate reporting. You can't use log data for aggregate reporting outside the N-week period. That is how I read the proposal but perhaps I am wrong.

npdoty: have been discussing 6 as a commonly heard number

aleecia: Is there anyone who can't live with this proposal?

<WileyS> Justin, agreed - the proposal requires that the unique identifier within records be "unlinked" from production values for retention beyond 6 weeks for aggregate reporting.

Brooks: Want more time to look at it.

fielding: Also want more time.
... Didn't understand.
... Would like to see a diff or actual text.

<Chris_IAB> just re-joined the call from Skype

dwainberg: Also not enough time.

<npdoty> I apologize if this formatting was unclear, I tried to provide the text and then provide a description of what the changes are

<fielding> On the whole, I think the suggestions are an improvement, but I don't understand why we are talking about it before reviewing an change proposal

<ifette> I didn't get a chance to really consider Nick's proposal yet

aleecia: This should be familiar from prior conversations.

<npdoty> fielding, some people have complained about my sharing diff-format proposals, so I tried to present the differences in english text

<npdoty> jmayer: we've been discussing this stuff for a long time, expect many people have thoughts already, specifically discussed in the form of CDT proposals discussed earlier

<fielding> npdoty, understood -- I just did not find the format readable last night, and have no idea what I am being asked to live with

<npdoty> ... question for nick, retain data for a short-term, use where reasonably necessary

<susanisrael> +susanisrael

<susanisrael> sorry i meant +q

<npdoty> ... do you get to keep logs with unique ids if you think it's reasonably necessary for a permitted use?

<justin_> Ugh, enough meta-discussion on "we need more time." Let's just talk. But jmayer is right that npdoty's proposal closely tracks the CDT proposal: https://www.cdt.org/files/pdfs/20110447_DNT_v2.pdf (with the addition of the short-term usage period, which we support).

<Chris_IAB> re Jonathan's first statement, call for decorum please (input should not be called "total nonsense" just because you disagree with someone's position or request)

<Chris_IAB> Jonathan, David's point is that there is new language, and we all need time to review that language and analysis (with a very BIG industry of stakeholders)

<Zakim> dsinger, you wanted to suggest what we're looking for...

<susanisrael> even though people may know high level positions, sometimes people like to have time to look at language nuance. MRC auditing is not purely financial

<justin_> We will not come to consensus on how appropriate wanting more time is on this call. Let's just stipulate and move on to substance.

<laurengelman> i just joined the call

<npdoty> npdoty: yes, I think there will be some cases where unique identifiers are retained beyond the short term period, and the reasonably necessary debate can be with your regulator or self-regulatory group

<dsinger> ok

<dwainberg> @justin_ Fair enough that many/most of these are not new concepts. However, given that we received this last night, and that a detailed discussion was not on the agenda, I did not come prepared to discuss these.

dsinger: Can maybe look at whether people can live with where this comes down on particular issues?

<dwainberg> Also, I think there's some fear about issues getting closed quickly, and missing something.

aleecia: Yes, review what people can live with.

<justin_> I wish we'd gotten earlier dwainberg, but we can at least talk about ideas. But I can see why "can you not live with this" would set off alarm bells!

BrendanIAB: 6 weeks is somewhat reasonable. Would we standardize that particular timeframe?

<npdoty> as I recall, Ian had suggested 6 weeks (more than a month logging), CDT had proposed 2 weeks, I've heard 5 weeks in other suggestions

aleecia: Date came from industry suggestions, roughly one month + some added tolerance time.

<dwainberg> That was my point. If it's let us have an informal discussion and see what issues come up, that's one thing. But the "can you live with this language" has become a pavolian signal that we're trying to close issues.

<Chris_IAB> I don't remember that companies had agreed to 6-weeks

<dwainberg> pavlovian

<tl> +q

<justin_> Industry did not agree 6 weeks, ifette just mooted it as an idea (as npdoty said)

<Chris_IAB> how about a poll? is that your point Brendan?

<npdoty> for the various permitted uses, to be clear, you would retain data for stated retention periods that would be business-specific

BrendanIAB: What about you must publish a retention period, but not a fixed six weeks?

<BrendanIAB> Jmayer - that's exactly what I was suggesting

<Chris_IAB> I believe industry gave feedback that more research was required... 6-weeks was pulled out by someone, but I don't believe it had been validated

<BrendanIAB> it allows competition on the retention period.

<npdoty> BrendanIAB, WileyS's industry proposal focuses on transparency (and potential competition) for retention periods that are based on implementer-specific decisions for each permitted use

tl: Should have a maximum retention period.

<efelten> Even with (e.g.) a 6-week limit, companies could still compete on retention period, by adopting a shorter one.

<npdoty> or competition on the retention periods for their particular permitted uses?

aleecia: Expect we'd narrow in on options - fixed period, flexible period.

<Chris_IAB> What is "6-weeks" based on? A best guess by people on this working group? Is there another basis for this seemly arbitrary number of 6-weeks?

<justin_> Chris_IAB, aleecia just explained the provenance of the 6 week period.

Lee Tien: The six weeks is a maximum, right? Could compete with shorter periods?

justin_, shhh, Chris_IAB is busy hitting his talking points today. Decorum!

<Zakim> fielding, you wanted to ask what is required at the 6 week boundary

<Chris_IAB> justin_, looking for more than "it seems that people might be able to live with it based on a past conversation" (such conversation I was apart of, and don't recall in the same manner)

<WileyS> Logged-in would be 1st party

<WileyS> Made unlinkable I believe is the goal - so removal of unique identifiers would be "enough"

<Brooks> Logged in does not have to be 1st party - think facebook

<aleecia> todo: explain what happens when data is not retained, and perhaps just link to where it is elsewhere

<Chris_IAB> jmayer, do you have something substantive to add on this subject? The rest of us are trying to get to the point...

fielding: Need clarity on what constitutes unlinkable data.

<fielding> WileyS, not in practice

<susanisrael> +1 to reducing sniping

aleecia: Stop sniping on IRC.

<susanisrael> chris, jmayer is just scribing i think

<fielding> I have no means to programmatically determine what is "linkable". I would need a list of fields to remove from the logs.

<npdoty> current definitions on unlinkable are here: http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#def-unlinkable

<WileyS> Brooks and Roy - I took your statement to say "authentication logs" - are you suggesting Facebook authenticates users in a 3rd party context in a manner that would have them operating as 3rd party (vs 1st party)?

npdoty: <some attempted explanation of unlinkability>

<justin_> I think fielding's point is that we need certainty around the definition of delinking in order to meaningfully know how to meet the N-week period. Do you want more prescriptive language on unlinkability?

fielding: Want to know about specific fields, e.g. must drop IP, must drop query parameters, ...? Don't need clarification immediately, but want it for drafting stage.

npdoty: The group has discussed linkability a number of times. Data where you don't know about linkability is a separate issue.

<Brooks> My understanding is that Facebook keeps the u= cookie so long as a user is in a logged in state. Don't know how they maintain logged in state (ie is it REMOTE_USER) don't know

<ifette> disagree

<npdoty> fielding's concern is related to the possibility that query parameters might include, unbeknownst to you, personally-identifiable information (like Web searching for my name)

<ifette> yes

I think we're very close on unlinkability. The DAA definition is roughly can't be linked to a particular user/device/...

<WileyS> Justin, see the proposal for unlinkablity I submitted in Seattle

<Zakim> ifette, you wanted to answer aleecia's question

<aleecia> specifically: raw log files

<justin_> WileyS, I think jmayer is right that we're close conceptually, but it sounds like fielding wants more certainty about which fields to strip. (?)

<WileyS> Jonathan - our goal is to break the tie between production and retention state identifiers - such that aggregate reporting still operates correctly but the data can't be used to modify a user's experience in anyway

<dsinger> I think it's 'tracking data' (not well defined) that is *outside* a claimed permitted use that we need to discuss

<npdoty> justin, I agree, maybe the motivation is that we want an implementers' guide, 'just drop these fields'

ifette: Thought we'd allow keeping a single copy of log files, access based on permitted uses.

<WileyS> Justin - that's fair. My thought was unique identifiers (ID/IP) would need to be "cleansed" to meet unlinkability.

<npdoty> I think aleecia and ifette agree, in that if you don't have a permitted use to keep the log files you would have to get rid of them, but if you do, then you can keep the data in whatever form is appropriate

<BrendanIAB> Clarification: when we're talking about "log files", we're talking specifically about the records in the log files that have the DNT signal, correct?

aleecia: Nick's proposal wouldn't require multiple copies.

<justin_> Yes.

<justin_> Yes, BrendanIAB.

<npdoty> BrendanIAB, yes, I don't think anyone has suggested changing retention for non-DNT users

<efelten> Yes, Brendan, this is just for records from DNT:1 interactions.

<BrendanIAB> Right, let's make sure that the language doesn't imply the former, since we do mean the latter.

<aleecia> Retaining and using data for frequency capping of online advertisements is allowed if the tracking identifier is only retained in a form that is unique to each super-campaign (e.g., one-way hashed with a campaign id) and does not include retention of the user's browsing history or activity trail (page URIs on which the ads were delivered). Implementers SHOULD NOT create detailed profiles of user browsing activity or user behavior based on their ad frequency

<aleecia> history, for example, by retaining identifiers unique to ad impressions served on individual pages.

aleecia: Moving to frequency capping.

<WileyS> +q

<Brooks> Is "super campaign" something that is clearly defined?

<eberkower> Not that I'm aware of

<dwainberg> that was going to be my question. I'm not sure I'm clear on what that is.

<justin_> WileyS, is that still tied to user? Don't show user 1234 the ad on Yahoo! cars x times/week? Or don't show over 50000 ads on Yahoo! cars?

<dwainberg> Actually, I'm sure that I'm not clear. :)

<fielding> brooks, no -- it was just made up to include "campaigns or a union of multiple campaigns"

<Brooks> I can tell you that I bet you could go to a WPP business, ask 10 people and get 10 different defintions of a "campaign"

<WileyS> Just wanted to make sure I was capturing your intent Nick

wileys: Can retain list of URLs user has visited for frequency capping?

<aleecia> (Can hash against URL, rather than campaign ID)

(Apologies for not accurately transcribing Shane's comment - Chris Mejia was trying to lecture me about professionalism in DMs. Most entertaining.)

<WileyS> UserID*SiteURL + Campaign ID vs. User ID + Campaign ID (Super Campaign)

<susanisrael> sure

<npdoty> scribenick: susanisrael

aleecia: need a little work to clarify how freq capping works re: need to limit frequency on pages or areas

<Brooks> shane, again I am not sure "campaign" is even well defined

<aleecia> defn super-campaign

aleecia: may be productive conversation to happen with shane. also need definition of campaign/supercampaign

<npdoty> my thinking was that WileyS may be suggesting another technique that would also achieve the goal (not retaining URL histories), and that might also get the support of the group

amy: we would be happy to participate in conversation but would also like to define purpose of frequency capping to avoid needing definitions of things like supercampaign

aleecia: can just explain concept?

amy: yes then standard can be more flexible

<justin_> Agree strongly with amyc that we don't need to add defs.

johnsimpson: curious why this is a should not rather than must not re: creating detailed profiles of users

aleecia: don't remember why we agreed on that but it reflects where group landed

<fielding> ditto, it doesn't make sense as a SHOULD NOT

npdoty: think that was my addition

<aleecia> Implementers SHOULD NOT create detailed profiles of user browsing activity or user behavior based on their ad frequency history...

<vincent> my understanding is that we would have two tables one with <hash(campagnID,userID,URL), adID > and one with <hash(campagnID,userID), adID >, is that correct WileyS ?

npdoty: thought it was hard to precisely define, if people are fine with must not, great

aleecia: any pushback on changing form should to must?

<npdoty> if people prefer MUST NOT, that's fine

amy: maybe that sentence not necessary
... permitted uses may cover this already in shane's draft

<fielding> agree, it is redundant

aleecia: may make sense to add in non normative language here if people read only a section at a time

<bryan> "should not" is typically allowed if there are reasonable limitations due to technical feasibility. given this is a new technology with substantial impacts, this latitude should be given

<WileyS> vincent, correct - the result would be neither record for the same user would be matchable

<npdoty> I was trying to distinguish between use and retention, i.e., you shouldn't retain the data if it reveals a sensitive profile

<vincent> thanks

aleecia: no one says they can't live with fc, some suggestions on implementation from shane, may be better todescribe than define supercampaign, and sentence "implementers should not" should be moved to nonnormative language was another suggestion

npdoty: ok, is amy volunteering?

<aleecia> 1. move from super-campaign to description, 2. discussion with Shane around methods, 3. non-normative text for not profiling

amy: can help out but not sure of action item, would just like to understand frequency capping suggestions a bit more

aleecia: nonnormative text re not creating profiles would help

<aleecia> sorry Roy - one moment

amy: ok, can do that

<justin_> johnsimpson, that concept is addressed elsewhere in the text

john simpson: confused about suggestion

<justin_> We're all agreed that's not appropriate.

aleecia: was just saying don't need to repeat something that is said elsewhere in normative text, so can add normative text here in case someone needs a reminder of what applies

<npdoty> ACTION: amy to draft text on freq. capping that would avoid new definitions and/or remove redundant normative requirement (with nick and shane?) [recorded in http://www.w3.org/2012/09/12-dnt-minutes.html#action01]

<trackbot> Created ACTION-254 - Draft text on freq. capping that would avoid new definitions and/or remove redundant normative requirement (with nick and shane?) [on Amy Colando - due 2012-09-19].

roy: was going to note that there is a tendency to move things to nonnormative sections but they shouldn't contain things like that, should be a must not

aleecia: why can't non normative refer to other place in document?

<amyc> hey Nick, I'm volunteering to help out with (3), but the frequency cap definition I was hoping that Shane could take lead on. happy to help out though

roy: it can but can't create a requriement

aleecia: just trying to reference normative section that creates requirement

roy: i don't see a need for that

<WileyS> Happy to take this on - but I'm on vacation for the next week and will miss next week's meeting so I'll need more time.

<npdoty> I think aleecia is suggesting non-normative text that would only refer the reader to an existing normative section with requirements

<aleecia> double-check that there is a global norm req

aleecia: should double check that it's normative language elsewhere

<amyc> just want to make sure that someone more tehchnical involved in frequency cap specifics

aleecia: we're getting to something that's pretty close on this, will move to financial reporting and auditing

<aleecia> To the extent required by law, third parties may engage in tracking as is reasonably necessary for financial reporting and auditing. Data necessary for recording unique ad impressions, positions and interactions may be retained for this permitted use.

pasting in normative seciton re: financial reporting permitted use

aleecia: reads fin reporting/auditing language permitted use language from nick's proposal. no comments
... if no comments we may be able to agree on this quickly

<jchester2> I think this needs to be discussed further. It depends on interpretation of the law and needs to be balanced with industry standard practices. We need to have a definite time period.

<ifette> why do we need to "allow" auditing?

npdoty: noted one open question there. might be some services that would retain identifiable data for auditing for significant period of time just to make customer s more comofrtable

<ifette> auditing isn't prohibited...

nick: want sense of group on this?

<jchester2> +q unmute me, please

<Chapell> +1 to auditing beyond legal requirements

<Chris_IAB> npdoty, when you say auditing, are you referring to ad verification services?

dwainberg: understand concern about loophole but need some flexibility on that due to real business requirements

<ifette> nope

<ifette> not me

aleecia: hearing one branch to something other than required by law

jeff: think we need to have more informatio nsupplied here quickly. want to see what industry standards are for financial reporting. can interpret law differently
... don't want to get to situation of difrerence on law

<Chris_IAB> Jeff, respectfully, the IAB doesn't publish such a standard (financial reporting is out of our scope)

jeff: call on regulators to supply this info (which info?)

<jchester2> mute me, please

<npdoty> Chris_IAB, yes, that's what I meant about auditing beyond legal requirements, maybe I should be using other terminology, very happy to accept suggestions on that

aleecia: hearing required by law not flexible enough for biz, clear enough for privacy advocates

<Chris_IAB> npdoty, no prob and thanks-- just trying to see if we are on the same page with the lingo :)

aleecia: have not been willing to get auditors to speak on record-if you can that would be welcome

<npdoty> I was hoping "required by law" would let us avoid having to determine particular requirements within the WG

aleecia: hearing this phrase will not work for many. anyone in favor? nick
... if no strong supprot for this need another metric

justin: don't understand if billing out of scope

<fielding> Most third-party audits are required by customers or as a regular part of business (annual), IIRC.

npdoty: tried to call out billing for ad impressions, thought that would be understood to be required by law

justin: don't think that's right

<Chris_IAB> law vs. contract law?

justin: this would be contract not law requirement, might need to write more expansively

brooks: diff between law and contract

<WileyS> +q

<npdoty> justin: I don't think keeping logs in order to do billing is required by law

<justin_> We need to find a middle ground between law and contract law. But I have no idea how to do that!

<jchester2> Can the DAA and IAB/EU supply the set of industry standard practice documents related to billing. etc.

<Chapell> .... auditing, including but not limited to ad vertification, billing, measurement, determining descrepancies in impression counts, etc

brooks: sarbox implicated but intersection of 2

<npdoty> agreement from 5/23 was "Adherence to laws, legal and judicial process, and regulations take precedence over this standard when applicable, but contractual obligations do not."

<WileyS> Nick,

aleecia: meme proposed language re: old contracts remaining in force, not create new contracts shouldn't contradict requirements

aleedia: npdoty proposed law trumps

<WileyS> Nick - this is an issue of financial/tax law - if I enter into a contract and bill someone for XYZ, I need to retain proof that I delivered XYZ (receipt)

aleecia: so conflict between law/contract is covered

<Chris_IAB> jchester, IAB doesn't have such a doc -- financial reporting is really out of scope for our practice, yet the necessity exists (we just don't stipulate any practices for them)

<fielding> s/aleedia/aleecia/

<justin_> That would invalidate future CPA implementations, which seems extreme. Maybe if we disassociate billing (relatively short term) from auditing (long term)? Just thinking out loud.

shane: said in irc too but we are saying contracts don't supercede law, but saying that re: finance and tax law, if you agree on something in contract you need to retain proof that you fulfilled obligations that you would deliver certain things

<Brooks> shane, well said

shane: contracts are subject to law, need to document performance

<Chris_IAB> and further to Shane's point, these laws and regs are highly jurisdictional around the world

shane: it's circular

<jchester2> But Shane, the contract device could be used to retain data far beyond what are the standard practices agreed to by the major advertisers

<justin_> Contract law does not per se require independent auditing obligations, but if statutory law requires retention of billing contracts, that's different and I think we can agree that should be allowed.

ian: way that i find helpful to look at this is that jonathan and others are trying to forbit adding contract language solely to require retention of data when would not otherwise be able to do it

<WileyS> Jeff, its not the contract that's the issue, its the federal, state, and local finance and tax laws that drive the retention of the elements contained in the contract

<npdoty> WileyS, per that point, if you had a contract that required behavioral reporting (delivery only to people who had visited certain other sites, say), would you suggest that financial reporting law would require retaining data to prove that's fulfilled?

ian: think you can look at requirements from contracts vs legal from contracts

<Brooks> jeff, perhaps but if law tells me I need to keep data to assure that a contract was fulfilled that is out of the advertisers hands

<Chris_IAB> justin_, that approach seems reasonable to me at first glance, thanks

ian: think this is a distinction we need to follow

<Zakim> dsinger, you wanted to note the general conditions

ian: don't think saying contracts grant you no rights to keep data will work in and of itself

<jchester2> We don't have a clear understanding of what the law requires. Sarbannes/OIx can be interpreted in mutliple ways. We need to have a definite time period.

<ifette> +1 to dsinger

<Chris_IAB> agree with dsinger verbal point

dsinger: need to say that if you retain data for permitted use it's your job to make sure it's used only for permitted use, i,e reporting/auditing for which it should be the minimum needed

<npdoty> "Secondary Use" is listed in the additional/general requirements

dsinger: may be better to focus on function

<dwainberg> Jeff, I get the issue. I don't think it'll be possible to establish a definite period in the way you want.

<Chris_IAB> great suggestion David

aleecia: will you (david singer) work with nick on language

<jchester2> Can the NAI supply to the list the standard agreements used by the IAB/US, AAAA, etc?

npdoty: i think we already have text prohibiting secondary use but if we need clarifying text happy to work on it

<justin_> I think the action should be translating what ifette described into the existing language.

alan chappell: this triggered memory of an issue I have encountered. pharma industry forbids advertising to clients in uk

<dwainberg> Jeff, the standard I/O is available on the web. But I don't think it provides the info you want, and is not the only contract in use.

<npdoty> justin, can you describe that action in more detail for me?

<Chris_IAB> jchester2 are you referring to the IAB & AAAA Standard Terms and Conditions for Display Advertising?

<Chris_IAB> if yes, I can supply the link here

alanchappell: had to show that ad agency and dsp did not serve the ads. it's edge case but sometimes you need records to prove something

<Chris_IAB> but I don't think you will find what you are looking for...

alanchappell: reaching for more broad framework than law and auditing

<fielding> I would think that siloing data by audit target would be a more useful limitation.

aleecia: suggestions?

alanchappell: will work with nick

aleecia: or make suggestions to mailing list

<jchester2> yes, those. And if you could point to the group where they discuss financial reporting, payment requirements, auditing. Many thanks!

<justin_> Sure, if statutory law requires retention for auditing of performance of a contract, that is allowed, but the contract cannot indepedently require extra retention for that purpose. Or something like that. Not sure if that's workable but that seemed to be where consensus was headed.

<Chris_IAB> it doesn't go into such billing detail, and in practice it also only serves as only a basis for the negotiation of a contract (hardly ever accepted as-is)

<npdoty> as we do increasing levels of review, we should get exposure of new use cases

aleecia: hearing that on frequency capping we are not comfortable

want to go throug remaining uses: next = security and fraud

<aleecia> Operators MAY retain data related to a communication in a third-party context to use for detecting security risks and fraudulent activity, defending from attacks and fraud, and maintaining integrity of the service. This includes data reasonably necessary for enabling authentication/verification, detecting hostile transactions and attacks, providing fraud prevention, and maintaining system integrity. In this example specifically, this information MAY be used to

<aleecia> alter the user's experience in order to reasonably keep a service secure or prevent fraud. Operators SHOULD use graduated or triggered responses where feasible.

susan israel thinks aleecia just meant financial/auditing in last comment

aleecia reads fraud/secutiry permitte use language from nick's draft

<jchester2> Chris from IAB: Can you review for us the relevant items in such docs as: http://www.iab.net/guidelines/508676/508858/1497; http://www.iab.net/guidelines/508676/tscs3

<dsinger> notes we'll need an example in an annex on what we mean by 'graduated or triggered' :-)

<Chris_IAB> jchester2, here it is: http://www.iab.net/guidelines/508676/tscs3

aleecia: agree that we need examples for security and fraud uses

<npdoty> I think someone wanted to take an action on new proposals regarding financial reporting permitted use

aleecia: any other reaction?

<Chapell> yes

aleecia: alan chappell would you take action to work on proposals for financial reporting? yes

roy: it should also include case of recording data collected for use in pattern matching for third party

aleecia: explain?

roy: it's confidential

<Chris_IAB> jchester, I'm quite familiar with those "best practices"; they are very high level and only a recommendation

aleecia: think you are trying to get at "have seen fraud before with certain data pattern, want to retain data that looks like that right?

<jchester2> Chris from IAB: It would be great if you could share with the list thelanguage in the standards--as well as with the AAAA and international ad bodies--that relate to this issue. Can you do? Thanks

<npdoty> ACTION: chapell to work on financial reporting text (with nick, ian) as alternative to legal requirements [recorded in http://www.w3.org/2012/09/12-dnt-minutes.html#action02]

<trackbot> Created ACTION-255 - Work on financial reporting text (with nick, ian) as alternative to legal requirements [on Alan Chapell - due 2012-09-19].

roy: no, third party companies collect to create pattern matching after the fact, just trying to find patterns

aleecia: can you draft?

<npdoty> action-255: justin may be able to help with that

<trackbot> ACTION-255 Work on financial reporting text (with nick, ian) as alternative to legal requirements notes added

roy: i can't put it in writing on an email message

can anyone?

aleecia: can anyone take this?

<Chris_IAB> not sure I understand the requested action?

<npdoty> is it not data for detecting hostile transactions and attacks?

<amyc> clarifying question for Roy

<Chris_IAB> fraud and security

<amyc> same question as Nick, actually

roy: if there is just a general thing that says dnt does not impact data collection for preventing fraud and attacks that is sufficient
... do not want to make that data avail for other purpose

<npdoty> agree, we should not specify detailed mechanisms

aleecia: you want "includes but not limited to....right?
... does general case statement make sense to you?

<fielding> includes but not limited to sounds good

aleecia: not seeing some reason why general language would not cover-so maybe we are ok

dwainberg: would prefer rather than "to extent reasonably necessary " just say can't be used for any other purpsose

<tl> Right, and we obviously can't use words which have meanings.

dwainberg: second point: uncomfortable with use of word fraud, which is used for impression fraud in ad industry

<Chris_IAB> deceptive, in addition to fraud

dw: prefer for prevention of security problems and malicious behavior

<Brooks> can we use the term "high quality" in place of fraud?

aleecia: have talked about this before. can you help with phrase that gets beyond legal version of "fraud"

<dwainberg> "the detection and prevention of malicious or invalid activity"

<Chris_IAB> click fraud, but also impression fraud

<fielding> deception, fraud, or malicious activity

aleecia: dw suggestions prevention and detection of malicious and invalid activity

<Chris_IAB> deceptive...

susan would deceptive be better than invalid?

<aleecia> illegit, e.g. bots

dw: companies can identify activity that's not malicious but not valid impressions, needs to be filtered

<npdoty> while it may be hard for me to convince advocates/regulators on a broad security exception for anything reasonably necessary, it will be much harder for me to win consensus for retaining anything (not even necessary) related to security

aleecia: illegitimate? can you draft one or 2 sentences?

dw: yes

<BrendanIAB> It may include bots and things other than bots

<BrendanIAB> like accidental clicks

dw: to first point, any response? i would act on this?

<dsinger> it's legitimate *activity*, it's not a legitimate *impression*, when a bot 'views' an ad

npdoty: i am hoping the reasonably necessary language would work, already a big move for advocates

dw: will consider and connect offline to discuss

<Chris_IAB> was still in the q

aleecia: one minute left, 2 more to work through

<aleecia> Operators MAY retain data related to a communication in a third-party context to use for identifying and repairing bugs in functionality. As described in the general requirements [reference to Minimization section], services MAY collect and retain data from DNT:1 users ONLY when reasonably necessary to identify and repair errors in functionality. Services SHOULD use graduated responses where feasible.

<npdoty> ACTION: wainberg to propose update on security/fraud regarding deception/ad fraud [recorded in http://www.w3.org/2012/09/12-dnt-minutes.html#action03]

<trackbot> Created ACTION-256 - Propose update on security/fraud regarding deception/ad fraud [on David Wainberg - due 2012-09-19].

chris: just wanted to reiterate a couple things.

chrisss_iab: when you collect data you don't know there is a pattern, you collect it and then look for pattern

aleecia: appreciate the problem

<efelten> Is it really a secret how this kind of technology works, in general terms?

chris_iab: i like approach of either word reasonable or just limiting to this purpose

aleecia: so there may be a counterprposal there

<dwainberg> Ed, there's great sensitivity about disclosing details because it's an ongoing cat-and-mouse game w/ bad actors.

aleecia reads normative text for debugging from nick's proposal

<npdoty> I think there's support on using general terms, both because it's a more flexible spec and it avoids concerns about IPR

<efelten> I understand that people want to keep details of specific products secret. But general outlines are well known.

<dwainberg> Bad actors are constantly inventing new ways to try to mask their behavior.

<Chris_IAB> efelton, yes, very secret... we don't want that kind of intel to get into the hands of nefarious actors

aleecia: probably need to take this to mailing list

<fielding> efelten, probably not, but it is difficult to know what parts are proprietary and which are already published somewhere

<vincent> not sure that should cover accidental clicks though...

aleecia: favor to ask. will need to use mailing list heavily in next few weeks. Please proofread to see if you can make your point in the most civil possible way that will help us to move forward

<efelten> Yeah, people not NDA'ed might be able to contribute more on these points.

aleecia: i owe you all work on the tripartite state, that's late and on me, coming soon
... thanks, look forward to speaking soon

<schunter> Aleecia?

<npdoty> Chair: aleecia

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: jmayer
Found ScribeNick: susanisrael
Inferring Scribes: jmayer, susanisrael
Scribes: jmayer, susanisrael
ScribeNicks: jmayer, susanisrael

WARNING: No "Topic:" lines found.

Default Present: +44.186.573.aaaa, npdoty, samsilberman, mikeo, aleecia, dsriedel, +1.919.388.aabb, +1.202.326.aacc, tl, +1.703.438.aadd, efelten, stevebellovin, vincent, +1.202.370.aaee, AnnaLong, +1.813.366.aaff, RichardWeaver, robsherman, jchester2, dwainberg, damiano, justin_, Lee, cblouch, johnsimpson, suegl, jmayer, hefferjr, bryan, +1.646.827.aagg, +1.206.658.aahh, +1.917.934.aaii, +1.646.654.aajj, dsinger, Joanne, susanisrael, eberkower, fielding, +1.646.666.aakk, vinay, chapell, adrianba, WileyS, KevinT, Chris_IAB?, hwest, +1.202.386.aall, ifette, Brooks, BrendanIAB?, +aamm, ksmith, schunter, laurengelman?, +1.202.507.aann, ChrisPedigoOPA, [Microsoft]
Present: +44.186.573.aaaa npdoty samsilberman mikeo aleecia dsriedel +1.919.388.aabb +1.202.326.aacc tl +1.703.438.aadd efelten stevebellovin vincent +1.202.370.aaee AnnaLong +1.813.366.aaff RichardWeaver robsherman jchester2 dwainberg damiano justin_ Lee cblouch johnsimpson suegl jmayer hefferjr bryan +1.646.827.aagg +1.206.658.aahh +1.917.934.aaii +1.646.654.aajj dsinger Joanne susanisrael eberkower fielding +1.646.666.aakk vinay chapell adrianba WileyS KevinT Chris_IAB? hwest +1.202.386.aall ifette Brooks BrendanIAB? +aamm ksmith schunter laurengelman? +1.202.507.aann ChrisPedigoOPA [Microsoft] Bryan_Sullivan
Got date from IRC log name: 12 Sep 2012
Guessing minutes URL: http://www.w3.org/2012/09/12-dnt-minutes.html
People with action items: amy chapell wainberg

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report