See also: IRC log
<npdoty> Meeting: Tracking Protection Working Group Bellevue F2F
<npdoty> Chair: aleecia, schunter
<npdoty> scribenick: npdoty
JC: welcome! breakfast kudos to hwest
aleecia: welcome, reflections on yesterday
... maybe not a particularly good use of our collective time, moving slowly
... group has gotten a lot larger, so today we'll try more to use smaller groups
... not adding things new, but trying different approaches
... we need to publish something
... we need to figure out what exactly we're building, better understanding of the two proposals
... self-hosted dinner tonight
efelten: want to say a few words for myself, I've been pretty quiet through these meetings but want to offer a perspective of where we are
... frankly it hards to see how either of these proposals will get consensus as it is now
... I can't see how either group could "steam-roll" the other, and in any case it wouldn't be successful in getting legitimacy of all the stakeholders and users
... companies don't want a technology that's overly prescriptive about their practices
... and consumers want a choice that makes a change in the data that's collected, retained and used
... not all consumers want the same thing, that's why it's a user choice mechanism
... not all companies agree, if the MSFT IE discussion has taught us anything
... natural in a competitive marketplace, different companies, even just the browser vendors, all have distinct positions
... everyone is going to need to make concessions, concessions that impose some pain
... those of us who have been involved for a long time recognize what the available compromise would roughly look like
... the biggest issue is the scope of permitted use exceptions
... if there is substantial agreement on that issue, the rest of it can be worked out, what the rest of an agreement would look like
... this is an issue where FTC has spoken, Do Not Collect with limited permitted exceptions
... we have an opportunity here to do something that's difficult to do in any other forum
... we have very significant areas of agreement, which we might miss because we talk most about the areas where we disagree
... not any magic to get to an answer on this, but the stakes are high, think about the alternative to a compromise (as we discussed yesterday)
... and to the extent that I can be helpful, either by talking to folks or getting out of the way, please let me know
<robsherman> ScribeNick: robsherman
aleecia: Want to summarize what we hope DNT will help us avoid as compared to current proposals.
... After that, break into small groups to discuss issues and then bring proposals back to the group.
... We'll re-plan after lunch.
jchester: Not sure that small groups make sense.
aleecia: we're not giving enough time for individuals to get their points across effectively.
jchester: Industry colleagues should specify what their concerns are and articulate how it would affect their business. If we break into small groups, that would help us understand the playing field.
<Ionel> thanks for using the mic
aleecia: Let's go ahead and do small groups and then do that after lunch. We'll get more out of people having a discussion than we will with this many people.
fielding: No point in talking to a portion of the group - just repeat ourselves.
thx efelten
fielding: How do you envision setting up the groups?
aleecia: Please do not go to groups of people you coauthored a proposal with. I'm not going to assign them, but they should be balanced.
... Observers should not write parts of proposals because of IP concerns.
schunter: Rob explained some principles under which exceptions are acceptable in the EU. We have to discuss each one-by-one but we need a working group to discuss this.
rvaneijk: Good idea -- we have work to do.
aleecia: Going to summarize status of proposals discussed yesterday, and also recalling CDT proposal.
WileyS: I think you've made some assertions that aren't correct.
aleecia: Don't interrupt.
<bryan> Does anyone have a link to the slide being presented?
aleecia: EU enforcement risk if people adopt Jonathan proposal is less likely, more likely under Shane's. Unclear under CDT.
... Few browsers would adopt new mechanisms for privacy under Jonathan proposal, more under Shane, unclear under CDT.
... Arms race continues regardless of which proposal we adopt.
... If I wanted to do this today, could do Jonathan's approach with cookie management. Shane's with beefTACO. No real analog for CDT.
... Jonathan's proposal protects privacy, Shane's doesn't, and CDT's somewhat.
... Jonathan's proposal is unlikely to be adopted. Shane's will get widespread adoption. Unclear where CDT stands.
<fielding> what CDT proposal?
WileyS: Please explain the CDT proposal and how you made those assertions because we didn't get a chance to summarize it yesterday. I think our proposal and CDT's were quite well aligned.
aleecia: Not going back to CDT workshop but looking at the CDT proposal from DC.
... We decided we weren't going to propose it but useful to look at for comparison.
<tlr> justin_ - can you drop a link to that proposal into IRC, please?
aleecia: Main difference is retention.
<justin_> I would say permitted uses were the biggest difference.
<justin_> I will link in one sec
<npdoty> I believe this is the CDT text: http://www.w3.org/mid/A10F51CA-396F-46FA-A1B5-9F082767D604@cdt.org
aleecia: At a high level, proposals are very similar in structure, and that's a great thing.
<tlr> thanks, Nick
WileyS: If you feel retention is the demarcation point between likely/clear/unclear, I don't understand that thought process.
<justin_> http://lists.w3.org/Archives/Public/public-tracking/2012Apr/0078.html
WileyS: The two proposals are different in this regard. Flat, arbitrary 14-day vs. company-specific periods with transparency.
... Justin, can you summarize?
justin: Biggest difference is permitted uses.
... Don't allow for product improvement -- thought that could go on forever.
... We did create a 2-week window for product improvement.
... We didn't include a broader 2-week grace period but that could be a logical extension.
aleecia: jmayer, want to weigh in?
jmayer: Aleecia's summary seems reasonable to me.
aleecia: Anyone else?
dwainberg: I'm not clear where this gets us.
aleecia: The point of this is to go back through what we discussed yesterday and to understand what we're trying to avoid with DNT.
... I'm looking at whether these proposals address the issues we're trying to avoid. I don't think either proposal would actually work.
<justin_> I would agree with WileyS's statement that CDT's proposal is more closely aligned to the industry proposal as it does allow for unique identifiers. However, if I were to update this in light of recent events, I would be more explicit that third parties cannot guess user agents (though I still want to explore other ways to ensure UA compliance with the spec).
npdoty: WileyS, you're saying that your proposal is similar to CDT.
<justin_> For those who have just logged on, http://lists.w3.org/Archives/Public/public-tracking/2012Apr/0078.html
npdoty: Maybe if we just tried to elaborate on the existing proposal w/r/t collection and retention that would be a way forward.
jchester: Don't support the CDT proposal, but Aleecia described it well. Yahoo's proposal is a non-starter with US/consumer groups/EU.
WileyS: Want to go through each of these points. You made some broad claims, such as that our proposal "protects privacy barely," which I disagree with.
<fielding> we are wasting our time
WileyS: There's a lot in there. You should ask whether the proposal "allows Internet to remain free, etc." and play this either way.
... Our proposal has incredibly strong limits, limits data use to only things necessary to keep business alive. I don't think there will be regulation, and I agree that it will be broadly implemented.
... On EU risk, I agree if done in isolation but also true for Jonathan's.
... I think new measures for privacy will come up regardless of what we do in this group.
... Privacy discussion didn't begin here and it won't end here.
... Arms race: I think that will exist for a long time. Companies will try to monetize the services they're providing and that will happen regardless.
... beefTACO -- I think you're talking about opt-out cookie persistence and lots of tools do that today.
... but our proposal goes farther.
... We say that data is only used for necessary purposes -- no further profiling.
aleecia: Under any of these proposals, small OBA companies will go out of business.
... Getting permission is difficult if you don't have a brand. So the only thing you care about is the percentage of people who have DNT on.
... Companies say 10-15% is breaking point. We're seeing 10-15% for FFX mobile, desktop >10%.
... So for those companies who JUST do OBA, this is a bad day. It really is. But not necessarily for the Internet overall.
<npdoty> to try to capture Shane's point, re: Do Not Target, we get that and the proposal goes beyond and addresses collection
ifette: Disagree with your assessment of the percentages. Setting it has no effect now because the user sees nothing. Not sure what will happen when it gets implemented.
... Been talking with jchester and others to understand the main,bottom line concern is that a 3P has a collection of your browsing activities that can be subpoenaed by gov't, subject to breaches, etc.
... I don't see either proposal changing that.
... We all understand for legitimate uses like security/fraud, that risk is there.
... Given that we all agree that this is a primary risk that people are most concerned about and given that neither addresses it, the fact that we get so bogged down seems a little strange to me.
rvaneijk: Transparency and accountability are important.
... Trying to build good controls. The outcome of this group should be building blocks leading to compliance.
... Control: Control is tied to risk. Looking at legitimate business interests, This is the thing we need to focus on.
... Increased control needs to be looked at from a business perspective, and that's one approach. But also need to consider from user perspective.
... Control is the last piece of the puzzle that needs to be solved.
erikn: This is well-traveled ground. Let's be more efficient. Support small group proposal.
fielding: Let's stop discussing the overview and start discussing actual written proposals that nobody has addressed from the mailing list.
<susanisrael> +1 to roy's discussion
<dwainberg> +1
<Chapell> +1 to roy
jmayer: Like the idea of small groups. Need to focus on specific permitted uses and how to balance business needs against privacy.
Brooks: Danger in Aleecia's comment that this is limited to small OBA companies. I think we're underappreciating the issues here.
... OBA is the least of my worries. If you take Internet advertising, there's much more value in reporting than in targeting.
... What we're talking about here is undermining the ability of advertiser to demonstrate the value of advertising.
<Joanne> we should Aleecia's combined proposal doc for the small group discussions
Brooks: We're talking about fundamentally undermining the whole ability for any advertiserto understand how effective it was to buy one property over another.
<npdoty> maybe this is a good guiding goal: maintain (or improve) reporting, and put limits on collection
Brooks: Google is successful in AdWords because it works perfectly. I know if I spent $1.25 on a click and made $1.26.
... The more we undermine that the less valuable it will be.
<npdoty> Joanne, +1, we can add the permitted uses we work out on to Aleecia's combo draft
aleecia: We've talked about outsourced parties as a way to get that to work.
... That helps with reporting, analysis, etc.
Brooks: I've been doing this for a long time. Publishers and advertisers don't trust each other, and we need an independent way of counting and reporting.
aleecia: That's exactly what the proposals do.
... 7 more minutes of discussion.
cSpiezle: Business discussion is the core of the issue.
... Last night I looked at IE. It's taken 14 months for it to get to current market share.
<tlr> I think Brooks' point is really important -- do not design assuming advertisers and publishers are natural allies in the business environment.
cSpiezle: We're inflating the impact. But on the other hand, we've seen other sea changes forced due to security/privacy.
<tlr> (in the sense of, being able to trust each other with invoicing or reporting)
cSpiezle: Pop-up blocker debate from years ago. Many people said they would go out of business and some did. But most people evolved and innovated.
... Same with privacy beacons in emails. And then clients addressed it.
<npdoty> others want to join small group with jmayer and Brooks on reporting?
<tl> +1
cSpiezle: Need to step back and look at real business issues here. Smart businesses will innovate and evolve. Need to move forward.
Marc: Notion that this will impact only a small number of OBA companies is wrong.
... Not helpful to this discussion. There's a huge impact on advertisers and publishers.
... Looking forward to having an opportunity to present those facts in a productive discussion.
... But if the decision is we'll throw some companies on the bus, some of us can go and the conversation will conitnue.
<npdoty> erikn, WileyS, want to work on retention/collection elaboration, based on the industry proposal, in a small group?
Marc: I also don't think this does so much for privacy. You'll have more data collection, that's more invasive, and that will involve PII.
... What will change is who is colelcting.
... We'll see consent wars and pop-up wars, and people need to consider that.
... I hope we can have that discussion in a thoughtful and productive way.
aleecia: Marc, I agree with you that there's far more going on than OBA.
<npdoty> I think we're all agreed that we'd prefer a Do Not Track outcome to the alternatives that Marc is referring to.
aleecia: Let's split into 5 groups. All groups will need a scribe and observers will have to just observe.
... I'd like groups to look at text and copy and paste where possible.
<jmayer> I'm unsure where this line of concern from. I didn't hear Aleecia argue that small-company OBA would be the only impact, just one significant impact.
aleecia: responsibilities of 1P, 3P, and outsourced parties. That's where we're having biggest disagreements.
... Some of the things we've talked about:
... no data collection at all
... aggregating at time of collection
... unidentifiable after collection
... siloing to specific party
... retention limits
... use limitations: security, billing/$, freq capping, debugging
... transparency
... Anything else missing from this list?
... Not suggesting that we should use these things in specific places, but they seem to be what we've discussed.
<npdoty> internal/operational limits?
susanisrael: Why are use limitations on the tools list?
aleecia: I really mean approaches.
schunter: Fraud prevention. If you collect for that purpose, you must not use it later.
susanisrael: Discussion yesterday about the idea of research. Is this meant to be restrictive and that internal product/improvement research wouldn't be legitimate?
aleecia: This was meant to follow Shane's proposal.
<fielding> I don't see any reason to continue with either proposal
ifette: Logistical question: Should we do an email to the mailing list for small group scribing?
<npdoty> we could have breakout groups working from Combo-draft, the CDT proposal, the industry proposal, the existing WD,
aleecia: Yes.
<npdoty> maybe also a breakout group trying to merge/diff the proposals presented by Shane and Jonathan
jmayer: Within the bucket of things that might be aggregated at point of collection: Some companies have a cookie that doesn't tell you anything, but then there's real information that is unlinkable (like an opt-out value).
<npdoty> +1 on internal controls (legal or technical)
jmayer: There's also been discussion of business/legal controls. Also internal technical controls. Example: if you're going to have protocol logs for 6 months for security, those would be encrypted and have access controls.
<npdoty> I've checked in our updates from yesterday's drafting session to the "combo-draft.html" that we can work from
<npdoty> http://www.w3.org/mid/E1ShkOO-00027j-Hg@lionel-hutz.w3.org
aleecia: I had intended to capture something like en_US. But I'm adding to this list internal business/legal and technical controls. Also adding auditing.
... Anything else that people might want to discuss?
sean: Disallowing specific technological means for collecting information
schunter: One example would be jmayer's distinction between active and passive collection.
... Could say that in some cases only allow passive collection.
fielding: Another example would be client-side cookies that are uniquely identified but never returned to server. Unique hashes.
tl: Normally a cookie is provided by one domain with a distinct identifier for one domain.
... A double-keyed cookie means the identifier is determined not just by who they are, but who they are + where they are.
... advertising.com gets a different ID on each 1P site.
... unique identifier for 1P+3P combination.
schunter: Way to implement siloing for cookies?
fielding: Yes.
... Other approach is server-side agreement to hash cookie that is cross-fed and not stored.
aleecia: Questions?
Alex: I understand the mechanism but don't understand how it works in double-iframe scenario.
fielding: Just one solution; won't work everywhere.
Alex: That may break down because of existing tech implementations.
tl: You're saying that some things you're currently able to do?
<tedleung> q
<tlr> ted, did you want to queue?
Alex: I'm trying to say that if I want to implement this, the intention of the proposal is that cookies be siloed based on 1P. Because of double-iframe problem, the first domain that I get is one iframe up, which may be same for mult domains. So I get the same hash.
<tedleung> thx tlr - a fat finger on my part
<tlr> ah, ok :)
fielding: On browser side, can always obtain top-level domain of current page.
... 3P would set cookie, but browser controls what to send back.
tl: Might have 100 advertising.com cookies. One cookie per 1P.
Alex: Implementation is browser-specific?
<npdoty> updated combo-draft is here: http://www.w3.org/2011/tracking-protection/drafts/combo-draft.html
tl: Let's take this offline.
rigo: We've done a lot of research on server-side data minimization. So many solutions. The question is how far can we go without overburdening the industry.
... One of my major problems is we okay frequency capping and you store the cookie ID w/ URI, then you can still see what I read.
... I don't mind you knowing I was on NYTimes.com but do mind you knowing what I read there.
... We should discuss this in a breakout.
aleecia: Any additional new approaches to add to this list?
... The goal here is to have approaches that people can match these and switch them around for various cases.
... What are responsibilities for various parties using these approaches?
... Let's not go into defaults and UAs now.
... Focus on the core of what we're doing and where there are disagreements.
... Also consider impact on privacy, implementation ease (for large and small 1Ps and 3Ps), likely to satisfy regulators.
... Important to understand impact on business.
... We should be able to estimate difficulty of implementation.
... As you split into groups, be sure you're not standing with people you normally work with.
... Observers, please spread yourselves out and observe.
susanisrael: Would it be better to summarize rather than scribe so that scribe can participate?
aleecia: If you have an observer, use the observer as a scribe.
... At the end, we'll come back in large group.
<aleecia> Approaches we just discussed:
<aleecia> No data collection
<aleecia> Aggregate at the time of collection (OPT-OUT)
<aleecia> Unidentifiable information after collection
<aleecia> Siloing of data to a specific party
<aleecia> Retention limits
<aleecia> Use limitations
<aleecia> Security
<aleecia> Billing / financial
<aleecia> Frequency capping
<aleecia> Debugging
<aleecia> Transparency
<aleecia> Internal legal / business controls
<aleecia> Internal technical controls
<aleecia> Auditing
<aleecia> Disallowing specific (hard-coded) technologies (e.g. LSOs)
<aleecia> Active v. passive collection
<aleecia> Double-keyed cookies on the browser side
<aleecia> Double-keyed cookies on the server side
<ifette> notes for center group: https://docs.google.com/document/d/1CHYowgPvQr-EDqflEsiD3cypi2XXcgiaGT5YpHJTTU4/edit
<ifette> https://docs.google.com/document/d/1CHYowgPvQr-EDqflEsiD3cypi2XXcgiaGT5YpHJTTU4/edit
<Chapell> I believe Aleecia said.... (paraphrasing) that the ultimate output of the TPG would be a bad day for third parties who conduct OBA because many would be out of business - but that is a good day for privacy. Do I have that correct?
<aleecia> No.
<Chapell> Ok - you may want to come into our group as that seems to be the conensus here
<aleecia> My concern is that it does little for privacy but harms business substantially
<aleecia> That is a bad outcome
<aleecia> And what DNT was designed *not* to be
<Chapell> I would encourage you to make that clear to the larger group - as that was the impression that many of us were left with
<aleecia> ...a year plus ago.
<aleecia> Thanks for that as feedback.
<Chapell> and while I'm not going to represent the views of others - but its not simply industry
<aleecia> Having privacy at the expense of business is the entire problem I hope DNT will avoid. That was the point, to me, of bothering to spend a year of my life on this.
<Chapell> so when i see the powerpoint from this morning coupled with that statement (as interpreted by many in the room) -- I'm sort of wondering if the end goal here is a productive discussion
<aleecia> We've been stuck. It's time to get unstuck. And yes, my frustration at my lack of ability to move things forward right now is coming through.
<aleecia> I am worried for business with this.
<aleecia> I don't want an adblock world.
<Chapell> This group is heading down a direction where large, first party companies are going to continue to collect data -- more data, more sensitive data --- and this will ultimately be at the expense of both privacy and innovation
<asoltani> Chapell: I don't necessarily agree with your conclusion as 'large first party' companies would still be under the same restrictions when operating in a 3rd party context.
<asoltani> However the net pro-privacy effect will be that consumers will have some ability to be informed about and control the typically non-visible 3rd party tracking that occurs as they browse the web
<Chapell> Asoltani: First parties will figure out ways to override DNT -- so we're into an opt-in world
<npdoty> scribenick: JC
<npdoty> some of the early notes from this group: https://docs.google.com/document/d/1CHYowgPvQr-EDqflEsiD3cypi2XXcgiaGT5YpHJTTU4/edit?pli=1
Meme: We decided that a flowchart was an effective way to present our work
... Ed helped us formalize our thoughts
Ed: Limit on targetting and collection with limited exceptions
Ian: There is likely going to be data collection to cover permitted uses
... the boxes show limits on collection
Meme: The boxes help us frame the issues
Ian: First box indicates what not to do
... The user's experience may be altered for security or fraud purposes
... unique identifier may be used
... retention period must be what is minimally necessary for the purpose (permitted use)
... use is limited for purpose for which the data was retained.
Aleecia: Can you indicate how limits are made?
Ian: Auditability of access to data
Justin: Tell me more about auditing
... explain why you are retaining data.
Meme: Will defer to those that know more
Ian: We retain what is necessary, cookie data etc., to satisfy an audit for a specific purpose
Shane: In financial transaction due to legal or contractual obligations retention may be needed
... for example to cover frequency capping commitment
... financial transactions must be recorded to cover legal obligations
... there are legal and contractual obligations that need to be audited
... some things are federally mandated and others contractual
Justin: So there are legal reasons to keep cookie and other data?
Shane: Yes
Brook: All ad data belongs t othe advertiser
... placing obligations due to the standard adds huge complexity
Jonathan: Contracts can inform what is needed and what can be accomplished
Meme: We all have contracts that we have to comply with
... we don't want to have contracts that create a loophole
... the reality is there are millions of contracts in place today that we cannot ignore
Nick: Trying to describe what is necessary for use can change over time
... trying to describe it is difficult
Ian: The ad network may be the processor, but not the owner
Matthais: Let's limit discussion to clarifying questions
Susan: I second Meme about contractual obligations
Meme: Contracts may reflect our work over time
In the hum test the Meme/Ian proposal was found acceptable
Simon: We focused on exceptions
<npdoty> that is, there didn't seem to be anyone who couldn't live with something in the Meme/Ian direction
<jmayer> My point earlier: There are two levels to the proposed exceptions discussion: 1) which uses are allowed and 2) which information practices are necessary for those uses? Contracts shouldn't dictate either, we should think primarily about substance.
Simon: we looked at Shane/Jonathan's drafts to see what we could use
<jmayer> I'm not sure if everyone followed what that hum was about. The proposal was a high-level framework for approaching problems, not any particular specifics.
<aleecia> Jonathan, what sort of language that meets MeMe's requirements do you think would work?
Simon: freq capping, impressions, clicks. Can advertiser keep this information.
... is there way to get this data without a cookie?
... we tabled that for later.
... Agreed that we need things for auding security and fraud.
<jmayer> aleecia, I think a phase-in period for old contracts would be reasonable. Going forward, I think the standard should determine what companies do and agree to, not the other way around.
Simon: Need to collect data before the fraud to determine if fraud occurred.
<aleecia> What would that look like?
Simon: looked at storing a unique cookie for debugging purposes.
... could not agree on whether it was possible to proactively place a cookie in anticipation of security or fraud.
Shane: What was the thought process for knowing what you don't know?
Simon: I pointed out the issue, but can't say we had an answer.
Jonathan: There is ambiguity, but companies need to state what they need for debugging.
... that can lead to alternative solutions. Low entropy cookies etc.
... Unlike security and fraud, forensics going back for debugging you can collect additional information.
... some companies already do remove cookies if the user opts out. They somehow debug witout cookies.
Aleecia: How to tailor debugging and fraud, did you cover other areas.
Simon: We did look at reporting, but focused on those two areas.
Jonathan: We tried to find middle ground on those two areas.
Ian: I don't agree that we can wait until we see a problem and then add a cookie.
<fielding> ditto
Aleecia: Is that just for security or other purposes?
Ian: Cookies are necessary for security purposes. I wouldn't want to get rid of them.
... I don't necessarily believe the same for debugging, but I don't have enough data to respond.
<npdoty> scribenick: jmayer
<JC> Jonathan: I feel Sean feels differently.
<rvaneijk> http://lists.w3.org/Archives/Public/public-tracking/2012Jun/0623.html
In our group, Sean (another Googler) suggested he could tentatively be OK with graduated response on debugging.
<JC> Shunter: We looked at Shane's proposal and looked at how to improve it to reach common ground.
<JC> ... The proposal should spell out a limited retention period.
schunter: focused on Shane's proposal, looked to improvements to reach common ground
<JC> ... Don't know if there should be a maximum retention period.
schunter: requirement of fixed retention policy, must be public
... might be different depending on business purpose
<JC> ... If possible one can specify different periods for different purposes.
<aleecia> scribenick: jmayer
schunter: discussed proportionality as a requirement
... discussed requirement of publishing which exceptions a company uses
... Rob pointed out the precautionary principle
... discussed fixed retention time, incentive to improve as they get better at minimization
... Rob's precautionary principle is like quality control: document where business is, state of the art, encourage getting better at retention
<npdoty> As I understand it, this is a good description of the precautionary principle http://en.wikipedia.org/wiki/Precautionary_principle
<rvaneijk> see also: http://europa.eu/legislation_summaries/consumers/consumer_safety/l32042_en.htm
<npdoty> though I'm not sure that directly captures what rob/schunter are discussing, since it means not taking an action (in this case collection/retention) without a scientific consensus
<aleecia> how (practical details) would you encourage companies to get better and better on retention?
schunter: study may be needed of how long data is retained and for what purposes
chesterj2: small groups were a good idea
... unclear what retention requirements are
... especially for different types of data and different uses
... will ask policymakers to report on what data is used and needed
erikn: i want to make the scribe work hard (jerk.)
<npdoty> interesting suggestion on FTC, Congressional Research Service, EU to work together on reports of what practices are necessary
erikn: side debate over value of aspirational statements in the recommendation that companies should get better
... agreement there's some value, but substance and transparency do more
<meme> +meme
rvaneijk: when thinking about risk, carefully reason about worst-case outcome
<npdoty> make sure there's an incentive to improve business practices
<aleecia> There's a concept of "progressive realization" in other areas
rvaneijk: make sure businesses are given incentives to improve
meme: the FTC will look at retention periods, if companies cannot justify them, it will enforce
<susanisrael> +1 meme
meme: as an attorney at a large company, I carefully watch what the FTC does, it matters
<rvaneijk> flowchart precautionairy principle: https://en.wikipedia.org/wiki/File:Precautionary_principle.png
efelten: FTC involvement depends on how the standard is drafted. Depends on what compliance means. Can't investigate just any question.
rigo: should include promises in the specification, they'll be binding in many jurisdictions
aleecia: the concept of "progressive realization" might be helpful, no backsliding
npdoty: some value in pointing to best practices in a specification, just because something is an industry practice doesn't mean it's good
<aleecia> sounds like a should not a must if it's useful
<aleecia> wouldn't want to scare people from trying things
<npdoty> the point I was after is that transparency alone shouldn't be sufficient (wouldn't be sufficient for enforcement, necessarily) of moving towards a best practice, and if you're transparently not in the practice, that could be a condition for non-compliance
WileyS: Yahoo experimented with industry-leading search retention. Broke lots of stuff. Spoke to a lot of internal stakeholders in advance. There can be times where privacy has to be walked back. But there are other market forcing functions that can make privacy better.
erikn: If there were a no-backsliding principle, should test internally before rolling out and updating policy.
<aleecia> (that's quite reasonable)
erikn: we could put progressive realization on paper without interfering with experimentation
<Chapell> No-backslide principle encourages companies to err on the side of a longer retention period
<npdoty> http://en.wikipedia.org/wiki/International_Covenant_on_Economic,_Social_and_Cultural_Rights#Principle_of_progressive_realisation
hum: can you live with (some), can you not live with (none)
<jmayer_> Again, unsure if it was clear what those hums were about.
hwest: Our group had a lot of discussion about phrasing.
... Lots of discussion about first parties sharing information.
<aleecia> :-)
<npdoty> "we at least feel that that's totally solid" :)
hwest: Came out where the spec is - no sharing what third parties can't collect themselves.
... Some agreement around certain permitted uses.
... E.g. product fulfillment like giving UPS shipping info.
<aleecia> Isn't product fulfillment outsource party?
<npdoty> product fulfillment -- do we have something in the spec about accomplishing the user's intended outcome?
hwest: Different sorts of sharing, e.g. social vs. data provider.
<aleecia> No, that's EU law :-)
hwest: Looked at FTC report text on commonly accepted uses.
<aleecia> But it might be a good thing to add, in terms of user's intended outcome. Devilishly hard to write, but possible.
hwest: Thought about market research, product improvement, debugging, some analytics, contextual decisionmaking (e.g. PETA ad not next to Oscar Mayer ad), transactions, security, fraud.
<npdoty> do we need to describe contextual processing in the spec? seems like that would be agreed that it was out of scope
hwest: On outsourcing, no combining data across first parties, but permitted uses OK as they relate to the outsourcing service.
aleecia: How were these terms defined?
hwest: Product improvement related to making something you do better. Not much precision on scope of each.
... Agreement that these were a good direction for permitted uses.
aleecia: Discussion was about adding to permitted uses.
hum of who's ok with this: some
who's not ok: few
justin_: ran late, no scribe (class act guys.)
... good discussion
... general agreement around outsourcing, though not about permitted uses
... talked about appending, general agreement that appending is in scope, appending services somewhat like outsourcing
hwest: didn't have agreement on this, somewhat like outsourcing
justin_: ok with ID cookies, tried to focus on permitted uses
<npdoty> allow cookies, but tie to proportionality, narrower list of uses
justin_: ad reporting seemed reasonable
<hwest> To be clear, we didn't have agreement on the very specific of all directions, but if they're an outsourced party acting as a first party, then they need to be acting on behalf of that first party
justin_: same for frequency capping
... but maybe not forever
...
... metrics ok, market improvement and product improvement not ok
... no clear agreement on line drawing, roughly if about ad performance, ok, otherwise not ok
... if information isn't for one of these narrow purposes, aggregate within two weeks
... alex proposed a different approach to aggregation
alex: problem with fixed aggregation period - might need to later re-run analysis
... instead of a fixed time period
... some alternatives
... 1) segregate data
... 2) standard-based limit + internal audits
<aleecia> JC for benevolent dictator!
<robsherman> +1 :)
alex: Leave it to companies to choose among the three approaches.
<aleecia> ?
<sorting out mic and phone quirks>
aleecia: good overview, hard to keep details straight
... no hum since not enough agreement in group
... some observations before lunch
... 1) there is a zone of compromise in the room
... hard part: getting there
... 2) almost all proposals followed structure of shane's proposal
... will focus on that after lunch
<npdoty> +1 on working from the industry proposal onto the current spec text
efelten: maybe start with current drafts
hwest: not in great shape
aleecia: shane's proposal isn't in standards language, jonathan is, may borrow from the latter
roy: there are terms that aren't well defined here
<justin_> Can we define collect instead of track?
aleecia: we can nail down some of the terms
<amyc> collect and share
brooks: let's define share too
aleecia: sure, we'll define anything we use
erikn: live editing with a large group is slow
... maybe small groups with more structure?
<susanisrael> susanisrael
aleecia: maybe, will think on this over lunch
... look for logical break points
<npdoty> just to be clear, we have had definitions of terms (like "share") in most of our drafts, if you have suggestions, please add them
erikn: example, the section on retention needs some focus
susanisrael: did some of this work in small groups, should try in large group
chesterj2: would be helpful to hear from IAB members after break about retention periods for specific uses
<npdoty> scribenick: npdoty
hwest: makes a lot of sense to bring the industry proposal into spec format
<jmayer> hwest: makes sense to try to bring shane's draft into consensus format
<jmayer> ... current compliance draft is out-of-date options, right?
hwest: text in the specs now are options no longer in use
<jmayer> justin_: the spec language is better, we should use it
<jmayer> tlr: start with substance of shane's text, but it isn't pretty - we should turn it into standards language over lunch
<aleecia> ?
jmayer: totally comfortable starting with Shane's format, a fine shape to it; wanted to get some clarity of the sense of the room
... some presentations follow the shapes of Shane's proposal, a lot of people who could live with that general direction and not a lot of people who couldn't
... the idea that there are some exceptions that give more latitude is common to all proposals
... not objecting because agreement on bucketing for security/fraud and other exceptions
... not sure how much is substance vs. structure of agreement
aleecia: necessarily we get a high-level gloss in these presentations
rigo: willing to work with Roy on the definitions, clean them up and present them back to the group
<scribe> scribenick: jmayer
rigo: yep, this was a focus on structure, need to get technical expertise on substance
... don't want to throw away current drafts
... lots of work went into them
... especially the TPE document
aleecia: started with places we agree, then places where we agree on substance and massage into spec, now finally places we disagree
<npdoty> fielding: small group on definitions works for me
fielding: my views of the compliance document turn on whether an outsourcing provider is a first party or gets an exception
<justin_> Ceiling voice --- put it in IRC
aleecia: i've been treating outsourcing as a separate type of party
roy: preference for putting outsourcing into parties
<rigo> goal is to have outsourcing into the party definition
aleecia: game of telephone this morning, some thought my view was bad for business = good for privacy, that's not at all what i said or meant
... want solutions that are good for business and good for privacy
... here to facilitate something that works for the group
<lunch break>
<bryan> Mc Cormick & Schmick's 700 Bellevue Way Northeast, Bellevue, WA (888) 226-6212
<npdoty> definers, when you come up with a definition, feel free to drop them in here so we can use it in editing :)
<npdoty> scribenick: efelten
aleecia: Folks took Shane's proposal, transposed it into spec.
... will do live editing on the resulting text
<rigo> nick, is there any way to get the latest version of the specification
<confusion about phone hookups>
hwest: How we did the reorganization: took Shane draft, reorg into standard spec
<aleecia> scribenick: efelten
hwest: moved non-normative text to an appendix
... put it in a Google doc, will go back into spec when done
<confusion about formats>
<aleecia> PDF to go to dlist
<aleecia> Defns went to another subgroup
hwest: Start at Sec 4, Compliance with an Expressed etc
... <reads first paragraph re outsourcing by 1P>
<aleecia> We have an issue around append
<npdoty> if we raised it yesterday, is it necessary to ask about it again?
dwainberg: How does a 1P know whether the 3P has an OOB consent?
<aleecia> We barely touched this yesterday
tl: If you don't know there is a consent, don't share data.
<jmayer> A first party and a third party can communicate to understand whether the third party has an exception.
<Definitions group rejoined the main group, don't want to miss this discussion.>
<jmayer> We've spent an awful lot of time on this very topic in the TPE discussions.
aleecia: We started discussing this issue yesterday.
<CraigSpi> can you clarify "outsourced releationship" contractural relationship with a first party, where as the data is used exclusively to support the first party
ChrisPedigoOPA: Don't like "collect" in second sentence, not sure what it means here
... 1P doesn't know how data was collected; could fix by using "share" here
robsherman: Basic concern is that DNT applies to a specific network interaction, so second sentence should apply to data from
... a specific network interaction.
... Suggest adding a clause limiting second sentence to data from a specific DNT:1 network interaction.
<npdoty> that sounds fine with me
aleecia: Roy, what do you think?
<npdoty> "share identifiable information about the user's transaction to any party...."
fielding: Agree that this should refer to data from a specific interaction.
STarting text went out to dlist.
<Ionel> aleecia - thanks
jmayer: Two suggestions. outsource -> outsourcing (grammar).
... Re robsherman's point on per-transaction data, per-transaction makes sense in some settings,
<aleecia> Jonathan could you please paste relevant text here that you think would help?
<npdoty> http://en.wikipedia.org/wiki/Noun_adjunct
jmayer: When a company receives data under DNT:1, will have some obligations later wrt that data.
hwest: Looks like a misunderstanding.
... robsherman was talking about when gathered, not when used.
<npdoty> do we have uncertainty about "about a user's network interaction"?
<justin> How about giving us a concrete *edit*!
jmayer: <Gives example, scribe missed it>
Meme trying to set up screen sharing via a competitive Adobe product.
<npdoty> jmayer: if a user with DNT on adds data to their own profile, and then the first party wants to sell that profile information, is that information covered by this?
<jmayer> Example: Website wants to sell account information to a third party, the user arrives with DNT: 1. Can the website sell the information?
<jmayer> Two relevant snippets from the EFF/Mozilla/Stanford proposal.
susanisrael: Talked about these issues in our small group
<jmayer> 1) "A first party must not share information with a third party that the third party is prohibited from receiving itself."
<jmayer> 2) "A third party must not receive, retain, use, or share any information related to communication with a user or user agent."
susanisrael: we have language on this, gist is that 1P may not share with 3P in way that bypasses 3P restrictions
... <language is read>
nickdoty: Does that require intent/knowledge by the 1P?
susanisrael: Might tweak to take out intent. Suggest stating the purpose of this.
nickdoty: Best to put that point in non-normative.
susanisrael: Agrees with Nick.
<npdoty> I'll try to come up with non-normative text to explain the intent.
aleecia: Susan and Paul to produce text for non-normative.
rigo: From definition space, concerned about service provider. Need safeguards in defn to make this work.
<susanisrael> can we come back and define service provider later?
kimon: Let's see what the Europeans have done with data processor / controller distinction.
... See if that works for us in defining service provider.
... <reads Euro defn>
... that's short and crisp
aleecia: robvaneijk: Rigo and I already drafted language for that. Let's re-introduce it.
... Let's move ahead--still on these second sentence.
hwest: <Reads text>
... "It's kind of a Franken-text now"
... needs fixup
<kimon> For service provider I suggest: 'processor' shall mean a natural or legal person [,public authority, agency or any other body] which processes data on behalf of the first party;
aleecia: Does anyone think they can do better?
tl: This is not a good way to produce readable and coherent text.
aleecia: Hear your frustration. How can we move forward.
<rvaneijk> for the minutes: if we are going to use EU language I prefer to go back to the text that is in the current public draft: http://www.w3.org/TR/tracking-compliance/#EUterms
<bryan> I suggest to change "operator of a first party" to simply "first party". "Operator" does not add anything here.
<BerinSzoka> I thought Aleecia handled that very graciously. She'd make a good therapist--or daytime talkshow host!
davidwainberg: Can we talk about our general goal?
<susanisrael> +1 thomas's idea
tlr: We're trying to get the general shape right. Editors will turn it into smooth, coherent text.
... Let's keep the discussion civil, please.
<hwest> I think that I can volunteer myself and Justin and Sean to go ahead and smooth out the franken-text
<hwest> So let's get it to a point of reasonable substance
<susanisrael> i am happy to help smooth out the text if useful
<amyc> +1 hwest
<hober> the "in which DNT:1 was sent to any party" doesn't seem to reflect the nature of HTTP...
<meme> url to see Heather's screen on your computer: my.adobe.acrobat.com/meme enter in as guest
kimon: Might need to have a precise version, plus non-normative text to help explain.
<aleecia> Brooks, are you still in the queue on purpose?
<susanisrael> Nick had suggested the same thing
<Brooks> yes
rigo: Simpler to say that 1P must not share info with any other party, except for service providers.
<fielding> Suggestion: A first-party MUST NOT share information received in a DNT: 1 request with any other party (*) unless the information shared is not linkable to a specific user, user agent, or device. (*) assumes that service parties are the same party.
<rigo> roy, that should be out of scope anyway
brooks: Don't know what it means to "share" information.
<rigo> and I also said "MUST NOT share personally identifiable information"
We have to write some text first.
<susanisrael> propose "pass along instead of share"
<hober> I think "A first party must not share identifiable information about a user's interaction in which DNT:1 was sent to any party it does not have a service provider relationship with." would make more sense as "A first party must not share with any party it does not have a service provider relationship identifiable information about a user's interaction in which DNT:1 was sent."
<tlr> hober's version sounds about right to me
jmayer: Definition here builds in dependence on mental state of 1P?
<tlr> (modulo share / pass along / ...)
jmayer: should be more explicit about that
aleecia: Rigo's edit was trying to deal with that issue.
Vinay: What kind of information are we talking about? PII?
<rvaneijk> "The Service Provider does determine the purposes, conditions and means of the data processing, but processes data on behalf of the First party."
<amyc> what about "share information that the first party has collected", which may help to clarify that there is active role in passing on info
<jmayer> If I understand correctly, Rigo and Aleecia are suggesting a punt on mental state (e.g. purpose, knowledge, recklessness, negligence, strict liability). I'm opposed to selecting language where we know it includes ambiguity.
Rigo: Service provider is needed here to limit the role that a 3P data recipient can play.
aleecia: Not worried about having some redundancy here.
robsherman: First sentence should also deal with network-interaction issue that I raised before.
<BerinSzoka> Heather: could we unhighligt that text? it would make it a lot easier to read
ifette: Talked earlier about exceptions for fulfillment. What about electronic fulfillment?
<npdoty> vinay, not sure we have an entry in a Definitions section yet, but the language we seem to be using in drafts is "non-identifiable === with high probability could not be used to identify a user, user agent or device"
ifette: e.g. online email service, type message and hit send, mail provider sends message for you.
Rigo: Should be covered by general exception for doing the stuff that the user asked you to do.
<robsherman> +1 to Rigo's suggestion.
<tlr> +1 too
<fielding> Suggestion 2: A first-party MUST NOT share (transmit or provide access to) information received in a DNT:1 request with any other party (*) unless the information is unlinka ble or the shared purpose is specifically limited to security or fraud control. (*) assumes that service providers are the same party.
<meme> would it be more effective for us to try to get agreement on issues rather than trying to draft langauge?
<vinay> Nick - that's fine. I was just suggesting that we specify the kind of information we're talking about here. I'm not arguing against 'identifiable information'.
aleecia: Calm down.
<susanisrael> I thought it was worth trying to edit as a large group but maybe we SHOULD split up to do it. I might have been wrong. Maybe identifying language that needs to be fixed/issues is best use of large group.
ChrisPedigoOPA: Need a tight definition of share/disclose/whatever.
... shouldn't require 1P to know what a 3P is collecting.
<sean> what are the rules around horrific conduct during a w3c meeting?
<sean> is anythign allowed?
dwainberg: ok with the goal of preventing circumvention of 3P limitations.
... worry that this is doing more than that.
tl: What do you think it will do that it shouldn't?
rigo: reiterates service provider exception
dwainberg: Not sure what side effects there might be.
aleecia: Stop.
<fielding> I provided two specific text suggestions before the queue closed.
<amyc> +1 justin
Back and forth between justin and rigo about what this means.
<hwest> +1 Justin - responsibility is on the third party
<hwest> At least that was my understanding
<robsherman> +1 hwest/justin
aleecia: Have worked on two sentences, for an hour.
... let's take a break. Editors send text to mailing list. Break into groups and wrestle with text.
tlr: Let's look at text, get issues and suggestions on the table, then move on.
aleecia: Half-hour break now. Editors transform this into form we can work on.
<hwest> Todo for the first party compliance first sentence:
aleecia: will break into groups.
<hwest> reference to "service provider" definition (kimon --- adopt processor language?)
<hwest> Exact wording of share/send/collect will depend on definitions. Need to check that it all works together.
<hwest> susanisrael coming up with text proposal on the first party intent and passing third parties information [potentially done]
JC: Issue with the men's restroom. <TMI> Need to take elevator to the second floor.
... metaphor for something?
<npdoty> scribenick: npdoty
aleecia: new breakout groups
... twenty minutes to come up with bullet points on each of the 5 permitted uses
... need to avoid looping on issues
... editors will create a complete single strawman draft based on these
... goal is a good strawman draft close enough to not debate eternally
... choose your favorite
efelten: can assume an unlinkable data exception? -- yes.
aleecia: call to order.
<scribe> scribenick: rigo
Aleecia: Looking for bullet points from the groups, go through quickly
... end summary no later than 4:15
<npdoty> Security
hwest: reading out concrete text they found -> please paste below
<hwest> Strawman text: Data MAY be collected, maintained and used for the express purpose of 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.
npdoty: what is reasonable?
hwest: talked about that a bit: no explicit consent. Some wiggle room for companies, rather good faith, due diligence
<npdoty> (my summary) companies to decide on their own, but with a good faith concept
jmayer: greater point of disagreement, is it reasonable for an ad network to put a uniqueID into every browser for security?
hwest: yes, speaking for Google
<hwest> Clarification: potentially yes
<npdoty> hwest, was that "reasonable measures" or "reasonably necessary" and does that make a difference?
<hwest> Our text was 'reasonably necessary' but I think either could work.
Brooks: data that is need to enable each event of sale, and the points that could be affected by DNT:1
... > reading whiteboard - > scribe makes a photo
npdoty: are these criteria that should be dropped or will be impacted?
Brooks: are impacted, there is no tremendous disagreement, just have to write it up
tlr: geolocation can mean anything, what is this?
<npdoty> ACTION: rigo to send Nick photos from whiteboard to include in minutes [recorded in http://www.w3.org/2012/06/21-dnt-irc]
<trackbot> Created ACTION-215 - Send Nick photos from whiteboard to include in minutes [on Rigo Wenning - due 2012-06-28].
Brooks: this is a cross over
aleecia: there is text already, we have already created an issue
<npdoty> ACTION: brooks to draft tentative agreement on financial reporting breakout discussion [recorded in http://www.w3.org/2012/06/21-dnt-irc]
<trackbot> Created ACTION-216 - Draft tentative agreement on financial reporting breakout discussion [on Brooks Dobbs - due 2012-06-28].
Brooks: if all affected we have trouble in reporting
hwest: we touched on that in Security
<npdoty> "so long as you're not storing the URL trail"
Alan: you can do so if you don't store URIs
... core concern, fair amount of discussion
fielding: application tracking, would allow that to do, if ID is only retained in a hashed way per campaign and there is no trail where that ad was seen together with the site information
jmayer: could you please clarify the present technical approach
fielding: for server-side frequence capping would use a campaign identifier and the counter for that ad, but not the trail of URIs that have been seen
EricWheeler: sequencing?
fielding: this would not be allowed under DNT:1
Sean: no limit on campaign, that does not mean you do not get aggregate information on the campaign,
AM: EricWheeler, you said that first parties would be able to do this, and not third parties?
EricWheeler: yes
WileyS: this would be covered under financial. Frequency capping is very special
... showing ads in sequence is a form of OBA, for a first party would be able to do that on that first party but be obliged to silo the data
<npdoty> s/??/EricWheeler/
<hwest> A note - we need to make sure that the contextual delivery is well allowed
<hwest> It's not clear in the text thus far, I think
fielding: contextual based advertisement would be allowed is not tracking
<justin> It's in the spec :)
WileyS: report is already in the email list
... not a replacement for QA, to address real time issue, short retention. Due to unknowns, we are all unclear about the "what to collect" as we try to do minimization.
... selective progression was discussed: if issue becomes bigger, you only increase retention time for this issue
... looked at proportional measures. Guiding principle: If you don't need it, don't collect it.
<npdoty> it sounds like "selective progression" would be a promising direction for much of our work
WileyS: don't believe in distinction between ad, analytics or content, debugging counts for all of them
<npdoty> http://www.w3.org/mid/CC08F807.40499%25jfurtsch@truste.com
<rvaneijk> debugging bullets:
<rvaneijk> Not QA
<rvaneijk> Typically retained for a shorter timeframe intended to address realtime issues
<rvaneijk> Due to the nature of the issue, more variables are needed
<rvaneijk> Reactive/unforeseen (issue usually raised through a user, site, advertiser, scanner, report)
<rvaneijk> Selective progression (retention variable)
<rvaneijk> No substitute
<rvaneijk> Protocol is not enough - need more (I.e. Cookie) guiding principle - if you don't need , don't collect
npdoty: selective progression idea, what about default values?
<rvaneijk> Needed by all third parties (ad, analytics, content providers)
WileyS: we didn't, resisted to put arbitrary periods, started from 30/90 day period, but up to every company to argue that
... for all retention there should be transparency and declared that somewhere publicly. They should give more information on why this data use occurs
robsherman: balanced privacy against business needs in aggregation
... started with CDT for a fixed period of 2 weeks. Feeling that we do not have enough information for what a time limit could look like
... if it is retained for other uses, it would be moved into unlinkable state after that period
... was discussion about bias in favor of ad companies
<npdoty> we should be clear, this was an expressed concern (expansion of purpose) within the group as well, this was just a proposal
Aleecia: You can keep raw data for aggregating. But if you keep it for other uses (financial), you can still aggregate from that data
ifette: I have n copies of data per use, or one copy of data and n uses
<npdoty> rigo: concern about purpose creep
ifette: if data already exist for other purposes, we can aggregate
<npdoty> rvaneijk: undermines the basic concept of siloing, for security purposes, for example
<justin> It will be hard to justify security data for seven years.
<npdoty> meme: if aggregate reporting is permitted and storing the data for security purposes is allowed, what's the problem?
<fielding> potential text on frequency capping: Third-party tracking for the sake of server-side frequency capping 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 activity trail (page URIs on which the ads were delivered) aside from what is allowed for other permitted uses.
<npdoty> rvaneijk: but the data is stored for a specific purpose
discussion about re-use of security data to create aggregate data for any purpose
Aleecia: what about siloing, security data, and ACL. So companies say they have one set of data, but different ACL. Push back mainly because silos are breaking. Idea of dual use of data is a cultural issue in Europe
tlr: discussion about collection, duration of collection and duration of retention. Surprise that some people thought there is a purpose limitation
ifette: limitation of time on aggregation is 30 days or the time period of other uses
<justin> 30ish days
ifette: aggregation from security data would itself be unlinkable
Aleecia: wouldn't this pressure companies into keep that data for other purposes
npdoty: companies would have advantages over other companies as they could collect data of security
robsherman: don't believe in the pressure argument, will have conformance pressure from regulators that is stronger
<npdoty> WileyS: market research is an explicit case of third-parties that do aggregate reporting, we should consider those businesses
robsherman: purpose of aggregate is not identifying. The aggregate result won't identify an individual
hwest: misperception: is not about individual profile about a person, but only aggregate result
alex: brought up segregation of data bases
<npdoty> alex: is there agreement or disagreement about segregation of data?
<wheeler> however, 1st party sites like http://health.yahoo.net will be able to target across their network - so that issue doesn't go away
aleecia: we don't keep separate databases, privacy advocates said ok, unless there is scope creep. Aggregation is a feeling of scope creep
<hwest> I think we need to reframe this from "use the security data for X" to "use the data collected for the permitted use of A, B, C, and security"
<hwest> With appropriate technical controls and mechanisms
aleecia: want to understand who can not live with the aggregation out of security data for the lifetime of the security data?
fielding: part of aggregate is that you know what you have
rvaneijk: one of the deep packet inspection is that you can do that on life traffic and put things in buckets
cultural split: mostly european hands up (around 6)
jmayer: this is related to the scope creep, no need to remove data, suddenly more collection and more retention
<npdoty> jmayer: a problem of perverse incentives, you will have much less of a reason to collect less data for security as it's an input to market research
aleecia: business saying, we have data, why shouldn't we use it for aggregation?
<jmayer> My argument: allowing aggregate analysis creates perverse incentives for additional collection and retention. We have enough problems as is checking for "reasonable" collection and retention.
<jmayer> Another problem: concerned there's a slippery slope to weaker protections on this data once more ordinary business purposes are allowed.
Sean: not saying toys are there, let's play.. For purposes of aggregation that is unlinkable
<justin> Rigo, they haven't promised anything yet. I imagine Google's privacy policy would say "We keep data for security for 1 years and finacial reporting for 4 years. For data we keep for these two purposes, we also reserve the right to use this data for aggregate reporting purposes."
<jmayer> I disagree that unlinkable data is out of scope. I don't believe we've agreed to that.
<jmayer> And, at any rate, the process of making data unlinkable is plainly within scope.
aleecia: who can't live with the fact that we cannot use security for aggregation?
-> clarifications
<jmayer> To be clear, this discussion of seven-year retention of all sorts of data is a thought experiment. We assuredly do not have consensus that it's allowed.
<hwest> Are we really saying that you cannot take identifiable data and making it unidentifiable? That just doesn't make sense to me.
<justin> jmayer, yes, we have not agreed that the data is going to be lying around for seven years always for financial reporting . . .
<jmayer> justin, "always" -> "ever"
<justin> jmayer, I would be happy to get there.
<WileyS> jmayer - agree the process of unlinkability is within scope but once there it is out of scope. Thought we had agreement on that perspective (dependant on the definition of course)
<jmayer> There's agreement that once data is unlinkable, the limits on it are almost entirely relaxed. That's not out of scope, of course. And there's still some disagreement on the definition of "unlinkable."
npdoty: should think about alternatives
... why I think there is trouble. some believe that we should not collect data others said you just have to be transparent about it and collect
... what we need to talk about is the alternative
<jmayer> hwest, Yes, really, for at least three reasons: 1) legal compliance, 2) perverse incentives, and 3) a slippery scope on siloing.
<susanisrael> would you really have communicated to the user that you are keeping the data only for security purposes
Aleecia: strong opposition against data re-use with purpose transgression
<jmayer> The group agrees: companies MUST NOT violate the FTC Act. Progress!
<Chapell> JM - ok, that was pretty funny (:
dwainberg: you keep your promises. but people erase their data by agregating them
ifette: aggregate data has separate promises. Minimum period of aggregation. Wanted to circumvent that problem of maximum period for aggregation
<npdoty> ifette: we could instead have the debate over how long you can keep data for aggregate reporting/market research purposes, not sure we want to have that separate debate which might be just as tricky
meme: if we want to come out on which devices were there 7 years ago.
... too much angst on what we try to aggregate
bryan: if access to security team, only those
adrianba: agree with ifette, am I right that people will keep raw data for some period of time, should there be a specified period of time
... if we have to keep for some period of time. Why not keep that data for that aggregation
ifette: you get x years for these uses and y for aggregate
<npdoty> adrianba: just collect data for a different period of time for aggregate reporting, and debate and justify that amount of time the same way that we do for all other permitted uses
if we collect data for a certain period for a defined purpose, at the end you aggregate. You can use that aggregate data.
<ifette> Frank, I'm not sure I understand what you're saying. I think what I just heard is that you can keep security data for 7 years. At the end of 7 years, I can dump it, or only keep it in an unlinkable form. That sounds like "At the end of 7 years you're allowed to aggregate the data." But I couldn't aggregate it at year 6?
Aleecia: consensus of the group: It is ok to have one copy of the data
<npdoty> I am hearing that it is okay to have one copy of the data, not multiple copies for different permitted uses
<npdoty> can have access controls for siloing data
Aleecia: it is ok ot have controls on that like Access control
... it is not ok to have 4 permitted uses and use the data for aggregation for the longest retention time
<npdoty> it is not okay to have aggregate reporting automatically/iimplicitly being the maximum of data timeframes for other permitted uses
<justin> Rigo, if the privacy policy says "We keep data for security for 1 years and finacial reporting for 4 years. For data we keep for these two purposes, we also reserve the right to use this data for aggregate reporting purposes." does that address your concerns?
justin: In fact you say: We keep data for 4 years and make analysis
<justin> rigo, Fine, but that would be OK with you?
<fielding> I clarified that the restrictions only apply to those records marked as DNT:1, meaning that aggregate reports can be created if they are only sourcing the non-DNT records.
Aleecia: time period discussion for aggregation
... take the approaches of the groups and integrate into the document and then have a discussion on the wording
no new items except for really new facts
<jmayer> Is the consensus accurately captured?
<jmayer> Want to make sure this is down: we agree that siloing will not require more than one copy of data. ACLs can be sufficient.
ifette: once the time is up (one copy) you cannot keep that data in linkable form. After that time period must be unlinkable and we need to define that unlinkability
tlr: erase identifier from data base?
ifette: or other measures
jmayer: notion to get rid of data may be different from making unlinkable because of the incentives that it creates
aleecia: what would mean 'get rid off" for you?
jmayer: do not have a copy of that anymore
<jmayer> Proposal: be reasonably certain you don't have a copy of the data.
WileyS: aggregation is one way to get there?
<jmayer> What Ian and Shane propose bleeds disposal into unlinkability and re-use--which the group clearly doesn't have agreement on.
tlr: trying to understand whether there is a difference between postion.
... throw away all identifiers, could jmayer agree there? Or even throughing even the unidentifiable data away?
<ifette> Proposal: "Once the time period for retention for all permitted uses has passed, you may only retain a subset of the data, or a transformation of the data, that meets the group's definition of 'unlinkable data'.
<ifette> I.e. as part of dumping my security data, I can create an aggregate "last 7 years of security data" but not a "here's the growth of tablets over the last 7 years" report
<npdoty> 'That unlinkable data must only be used for the permitted use for which it was retained.'
<ifette> and by last 7 years of security data I mean "last 7 years of security threats etc"
<dwainberg> ... Unless you had previously disclosed that you would be aggregating for other uses at 7 years. Right?
<vinay> Question -- what if the stated retention period for aggregate reporting is for 7 years?
Aleecia: Victory!
<jmayer> My understanding: We haven't agreed what you can collect. We haven't agreed how long you can retain it. We haven't agreed how you can use it. But if there's something you're allowed to collect/retain/use for some particular purpose, at the end of the allowed retention period, you can make an unlinkable dataset for the particular purpose.
<rvaneijk> we havn't agreed that aggregate reporting is an excepted use
<npdoty> aleecia: feeling much better after today than yesterday
<npdoty> ... thank you for staying engaged, this is a lot of work
<justin> rvaneijk, agreed. I was arguing for treating it as a quasi-excepted use, but I hear that that has not been approved by the group.
Resolution: Aggregation can be done for the purpose within the period of retention for that purpose
<rvaneijk> rigo: NO, need discussion on that
