See also: IRC log
<npdoty> scribenick: ifette
Brill: key is choice
... 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?
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
... 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?
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
<rigo> ifette++ for good minuting
<asoltani> <rigo> ifette++ for good minuting - +1
<npdoty> scribenick: JC
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
... 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
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
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
<trackbot> ACTION-160 -- Peter Eckersley to work with Shane on common ground on unlinkability normative/non-normative text -- due 2012-04-24 -- OPEN
<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
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
... 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
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> 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
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.
<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?
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
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
... 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
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?
<trackbot> ISSUE-132 -- Should the spec speak to intermediaries or hosting providers to modify any responses/statements about DNT compliance? -- raised
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
<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 / ...
... 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
<trackbot> ISSUE-26 -- Providing data to 3rd-party widgets -- does that imply consent? -- raised
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
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
<trackbot> ISSUE-60 -- Will a recipient know if it itself is a 1st or 3rd party? -- raised
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
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
<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
<trackbot> ISSUE-72 -- Basic principle: independent use as an agent of a first party -- raised
<trackbot> ISSUE-75 -- How do companies claim exemptions and is that technical or not? -- raised
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
<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.
dsinger: lots of difficult questions in here.
rigo: this is DNT thing.
WileyS: is is TPE
<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
<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
<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
<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
aleecia: status to postponed
<trackbot> ISSUE-97 -- Re-direction, shortened URLs, click analytics -- what kind of tracking is this? -- raised
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
ifette: use case of facebook connect
jmayer: some SSO will continue to collect information
fielding: agrees with jmayer
dsinger: now first party?
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
<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> ACTION-157 -- Shane Wiley to update logged-in consent proposal by April 24 -- due 2012-04-24 -- OPEN
<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
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
<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
<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
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
<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?
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
<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
<trackbot> ISSUE-98 -- Should we consider applicable laws and regulations, such as the Article 5, paragraph 3 ePriv Dir -- pending review
to be dealt with in GLobal COnsiderations
<trackbot> ISSUE-30 -- Will Do Not Track apply to offline aggregating or selling of data? -- pending review
<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.
<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> ISSUE-19 -- Data collection / Data use (3rd party) -- pending review
<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
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
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
<Chris> technically speaking, the terms collection and storage are inherently connected-- you can't have one without the other
<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
<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
<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_
<trackbot> ISSUE-5 -- What is the definition of tracking? -- open
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
<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
<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
<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> ISSUE-54 -- Can first party provide targeting based on registration information even while sending DNT -- open
fielding: I thought issue-54 was closed
<npdoty> we agree on the important basic outline of first parties as the same between open proposals
<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
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
<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
WileyS: three open issue on that problem
<trackbot> ISSUE-88 -- different rules for impression of and interaction with 3rd-party ads/content -- open
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
aleecia: addressed in the current proposal but leave it open
<trackbot> ISSUE-111 -- Signaling state/existence of site-specific exceptions -- open
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)
<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
<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:
<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