See also: IRC log
aleecia: comments on minutes? no
<aleecia_> https://www.w3.org/2011/tracking-protection/track/actions/overdue?sort=owner
aleecia: minutes are approved
<clp> Charles L. Perkins, VIrtual Rendezvous, arriving.
justin: text says a public committment is needed on honoring DNT, and various ways to comply with that.
<aleecia_> https://www.w3.org/2011/tracking-protection/track/actions/186/edit
aleecia: to update the action a month out
<clp> Aleecia -- I have been away in RL moving the past 5 weeks, so have not yet assembled the Examples for you I promised about 6 weeks ago. But I have not forgotten.
aleecia: shane, will this be better as two proposals or breaking out? (Shane's not on yet, to come back)
<rvaneijk> pde is in irc
<WileyS> Shane is on now...
<justin> Ok, I've pushed the due date off for two months --- will provide text once it's clear what the well-known URI and response header look like.
wileys: we are close, expert review/validation is the mire point. but generally in the same area. waiting on peter to come back.
aleecia: give it another week, then hand off if needed
<ifette> ACTION-192?
<trackbot> ACTION-192 -- Shane Wiley to write up proposal for allowed uses for protocol data in the first N weeks for ISSUE-142 -- due 2012-05-05 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/192
wileys: this is not assigned to me
<ifette> how did htat get assigned to shane
<johnsimpson> I think Ian wrote that
<ifette> i thought that was mine
wileys: there was a proposal and a discussion of the # of weeks
<jmayer> Shane focused on "Why six weeks?", not "everyone."
<ifette> tracker lost the context
<ifette> i could have sworn there were many emails on that
aleecia: this is on the agenda. will move it to Ian and pending review
wileys: draft has been with ninja for two weeks
<WileyS> Jonathan, I wasn't specifically focused on "Six Weeks" - please check the email chain again.
<npdoty> we created an ACTION on protocol logging proposals for Ian, Shane and Tom
<WileyS> In fact, I've made no comment on that chain.
<npdoty> maybe we had assumed that three people wanted to write different proposals?
<ifette> I think ACTION-192 is a duplicate of ACTION-190 that I already did, unless the objective was to get an alternate proposal
aleecia: 9 open/overdue for Tom, we will find ways to avoid that - other volunteers? if not we will consider closing
<clp> Can you describe the amount of work for each item?
<clp> I can do about 5 hours of work for you Aleecia each week and take some of the items no one wants.
<npdoty> action-180?
<trackbot> ACTION-180 -- Thomas Lowenthal to provide a text update to section 4.3 to resolve issue 116 and ISSUE-84 -- due 2012-05-05 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/180
aleecia: on the TPE spec. guessing Tom is the correct owner
tom: this is one of the least important ones - appreciate if someone could take it
aleecia: avoiding JS DOM property to receive mixed signals
tom: we should not have a property unless we can resolve this issue
aleecia: could nick help
<npdoty> yes
<fielding> by inline javascript, it means javascript loaded within an iframe?
<npdoty> fielding, I think we're talking about external script tags embedded in a page
<tl> fielding, Or just with a script src.
<fielding> so, not "inline"
<sidstamm> fielding, yes... third party referenced scripts, not inline.
<tl> fielding, Maybe I misunderstand "inline".
aleecia: ok handoff the action and no later than COB today please
tom: kevin should be able to handle that
aleecia: send a note to kevin that he is assigned
aleecia: this is pending review - if more please do quickly
<npdoty> no! we haven't
tom: this sounds done
<clp> Always good news.
<johnsimpson> which action, pls?
<npdoty> action-177?
<trackbot> ACTION-177 -- Thomas Lowenthal to add an API to let a site request a web-wide exception -- due 2012-05-05 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/177
tom: take that back - it requires copy paste of all instances of zero with one
... it was originally requested by ??? - if they could address that please
<tl> by Abine.
nick: 177 is about web-wide exceptions.
<Zakim> npdoty, you wanted to clarify which action we're talking about
<Zakim> ifette, you wanted to discuss ACTION-192, ACTION-190, ACTION-193, ACTION-194
ifette: 192 is a duplicate of 190
<npdoty> I think it was intended to get different versions originally
aleecia: sounds great
<WileyS> I didn't want different text - I believe the entire exercise is a waste as its directly tied to the pure "unlinkable" proposal and doesn't take "permitted uses" into account.
<aleecia_> ACTION-180 open Provide a text update to section 4.3 to resolve issue 116 and ISSUE-84
<npdoty> action-177?
<trackbot> ACTION-177 -- Thomas Lowenthal to add an API to let a site request a web-wide exception -- due 2012-05-05 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/177
tom: this is unstarted
nick: 180 is handed off to me
tom: is 177 not subsumed by the current API proposal?
nick: no
tom: anyone want to make that change?
<schunter> nick?
<ifette> i don't think we can just let it drop
tom: happy to let it drop
ifette: I think the group had consensus that this was something we wanted to support
<WileyS> I can update the API text
<aleecia_> thank you, Shane
<WileyS> Please give me an action to do this
<tl> I'll hand it off.
<WileyS> Its the same API but a flip of passed arguments
nick: the current API does not support the web-wide exceptions style and need proposed text
<npdoty> yes
aleecia: shane will take this one
schunter: we should just give this to an editor
<npdoty> I'm not sure it's quite as simple as we're assuming
fielding: don't know what to add
<WileyS> One week it'll have to be (I'm on vacation May 16th - 22nd)
<tl> I'm sure Shane will inform us if it sucks.
<WileyS> :-)
<npdoty> yes, both are tied to issue-84
tom: seems overlapping with the previous DOM API concern - the one handed off to nick
nick: this is a duplicate
aleecia: to close as dup with 180
<clp> (I have been away so much I have lost track of the ending dates for documents now, what are the goal dates for next steps?)
<jmayer> Proposal: move issue management off the weekly call.
<ifette> ACTION-167: duplicate of ACTION-180
<trackbot> ACTION-167 Come up with updated text for a DOM api to allow access to DNT state notes added
<ifette> ACTION-180?
<trackbot> ACTION-180 -- Nick Doty to provide a text update to section 4.3 to resolve issue 116 and ISSUE-84 -- due 2012-05-16 -- OPEN
<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/180
tom: we can drop it
aleecia: would someone else like to take it?
<WileyS> We have draft text - many comments on that draft text
<clp> I can volunteer to take something quick, if anyone needs to create a small action.
aleecia: anyone else? don't need a separate action item on this
<ifette> close ACTION-167
<trackbot> ACTION-167 Come up with updated text for a DOM api to allow access to DNT state closed
<jmayer> There are some issues that need group input, to be sure. But many require just a pairwise discussion.
<jmayer> For example, we don't all need to participate in sorting through Tom's delinquency.
<bryan_> (having trouble keeping up with all the #s - please summarize the AI plan)
<WileyS> Sure
aleecia: shane please take 177
<fielding> shane, I updated 177
aleecia: any discussion?
... ok propose to adopt as policy
jmayer: need to understand the objection
wileys: people will alter or hold back candidness on the phone if unknowns are there - this will bog down progress\
<npdoty> have people on the call been holding back?
jmayer: dont understand
<bryan_> WG meetings are not public
<sidstamm> if there's a concrete example where someone in this WG has been burned by a lurker, it would contribute to the discussion here...
jmayer: a member of the WG
johnsimpson: just did a whois - can't tell who half the people are even if associated with #s
<dsriedel> Is this just about phone numbers or also ppl of non-member organizations and/or individuals?
jchester: good to know who is on the call - dont mind listeners
<npdoty> are those concerned about lurkers still uncertain about the handles we're using for Zakim?
<bryan_> are you saying it should not be restricted to WG members?
<aleecia_> (Nick, can you jump in if scribing lags?)
ifette: similar concerns to presence of press at meetings
... a person may not be authorized or willing to speak if press is present - it impedes openess
... concern about a direct quote context, press or other agencies that they're not authorized to speak in front of
<bilcorry> Can I revert to just a phone number? What happens if we all do?
ifette: not talking about limiting who can join the call, just who is who
... have provisions for interested non-members who wish to observe
... not a notion of closing the room out of the public eye - but legit concerns about who we can speak in front of - we have procedures to follow
<WileyS> As you
simon_cablelabs: could we have a statement at the beginning of the call about who is not a member?
<WileyS> As you've pointed out, people can join late so a statement at the beginning of the call doesn't cover us.
jmayer: the problem seems to be specific categories of exclusion as a concern
<Zakim> ifette, you wanted to note that simon wouldn't have to "jump in and identify himself"
jmayer: can we get agreement that in general its OK to be on the call
<bryan_> -1 to jmayer's proposal
<jchester2> Sounds good to me, carve-outs ok
<WileyS> In the spirit of "openness" I have no issues with people being on the call but they should at least identify who they are.
<laurengelman> i am on the call
ifette: we should not have to go around the room - we should not slow down the call
aleecia: its important to be on IRC if possible
<clp_> clp_ is Charles L. Perkins, FYI
<jmayer> Shane, I think a compromise of "all welcome, but you must identify yourself" would be ok.
<npdoty> ifette, there are likely to always be a couple that can't join IRC and may need to announce themselves, but I agree we don't need to go around the room or anything like that
<WileyS> Jonathan, we're in agreement then!
aleecia: two separate but similarly motivated concerns - knowing who is on the call, and who is the call open to
<npdoty> WileyS and jmayer agree! :)
aleecia: we have not had agreement to close the call down to WG members
<tl> Consensus!
<johnsimpson> my point is that even if people are associated with their number in IRC, I still don't know many are...
<clp> .
wileys: it isn't that everyone isn't welcome, just that they have to be id'd
<jchester2> That sounds great. Identify yourself
clp: membership is designated by W3C
aleecia: different groups operate differently
<npdoty> clp, membership is a formal process, but feel free to follow up with me
<jmayer> I'd like to point out the irony of a privacy group requiring identity to participate. Someone's going to.
aleecia: speak with nick on that
<WileyS> Nick, how do I reassign an open action? I go to edit the action and it doesn't allow me to change this. https://www.w3.org/2011/tracking-protection/track/actions/177
<clp> Thanks nick
<WileyS> Jonathan - :-)
<clp> We talked about this at MIT the first few days.
<bryan_> please send a link to when the group reached consensus on opening to non-members - that is unusual
<tl> jmayer, I plan to connect my sockpuppet to IRC over tor with a humorous pseudonym, and associate that with a second phone number.
<clp> It was a discussion between formal meetings
<npdoty> WileyS, that action is currently assigned to you, I can help edit it if you need more changes
<WileyS> Nick, Thank you.
aleecia: that was an early discussion - may not be able to point to a decision point
... if no dissent, we will drop unID'd callers
... from the next call
<bilcorry> Nick is Sgt at Arms?
<clp> And "identifying yourself" is simplyy something like:
<clp> clp is Charles L. Perkins, Virtual Rendezvous ?
aleecia: ok, we will do that
<BrendanIAB> Name or Name plus Organization?
<tl> clp, no, more like "Zakim aaaa is clp."
aleecia: we do not invite the press to F2F or calls
<johnsimpson> i think we mean just associate you're IRC handle with your telephone number, right?
<jmayer> BrendanIAB, the concern was understanding who's represented. That would seem to necessitate organization, not just name.
aleecia: for meetings, the chairs have declined to invite press - do not need to go to the WG for that
<BrendanIAB> cool thanks.
<npdoty> BrendanIAB, I think name plus organization is great when people might not know you, though eventually the group knows people
ifette: one of the things that we saw was press articles were written from the F2F, and the risk of reporting out of context is a concern
<bryan_> agreed - the differences were way overblown in press reports
ifette: concern over someone reporting on something overheard on calls - they are not going to have the right context
<npdoty> ifette, do we think press are likely to be less contextually informed if they're not listening to calls and meetings?
<ifette> npdoty, yes
<justin> Actually, I think it was members of this group who were quoted in the press as framing the Washington meeting as a showdown . . . ;)
<aleecia_> :-)
jmayer: undoubtedly some crummy coverage -people looking for story - characters and conflict are part of modern media
... requiring text to interpret on their own is problematic - they would be in a better position if allowed to be in the room
... when engaged they tend to get things better. we need to be careful in weighing risk of public exposure and transparency
jchester: we should try to invite press
<jmayer> I'd prefer to be open to anonymous participants, but I'm comfortable with the caller policy.
jchester: we do want a dialog - this is part of a larger global debate
... they may otherwise misconstrue developments
<npdoty> are there alternative ways for the WG to help inform the press, if not inviting them to meetings?
wileys: strongly disagree, all interactions over the last decade - they rarely have the background to interpret, and respond at the surface level
<jmayer> The final part of my comment was: even if we think media coverage is worse, and even if we think there's a conversational chill (I disagree on both), we have to weigh that against the tremendous benefits of transparency.
wileys: responding over time will be unlikely, so developing history is unlikely
<jmayer> If the concern is accuracy, we can fix that - e.g., to join calls/meetings, you have to sit through a background briefing.
<JC> +1
wileys: a press day or event would be better
... seeing a small sliver of the group's work would be bad
<johnsimpson> we could schedule a news conference after the F2F
<npdoty> press day or press event suggestion is an interesting possibility
<bryan_> presence of press would be a serious impediment from my perspective
<jchester2> I think we should do press briefing before Seattle meeting begins
<jmayer> Let's recall that 1) there's already going to be press coverage, and 2) in the absence of being in the room, the press has to rely on scattered second-hand accounts and transcripts.
<johnsimpson> press is increasingly interested and we will be getting more and more coverage. it would help us to make everything as transparent as possible
clp: more openess on transcripts and putting results out for review would be an improvement
<clp_> I suggested a formal "press recording event" regularly and transcripts etc.
<WileyS> Jonathan, I agree in the interest and believe a more controlled outreach will meet their needs and our needs at the same time.
aleecia: are there ways that we can review the concerns around press
... suggest to take as a thread for the next week to brainstorm ways to make this work or not, and overhead of taking time to brief the press
<npdoty> "saying that someone should brief the press is lovely" but people are busy
<jmayer> Another option: no quoting from live meetings/calls.
<clp_> +1
aleecia: unless we have concrete results in the discussion we will continue the current policy
<JC> +1
<jmayer> sure
<WileyS> Not allowing them on calls or in live meetings meets the same outcome :-)
aleecia: jmayer can start the ball rolling?
<WileyS> aka - "no quoting"
<jmayer> Though I'm not comfortable with this framing: "no agreement = current policy."
<jmayer> WileyS, press in the room but no quoting = can still report on proposals, votes.
<WileyS> Jonathan, they can do the same through a more controlled press outreach engagement
<jmayer> WileyS, that won't allow them to as deeply understand or as faithfully report the group's work.
<WileyS> If we setup the press outreach event appropriately they will reach "deep understanding" - or at least as much as any reporter will ever reach in this type of discussion.
<jmayer> Shane, press conference != attendance. That's not up for debate.
<WileyS> Jonathan, I thought we were debating press attendance. Now I'm lost. I'm proposing a press outreach as a substitute for direct press participation. For me, press attendence is a non-starter.
<aleecia_> ISSUE-65, How does logged in and logged out state work
<ifette> ISSUE-65?
<trackbot> ISSUE-65 -- How does logged in and logged out state work -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/65
aleecia: we had two competing proposals expected from the DC meeting
<WileyS> Logged-in/logged-out = out-of-band consent (working on that draft language)
<JC> Disagree
justin: saw it different that there would not need to be separate rules per logged in/out state
aleecia: not my understanding
tl: concur with justin
aleecia: will go thru the minutes to verify that happened
<aleecia_> ISSUE-97, Re-direction, shortened URLs, click analytics
<ifette> ISSUE-97?
<trackbot> ISSUE-97 -- Re-direction, shortened URLs, click analytics -- what kind of tracking is this? -- open
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/97
aleecia: we are getting to the point of knowing what we are doing with URL shorteners
<justin> I'm willing to take it as an action item.
<jmayer> Have to drop off, my thoughts on out-of-band consent are on the list.
jc: login initiates a connection with a service - thus there should be a difference. any agreements made when logged in are deactivated when logged out
aleecia: looking for actions on this - will review the minutes to see
<npdoty> JC, do we need an action item for you to write that up? or is that an existing proposal?
<JC> There should be an existing proposal
<justin> Me
aleecia: looking for someone to take an action to draft text
<JC> i7
<JC> 97
<justin> I have drafted language on this issue before, but I'll recirculate.
<fielding> http://www.w3.org/2011/tracking-protection/track/issues/97
<aleecia_> ISSUE-99, How does DNT work with identity providers?
aleecia: please link to the language in the issue 97
<fielding> http://www.w3.org/2011/tracking-protection/track/issues/99
UNKNOWN_SPEAKER: no text yet. the idea is if you use oauth, what does that imply
<npdoty> aleecia: if you use OAuth, now what?
<WileyS> I'll take it
<ifette> i can draft text
is that not the same as logged in / out issue?
<WileyS> We had draft text initially
<hwest> I think this could be addressed int he logged in section
<jchester2> I agree it's important and would be happy to help
justin: this is an important issue, willing to work on this
<JC> I feel this is slightly different from logged in state
<WileyS> For authentication event, 1st party. All downstream activity is 3rd party. Okay?
<fielding> http://lists.w3.org/Archives/Public/public-tracking/2012Apr/0112.html
<ifette> sure
<WileyS> Sure
aleecia: shane take the lead and work with ian and justin
<npdoty> WileyS, that sounds promising
<JC> What if auth service stores profiel as well?
<aleecia_> Ian's text for ACTION-190 and ISSUE-142, Allowed uses of protocol data in first N weeks.
<aleecia_> Protocol data, meaning data that is transmitted by a user agent, such as a web browser, in the process of requesting content from a provider, explicitly including items such as IP addresses, cookies, and request URIs, MAY be stored for a period of 6 weeks in a form that might not otherwise satisfy the requirements of this specification. For instance, the data may not yet be reduced to the subset of information allowed to be retained for permitted uses (such as
<aleecia_> fraud detection), and technical controls limiting access to the data for permitted uses may not be in place on things like raw logs data sitting on servers waiting for processing and aggregation into a centralized logs storage service.
<aleecia_> Within this six week period, a data collector MUST NOT share data with other parties in a manner that would be prohibited outside of the six week period. Similarly, a data collector MUST NOT use the data to build any profile, or associate the data to any profile, of a user used for purposes other than would be allowed outside of the the six week period. As examples, a data collector MAY use the raw data within a six week period to debug their system, a data
<aleecia_> collector MAY use the raw data within the six week period to build a profile of a user fraudulently or maliciously accessing the system for purposes such as blocking access to the system by that user, but the data collector MUST NOT build a profile to serve targeted advertisements based on the user's past six weeks of browsing activity.
<aleecia_> After the six week period has passed, all other requirements of the DNT specification apply.
<ifette> http://lists.w3.org/Archives/Public/public-tracking/2012May/0109.html
aleecia: is this something we are ready to adopt
<tl> r-
aleecia: DC consensus was to have some timeline - not a major problem
wileys: dont understand re protocol data from a logging perspective - this was IMO associated with unlinkable data. if we combine with permitted uses, it contradicts with the nature of this data as unlinkable.
aleecia: also not expecting to see cookies as part of this proposal
<npdoty> I thought this wasn't about unlinkable data, just that there's an additional allowance for short-term logged data of most kinds
tl: this should not be linked to permitted uses and unlinkable data
... only when logged data is processed do you need to limit the data stored
... it should be no ability to use data until the data is in the form allowed to be stored
... should not put a time limit on that
<bilcorry> What constitutes 'process'?
<tl> bilcorry, The thing that you do to change the logs into the thing that you're allowed to retain.
fielding: similar to that, the goal is to allow storage of unprocessed log data - but dont understand it disappearing as soon as touched
<johnsimpson> what is included in protocol data?
fielding: e.g. raw log data is stored and fraud is discovered, then extraction should be possible without affecting other data in the log
<npdoty> johnsimpson, there have been some different definitions -- the main question being whether cookie data is logged
aleecia: think you are close to agreement with tom
<johnsimpson> that's the concern whether cookies are included or not...
<fielding> fancy finger work, at least
<Chris_IAB> does fraud include security?
tl: if you are storing log files, and need to use the log for a fraud use, then doing so it OK but we need to avoid it being a loophole
ifette: we want DNT protection to be proportionate to the risk. we dont want to force data logs to force you though hoops
<bilcorry> tl, what if logs are searchable via Splunk? Or 500 errors are pulled out for monitoring of problems?
ifette: for various purposes e.g. unique user counts, the data should be able to be processed, and requires the original logs
<bilcorry> tl, I'm thinking of Apache logs in particular, not application logs
<fielding> could we exclude aggregate processing?
ifette: we should make it clear that this is not carte blanche, but we need to leave it open for that period
... suprised at toms suggestion on further data retention after 6 weeks, as users may not like that
<Chris_IAB> I'm not sure we should time limit use of (log) data for legitimate fraud detection and prevention and for legitimate consumer protection purposes (i.e. pattern analysis)
ifette: rather keep it simple and say must be in compliance after 6 weeks
tl: orgs would even less like to store data that they can use for two years. it is in their interest to process the data
ifette: processing is not a single event, there might be multiple dips to process it. we should not force specific processes in that 6 week period
robsherman: what do we mean when we say process?
... we need to clarify that logs are needed for a variety of purposes, and that processing needs to be flexibly supported in the 6 week period
tl: not comfortable with the 6 week period - rather create a system that encourages logs to be dealt with promptly
<ifette> who is disagreeing beyond just tom?
aleecia: thought we wre closer to agreement than we appear now
<bilcorry> Data retention is a regulatory issue in some jurisdictions. Having to drop information ASAP may conflict with requirements to retain data.
<Zakim> ifette, you wanted to ask who is diagreeing beyond just tom? it seems like we are very close to consensus
aleecia: we have issue now with a log of data stored with few restrictions, and need to go down a longer path
<ifette> i think we are not diverging on this call
<ifette> i think we are very close, minus tom, closer even than we were in dc
<justin> I would like some more time to look at it. I haven't reviewed yet today.
aleecia: straw poll on ian's proposed text or do we need to continue discussing
<ifette> justin, it's been more than 1 week
<ifette> +1
<aleecia_> +1 for Ian's text now -
<hwest> +1
<ifette> (or the general concept)
<Chapell> +1
<JC> +1
<robsherman> +1
<fielding> +0 (not comfortable, but happy to see it in doc)
<alex> +1
<bryan_> +1 as compared to the alternative
<Chris_IAB> +1 with some modification of no time limit
<tl> Whoa, "the general concept" ?
<aleecia_> -1 to substantially different
<Lia> +1
<Chris_IAB> no time limit for proper use
<WileyS> -1 Remove this text completely or add it as a permitted use
<johnsimpson> still considering text
<rvaneijk> -1 no time limit but normative text to keep it to absolute minimum
aleecia: otherwise enter a -1 if we need to do something very different
<vincent_> -1
<clp_> Say again choices
<justin> -1 for now
<tl> I think we agree on the "general concept", we just need to get the details right!
<jchester2> -1
<clp_> -1
<Chris_IAB> Hey all, to clarify something: "where the raw logging events are put directly into the database", In the case of logging into a database, where the raw log files are put directly into a database, when would the "process" event happen? At log, or at a later date?
<tl> I neither agree with Ian's proposal nor think we need something substantially different!
<ifette> i hear justin saying "I haven't reviewed the text" and hten asking for something substantively different, that seems in conflict...
<tl> Just *a little bit* different.
<rvaneijk> yes
aleecia: what do non-supporters want: shane is concerned with effect on unlinkable data
... rob had a concern (did not capture)
<rvaneijk> @bryan, no time limit but normative text to keep it to absolute minimum
<tl> Ian, I think we can do this.
<ifette> i had in my original proposal an attempt at some "prohibited uses" in the 6 weeks adn would be happy to take proposals for additional "prohibited uses"
<justin> ifette, Sorry, just trying to indicate I don't feel comfortable signing on to this for now. I apologize that I just haven't been as focused on this issue, but it's an important deviation from where we all had been.
vincent: too vague so far - preferred the splitting of data based upon use, a specific set of data for a purpose
<ifette> justin, that wouldn't be a -1 then :)
justin: not ready to vote, prefer to park for a week
jchester: need more time, another week
<johnsimpson> same for me to review
clp: interested in making it larger, including more cases, more discussion
<alex> I thought we only close issues in ff meetings :-)
aleecia: we need to close issues. looking at a big gulf between process once and enabling longer processing. shane's point is different also
<ifette> (and there may be intermediate processed forms)
aleecia: tom please focus on uses and timelines for logged data - the goals dont appear far apart. we have a span of non-realtime use
<ifette> happy to chat with tom, but would like to get forward progress
tl: need to talk to ian, to provide a more nuanced proposal
ifette: as example, 10K servers, each time the service is accessed IP address, cookies, and service asked for,
... very few minutes the logs are scaped and stored centrally for 6 weeks
<johnsimpson> Is this protocol logs only of 3rd parties, right?
ifette: at eh end of 6 weeks, the complete logs get dumped
... during the 6 weeks, a lot of analyses are run for various purposes
... some access control, but not claiming dnt compliance
... aggregate data is stored over the 6 weeks, based upon lod data that is complete some what processed but still available for the 6 weeks
... in the 6 week period the analyses are thus possible, and after 6 weeks the logs are dumped or put into a dnt-allowed form
... the intent was not to enable free use during the 6 weeks. just a grace period for existing practices without a highly complex locked down system
fielding: +1 to ian. have worked on log file analysis also. large companies process data similar to ian's description.
... we need to find a phrase where privacy concerns are identified without impacting ability to do reporting e.g. aggregate
<WileyS> Then this discussion should be moved under the "Aggregate Reporting" Permitted Use.
<aleecia_> should it?
tl: counterpoint to ian's example, this is mostly about 3rd parties
<npdoty> storage and processing for the purpose of aggregate reporting?
<justin> Uh . . . it's about third parties.
ifette: this should apply to all parties
<bryan_> agree it's about 3rd parties only
<fielding> that surprises me
<WileyS> If the goal is to define the time period data may remain in raw form prior to aggregation, wouldn't that be the best place to have that discussion.
<Chris_PedigoOPA> should be third parties only
<npdoty> I also thought that this was only for third parties
<WileyS> We've already agreed DNT generally only applies to 3rd parties.
<aleecia_> Check the dlist thread
<fielding> but third parties still need the same log windows for trend reports
tl: use-based restrictions vs time-based restrictions are better, as its harder to control use
<justin> I mean, the language can apply to first parties too, I really don't care, but it creates an exception to a prohibition that doesn't apply.
<aleecia_> We can discuss if it should change, but the proposal itself was for all
<rvaneijk> @tl, if you go for used based limitation, please include reasonable technical and organizational safeguards. (...stated in DC)
<justin> But I'll look at the mailing list.
tl: leaving all the data around makes it difficult to use-based retention
<Chris_PedigoOPA> let's discuss that this should apply to only 3rd parties
<ifette> it would be nice to have concrete next steps
aleecia: interesting discussion re who this applies to (all parties?)
<ifette> we've had text make it into the draft with a heck of a lot less consensus than this one has
<bryan_> straw poll?
aleecia: like to continue and close this discussion
<tl> ifette, I'm messaging you privately to find a time to talk.
<Chris_IAB> If we publish a time limit on this use case (fraud/security), the fraudsters/nefarious actors will use that information to their benefit, to remain undiscoverable
ifette: need to know what it takes to get this in
... hearing one objection, others need more time
<tl> ifette: Ping?
aleecia: on the TPE editors put in rough consensus then listen for screams, on TCS editors only enter text if they don't think they'll hear any
<aleecia_> To add to bryan's summary: we're not looking for "stronger" consensus in one document or another. It is a question of when editors put text into the drafts
<npdoty> is the request just that we could put this in the document before we come to consensus?
aleecia: looking for mail list discussion on whether this applies to 1st or 3rd parties
<justin> There really isn't an operative compliance doc at the moment --- the current text is outdated. There are too many open issues in play.
<npdoty> Chris_IAB, I don't think we're currently discussing the fraud/security exception
aleecia: matthias will chair the next call
<clp_> Bye all *waves*
<clp> bye
please correct the scribing if inaccurate... thanks