Tracking Protection Working Group DC face-to-face

11 Apr 2012

See also: IRC log


Attendees list
Aleecia and Matthias
ifette, JC, rigo, rvaneijk, vincent_, bryan, amyc


<tl> https://www.cylab.cmu.edu/research/techreports/2012/tr_cylab12007.html

<npdoty> scribenick: ifette

Remarks from Commissioner Brill

Brill: key is choice
... doesn't hinge on a long privacy policy
... DNT should be a simple, elegant form of choice for users
... understandable and consistent choices for consumers
... good progress, worth reviewing how far we've come to put issues in perspective.
... browsers developed that permitted consumers to tell websites not to track their activities across websites
... yahoo announced it would roll out a DNT mechanism across its platforms
... challenges are greater in mobile space
... Mozilla has also released a mobile browser with DNT support
... DAA has more fully developed its aboutads program
... had event in Feburary at White House, committed to honor choices consumers make through settings on their web browsers
... support collaboration between browser + icon based systems
... welcome DAA's commitment to honor browser based solutions
... great progress at W3C as well
... stakeholder participation from many sectors
... Dec 2010, first call for DNT from FTC, had vision of successful DNT mechanism
... works on all sites, easy to use and understand for consumers, would have staying power even if browsers updated / cookies deleted
... meaningful (if companies don't honor choices they tell consumers they can make, would be consequences)
... and mechanism for consumers to affect how much data is gathered about them, not just targeting
... vision has become a reality including w.r.t. collection and use of consumer data
... concern around employment, healthcare, insurance eligibility etc
... DAA committed to preventing these precise forms of collection and use in conjunction with its aboutads program
... eagerly await full implementation of DAA commitment
... demonstrates DAA and others have embraced collection minimization
... understand group has reviewed several proposals with key issues outstanding
... commission addressed 1st/3rd party to an extent
... indicated that as far as affiliates are concerned, consumer choice mechanism necessary unless it's clear to consumers. (quoting from pp42)
... common branding as one way
... negotiation, compromise
... looking for outcome that the broadest set of stakeholders can live with
... hard and important issues remaining
... hope that people will be guided by principles laid out in FTC's final report
... if successful, will help secure better online environment with meaningful lasting benefits
... happy to take questions

Roy: Notice you don't define collection
... have any thoughts?

Brill: there is no definition of collection (in ftc report). We refer to it in many areas
... de-identification carveout
... element of collection subsumed in that concept
... as well as data minimization that focuses on collection issue
... are you asking how long retaining info becomes "collection"

Roy: Currently have "receiving" is collection
... but believe intent of FTC is retaining is collection

Brill: interesting issue, not sure i want to step into that debate
... one thing to receive and do nothing, can also pass through and be a conduit in which case there is an element of collection
... can see all sorts of examples
... if you receive it and it immediately disappears, it's done away with, that's one thing, vs receiving and passing on, a number of scenarios...

<tl> Brill: Nice try though. Anyone else what to see what you can snare me with?

<npdoty> <laughter>

Bryan: Looking at commonly accepted practices, there seems to be a general understanding that there's a set of things we all recognize, but there's explicit language in the report that those things may change, aspects of context that need to be taken into account
... how do we deal with complexities, business models, broad overlapping categories

Brill: Asking $64,000 question
... let me lay out some thoughts
... true that we started with concept of commonly accepted practices (5 in report)
... fraud prevention etc
... we got a lot of comments in this area
... final report notes difficulties in trying to lay out specific examples
... under/overconclusive
... May not take into account innovation, use of info
... may be under-inclusive as wel
... so changed to the 'context of the transaction'
... your question is getting to permitted uses exception
... think you can look at context of transaction and answer 1st/3rd party issues as well
... believe there should be a signal to consumer if there's a first party relation (page42)
... eg branding is a context of the transaction
... other exceptions, would say it's not easy
... we did suggest is that the list FTC set out is a good starting list
... (the 5 examples in the report)
... will be sitting here a while longer

JeffChester: is it fair to see FTC looks forward to resolution at W3C where multi-stakeholder process agrees on meaningful standard for DNT? is this important?

Brill: Absolutely. One of three major industry processes underway
... would be terrific if you can come up with a solution. don't want to dictate what that solution is.

<npdoty> "we call it industry, but really this is broader"

Brill: very supportive of this process

JohnSimpson: Can you speak more to affiliates and user expectations
... mentioned branding, are there other ways to know something is an affiliate that is in line with user expectations?

Brill: We do talk about common branding as one signal
... reason why I went to law school and not advertising. I'm not the most creative person
... I feel there's ways to communicate clearly to consumers that wouldn't necessarily involve common branding to consumers
... looking for a clear upfront signal to consumers, not something buried in a policy
... clear and immediate communication to consumers, not buried information, in terms of what it would take to give appropriate signal to consumers
... answering by saying what it isn't, not what it is
... think that's the only fair reading of what the report says
... happy to chat, but we are trying to get clear immediate info flowing to consumers, not buried in privacy policies

JonathanMayer: Chairman L. suggested if there weren't an effective DNT mechanism developed, he would consider calling for DNT legislation. Would you join in that call?

Brill: In other words, if there is not a clear solution he would call for legislation?

JM: yes

Brill: Yes, I do agree
... but i want to add that he said (the chairman) he thinks we're very close and will get there by EOY and I agree with that as well
... I think we will get there, I've outlined things I still want to see, I think this process is important, but will join him in that call if this isn't successful at the end of the day

JC: Can you give us update on work with EU on consolidating DNT? They have their idea of DNT as well, want to make sure we don't ahve two different standards

Brill: Makes sense
... whatever is developed here, and the DAA program, all of it should be something that works elsewhere if posible
... have had lots of conversations with EU friends, some are here
... think there is optimism in Europe not only on possibility of legislation
... but also folks wanting to see if this process will work and provide answers to concerns europeans have
... haven't gotten into 1:1 discussion with counterparts on particulars of DNT and if it needs to go one way or another on issues
... sense is that they are optimistic about DNT generally providing some solutions for the issues they're looking at

Rigo: When we talk about the EU context, will consent enable the industry to do things they could not cleanly do
... if we create a consent mechanism, can the FTC envision that a company who will use DNT as a consent mechanism, can the FTC envison a company would get an advantage out of it?

Brill: If company embraces DNT, hopeful there will be competition on privacy
... seeing examples of this
... believe companies that advertise how protective they are of customer data, respect customers, ... - believe these companies will have a huge advantage in the marketplace
... for companies here that develop a program that they then embrace, you should tout that where you can and engage in competition based on privacy as well. this is where i see the primary benefit
... wraps up
... thanks

<rigo> ifette++ for good minuting

<asoltani> <rigo> ifette++ for good minuting - +1

<npdoty> scribenick: JC

Big Issues

Aleecia: Will start with text that Bryan sent yesterdar

Bryan: My email summarizes what I stated yesterday round our group's focus
... I don't think W3C will be succcessful in short term
... user intent and server response
... TPE should clarify what we are doing here
... what is signal conveying from user
... what is policy that the site complies with
... comply with what they say they will do
... we should do son in normative set of best practices
... don't want to slow down work on tracking preferences
... policy-focused work, W3C works best when focusing formats and technical specs
... we hope community group progess will shed important light on user needs

<jmayer> What a wonderful delivered address!

<tl> I too find these prepared remarks both useful and on-topic.

<npdoty> bryan, would you care to send that text via email?

Bryan: we should not replicate community group process within the W3C

Aleecia: We is AT&T
... looking for how much support there is for proposal

rigo: would be helpful to send text to email DL

<bryan> Here are my comments in the meeting: The history of policy-focused work in W3C has demonstrated to us that W3C works most effectively when it focuses on protocols (including APIs), data formats, and related User Agent requirements. In areas of policy expression and compliance, it has been less successful, due to the complexities of representing policy choices for users through browser UI, combined with the unfamiliarity of W3C with dealing with the rapidly evolvin

Jonathan: lets try a hum

<bryan> service architectures, and the roles of various market stakeholders. We hope that the introduction of the Community Group process will help W3C gain a broader and deeper perspective on the Web-enabled services marketplace. But in the short term, which is the most important term for DNT, we believe that in order to make a fast, positive influence on user privacy on the Internet, the W3C should focus on what it does best by focusing on the expression of user intent

Mike: I want to understand process
... do you want to decouple TPE from compliance document?

<bryan> It should tackle the more complex issues of policy and compliance through the community group process and collaboration with existing compliance forums, while the market gains experience with the DNT standard. If those compliance forums need to step up their game to address market-specific requirements, that I believe is possible, but it is not necessary or helpful to replicate or supplant that existing process of market-based self-regulation with a one-size-fits-

Mike: any other ideas about where you may go in reagards to permitted uses

Bryan: We made early attempts to bring in policy expresions.
... we should revisit that
... the W3C could revisit the policy expression

Aleecia: going to hum. do we want to spend more time to discuss Bryan's proposal

<bryan> through W3C.

Aleecia: hum if we should not discuss policy
... basically a split in the hum feedback

<npdoty> Aleecia: suggest we take time on a conference call to discuss this further

Aleecia: we will continue the discussion during a future call
... let's pickup where we were yesterday
... we have tom

tom: Procedural question
... in the past there have been items where the group has been split and we haven't discussed them
... I don't think we should discuss it

Aleecia: noted
... let's see what Bryan proposes
... whe have an idea of what he is not happy with, but now what he suggests instead

<tl> s/"... I don't think we should discuss it"/"... I don't think we should continue this procedural question now, but I wanted to raise it"

Aleecia: yesterday we looked at proposals from Jonathan and Shane
... discussion around permitted business uses

<jmayer> Shame on the industry participants. You're not getting your way on substance, so months in you're trying to bail on the process.

Aleecia: Jonathan etc had a proposal for unlinkable data
... Shane says it is unlinkable if it goes through a de-id process

<jmayer> Once again, if users were in the room, they'd be disgusted.

Aleecia: Jonatha indicates business uses are okay if data is unlinkable
... shanke groups suggested that there be a stated policy of what a company is doing
... lets look at details of proposals
... are there questions for authers on this. Where do we stand and why
... after we talk we will go in different direction

Rob: What to state why unliknkability is important
... data which you are processing would not be personal data and therefore there are no restrictions
... you always have to comply with the directive for personal data
... take privacy safeguards
... it is well worth spending time on that

Shane: there have been several conversation

<ninja> we definitly need to find a different wording from "unlinkable"

Shane: once data is unlinkable that data should be outside the scope of DNT
... can we make that statement in one place in the document
... then we can look at data minimization standards

Jonathan: Don't say that unlinkable data is not in scope

Rigo: If we say unlinkalbe, unlinkable between what and what
... link between me and dossier

<pde> ninja, why are you unhappy with "unlinkable"?

Rigo: unlinkable is not connection between me and dossier
... going back into such a discussion with our time constraint is a rat hole
... if we have sufficient requirements where we clearly can state that you have unlinked data then you can do whatever
... I don't want to say that because it is unlinkable that it is out of scope
... but it does give us a threshold

Aleecia: I think what he means that if we we define unlinkable then we can use data in any way we want.
... It is the same in the EU

<npdoty> "everybody's happy"

Aleecia: I htink we all agree

<ninja> pde, "unlinkable" is a term which is already used in area of privacy research and upcoming ISO standards - in a different way. Unlinkability is in the area of pseudonymity - not anonymity. But we (the working group) is talking about anonymity here.

Aleecia: we still have the task to describe unlinable data
... Shane and Peter will work on text

David: can we say what we are worried about and skip the things we are not worried about

<npdoty> ninja and pde, FTC has used the term "reasonably linked to a specific consumer, computer, or other device"

<vincent_> ninja, I don't think we're just speaking about anonymity here

<pde> ninja, you mean the literature uses it to mean "unlinkable" between a read world identity and the pseudonym's actions

<pde> ?

Rigo: i want unlinkable to be non-exclusive
... we can state unlinkable, but we cannot say that you have to do specific things

Bryan: will you provide a specification for unlinkable and who will be responsible for compliance?

<pde> npdoty, and I would note that if you can link all of a device's data points together, then implicitly you have linked them to a particular device (not sure if "particular device" is exactly the same as a "specific device"

<rigo> Bryan, I think that's Specification maintenance

<pde> )

Aleecia: lets wait until we have text before we discuss this

<vincent_> npdoty, so FTC defines unlinkability in the context of anonymity?

Jonathan: the DAA already has text on this

<npdoty> action-160?

<trackbot> ACTION-160 -- Peter Eckersley to work with Shane on common ground on unlinkability normative/non-normative text -- due 2012-04-24 -- OPEN

<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/160

<ninja> pde, yes and linkage between several different pseudonyms, or segregated pieces of data.

Aleecia: Lets take out unlinkable data for a moment

<pde> ninja, this sounds like a good topic to discuss over coffee

<ninja> I won't argue about wording as long as we find a clear definition of what we are talking about

Aleecia: jonathan states that protocal info is okay for short-term use
... Shane states its okay of reasonable data minimization efforts are made

Ian: it sounds like everyone is okay with short-term protocal data use

Aleecia: anyone disagree?

Ian: need to define short-term and what data can be collected afterwards

<npdoty> there is apparent agreement in the room on that point

Amy: logs are okay to collect for anyt purpose as long and retention is foloowed?

Jonathan: we talked about sensitive use, but decided not to define that

Aleecia: what is reasonable retention period

Jonathan: That is for protocal data. Fon non-protocal there is a lot to talk about

Rigo: We need a use limitation on the data
... this is in the TPE where we have lots of disputes

Aleecia: lets take market research off the table for now

David: for transaction data we know what is needed
... for other data it is difficult to get a handle on minimization and retention

Aleecia: lets look at data minimization for protocal data

Peter: thoughts on data minimization
... different retention periods for general use like two weeks
... security and fraud a longer period
... perhaps auditing in the same bucket
... there is a subtle difference between types of protocol data and the full list of data that you can get from logs
... I would like to define a standard set of protocol data
... Marc: threshold question
... what is protocal and non-protocol data?

Aleecia: lets use flip chart to write text

Shane: I beleive delta between protocol and non-protocol data is log data and cookie data

Jonathan: nonprotocal, any cookie or data replayed from client
... data solicited from client

<rigo> JM: any cookie, information service sollicits from a UA (fingerprinting & API call)

Jonathan: moment an API call is made or data is stored it is not protocol data

<rigo> WileyS: agrees

Shane: arbitrary timeframes are difficult to describe
... there are many global companies and we do not understand all of their business models
... lets stay away from arbitrary timeframes

Aleecia: protocol information is what hits your Apache log

Ian: then that would include cookies

Aleecia: true

Peter: one option is use a rule that can apply to a third party then we can include cookies as well

<WileyS> Rigo - no strict limits - force companies to disclose and defend their data retention periods

Bryan: standard protocal information received by a third party can be obtained?
... custom headers are used by many systems and sticking to a standard header can break things

<npdoty> WileyS, I think the suggestion is that in addition to the discussion of minimization of long-term business practices, there would also be a blanket exception for short-term retention

<dsinger> seems like there may be a major difference between data you are 'exposed to' (stuff sent in headers, for the most part) and stuff that you take explicit measures to 'collect' (e.g. a fingerprint, data from other sources about the user)?

<rigo> WileyS is a year too long, too short as the absolute limit? 10 years? What is our absolute limit?

Aleecia: there are interesting business models over what is placed in a header

Rob: in NL telecom operators are injecting data into fields
... those identifiers could be used as cookies, but they are extremely persisitent

<rigo> there is a relation between what you retain and how long you can retain it until it stinks

Amy: I think that there is room for best practices for serving ads and collecting information
... we need to recognize how frequency capping and other tasks require cookies

<WileyS> Rigo - I can't speak for every company in the globe - far too diverse of a continuium to set a single limit. If a company is involved in nothing other than security support of their clients (traditional 3rd party) they may have valid data retention limits that extend into years.

Amy: lets not constrain the common uses of the Internet

<WileyS> Rigo - similar example for financial audit firms

<tlr> One question for the fingerprinting is whether protocol vs non-protocol is the right distinction. Sometimes, protocol elements can be tuned in a non-obvious way, and we'd be concerned about that. Therefore, look at whether and how the site tunes the protocol interaction.

<ninja> I want to end up constraining these uses of cookies with unique identifiers

David: lets look at data that is exposed to the sever and data that it collects

<tlr> (e.g., eTags, last modified date and cache-control headers, ...)

David: associating people's name with IP addresses
... certain data should not be passed with DNT
... can we look at data that is received versus data that is collected

<rvaneijk> just making ure that the test we are discussing does work out that custom header fields with unique identifiers are NOT standard protocol information. i.e. http://www.t-mobile.nl/corporate/media/pdf/asid-omi-cookbook.pdf

<jmayer> I agree with tlr, we need to be careful about etags, last modified, and other non-cookie protocol information that's set or solicited by a server.

Aleecia: just because you get the data doesn't mean that you need to store it in logs

Ian: Aleecia mentioned that we want broad adoption
... lots of servers do collection by default and changing this behavior can be difficult
... removing cookies can be difficult

<rigo> I think dsinger's argument was forgotten that amount of logging, retention is in function of the things you want to achieve

Ian: it might be useful to say that the information you get is okay and if you keep the data for a long period of time then some must be cut out

<npdoty> all the values in cookies are logged by default? I thought access.log just had IP, UA, etc.

Aleecia: it is better to remove data from logs than to modify Apache logs

Ian: everyone doesn't use Apache and there are many intermediaries

<dsinger> cookies only return data to you that you previously attached to the UA; the question needs to be where the data came from in the first place (e.g. from a non-DNT session)

Aleecia: if you make a change for data retention vs. data that is stored should be a big difference
... am i wrong

Ian: i believe so

shane: Yahoo represents several hundred thousand businesses that we represent
... most of them have no technical staff
... making those types of changes would be complex
... Yahoo won't do that for them
... this is a huge hurdle for them

Aleecia: what is difference between changing retention time and changing what we save

<rigo> I think we should define data/information controller before we continue this discussion

Ian: it is easier to dump logs after two weeks vs. changing collection

<bryan> My earlier point: Re the idea to limit retained protocol info to standards-based headers only (under a DNT:1 signal to 3rd parties), a note: custom headers are used by many sites/apps and devivces. For the "contextual content / ad serving" use case, dropping those headers will break a lot of deployed sites/apps. For example, an aspect of context is the user-agent/device that is making the request.

<bryan> For mobile devices, it is often necessary to identify the device make/model to ensure delivery of content that is compatibile with the device, using a custom header for that purpose, as the standardized headers do not provide the necessary info.

Ian: for a lot of companies it would be more natural to do a DNT check during log processing than changing what is collected

Aleecia: I still don't see a big difference

Rob: I want to add that if you want to use retention as a privacy safeguard look at what is needed for the communication

Aleecia: Is advertising a necessary part of the transaction

Rob: no
... i think advertising is too broad
... a lot of data is collected that is not necessary to display an ad

<npdoty> Bryan, I think we're talking about the retention of protocol information, not dropping custom headers or anything like that

Roy: for financial advertising accounting all data including IP are needed.

Aleecia: Peter walk through your text

Peter: I wrote what most web servers collect
... IP, UA, referrer, data time stamp, URL DNT flag, etags
... i wrote donw what servers collect out of the box
... Apache servers can be configured to collect more
... there are other things that can be collected
... there are issues such ast the order of the headers
... this can permit fingerprinting
... do we want to include the order of the header in the protocol
... do we want to include of the TCP data

Jonathan: we could draw a line that states we can collect TCP data

Thomas: You are describing the protocal vs. how the data is used

<WileyS> This approach is FAR too complex for us to resonably believe industry will be able to implement to this detail.

<jmayer> Really? It's difficult to make a modification to HTTP logging?

<jmayer> These technical challenges are an order of magnitude easier than the things the companies here accomplish on a daily basis.

<jmayer> My comment earlier: we could add a line where a company abuses protocol information, like TCP fingerprinting.

Roy: we are concerned about data that will lead to identifying the user

Ed: unlinkablility can be useful here
... if the stored data is unlinkable it is not our problem

<fielding> user. user agent, or device

<WileyS> Its the level of modification and the resulting downstream impacts that will be difficult to change. Obviously not difficult with someone of your skills Jonathan, but you're rare in that context. I believe it will be easier to education industry on what we're asking them to implement if we use higher order normative text and not specific header details.

Aleecia: according to Jonathan there are ways to use the data for fingerprinting
... as long as it is not being done we dont care

Janathan: I want to clarify that as long as we are using IP unlinkability is not on the table

<jmayer> We could also add a line, as Ed just suggested, where additional protocol information is not marginally linkable.

Tom: I agree that trying to narrow this too much is the wrong place to optimize.

<jmayer> E.g. the Accept header.

Tom: as long as you rotate logs every 6 12 hours the way the logs are processed is important

<amyc> +1

Tom: tweaking the servers should not be important

Ian: +1 to Tom.
... we should focus on when we are moving the data from logs

Aleecia: we have retention that shane and amy are concerned will be arbitrary
... so we should take that off the table
... what we do when processing is important

Tom: there should be a retention policy and make it very long
... two weeks should be good
... otherwise the period is peculiar
... even a really long time is a very short period

<npdoty> tl: longer than any log rotation period

Roy: I disagree
... two weeks is okay for large companies

<amyc> tom, are you referring to two retention periods, one for logs and one for purpose-specific processed data?

Roy: for small companies monthly is more realistic

Jonathan: I agree with Roy

<npdoty> Roy, are those mostly first-party servers?

Jonathan: I'm not sure how common that is for third parites

<fielding> mostly. yes

Jonathan: there should be an unlinkability requrement
... as long as the analytics report is there the logs can be rotated

Ian: that is not possible

<tl> amyc, No.

<rvaneijk> tekstproposal: a party must take reasonable technical and organizational safeguards to prevent unintential use of log data.

Ian: it is hard to say how many unique users you have over three weeks

Rigo: the retention period is indefinte
... so setting it to 6 weeks would be an outrageous achievment

<npdoty> pde: "we're making a huge concession here"

Peter: it wouldn't be impractical to modify Apache logs to say we won't keep specific data
... only for businesses with a large 3rd-party presence
... if it turns out that a two-week period is inconvenient then it okay to write a bit of code to resolve that

David: it is true that the amout of work you need to do for DNT shoud be proportional to the amount of data you collect

<bryan> Can Apache be easily configured to output a special log file format (or to a special log file) based upon the presence of a specific header? Can someone point to info on how this is done? I doubt how easy that would be.

<npdoty> singer: if you just have a web badge and don't care about tracking in any way, don't want to make that hard

David: small companies should not have to worry about DNT

<npdoty> ... grief should be proportional to the amount of effort you're putting in to tracking

Thomas: there are two discussions
... are we okay with data being stored
... can the data not be kept for specific uses
... people say okay
... where is the line
... are arbitrary timelines a good idea?

<bryan> David, are you saying that the Internet at large should pay the penalty (grief) for tracking by some sites?

Thomas: we may need to punt on being normative on these issues

<npdoty> bryan, I think that was the exact opposite of his point?

<bryan> great, i misunderstood

Rob: a party must make reasonable safeguards to prevent improper usage

<rvaneijk> Normative:

<rvaneijk> a party must take reasonable technical and organizational safeguards to prevent unintential use of log data.

<rvaneijk> Non normative:

<rvaneijk> retention time is a safeguard

shane: rob stole my thunder

<rvaneijk> un-linkability

<rvaneijk> k-anonimity

shane: we are becoming too prescriptive and focusing on wrong areas
... we should look at permitted usage, but we are focusing on collection
... this conversation is not helpful to the outcome
... the normative language should provide options for companies

Aleecia: we have not spent enough time on this area
... once we figure this out we will look at text proposals

Tom: the problem with non-tracking not worrying about DNT is systems are setup to do tracking all the time

<npdoty> <IIS/ISS confusion>

Tom: there should be a way to turn off tracking that they do by default

<WileyS> +1 for "a party must take reasonable technical and organizational safeguards to prevent unintential use of log data."

Bryan: i support PbD approach
... data collection is business-needs based
... we should be very careful not to interrupt work towards PbD by introucint Draconian rules

<npdoty> what does the room think about WileyS text: "a party must take reasonable technical and organizational safeguards to prevent unintential use of log data."?

<chapell> +1 for "a party must take reasonable technical and organizational safeguards to prevent unintential use of log data."

Jonathan: without careful best practices I am not comfortable with reasonably needed statements

<bryan> We have strong internal control on data use and retention that are business needs-based. This is a "Privacy by Design" approach as recommended by the FTC. We should be careful to not impact the positive efforts of companies that take such Privacy by Design steps, by imposting a draconian/inflexible set of rules on what can be logged and/or used. It is more important to promote the efforts of good players in the industry, rather than penalize them for the behavior

Jonathan: there can always be a reasonable explanation to keep logs for 18 months

<ninja> please note that "reasonable safeguards" is interpreted as state of the art safeguards by DPAs and courts.

Jonathan: there should be degrees of requirements
... defend degree of needs
... provide total transparency

<rigo> necessary is the key word that worked in the EU for years

Jonathan: weeks or maybe months is okay, but not 18

Ian: the way that a lot of large services are deployed is there are thousands of web servers doing logging
... data is copied to other locations

<chapell> been following via IRC - not in DC

Ian: doing minimization on these servers is a non-starter
... once data is stored in a central localtions lots of decisions are made on the data
... we should get to a point that we can say what we collect for a short amount of time is okay, and talk about if we persist data collected from logs what is allowed

David: lets look at latest questions. Only persist data to satisfy a use
... you are responsible for preventing the data for unpermitted uses

<jmayer> ifette, are you asking for a *specific* short-term time period where all use is allowed?

David: can we apply that to logs?
... maybe we can use same principles to raw log data collection
... justify why you kept it and for how long

<rvaneijk> +1 dsinger

Jeff: Great discussion

<WileyS> +1 dsinger

Jeff: online ad principles is data maximization
... this discussion is critically important

Alex: need to change normative text to explain unintentional usage

<Chris> I just want to bring the point that ALL this information (F-capping, financial logging, 3rd party auditing, contextual content, ad serving) is related to the impression delivery, which is the "currency" (it's what's paid for), THUS it all must be retained for SOX compliancy in the US (at least 7-years)

<justin> Agree with jchester2 that this discussion has been very useful

Aleecia: lets do ten minutes where we think lines are between data collected and usage
... we are talking about log file information

<WileyS> Discussion is good, prescriptive, field specific protocal collection limits are not

Peter: we can look at cookies, but not high entropy cookies
... though we use same first and third-party domain name we need to mind the tracking with cookies

<Chris> is there an exception proposed for legally required data retention (i.e. SOX compliancy in the US)?

Aleecia: looking at FB
... how do we deal with sometimes first party and other times third party?

<dsinger> For the record: so basic 'rules' for processed data retention seem to be roughly (a) only for a permitted use (b) minimized to the data needed to meet that use (c) retained only until the use is satisfied/met (d) you are responsible for ensuring the data does not get used for any other use. A permitted use needs to be specific enough to enable both the minimization and retention to be definable (by a business) and justifiable; we can't have 'vague' permitted

<dsinger> uses that don't enable a business to define both the data needed and the term needed. We can now apply these rules to the 'raw log retention' - you should be able to justify the data logged (minimization) and how long (until all processing needs are met), based on what processing you are going to apply to it.

Peter: there needs to be different domains

<WileyS> +1 on impossible migration problem

<WileyS> +1 DSinger's proposed text

Jonathan: we are starting from the point that there is a base set of information that we get to colelct
... without moving into linkable or identifiable cookies, the question is what do we get to use the data for

<Chris> we need to decouple retention time and permitted use

<justin> dsinger, can we add (e) the retention period(s) disclosed

Ian: i thought you were saying from the short term information what do I get to use not what may one do with the data during a two week period

<npdoty> I thought we were talking about ifette's first part

Aleecia: we should look at that after break

<justin> dsinger, sorry, that got cut off: (e) the retention period(s) must be publicly disclosed (easily discoverable)

<rigo> I haven't discussed the arbitrary use for 2 weeks

Aleecia: I was assuming that a company had two weeks to process logs, not that one could do whatever they wanted during the two weeks

Tom: I do not believe that the time before logs are deleted is a free for all

<justin> Even the DAA principles don't have a free-for-all period

<dsinger> justin - ok, this is rough text and we should smith it

Tom: you just get two weeks for process for permitted usage

Peter: it would break everything just cost more to implement

<WileyS> This is why attempting to discuss log collection in isolation is not useful. Permitted uses should apply from the moment of collection.\

<npdoty> tl: not a free-for-all during the two week period, just that you don't have to process/minimize within that two week period

<amyc> we should get grounded in accepted practices, there are existing materials there

<npdoty> pde notes that facebook actually already uses a different domain for 1st and 3rd party content

Rigo: We need to discuss market research

<pde> so they can indeed blank their 3rd p cookies without blanking the 1st p ones

<dsinger> I don't think we need a specific interval; if someone reads in your policy "we keep raw logs for 10 years" you are on the hook to explain why - and it had better be (really) good!!

Rigo: free flow is way beyond our discussion

Jonathan: at the moment raw logs are touched then rules apply
... for short period logs can be used for lots of stuff, maybe anything you want for a short time

Aleecia: let's take a half hour break

<npdoty> thanks to JC for scribing a difficult session

<chapell> +1 to David - "I don't think we need a specific interval; if someone reads in your policy "we keep raw logs for 10 years" you are on the hook to explain why - and it had better be (really) good!!"

<Chris> FYI: Sarbanes-Oxley requires that strict records retention policies and procedures must be in place, but it does not specify a specific data storage format. It does require corporate officers to institute internal controls on their information to ensure completeness, correctness, and quick access. One exception to the specifics: accounting firms are specifically mentioned in Sarbanes-Oxley. The act calls for accounting firms that audit publicly-traded companies to

<Chris> The act calls for accounting firms that audit publicly-traded companies to keep related audit documents for no less than seven years after the completion of an audit. Violators can face fines of up to $10 million and 20 years in prison.

<rigo> ============================

<npdoty> scribenick: rigo


Privacy changes of users and industry changes for privacy, all synthesis

AM: what are users changes from current state to Shane's proposal

<npdoty> how does privacy situation change for users who turn on DNT?

WileyS: with DNT=1 a user profile wouldn't used to influence user interaction and also no sharing with other partners.
... will narrow down to uses on that interaction to keep that running

<npdoty> npdoty: when we don't add data to a profile/dossier, does that mean that data isn't stored with identifiers in such a way that they can be joined into a profile? or just that they're not combined together in the same table?

<npdoty> WileyS, as I understand your response, you're saying that it's the latter, profile/dossiers aren't created in the sense that the data isn't combined in the same data table, yeah?

jmayer: relevant characteristics is to avoid recording browsing history
... IP and UA are sufficient to track

<npdoty> jmayer: significantly greater privacy risk to users when there's more unique IDs

jmayer: marginal difference is no unique IDs. Privacy risk if companies collect uniqueID cookies. Forms of business that can be accomplished through unlinkable data are fine

WileyS: what is the risk delta.
... primary risk .. our proposal is vulnerable to governmental attack
... governmental risk should be addressed by citizens

<amyc> so can collect IP address (could be unique ID) but not unique cookie identifier, right

<npdoty> no meaningful security breach risk for ad networks?

<dsinger> s/SW/WileyS/

pde: rogue employees. intrusions, also businesses that pretend to do DNT

<amyc> Peter argues for auditability by users via not placing cookies

pde: if there are still tracking cookies and just use limitation, than we have no way to see what they do

aleecia: what about fingerprinting

Rob: compliance delta on the table. In favor of Peters suggestion. Have to see which version of DNT will fly, Tom's version is much more likely to compliant

Roy: implemented version of DNt is what counts
... we will never reach consensus on ID setting as you need it for fraud control

aleecia: : marginal changes on implementation
... what would take to implement that

JM: focusing on cookies? or protocol info too?
... knock off uniqueID cookies...

discussion between TL and JM

<npdoty> aleecia: for the eff/jmayer/moz proposal, what would it take to implement?

MarcG: some things opposed and some things similar
... talking about risks is the creation of a profile.
... taking information out of logs and put it into profile ceases to happen.
... that's what we try to achieve

<npdoty> what do we mean by "creation of a profile"? again, does that mean that there's still a unique ID that combines all of that data?

pde: if you can query that data years later and combine them and that's a profile, then we agree
... if it is just about not targetting in ads, than we are far from each other

TL: implementation is simple: don't share information with others of information that you get from users on your site, aggregate all within two weeks and you're done

jmayer: just stop doing most of the things you do. ...

<tl> s/"aggregate all"/"aggregate all logs from your third party objects"

jmayer: get rid of uniqueID if you receive of opt out. allready 50% of companies do that

<npdoty> jmayer: for simpler cases (hosting a badge, say), you could just change logging or remove cookies

jmayer: second step is what to do with protocol information
... there may be areas where it needs re-engineering, e.g. IP based frequencey capping, unlinkable data exception..
... some loss in functionality, but can get that back by re-engineering
... e.g. those being dependend on uniqueID cookies

<bryan> "re-engineering" is a very broad/fuzzy impact.

AmyC: you focusing on number, many different business models in the room.

<Chris> what kind of "re-engineering" would replace cookie based F-capping exactly?

AmyC: logins, cookies, analytics, so requirements may be much more substantial

jmayer: about analytics services: Some will not have to change a lot. Adobe siloing data, making representation to customers and public.

Roy: but still setting uniqueIDs

jmayer: outsourcing ok, and first party can use uniqueID

fielding_: important part is backend, we do not keep the information in the backend, only segregated by customer

jmayer: if Adobe silos collection and retention, than its fine

HeatherWest: user get analytics cookie and can opt out

jmayer: you could link the opt out cookie to DNT
... for social networks widgets, because we focus on collection. They would have to segregate identifiers
... effect for user, you would see an unpersonalized widget

<Zakim> dsinger, you wanted to give a point of view on what cookies are

dsinger: what is a cookie, it is data that originates from server. cookie is an extension from the sites database
... you may want to include cookie data in the extensions

<dsinger> so a cookie is much more like an extension/part of the site database, than part of the protocol

Chris: some re-engineering to do frequency capping without cookies
... what would the re-engineering imply?

jmayer: yeah! have a solution

WileyS: see mailing-list
... NAI users not 50% rather 20%. And they do use alternate means to preserve their business without unique IDs
... also, it is not "some" re-engineering, it is "major" re-engineering possibly from scratch

AM: how much is WileyS proposal easier than jmayer's

<Chris> yes, agree, it would be major re-engineering

<npdoty> equating DNT use with existing self-regulatory opt-out, but persistent

WileyS: it is using DNT to perform the trigger of our opt out regimes that we already have implemented
... attach into opt-out system

<Chris> not sure client side f-capping is accurate or scalable

WileyS: more of a deployment issue
... scale: 2-6 weeks dev circle, than into a train to be implements

AM: how different are those? Can we figure out what the differences look like and see how far apart we are.
... changes for privacy are so far apart

pde: if DNT is implemented in a way that a lot of uniqueID cookies are used, the privacy gain is minimal

Roy: issue is not collecting that data, but retaining that data

<dsinger> ...and dave would add, associating that identifier with data (and whether that associated data is permitted or not)

jmayer: issue of outsourcing, ID scoped on first parties.

<ninja> I would like come back to the proposal of johnsimpson - who was objected to frequency capping for DNT1 users at all. I agree.

<dsinger> fielding_: also associated with freq capping

aleecia: ask the authors to hash out what the marginal differences between the proposals are


Fraud and Cookies

jmayer: company would be able to use protocol logs retained over a certain period of time. IETF group allowed for longer time
... companies have in practice be isolated from the rest of the business
... protocol information is available, enables attack detection. wanna make sure legitimate security concern does not swallow the privacy gain

<Zakim> dsinger, you wanted to talk about what happens when cookies aren't used

dsinger: removing cookies deplaces the problem into harder places to manage

<npdoty> dsinger: moving cookies off the table might lead to sophisticated fingerprinting which might be even harder to detect

pde: fingerprinting javascript calls to do fingerprinting are known
... announcing DNT ok and doing fingerprinting is a giant red flag

ifette: only collect data for fraudulent is if you discover, you go back into your logs and see what happened. What other actors acting at the same time

<Chris> great point about fraud detection-- you have to see it in logs over time

pde: we tried to write down what the engineers said: If we have six month of protocol log than we can manage

iefette: 6 month is a big IF

<npdoty> s/PE:/pde:/

bryan: is that tied to a specific incident or things that you have to keep in place (this is potential harmful actor etc)
... national carriers have some reponsibility

<npdoty> aleecia: again, we're only talking about third parties, fewer national security issues with advertisers

jmayer: perhaps 2 parts to that question.
... a service persistently under attack and other is uniquely sensitive circus
... fix exploits

aleecia: anon announces that they target your service. Now would that alter your approach

<bryan> The essence of my comment was: Does "a specific concern" mean a specific incident (e.g. breakin or fraudulent act), or something more on-going, e.g. "this service is commonly susceptible to fraud/attack"?

<Chris> most reliable fraud/threat detection uses pattern analysis algorithms that sort through historical data (logs), over long periods of time, to identify fraudulent/nefarious trends; if we limit the log data that can be analyzed, don't we cut off our nose to spite our face?

jmayer: we are only targetting a particular user or user agent. It doesn't takes into account if the entire service is into account

tl: cookies and fingerprinting to security, servers is not distinguishable

mikez: one issue for later discussion: only talking about third parties, how carriers are defined, ISPs are those first parties

<bryan> The reference to the 1st party responsibility to safely/reliably operate a network was an example, understood as outside the scope of this particular case (3rd parties) but illustrative of types of ongoing security concerns that in other examples could apply to 3rd parties.

<npdoty> do we have an issue open on carriers/ISPs and how they handle/respond to a DNT signal?

<npdoty> issue-132?

<trackbot> ISSUE-132 -- Should the spec speak to intermediaries or hosting providers to modify any responses/statements about DNT compliance? -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/132

fielding_: couple different aspects on fraud control. Mainly to discover patterns for fraud that is going on. But also discover fraud before it occurs, and this uses third party data some times
... mesh up the data from sources and hypthetic fraud case, you would apply a different higher level process

<Zakim> dsinger, you wanted to say that trying to 'read tea leaves' on compliance is a tar pit

dsinger: we should not guess what makes a site fraudulent. If you do not trust a site, don't use it

<pde> fielding_, I'm sorry you got cut off there

<pde> I was hoping to hear the end of your answer

<dsinger> trying to guess whether a site that claims compliance, is in fact in compliance, by watching how they behave, is a tar pit for us

<ifette> sorry, didn't mean to cut roy off

tl: DNT is about influence databases that I do not control or know about. Basically users turn on DNT to avoid the Panopticon
... we are storing and creating the panopticon all the time, bad result

<fielding_> and we are back to the definition of collection

<pde> ifette, when we create private spaces in the real world, we close the doors and pull the blinds

<ifette> do you pay in cash at the grocery store using no loyalty cards?

<ifette> out of curiosity?

<dsinger> aleecia: can we do fraud detection etc. without using identifiable cookies?

<pde> ifette: indeed I do

<ifette> you are quite special :)

<sidstamm> ifette, you *can*

<pde> I have to respect the price that Safeway will pay for private data though.

<ifette> sid, and you can open an incognito window as well (or a private browisng window etc)

<WileyS> pde, You can also avoid the internet - problem solved

<dsinger> dsinger wonders if aleecia's question is in scope? you can set a unique ID and associate it with very little data, for example. it's the associated data that is the 'track'

<npdoty> ifette, can fraudsters open incognito windows?

<justin> WileyS, or more like, just block all third parties. Would hope people agree that's not the ideal outcome.

<pde> WileyS: "Yahoo!'s advice: if you want real privacy, avoid the Internet" ;)

<rvaneijk> in EU a permitted use (even when DNT is on) has to pass a simple test which is called the legitimate business interest test:

<rvaneijk> 1a is the processing proportionate

<rvaneijk> 1b. can it be done in another way

<sidstamm> ifette, how well does the incognito window work if it's always active?

<rvaneijk> 2. what is the impact on the privacy of the user

<rvaneijk> outcome => unique ID possilbe

<ifette> nick, sure, and you see that they are coming with no cookies and htat's potentially useful information to you

but purpose limitation

<ifette> sid, compared to what?

<pde> WileyS, Verizon actually said that on the record

jmayer: have to better understand how to do more security with less personal information

<sidstamm> ifette, lets take it offline

<ifette> sidstamm, beer

<sidstamm> \o/

<npdoty> ifette, can industry fraud teams treat DNT users like incognito users? (i.e. use that as a signal, although not the signal of a persistent unique identifier cookie?)

<justin> I think the eventual language will (and should) closely mirror what rvaneijk just said.

<WileyS> pde, Not what I said - but close. If you are unable to manage cookies directly (fairly low knowledge bar) the next best way to avoid unique IDs in cookies is to avoid web sites that use them

<jmayer> My point was that we need to understand exactly what the marginal impact on security and fraud prevention is.

jchester2: I want to hear specific responses on the proposal from mozilla

<jmayer> Many companies currently allow users to opt out of a unique ID cookie and still accomplish security and fraud prevention.

WileyS: I tried to respond to this on hte mailing-list

<ifette> npdoty, i feel like we're conflating the two

WileyS: malware protection, filtering

<ifette> npdoty, there are still uses for incognito windows / private browsing / ...

WileyS: use cookies and uniqueID are useful to detection
... losing this abilities and making DNT a trigger

amyc: about malware, this is critical use of IDs

<WileyS> jmayer: not "many", rather "few" in reality

aleecia: would be good to have a conference call on security with the entire group

<npdoty> pde: do you have higher attack rates related to Safari users?

aleecia: not necessarily present, and have security experts present

<dsinger> WileyS: yes, to some degree

<jmayer> Shane, I've done research on this very topic. You are wrong. Many ad companies drop their unique ID cookie when a user opts out.

<fielding_> jmayer, the web is more than ad companies

<Chris> due to the very sensitive nature of their work in discovering and preventing fraud, security experts are not going to be super willing to share much, if any information about their methods

<fielding_> so is Y!

<jmayer> Roy, I agree that we need to talk about non-ad third parties.

<jmayer> FYI, here's my research on cookies NAI members leave after opting out: http://cyberlaw.stanford.edu/node/6694

aleecia: going with WileyS only would make privacy advocates unsatisfied, going with jmayer and tl and pde only would leave the industry clueless on how to implement, so have to compromise more

<Chris> I lead with the IAB's Consumer Protection Taskforce, a group of industry security experts that works on anti-malvertising; this group does not loosely share methodology

<scribe> scribenick: rvaneijk

looking at raised isues now

raised issues and changes in status


<trackbot> ISSUE-26 -- Providing data to 3rd-party widgets -- does that imply consent? -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/26

promoted to open

<asoltani> lima lounge = walk out, turn right, walk 4 blocks towards 14th street. embibe


<trackbot> ISSUE-59 -- Should the first party be informed about whether the user has sent a DNT header to third parties on their site? -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/59

shunter: the assumtion was normally DNT all over the place, now you do only send header + also what header

tl: thought this is dealt with in the exception api

rigo: TPE


<trackbot> ISSUE-60 -- Will a recipient know if it itself is a 1st or 3rd party? -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/60

dsinger: will a receipiant know or will a recipient be told ?

tl: answer is already present in the spec, issue is closed

<bryan> Can Tom point to the place in the spec where this is explained?

pde: takes action item.

<pde> WileyS, can you point me to a thread or two?

pde: to review the spec and make sure that the text intended is in the spec. + coordinate with tl


<trackbot> ISSUE-66 -- Can user be allowed to consent to both third party and first party to override general DNT? -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/66

aleecia: answer is yes. issue closed.

<tlr> issue-66 closed

<trackbot> ISSUE-66 Can user be allowed to consent to both third party and first party to override general DNT? closed


<trackbot> ISSUE-67 -- Should opt-back-in be stored on the client side? -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/67

<tlr> jonathan: issue-67 overtaken by events

<tlr> dsinger: overtaken by events

schunter: close it, because assupmtion is part of the exception API

<tlr> issue-67 closed

<trackbot> ISSUE-67 Should opt-back-in be stored on the client side? closed

<tlr> issue-72?

<trackbot> ISSUE-72 -- Basic principle: independent use as an agent of a first party -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/72


<trackbot> ISSUE-75 -- How do companies claim exemptions and is that technical or not? -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/75

rigo: if you have out of band, then you have to send a response header. This is not in the spec yet, therefor open issue.

WIleyS: agreemment, details need to be worked out.

<dsinger> maybe change the issue to "signal a claimed permitted use" :-)?


<trackbot> ISSUE-83 -- How do you opt out if already opted in? -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/83

<fielding> not necessarily a response header -- the consent is noted in the response (wherever that response is given)

tl: uri specifies whether user has opted in

rigo: if you received a DNT header yesterday, and today new DNT header, then the newer header should overwrite.

tl: indeed

dsinger: lots of difficult questions in here.

rigo: this is DNT thing.

WileyS: is is TPE

issue-83 open


<trackbot> ISSUE-92 -- If data collection (even very specific with IP address, user agent, referrer) is time-limited, with very limited retention, is that still tracking? -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/92

<tlr> issue-92: subsumed by other issues, don't touch with 10 ft pole

<trackbot> ISSUE-92 If data collection (even very specific with IP address, user agent, referrer) is time-limited, with very limited retention, is that still tracking? notes added

issue-92 closed

<trackbot> ISSUE-92 If data collection (even very specific with IP address, user agent, referrer) is time-limited, with very limited retention, is that still tracking? closed

<tlr> issue-92 closed

<trackbot> ISSUE-92 If data collection (even very specific with IP address, user agent, referrer) is time-limited, with very limited retention, is that still tracking? closed

<tlr> npdoty: do we have an issue about short-term storage as discussed this morning?


<trackbot> ISSUE-93 -- Should 1st parties be able to degrade a user experience or charge money for content based on DNT? -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/93

<tlr> aleecia: good point; we should have an issue against that

WileyS: answer is yes

<tlr> issue-93: group agrees answer is yes

<trackbot> ISSUE-93 Should 1st parties be able to degrade a user experience or charge money for content based on DNT? notes added

<tlr> issue-93 closed

<trackbot> ISSUE-93 Should 1st parties be able to degrade a user experience or charge money for content based on DNT? closed

WileyS: these are first parties.

<tlr> johnS: disagree, but move on closing this

<dsinger> it may be imprudent, but alas, they can do whatever they like


<trackbot> ISSUE-94 -- Is "Do Not Track" the right name to use? -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/94

aleecia: status to postponed


<trackbot> ISSUE-97 -- Re-direction, shortened URLs, click analytics -- what kind of tracking is this? -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/97

aleecia: good text from justin

<npdoty_> ISSUE: would we additionally permit logs that are retained for a short enough period?

<trackbot> Created ISSUE-134 - Would we additionally permit logs that are retained for a short enough period? ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/134/edit .


<trackbot> ISSUE-99 -- How does DNT work with identity providers? -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/99

ifette: use case of facebook connect

jmayer: some SSO will continue to collect information

issue-99 open

fielding: agrees with jmayer

dsinger: now first party?

<tlr> action-159?

wileyS: we have text.


<trackbot> ACTION-159 -- David Singer to draft shorter language to describe conditions for consent (with npdoty) -- due 2012-04-24 -- OPEN

<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/159

<npdoty> dsinger: what happens when a user visits a site and is already logged in to the identity provider? are they still a first party?


<trackbot> ISSUE-102 -- Short names & titles of specifications -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/102

<tlr> action-157?

<trackbot> ACTION-157 -- Shane Wiley to update logged-in consent proposal by April 24 -- due 2012-04-24 -- OPEN

<trackbot> http://www.w3.org/2011/tracking-protection/track/actions/157

<tlr> shane -- this one?

<dsinger> if I visit BogVille Chron who use Twitter as an identity provider, and I am already logged in, so I don't interact then with Twitter, is Twitter then 1st or 3rd party?


<trackbot> ISSUE-103 -- We're not sure where the exceptions should be and ensure they are categorically captured in the base 3rd party prohibition statement. -- raised

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/103

aleecia: this is overtaken by events -> close issue

<npdoty> dsinger, +1, I think that's important

now moving on to pending review...

<tlr> issue-99: see also issue-152 and related text in http://lists.w3.org/Archives/Public/public-tracking/2012Apr/0112.html

<trackbot> ISSUE-99 How does DNT work with identity providers? notes added


<trackbot> ISSUE-49 -- Third party as first party - is a third party that collects data on behalf of the first party treated the same way as the first party? -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/49

<dsinger> s/mooving/moving/

<dsinger> :-)

<rigo> we should raise an issue about it


<trackbot> ISSUE-14 -- How does what we talk about with 1st/3rd party relate to European law about data controller vs data processor? -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/14

<npdoty> for those interested in context for issue-103, the discussion was whether the compliance spec should have language for a broad prohibition on practices and then a list of exceptions, or organized otherwise, as in http://www.w3.org/2011/11/23-dnt-minutes

<tlr> ACTION: Shane to work on issue-49 - due in 3 weeks [recorded in http://www.w3.org/2012/04/11-dnt-minutes.html#action01]

<trackbot> Created ACTION-161 - work on issue-49 [on Shane Wiley - due 1970-01-01].

<tlr> action-161 due 2012-05-07

<trackbot> ACTION-161 work on issue-49 due date now 2012-05-07

<npdoty> "Global Best Practices" as the product/document name?

WileyS: best practices document,showing how DNT maps to different frameworks
... some of this will change depending on the outcome of these days.

dsinger: it is a non normative document

rigo: object to anything having legal in the name

<npdoty> "Global Considerations"?

tlr: global considerations

<npdoty> (at this point, I would take just: "Practices")

jchester2: bill of rights interpretation, is negotiated very soon.

aleecia: people have volunteerded to work on the document (Brussels)

<npdoty> aleecia: as long as we're not taking away time from the group, but we have expertise and interest in the room

<npdoty> https://www.w3.org/2011/tracking-protection/track/products/4

issue: draft Global Considerations document

<trackbot> Created ISSUE-135 - Draft Global Considerations document ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/135/edit .


<trackbot> ISSUE-52 -- What if conflict between opt-out cookie and DNT? -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/52

<fielding> the nice thing about non-normative docs is that they don't require consensus and can include multiple opinions

aleecia: any comments on the draft text?

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

aleecia: compliance spec section 5.3 ?

<npdoty> ACTION: newland to remove note from section 5.3, now that we have consensus [recorded in http://www.w3.org/2012/04/11-dnt-minutes.html#action02]

<trackbot> Created ACTION-162 - Remove note from section 5.3, now that we have consensus [on Erica Newland - due 2012-04-18].

<npdoty> fielding: not sure I actually understand that section

Interaction with existing user privacy controls

As multiple systems may be setting, sending, and receiving DNT and/or Opt-Out signals at the same time, it’ll be important to ensure industry and web browser vendors are on the same page with respect to honoring user choices in circumstances where "mixed signals" may be received.

As a general principle, more specific settings override less specific settings.

No DNT Signal / No Opt-Out: Treat as DNT unset

DNT Signal / No Opt-Out: Treat as DNT:1

Opt-Out / No DNT Signal: Treat as DNT:1

Opt-Out / DNT User-Granted Exception: Treat as DNT:0 for that site; DNT User-Granted Exception is honored

NOTE: The above text will need to be modified to include the appropriate terminology as this is decided upon by the working group. For example, DNT User-Granted Exception would need to be replaced with "Site-Specific Exception" depending on the outcome of that discussion.

fielding: will provide replacement text...

<npdoty> ACTION: fielding to explain confusion or an alternative to text explaining the interaction with existing user privacy controls [recorded in http://www.w3.org/2012/04/11-dnt-minutes.html#action03]

<trackbot> Created ACTION-163 - Explain confusion or an alternative to text explaining the interaction with existing user privacy controls [on Roy Fielding - due 2012-04-18].

aleecia: text need editorial work


<trackbot> ISSUE-65 -- How does logged in and logged out state work -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/65

<npdoty> action-163: related to issue-52

<trackbot> ACTION-163 Explain confusion or an alternative to text explaining the interaction with existing user privacy controls notes added

-> open


<trackbot> ISSUE-98 -- Should we consider applicable laws and regulations, such as the Article 5, paragraph 3 ePriv Dir -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/98

to be dealt with in GLobal COnsiderations


<trackbot> ISSUE-30 -- Will Do Not Track apply to offline aggregating or selling of data? -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/30

<tlr> action-164: duplicate of action-163

<trackbot> ACTION-164 Provide replacement text for issue-52 notes added

aleecia: is the answer we do?

npdoty: was the proposal to not have additional text?

aleecia: amy did not provide text.

currently closed

<npdoty> ACTION: fette to draft example text around using the Geolocation API for non-normative text on "Geolocation compliance" section in Compliance [recorded in http://www.w3.org/2012/04/11-dnt-minutes.html#action04]

<trackbot> Created ACTION-165 - Draft example text around using the Geolocation API for non-normative text on "Geolocation compliance" section in Compliance [on Ian Fette - due 2012-04-18].


<trackbot> ISSUE-39 -- Tracking of geographic data (however it's determined, or used) -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/39


<trackbot> ISSUE-19 -- Data collection / Data use (3rd party) -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/19

issue-19 closed

<trackbot> ISSUE-19 Data collection / Data use (3rd party) closed

<tlr> issue-19: handled elsewhere

<trackbot> ISSUE-19 Data collection / Data use (3rd party) notes added


<trackbot> ISSUE-16 -- What does it mean to collect data? (caching, logging, storage, retention, accumulation, profile etc.) -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/16

aleecia: text that went to the mailling list

WIleyS: we do not address what is 'collection'

dsinger: there is a different to being exposed to data and using the data

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

wileys: if it hits a webserver, is that collection or not?

rigo: as soon as there is storage involved we are confronted with collection

<npdoty> WileyS, is that a suggestion that you want "receives" to mean that data that is received but purged?

rvaneijk: collection is receiving with the intention to storing..

<npdoty> ACTION: west to draft updated text on definitions of "collection" and similar terms "Data collection, retention, use, and sharing" (with fielding) [recorded in http://www.w3.org/2012/04/11-dnt-minutes.html#action05]

<trackbot> Created ACTION-166 - Draft updated text on definitions of "collection" and similar terms "Data collection, retention, use, and sharing" (with fielding) [on Heather West - due 2012-04-18].


<trackbot> ISSUE-28 -- Exception for mandatory legal process -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/28

<Chris> technically speaking, the terms collection and storage are inherently connected-- you can't have one without the other

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

<Chris> if you collect, the moment you do so, you store

<Chris> if you store, you have collected in order to store

<Chris> I think what you want to define is duration of collection and intended use

<npdoty> Chris, does that mean we should use "collect" and "retain" interchangeably?

<Chris> as soon as you collect, you retain

<Chris> retain should be defined more precisely by duration

<fielding> it is not just storage -- it is storage associated with a user/agent/device

<rvaneijk_> +1 fielding

<npdoty> fielding, storage not associated with a user/agent/device is just storage of unlinkable data, right? do we have to change the definition of "storage" or "collection"?


<trackbot> ISSUE-21 -- Enable external audit of DNT compliance -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/21

<jmayer> I'm not thrilled with the text on legal compliance - it's pegged to a few specific legal constructs.

take this conversation on a call

<jmayer> So long as the understanding is, essentially, voluntary vs. mandatory legal obligations.

<Chris> legal compliance is jurisdictional


<trackbot> ISSUE-25 -- Possible exemption for research purposes -- pending review

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/25

<jmayer> Voluntary in the sense of the law allows saying no, even if it may not be in business interests to say no.

<Chris> all legal compliance is voluntary; but if you don't comply, you are subject to the penalty of laws for which you are not complying

<scribe> scribenick: vincent_

issue-5 ?

<trackbot> ISSUE-5 -- What is the definition of tracking? -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/5

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

aleecia: still an open issue

<npdoty> three different options are in the Compliance editor's draft

tl: if some fraction of the group want to add it to the doc and some want not, does it happen or not

<fielding> npdoty, I mean that the notion of data collection (the term used by regulators) is distinct from storage because it is specifically about data linked to a user/agent/device

aleecia: moving on


<trackbot> ISSUE-6 -- What are the underlying concerns? Why are we doing this / what are people afraid of? -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/6

<npdoty> fielding, so "collecting data that can't reasonably be linked to a particular device" is an oxymoron? it seems like a sensible phrase to me, fwiw

aleecia: unless anybody object, we're geting this close

<fielding> I know, which is why we need to define it. ;-)

johnsimpson: introduction pretty good, agree to close

rigo: should we mention westling (who defined the notion of personal dossier)

npdoty: would additional text help people understand if so we should leave issue open

rigo: will to take on action to take a pass on the introduction

johnsimpson: the introduction was first in the compliance doc and is now in both

<Chris> how about we just add a "reading list" of documents submitted voluntarily that relate to the subject of DNT?


<trackbot> ISSUE-10 -- What is a first party? -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/10

<npdoty> ifette, you're one of the people who told me that you thought having a consolidated list of our privacy concerns would improve our discussions of the other sections. would you agree that it would help to have consolidated text here?

aleecia: covered in proposed text

WileyS: no big difference express on that one yesterday
... all draft proposal share a common view on that

issue-10 closed

<trackbot> ISSUE-10 What is a first party? closed


<trackbot> ISSUE-31 -- Minimization -- to what extent will minimization be required for use of a particular exemption? (conditional exemptions) -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/31


<trackbot> ISSUE-54 -- Can first party provide targeting based on registration information even while sending DNT -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/54

fielding: I thought issue-54 was closed

<npdoty> we agree on the important basic outline of first parties as the same between open proposals


<trackbot> ISSUE-69 -- Should the spec say anything about minimal notice? (ie. don't bury in a privacy policy) -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/69

<npdoty> but still need to work out the exact text

tl: that's open


<trackbot> ISSUE-71 -- Does DNT also affect past collection or use of past collection of info? -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/71

WileyS: we have a draft, currently text, agree that it MAY affect prior but not MUST

<npdoty> agreement among parties that dnt may but not must affect handling of past collection, but haven't detailed exact wording

aleecia: is this also working in EU

brian: use of prior collective data is blocked

<npdoty> rigo: there are use cases where users turn on DNT temporarily and then want that profile to come back when they turn DNT back off later

WileyS: the question is about getting to the data collected prior to dnt:1 and delete it

<npdoty> wording of issue 71 confusing

aleecia: the wording on it is not so good

<npdoty> agreement is on purging of prior data, rather than on using of previously collected data or retroactively preventing collection of data

jmayer: get a super concrete example
... user sent a unique ID and send DNT:1 should the website delete the profile

rigo: no, we can close it

npdoty: changing the title

tl: ok as long as it stays closed

issue-73 ?

<trackbot> ISSUE-73 -- In order for analytics or other contracting to count as first-party: by contract, by technical silo, both silo and contract -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/73

WileyS: three open issue on that problem


<trackbot> ISSUE-88 -- different rules for impression of and interaction with 3rd-party ads/content -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/88

WileyS: this is the meaningfull interaction, captured in another issue
... we all agreed and it did not make it in the final text

<npdoty> new title for clarifying: ISSUE-71: Does DNT require purging or modify data collected in the past (not under DNT)?

WileyS: the detail that we not closed on is about the brand
... facebook has proven that you can get away without brand

aleecia: it is brand

hwest: like button did not started as a brand but it is now

efelten: user knows that they are interacting with someone else that the first party

<npdoty> I think when the Like button first came out, all versions had an F logo http://www.insidefacebook.com/2011/04/21/like-button-birthday/

ifette: : if you are a smaller company, just getting started, branding is not that simple, hence facebook is a bad example

jmayer: it's possible there will be a 3rd party widget that is not branded
... twitter comes with tweet which is branded
... if you did not know that the like button was facebook's, why would you click it?
... tweet is sufficently related to twitter that if they click on it, they'll understand it's twitter

rigo: the discussion about branding & expectation is an area specific on
... the branding issue is trying to define a party even though we do not have define a party at all

<npdoty> we certainly have discussed the breadth of parties, although we haven't come to a conclusion on it

rigo: we did not agree on a definition of party (APEC or EU for instance)
... adopting the branding concept of party
... a party definition that relies on branding is US specific

<npdoty> Chris Pedigo this time, not Chris Mejia, sitting next to him

<jmayer> An important point here: clear branding or user expectations - for a user who clicks.

<jmayer> The relevant population is not the world at large.

aleecia: some people branding means you can say where it comes from

<jmayer> P(understand source | button design)

JC: are we talking about discoverable branding

<jmayer> vs. P(understand source | button design ^ click button)

aleecia: anyon object of leaving this open?

<npdoty> JC: for example, maybe hovering over a small button would tell you more about which company, etc.


<trackbot> ISSUE-89 -- Does DNT mean at a high level: (a) no customization, users are seen for the first time, every time. (b) DNT is about data moving between sites. -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/89

aleecia: addressed in the current proposal but leave it open



<trackbot> ISSUE-111 -- Signaling state/existence of site-specific exceptions -- open

<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/111

issue 111 move to TPE

<fielding> I was going to say that hyperlinks in text don't have branding and are considered first-party. There is no need for more restriction there.

<rigo> rob was on the Q too

<npdoty> Lima Lounge @ 14th & K (upstairs)

<npdoty> break for 30 minutes

<rvaneijk> Just wanted to remind that WileyS, Rigo and I have worked on a definition and proposed text for it: "A first party is who determines the purposes, conditions and means of the data processing"

aleecia: starting with a hum and then spliting in small groups

HUM for "if you have definition of Shane view of parties, could you not live with that"

<amyc> hum for cannot live with Jonathan (parties) and Shane (uses) is louder

huming for the different combination (Shane definition of parties and Jonahan definition of business)

quite loud

<vincent> ok I got it wrong, sorry

Aleecia: other hums appear to be evenly split
... breaking into small groups to discuss use cases
... different effects for users
... what harms are we trying to prevent

Ed: groups should be diverse

Aleecia: picks groups
... picks group leaders

Results of small groups on concerns

<amyc> Aleecia: reviewing results of small groups

<bryan> scribenick: bryan

amyc: we came up with 16 things. here are the highlights
... 1: having a copy of online reading / browsing history
... 2: ease of access to info by 3rd parties, gotvs, employer, family etc
... 3: use by others for bad purposes, things you do not want to be targeted for

4: diffuse things re online ecosystem, e.g. accuracy of data, online experience, losing access to low-price content (please check this)

<scribe> scribenick: amyc

Shane: also tried to highlight actual harm
... based on proposals, which were removed
... government access, inadvertatnt disclosure, internal bad actor, creepy or chill factor (harm to dignity), denial of employment/insurance, discrimination
... content exclusion (diminished diversity); modifying user experience based on sensitive data, secondary uses in violation of silent norms
... sharing or selling to 3rd party, unsolicited or annoying marketing

Tom: recorded selection of harm and grouped
... we then classified whether DNT could prevent, and measured on Shane and J porposals
... Consequences, somebody makes decisions about me, J may mitigate
... Sharing, site exposes to 3rd party
... both mitigate
... Collection, someone unknown retains info, neither mitigate
... Retention, someone unknown retains info, neither mitigates
... Info retained by others using devices
... Bad actors collect info, not sure what proposals have to say about that
... Company claims to honor practice, but does not, not something that DNT can fix
... Compliance and noncompliance looks similar enough on back end, DNT should fix, J proposal may fix, Shane does not
... Companies use means to bypass technical barriers I have used to prevent collection
... (1) company provides data to govt and (2) accidental data breach

npdoty: will consolidate discussion
... unknown party out of my control retaining data about me
... govt can request data, breach may lead to release of data, rogue employee
... distinction between how that was controlled within company, maybe OK if small team had access
... better if data was siloed and retained only for particular use
... knowing which ads were seen could tell you about user

Aleecia: at a high level, a lot of overlap, but different in particulars
... send lists to mailing list or IRC

<npdoty> Photos of our paper lists:

Paper lists of tracking privacy concerns -- 1 Paper lists of tracking privacy concerns -- 2 Paper lists of tracking privacy concerns -- 3

<tl> Our list is at https://pad.riseup.net/p/bYunX006EHqv, can someone post that to the list?

Aleecia: meeting tonight at Lebanese Taverna, take redline to Adams Morgan
... meet at 8 pm

Summary of Action Items

[NEW] ACTION: fette to draft example text around using the Geolocation API for non-normative text on "Geolocation compliance" section in Compliance [recorded in http://www.w3.org/2012/04/11-dnt-minutes.html#action04]
[NEW] ACTION: fielding to explain confusion or an alternative to text explaining the interaction with existing user privacy controls [recorded in http://www.w3.org/2012/04/11-dnt-minutes.html#action03]
[NEW] ACTION: newland to remove note from section 5.3, now that we have consensus [recorded in http://www.w3.org/2012/04/11-dnt-minutes.html#action02]
[NEW] ACTION: Shane to work on issue-49 - due in 3 weeks [recorded in http://www.w3.org/2012/04/11-dnt-minutes.html#action01]
[NEW] ACTION: west to draft updated text on definitions of "collection" and similar terms "Data collection, retention, use, and sharing" (with fielding) [recorded in http://www.w3.org/2012/04/11-dnt-minutes.html#action05]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2012/04/24 05:51:26 $