W3C

- DRAFT -

SV_MEETING_TITLE

11 Feb 2013

See also: IRC log

Attendees

Present
+1.215.480.aaaa, +1.617.324.aabb, statacenter, WaltM_Comcast
Regrets
Chair
dsinger
Scribe
adrianba

Contents


<dsinger> DNT C is online on the phone.

<WaltM_Comcast> WaltM is Comcast 215-480-5838

<dsinger> QUESTION 1: “Lifetime browsing history” is a phrase that is often used, but never defined clearly. What would LBH mean as a technical matter?

<scribe> Scribe: adrianba

“Lifetime browsing history” is a phrase that is often used, but never defined clearly. What would LBH mean as a technical matter?

<dsinger> we discuss background of 'buckets'...

Lmastria_DAA: for the 1024 case, we're talking about minimum number of people in a bucket

dsinger: so that the addition of one more piece of info doesn't identify the person

adrianba: so you would need 2000-ish people before you have more than one group

dsinger: there are some famous cases of problems with DeID

Lmastria_DAA: yes, but many of these examples were a long time ago
... contractual constraints have been added often to stop this
... one of the traps from the 1024 route is that it assumes there are no other constraints in place
... if i give information to some company, what am I giving actually, and what are the safeguards for preventing non-authorised use of the information
... 1024 doesn't address this

dsinger: okay, so let's look at Q1
... what does LBH mean as a technical matter

Lmastria_DAA: LBH of what?
... of my browser? cellphone? person?
... is it PII?
... me vs. an IP address in some county
... should be tied to use - it isn't only a technical matter

adrianba: is LBH the data we're trying to protect?

Lmastria_DAA: objectively, what is the thing we're trying to protect?

[general discussion about different kinds of risks - commercial, government]

dsinger: might someone be able to buy data about individuals?

Lmastria_DAA: providers of data for advertising provide instances of people in a particular category but not down to the individual level

Ionel: to be constructive - we either say we don't know what LBH is because we don't know what it is or come up with some answer and try to define it
... we should be able to define as something like points of data across time - e.g. all the URIs a computer traverses across time
... you put all this in a giant database, collect it, that's it
... the issue is can you link it back to a person or is it just some unknown ID

mike: is this part of DeID?

Yianni: yes
... we need to consider all the risks - LBH has some risks, we identify the possible harm and try to mitigate it

Ionel: with cookies being deleted, if someone tries to keep a LBH they will lose me

dsinger: i think you're optimistic about how easy it is to be forgotten

Lmastria_DAA: advertisers need to scale - they don't target an ad at an individual
... the use really matters

In light of this definition what technical measures would suppress or delete LBH?

dsinger: LBH: Personally identifiable browsing history (URLs, search terms, etc.) that represents a 'reasonable portion' of that person's activity over a 'significant time'.

mike: we could put rules on browsers

Lmastria_DAA: that's not feasible

dsinger: browsers don't know what cookies are being used for

[discussion of alternative techniques for identification, contractual/best practice/etc safeguard measures]

[could configure browsers to not visit some sites]

[set limits on what and how long data is retained]

[set browsers to limit maximum cookie lifetimes]

[discussion of timeline for deletion]

Tying LBH to the previous group discussions of "buckets" or "low-entropy cookies", how can the latter continue while suppressing or deleting LBH

[discussion that the URLs are useful to begin with but not later - can we put people in buckets after that time]

Are there any compelling use cases for retaining detailed browsing history beyond a general time limit on retention?

dsinger: we already have permitted uses that say you only collect the data you need for the purposes you need and only for as long as needed for that purpose
... this is already in the spec

[all agree]

If so, how would you limit those use cases consistent with the goals of (1) limiting LBH; while (2) enabling "buckets" or "low-entropy cookies"?

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013/02/11 21:38:49 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Found Scribe: adrianba
Inferring ScribeNick: adrianba
Default Present: +1.215.480.aaaa, +1.617.324.aabb, statacenter, WaltM_Comcast
Present: +1.215.480.aaaa +1.617.324.aabb statacenter WaltM_Comcast

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 11 Feb 2013
Guessing minutes URL: http://www.w3.org/2013/02/11-dntc-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]