See also: IRC log
<trackbot> Date: 03 April 2013
<kulick> .aabb is me
<WaltM_Comcast> 215-286 is Walt M from Comcats
<Chris_IAB> just joined the call via a private number
<sidstamm> hi all, please accept my regrets as I'll have to leave halfway through the call due to a conflict.
<npdoty> updated agenda http://lists.w3.org/Archives/Public/public-tracking/2013Apr/0056.html
<peterswire> any scribe volunteer?
<vinay> i can do the second half (I'm eating lunch right now)
<aleecia> nope, this is my commute time, sorry
<Joanne> I can take th efirst 30 minutes
<aleecia> (which is why I volunteered so quickly in Berlin :-)
<npdoty> scribenick: Joanne
<npdoty> with vinay to take over (just let us know)
<npdoty> thank you Joanne for filling in in the gap!
Peterswire: things aboutupdated text. Alan submitted test on user eductation topic. on agenda for next week. please review and respond to email
<aleecia> shane, took me 3 tried
Peterswire: lots of activity on list noted on de-eidentification. critical mass of people from diff perspecitves. propsoe conference or other forum to work thorugh topic. FPF willing to host. may be useful to get short submissions for those on list
<jmayer> Can't dial in.
Peterswire: get submissions to help spolicy makers, etc to learn from group's work.
<Brooks> ditto on the no dialin
Peterswire: lets work through
agenda
... Chris to explain changes to service provider and why
<Wileys> Aleecia, 6 tries and still no luck... :-(
<BillScannell> Same here.
<jmayer> I'm at 5 redials.
<aleecia> Unclear: did Peter propose "let's use the wisdom in this group to hold a discussion others can benefit from" or did Peter propose "let's all travel some place to solve this issue"? I think it was the former and yay. If not, please someone let me know
<Wileys> Up to 9...
ChrisP: agreement servicer provider should act on behalf of client. question arouns tems we use (e.g. service provider, data processor)
<aleecia> Ooooof. Zakim is harsh.
<jmayer> Ringing indefinitely.
<tedleung> i can't join the call either. It's just a busy signal
ChrisP: issue with term data processor - carries EU legal implications. wants to pick term.
<peterswire> I was saying let's use the wisdom of the group to inform others about de=identification
<aleecia> I'd get Ralph's voice, then not get the code accepted. But it sounds like I had different issues.
ChrisP: difference here is remved word "only" becasue it implies service provider has one client which is not the intenet
<aleecia> thanks, peterswire. Cool idea.
<jmayer> Now at over 10 redials. I give up.
<Brooks> I just got "number no longer in service"
<vincent> I dialed only once but had to type the code a couple of times and then it worked for me
ChrisP: discussion to silo the data and Roy pointed out siloing doesn't happen right away. Put data is only accessed used by that one party
<jchester2> I cant get through the voice line.
<rigo> Brooks: that's curious, you burned zakim
<dsinger> "only" was modifying "acts" not the primary site. It means that they can't act in some other way as well with the data (which may be already covered)
<Wileys> Jeff, many of us are having the same issue...
<jmayer> Here's the question I would have asked the authors of the "append" text: What's the meaning of the language about identifiability? Could a third party hand a browsing history to a first party?
ChrisP: no independent right to data. added text to end around no other right to use of that data
<jchester2> Thanks. I though my phone had been data appended!
Peterswire: shifting towards outsourced service provider versus just service provider
ChrisP: on same page as what a service provider can do but hpow to describe it
<Wileys> Jonathan - looks like you got through?
<BillScannell> I'm in.
Peterswire: this looks to be easy. Rigo question?
<tedleung> still getting the busy signal
Rigo: likes Chris' text and not concerned with eEU implications and encourages us to conclude on this
peterswire: consensus to move to pendning review stable
JohnS: doesn't understand why siloing was taken out
<jmayer> For those who recently joined... what's the language under discussion, and what's the proposal?
<npdoty> service provider text, http://lists.w3.org/Archives/Public/public-tracking/2013Mar/0057.html
<susanisrael> jmayer, we are discussing chris pedigo's service provider language
<rigo> I wonder about siloing if one has no own right for processing anyway
<peterswire> we are on service provider, with the text as re-circulated late this morning in the agenda/updated email
ChrisP; based upon Roy comments on list. when a service privder is collectiong data on behalf of an entity - data is collected in one big stream then separated by client. Concern is that want data mingled across multiple clients.
<susanisrael> rigo, i think the idea was to silo while processing the data
<npdoty> is johnsimpson's question about "separated" vs. "siloed"? normative text still has "separated"
scribe: can't use one client data along with other client data.
JohnMayer: has same consern as John S. Meeting at Santa Clara - group at logger heads. no agreemnet on whether siloing would be required
<npdoty> "separated by both technical means and organizational process" -- doesn't that match what we agreed on in Santa Clara?
<Wileys> I agree with technical siloing but not prescriptive requirements (for example, logical vs. physical separation)
<susanisrael> does it matter what we discussed in the past if we are agreeing now?
<rigo> +1 to fielding
Fielding: that change didn't come from me but outside this group no one would understand it. Siloing would be explained in the text. Sepearted by customer is silo'd. Siloing not common technical term
<jmayer> qa+
Fielding: no issue with stating access as directed by the client
<rigo> Agenda: http://lists.w3.org/Archives/Public/public-tracking/2013Apr/0056.html
<fielding> we discussed it at first F2F and DC
Mayer: mozilla proposal - do something like analytics companies do now.. fundamental disagreement on the same orgin policy on service providers. appreciate chair wanting to move forward but we disagree
<fielding> SOP has never been mentioned with regard to service providers, so I have no idea what jmayer is talking about.
<npdoty> jmayer, is your concern just that data be silo'd immediately, or that it be silo'd at all?
Peterswire: as data comes in there is an additional requirement. Trying to get clarity from Jonthan.
<npdoty> fielding, we discussed the same-origin policy at Santa Clara in describing siloing of data by service providers, with the conclusion that there must be technical means and should use same-origin policy siloing
<Wileys> Technical, administrative, and operational controls
Mayer: two sep issues. 1. are there access restrictions procedural silos 2. technically - is it silo'd
<aleecia> +1
<npdoty> I think that's the current text "technical means and organizational process"
<efelten> Would need to review the text.
<johnsimpson> +1
<jchester2> +1
<moneill2> +1
Peterswire: are there folks in the group that support Jonthan on having add'l text on this matter? do a +1 if agree
<npdoty> (I'm +1 for that requirement, but think it's covered in the existing text)
<fielding> right, technical means and operatinal controls, but per party not per SOP
<aleecia> have specific procedural suggestion
Peterswire: there is disagreement
from several folks and stop discussion on this now and not put
in final language for now
... moving to append. Written by John S
Alan will explain
<npdoty> fielding, I think the example was using clienta.example.com and clientb.example.com in order to use the same-origin policy on cookies to silo data by client
<aleecia> that being: contrast the new text with the existing two texts. If there is no support for one or more texts, great, drop them as overtaken by new proposals or new understanding.
Alan: when user enacts DNT something needs to happen with online data. gap with req around offline data. if not addressed - incentive for market pllace to build around this
<aleecia> But just starting from scratch when there were two fully formed proposals seems inefficient.
<jmayer> I'm once again very frustrated with the apparent need to continuously reiterate objections.
<fielding> To clarify, "same origin policy" is per origin server domain, whereas per "party" means per first party contract (or third party contract if they happen to be a third party).
Alan: when data is gathered outside first party context and DNT is on then that data can't be used
(hope I got that right)
Peterswire: any others want to add comments
<jmayer> My point is not that the same-origin policy will always be required. But it's the sort of collection-time siloing that would be required.
Peterswire: question - I am first party with employees but dont'have an address but a phone number. Can I look up the address
Alan: first party can coll offline data for legitmate purposes
<robsherman> +q
<aleecia> (John is correct)
<Wileys> Disagree with attempts to move the DNT signal to the offline world. This is an online context - let's keep it there. Consumers have other options to block the offline world.
Alan: challenge to work around the question Peter raised.
<npdoty> but on peter's example, you wouldn't be able to match a user's phone number that they gave you to the address in the white pages?
<jchester2> +q
Peterswire: companies have some info on a cust and would get info from other sources. If 1st party combined offline with DNT:1 wouldn't be allowed (?)
<aleecia> Chris' examples: http://www.w3.org/2011/tracking-protection/track/actions/229
<npdoty> is the second paragraph (a first party must not share) already covered by the first party requirements?
(missed what ChrisP said)
<npdoty> ChrisPedigoOPA: would prohibit append even when data was collected with consent
<npdoty> ... even when the data is public
ChrisP: in first party context - user has relationship with 1st party. lang is overly restrictive. restriction should lie with who is coll
<npdoty> ... third parties are already prevented from collecting information and first parties from sharing
peterswire: any view on third paragraph
JohnS: not seieing how its diff
<susanisrael> isn't part of the idea of dnt that it applies to third parties because users do not have an easy way to opt out from their activities, while they can easily opt out from a first party's activities? also chappell, if your main concern is the use of appended information for targeting, rather than simply the appending, are you suggesting that the standard is mainly about ad targeting and not other activities?
ChrisP: it is diff. you are
talking about how you can use first party data. discussion on
what you can do in a third party context
... whether you can add data to what you coll as 1st party is
diff
peterswire: there are diff between what 1st party can do vs what third parties can draw upon
<susanisrael> my understanding of append is as peter just described it.
Rigo: 2 points. entire discussion shows what came from global considerations discussion and that 1st parties only do permitted uses is needed. overstating data ppend thing. if data is in hands of first party - they have database and can look up data. if you use an outside service like whitepages
<npdoty> I understand that john and alan are proposing *new* requirements beyond the example of the first party sharing IDs when reaching out to append data to their users' records
Rigo: if share a unique id - that shouldn't be allowed. rule around not sharing using a unique data.
Peterswire: is data coming out of 1st party with a unique id
<npdoty> while I think ChrisPedigoOPA's text already accepts prohibiting first parties' sharing user IDs during the data append process
<jchester2> +Rigo
Rigo: yes. if 1st party uses id to draw data from 4rd party then 1st party shared the data
<npdoty> rigo, except in the white pages example, right? or some cryptographic matching algorithms?
Rigo: problem is data geoes to the 3rd party
<susanisrael> Rigo, if you use offline data added to first party, how is that going cross site?
Peterswire: concern there is leakage from 1st party to a third party.
<vinay> Joanne - I'm done now. Do you want me to take over after this topic is done?
please Vinay
scribenick Vinay
<npdoty> scribenick: vinay
<npdoty> robsherman: distinguishing between using information a first party already has to customize content in a third-party context
robsherman - think you can distinguish between using information a first party already has on a 3rd party site versus collecting data in a third-party context
scribe: append is not about what first parties are getting, or third parties are getting. Instead, its when a party is trying to get additional information (and as part of that is passing identifiable information to another party)
<johnsimpson> +q
scribe: text is making the
solution more complicated then it needs to be
... instead, make the solution about limiting how the data
provider cannot use the ID/information in other ways than for
fulfilling the service
... don't want to re-hash the conversation from the mailing
list
<aleecia> zakim unmute me please
<aleecia> zakim unmute me
jchester: wants to echo what rigo said, and supports achapell's proposal
<aleecia> eats shoots and leaves?
jchester: if the user has
expressed a DNT preference, it has to be permanent (and not
done at a transactional level)
... first party cannot use online products to target that user
outside of a 1st party context
<rigo> I think "offline" is not really "offline" It is looking up data real time over another network.
Aleecia: wants to talk about the
crux of why this is an issue (entering academic world)
... context class. what you told a first party, and what you
understand that first party doing
... data append is about adding 3rd party data to some other
party
... what i paid for my house is public data
... but the idea that facebook (as an example) can use that
data (for a DNT:1 user) to profile me and serve me an ad in the
context of FB breaks the idea of DNT
<npdoty> that seems like a good reason to be very concerned about social networks that use a real-name policy, rather than a DNT issue
Aleecia: If we can start with something smaller and work up, maybe that is a better approach.
<Wileys> Aleecia, I agree with the concern but don't believe DNT is the right place to solve for that.
Aleecia: for example, do we all agree that non-public data is not okay to append for 1st parties
(Did I get that right?)
jmayer: three different questions/concerns
<aleecia> heh
jmayer: 1) not sure what the word
identifiable is meant to mean. is it meant to mean linkability,
is it meant to be de-identified, or okay to use user names but
just not using it
... until we get an idea of what identifiable means, we can't
go that far
... 2) wasn't entirely clear to jmayer whether/how this
operates bi-directionally
... Peter agrees and will ask this later
... 3) alternate proposal (both more and less expansive than
this one). its the proposal that pre-dates this one from the
EFF one. No special rules around appending
... instead, go by general guidance of no collection/sharing of
linkable data
... would actually allow a party to use data collected in a
first party context in a 3rd party context
... and allow some sharing of data if the 3rd party could have
collected it themselves
<fielding> Aleecia, I am not sure why your concern would differ whether the user had DNT:1 or DNT:0 in that scenario -- the user has an account with the first party and if they don't want that first party to obtain more public information about them then they should insist on a control interface specific to that first party (not specific to tracking or DNT). Any other solution would require that first parties change their function per DNT (i.e., change the service
<fielding> intentionally requested by the user, as far as we know) which is something we are deliberately trying to avoid.
<npdoty> jmayer is saying he would prefer an alternative that is actually more permissive in terms of use of data by first parties
johnsimpson: wanted to take a
step back and say that i'm trying to accomplish this -
hopefully we can arrive at text that gets us there
... agrees that in a first party transaction/interaction,
johnsimpson is reasonably comfortable with that 1st party
gathering data
... but if im sending DNT:1, I do not expect that first party
to use/take/bring in anything to that transaction
achapell: responding to a number of comments
<npdoty> johnsimpson, do you think that's specific to a DNT preference, or are you concerned about combining data in general?
achapell: to jmayer - re:
identifiable, alan's thoughts were unique IDs. tried clarifying
that in non-normative text. Intention was to be
bi-directional
... w/r/t robsherman, i agree we're not worreid about 1st party
usage; the challenge is that in most data append use cases the
use is not clear
... w/r/t Chris, we're clear that consent trumps DNT
<jmayer> If the intent is unlinkability and non unidentifiability, then the proposal should use different language.
peterswire: thinks the
conversation was useful. shows different views and several
different data flows
... what peter's going to try to do is write up a list of
structured questions and send it to the group (and perhaps a
smaller group)
<jchester2> we should incude examples of what's being done today, Peter
peterswire: hopefully find out where there's agreement on some points and disagreements on others
<npdoty> to be clear, ChrisPedigoOPA and jmayer, both of you would prefer to be silent on requirements around data append?
<johnsimpson> sounds like a good way forward, Peter.
peterswire: next item on the agenda is multiple first parties
robsherman: on last call, bothh im and justin had some text.
<jmayer> npdoty, in normative text, I think silence would be adequate. In non-normative text, I think an explanation would be worthwhile.
robsherman: since then, they;ve spent time trying to bring them closer together
<npdoty> jmayer, understood, thanks.
robsherman: understands there are
times when two companies are coming together to provide a
website
... couple takeaways from last call: 1) make clear its not a
common situation; 2) carve back the ways this could happen in
unintended ways
<scribe> ... new proposed text tries to capture whether the user would expect to reasonably communicate with both/all companies
UNKNOWN_SPEAKER: includes example
(language may change, but intent is there)
... "powered by..." won't be enough
... had discussions between 1st/3rd party in platform
context
<peterswire> are john and alan on the Q for multiple first parties?
UNKNOWN_SPEAKER: needs more work,
but will want to make clear that in the context of a platform
the person operating the page will still get actions on the
page
... still needs to formalize it
<npdoty> I think this is looking good, thanks for putting so much work into it, robsherman, justin
<jchester2> +q
Peterswire:
questions/comments/any consensus?
... can we move this to pending review/stable
jchester2: has some concerns
about this
... may see a loophole in it
... can we get an example of this
... including at the platform level
<rigo> jeff, look at facebook corporate pages, this is IMHO what Rob is talking about
<npdoty> jchester2, they include a negative example ("powered by Example Analytics" does not suffice); are you looking for a positive example as well?
robsherman: let me talk with justin about this
peterswire: one example of a co-branded site is a delta + american express joint promotion re: its credit card
jchester: can we do an informal poll on this?
peterswire: lets try it
<npdoty> satisfied with latest proposal +1, unsatisfied -1
<npdoty> +1
<hefferjr> +1
<Wileys> +1
<robsherman> +1 :)
<ChrisPedigoOPA> +1
<amyc> +1
(thanks npdoty -- you type faster than me!)
<tedleung> +1
<JC> +1
<Joanne> +1
<kulick> +1
<moneill2> +1
<susanisrael> +1
<rigo> +1
<phildpearce> -1 As need more examples of "powered by..."
<Chris_IAB> +1
<fielding> -1 for reasons not discussed yet (SP provisions)
<jchester2> -1
peterswire: if you have concerns, i suggest contacting rob and/or justin
<dan_auerbach> +1 on text, -1 have some related concerns
<npdoty> or contact on-list, I'm not sure what the service provider concern is, for example
<phildpearce> ok
<johnsimpson> q_
next topic: should be easy (riight?) -- de identification
Peterswire: thinks the issues
we're discussing will come up in many other processes
... have a proposal from Dan with some edits by Roy
... but thinks we may have bigger disagreements on
non-normative text
dan: don't see too much
disagreement between him/Roy on the normative text
... okay to accept roy's edits to his normative text
<Wileys> +q
<npdoty> "actions of" vs "infer information about", dan could accept either one
peterswire: can you clarify what you meant by being okay with Roy's email?
<efelten> Echoing earlier discussion, we don't have a definition of "identify"
<Wileys> By "particular" I want to be sure your goal is to isolate the "actual" user or device - and not suggesting that a unique record replacement does not meet the definition of de-identified.
dan: okay with roy's suggestion about the inferring action (did I get that right?)
<fielding> yes, I provided two choices and the summary only had the first … either is okay with me.
dan: the language from Roy was to
'identify a user'
... I'm suggesting the other one Roy suggested was better
... identify an action
<npdoty> (if we can infer your name and address and gender and medical status, that wouldn't infer any actions of that user, right?)
wileys: one recommended amendment
-- use the term actual instead of the word particular
... belief that there is a way that a unique record can exist
(but it is de-identified)
<rigo> unique => red zone
wileys: the term particular can be interpreted in either direction
<dsinger> is the word 'specific'?
Dan: quick response is that his interpretation of the normative text is different htan how shane would interpret it
<Wileys> Thank you Dan!
Dan: but at a glance, it should be fine with him
<dsinger> i.e. the question is whether a singular, specific, particular user can be identified from the data, not whether the user is virtual or real...
rigo: question to wileys. in your situation, can you single out a particualr device?
<efelten> +q
wileys: when you say that,
assuming you mean ________ ( missed it), the answer is no
... we can still de-identify a record for non-real time
use
... but none of that would link back to a user in the real
world
<fielding> “Data can be considered sufficiently de-identified if there exists a reasonable level of confidence that the data cannot be used to identify the actions of a particular user, user agent, or device.”
<efelten> -q
wileys: thats why terms like specific or particular may muddy up the language.. where actual goes after the intent
<npdoty> we could just go without an adjective "cannot reasonably be linked to a user, user agent or device"
Rigo: what you're saying is -- we
stream in a lot of data, change the IDs, then store it, do
analytics/etc.
... but you still have unique traces that are connected to a
unique ID
... so you don't aggregate so you don't get 1 of 500
<aleecia> swapping one GUID for another is not a privacy solution
<jchester2> leaving IRC to go to meeting but listening on phone
<efelten> +q
wileys: for de-identification to work, the important element is that once de-identified, the information is never used to modify a particular user's experience.
<vincent> so as soon as I update my user agent you can link all my request to my previous UA and that'd be ok because it's no longer my *actual* UA?
<npdoty> I don't think the de-identified property of the data is dependent on whether the data is going to be used to modify the user's experience
wileys: your goal of 'single out' is looking at singling out a user in the real-world
<efelten> +1 npdoty
wileys: wileys goal is to not allow that, but at the same time allow flexibility in analytics
Rigo: singling otu is a compelling topic that is addressing the particular topic they're trying to address
<efelten> De-identification
should depend on the data, not on the server company's state of
mind.
...wileys: thinks we can acheive an outcome that the connection
to the real-world that makes them identified is removed; but we
still maintain value in the data for analytics purposes
<npdoty> so the AOL data set would be "de-identified"?
<fielding> The goal of this definition is to avoid "linked" and "unlinkable" -- I know that word is used in other privacy contexts, but it is very confusing for the Web (the entire point of which is to enable linking of information).
<aleecia> +1
dan: wants to emphasize that even though we;re coming to some agreement on normative text, we have a fundamental disagreement on what de-identification details
<aleecia> (+1 to Dan's point we're worlds apart)
dan: don't think using pseudonyms or scrubbing log files is adequate de-id
<vincent> npdoty, according to Wileys definition, I think it would be
dan: until we hammer out the non-normative examples, dan believes we're at an impasse
<npdoty> WileyS, do you think the AOL search data set would satisfy your interpretation of "de-identified"?
moneill2: should be both
de-identified and unlinked
... DNT means do not track me over time
<Wileys> Nick, NO - as they left markers that allowed re-identification (~4 people out of 600K). URL scrubbing should included in any de-identification process.
efelten: don't think its workable
to have a definition of de-identified when looking at what
someone can/cannot do (not sure if i got that right)
... that kind of definition is not sustainable (certainly not
testable or actionable)
<rigo> +1 to edfelten
<dan_auerbach> -q?
efelten: tends toa gree with dan that the discussion on non-normative text will focus the conversation
<Zakim> dsinger, you wanted to say that modifying experience is not the (only) privacy issue
dsinger: the concern is not youre going to use this data to target me, its that you have this data
<fielding> I agree with Ed -- what is important is that the data cannot be used to identify
<npdoty> Wileys, so you agree that data that could be linked back to (even if it operationally wouldn't generally be) a user or device isn't de-identified?
<efelten> +q
<rigo> I think the disagreement is on what "identification" means. Whether it is name or "single out"
peterswire: we have this puzzle for the group of how to proceed (how much of a standards process is it to resolve non-normative text)
<Wileys> Nick, If I can pass you a record, and you can leverage that record in isolation to re-identify a user then it has not be de-identified.
peterswire: suppose for
discussion that we're close to consensus on normative text but
far apart on non-normative text
... whats happened in the past for other standards
processes
<efelten> Why "in isolation"? Why pretend that Nick doesn't have access to side information? (Because he does.)
peterswire: david, roy, andrian -- any previous experience in this?
<Wileys> Nick, If I pass you group of records, and those records in concert can be used to identify a user, then the group of data has not been deidentified.
efelten: echoing what dan said in the maling list, it would be helpful for an example of a specific administrative control that meets this
<Wileys> Ed - agree on "Side Data" as you presented in Cambridge - this includes that concept.
<dan_auerbach> I strongly believe that we don't have agreement until we have agreement on the non-normative examples
<npdoty> Wileys, thanks, that seems like maybe you agree more with dan and ed (and the examples in the proposed text) than we might have thought
<dan_auerbach> to go back to Peter's question
rigo: personal data is much weaker than unlinkable data
<susanisrael> rigo, i think the idea of "split" keys, for example, means split between 2 different entities or at least different people.
rigo: you may have identifiable
data, but if you need the help of many other people to identify
an indidivual, then that posses a harder problem
... can maybe address this by saying that the entity cannot
re-connect/re-combine the IDs
<vincent> Wileys, so if you can "neither infer information about an *actual user agent* nor *a specific use or devicer*" would that be ok?
<Wileys> Rigo, agree with the grouping concept. IP Address is a unique identifier and should be de-identified.
<efelten> Just *saying* that something will not happen is not an administrative control.
adrian: to address the process
question, typically we haven't really tried to differentiate
text between nornamtive and non-normative text
... but generally if we have this type of disagreement, I would
think peoople have different interpretatiosn of the normative
text
<dan_auerbach> +1 to Adrian
<aleecia> agree with adrian that this is a sign of ambiguity rather than agreement
adrian: and would suggest we make sure the normative text is clear
<rigo> +1 to adrianba
<fielding> peterswire, I would suggest using the WG decision process -- narrow the options to a relatively few specific texts, use the polling tool to identify objections, and then make a decision that tries to thread the needle. We can then move on, at least until more information is provided to make re-discussing it worthwhile.
<aleecia> but, the non-norm may help people learn where those issues are, if there is any lack of clarity still
<Wileys> Vincent, I would go with Roy's definition and simply replace "particular" with "actual"
<Wileys> I think that gets to what you want.
peterswire: in the discussion
last week re: financial/auditing, the Deloitte people said that
advertising is becoming more important to make sure nobody is
cooking the books
... so a bunch of advertising data may be likely to come under
the rules for retention for 7 years
... that's what Peter took from last week's call
... so wondering to put that claim, if true, against what we're
discussing here
<efelten> +q
<dan_auerbach> +q
<vincent> Wileys, not really, if I stop using a service or if you service is discontinuated I'm no longer covered by the term "actual"
peterswire: how is what we're doing here affected by possibly having a separate process for auditing?
<moneill2> +q
efelten: to the extent that something may be required by law, there's no cover/need to provide specifics in the standard to discuss it
Dan: couple things: 1) better to keep the discussions separate
<Wileys> Vincent, by actual I mean any identifier that connects to the "actual" person, system, device, or user agent. How does the starting or stopping of a service affect that test?
<aleecia> +1 to keeping these very different discussions
<rigo> if you still have financial data in that granularity, you can't claim de-identification
<Wileys> Disagree - raw log data is needed
Dan: as an aside, my
interpretation of the experts last week was a bit different
than yours. dan heard that raw log files are rarely, if ever,
needed
... thinks a lot may be able to get done in a de-identified
manner
<rigo> Wileys: as long as you have raw logs, you can't claim "de-identification" without attracting remarks
moneill: if we say what we mean by unlinkability, how long do we need to link the data sets?
peterswire: as I've summarized already, we have quite significant disagreement on non-normative text
<vincent> Wileys, sorry the normative text said "actual" user (not person) but I get your point
peterswire: im inclined to go directly to those most involved to share tenative thoughts to discuss how to proceed
<Wileys> Rigo, as I explained on the email list - you would need to keep these datasets separate
<Wileys> Thank you Vincent.
peterswire: tempted to try to
have a conference/meeting to clearly explain why we have
different views; and have well-reasoned explanations of the
views
... don't see a way to bridge the divide on non-normative text
right now
... highlight for next week...
achapell has a proposal that he asks people to consider for next week re: user education/interface
scribe: peter to work on appends
<johnsimpson> if you can't agree on non-normative text, I don't see how you can claim agreement on the normative. It means different things to different people and that implies a fundamental problem with the normative text.
<aleecia> +1 john
<phildpearce> Re: moneill2 on using de-identified and unlinkable if this was via a temporary 30min or time dependant sessionID rather than permanent sessionID... this would cause significant changes in data analytics reports for example for new and returning visitor counts would skew.
<npdoty> thanks peter, and vinay and Joanne for scribing
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Fiedlding/Fielding/ Succeeded: s/reiterated/reiterate/ Found ScribeNick: Joanne Found ScribeNick: vinay Inferring Scribes: Joanne, vinay Scribes: Joanne, vinay ScribeNicks: Joanne, vinay Default Present: +1.781.482.aaaa, samsilberman, npdoty, +1.408.836.aabb, +1.646.654.aacc, +1.215.286.aadd, eberkower, RichardWeaver, efelten, WaltM_Comcast, Rigo, MECALLAHAN, Chris_IAB, sidstamm, peterswire, +1.937.215.aaee, Fielding, ChrisPedigoOPA, moneill2, Yianni, JeffWilson, Joanne, [Microsoft], hefferjr, vinay, +1.202.370.aaff, +1.202.331.aagg, +1.202.347.aahh, hober, Aleecia, prestia, adrianba, chapell, johnsimpson, Susan_Israel, Craig_Spiezle, Chris_Pedigo, kulick, vincent, hwest, BerinSzoka, Amy_Colando, +1.650.365.aaii, Dan_Auerbach, Brooks, [FTC], Jonathan_Mayer, bills, +1.202.370.aajj, robsherman, WileyS, +1.202.494.aakk, Ted_Leung, jchester, Walter, +1.415.821.aall Present: +1.781.482.aaaa samsilberman npdoty +1.408.836.aabb +1.646.654.aacc +1.215.286.aadd eberkower RichardWeaver efelten WaltM_Comcast Rigo MECALLAHAN Chris_IAB sidstamm peterswire +1.937.215.aaee Fielding ChrisPedigoOPA moneill2 Yianni JeffWilson Joanne [Microsoft] hefferjr vinay +1.202.370.aaff +1.202.331.aagg +1.202.347.aahh hober Aleecia prestia adrianba chapell johnsimpson Susan_Israel Craig_Spiezle Chris_Pedigo kulick vincent hwest BerinSzoka Amy_Colando +1.650.365.aaii Dan_Auerbach Brooks [FTC] Jonathan_Mayer bills +1.202.370.aajj robsherman WileyS +1.202.494.aakk Ted_Leung jchester Walter +1.415.821.aall dsinger Agenda: http://www.w3.org/mid/CD81C69A.74DB0%25peter@peterswire.net WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 03 Apr 2013 Guessing minutes URL: http://www.w3.org/2013/04/03-dnt-minutes.html People with action items:[End of scribe.perl diagnostic output]