<npdoty> scribenick: npdoty

aleecia: getting started, welcome, going through the agenda
... we have 24 open issues against compliance
... intending to go through all of them today, we will not be closing them all
... what do we need to do to get them to closed?

http://www.w3.org/2011/tracking-protection/agenda-2012-10-03-F2F-Amsterdam.html

aleecia: grouped issues, will try to keep the times and breaks
... when people tried to make an immediate response, a direct quick response, holding up a pen
... like to suggest that we go back to that method, just a quick response, hold up a pen (rather than my noticing you vibrating in your seat)
... start with Open Issues through 10:30
... calling for scribe volunteers

first session: bryan

next session, 10:30-11: ifette

1130 on: robsherman and efelten will split

<johnsimpson> getting messagr that call is restricted again, uses 8277 pass code what should iuse, please?

lunch will have a global considerations table, if that's of interest to you

compliance right after lunch: dsinger, with adrianba to help

<johnsimpson> Got it worked. Am in thanks.

pre-afternoon-break: adrianba, with dsinger to help

final session: vinay

cheers to vinay for helping with screen-sharing

<johnsimpson> where is screen sharing, pease?

<vinay> for those that want to view Aleecia's screen remotely -- http://my.adobeconnect.com/vigoel

<ifette> ISSUE-134?

<trackbot> ISSUE-134 -- Would we additionally permit logs that are retained for a short enough period? -- open

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

issue 134

<scribe> scribenick: bryan

aleecia: two options went out for poll text
... 1st option was discussed yesterday e.g. unlinkability
... 2nd option also discussed; fundamental differences appear between the two
... justin suggested changes to option 1
... (describing proposed text)
... discussions back and forth ensued; what is the way forward re nick's and justin's text, also maybe text from jonathan

<jmayer> Anyone have the current conference call code? TRACK isn't working. Thanks.

aleecia: anything else from the discussion, any changes by the authors, anyone else have other text?

nick: maybe the differences are due to different goals
... unlinkable/unidentifiable/research discussions...

<WileyS> +q

nick: maybe having a separate section on market research would be a way forward?

brendanIAB: a lot of discussion about 6 weeks and what is allowed to be done
... agreement may be quicker if we looked at allowed uses independently from retention period
... any specific period may be subject to a further discussion (outside W3C)

aleecia: suggestion is to decouple the issues - not sure that will solve the issue

<npdoty> if we wanted to get rid of the time period here, then I think we wouldn't be talking about a grace period at all, just permitted uses as usual

justin: sounded like we were moving away from permitted use, with use allowed within the retention period

<tl> +q

<robsherman> +q

shane: favor nicks proposal; the general reporting need for research goes far beyond 6 weeks

<efelten> +q

<jmayer> +q

shane: the research need is very specific to how long between data retained and anonymization (?)

<jchester2> +q

<npdoty> +1, if we have uses we want to enable, then we should discuss them as permitted uses

shane: should avoid a black/white list of uses in that period and changes to what you can do during time periods
... this is very dependent upon where unlinkability ends up

ifette: people who store data for a short time should bhave a very simple path to compliance

<WileyS> Ian - are we saying the same thing?

<WileyS> Ian - I don't see where we're apart?

ifette: people who retain after 6 weeks would have to show purposes and minization are consistent
... some restrictions on the 6 week period makes sense but overlaying that with what you can do with a longer purpose is problematic

aleecia: what hearing from ian is to make this simple for people to comply, with almost anything allowed within some limits in the period
... vs shane's proposal this seems to address fundamentally different things

wileys: what use in the 6 week timeframe would be outside the permitted uses in ian's proposal?

<WileyS> Two sets of rules: one set for sub-6 weeks and another set for post-6 weeks. Not an easy standard to follow.

ifette: we are not sure what all uses may arise in the 6 week period; really want it to be simple for the data retainers and not add a lot of auditing overhead
... don't think we are far apart
... not sure what companies would have to show if they are keeping data for longer

<fielding> My position on logfiles hasn't changed -- it is at http://lists.w3.org/Archives/Public/public-tracking/2012May/0338.html

dsinger: so there are no restrictions in the 6- week period

<justin> dsinger, The language I suggested said "no xfer, and no personalization"

ifette: no, there would be limits

dwainber_: suggest we open this as a new issue and punt it for later
... though we were talking about a period where getting your data together would be possible

aleecia: thought were were further along, but the main need is to figure out which one we are doing; but for now we should be ok keeping this a single issue

<justin> If you don't want a grace period, I'm not going to make you have one.

lmastria-DAA: the chasm between the proposals and business as operated is large; this should be handled as a separate issue

tl: Perhaps I misunderstand. If you don't think that DNT requires you to change how you store data about people, what did you think we were doing here?

<npdoty> is there a chasm on having a grace period to bring data into minimization requirements?

<fielding> tl, if we had a definition of tracking, I could answer that question.

<npdoty> lmastria-DAA, is the grace period what you're concerned about, or something else in the short-term retention proposals?

lmastria-DAA: as a compliance matter this has taken an enormous amount of effort so far; DNT compliance should be a singluarly technical issue
... company-internal policies should deal with data handling and we are not in the position to override those policies

<efelten> -q

kj: we submitted a poll text specific to research under issue #25 aggregated reporting

<robsherman> -q

<robsherman> +q

kj: it specifies data rention conditions and aggregated stats as output; we'd like that to be included in the text

<justin> KJ's text: http://lists.w3.org/Archives/Public/public-tracking/2012Oct/0089.html

<tl> aleecia: That's very interesting lmastria-DAA, but I think that the problem you want us to be solving is very different from the task that we are actually performing.

<jmayer> aleecia: And thank you for representing some of those companies in the group.

kj: (describes the aspects of the proposal)

aleecia: how much could be done under consent?

kj: most is done thru online panels per agreement with panel members
... research needs to project that to larger populations; a limited use is needed to check those assumptions

<justin> KJ's text requires "no return path to the individual" --- very similar to the discussion we had yesterday afternoon on unlinkable.

aleecia: seems off-topic but would like to hear more

<jchester2> Kathy Joe--what is ESOMAR's definition of individual, and could the research be used in any way linked to a personna that will eventually used for online marketing applications?

tl: there has been talk about related but similar issues, e.g. ian's use case about short-term retention with no other use, that sounds good

<justin> jchester2, kj's language says you can't alter any individual's experience.

tl: but the question is what is the short period of time before you are allowed to keep the data in another form;
... we should not be talking about additional uses during this grace period

<npdoty> do I understand that we have agreement that there should be a grace period to bring data into compliance regarding minimization/permitted uses? and then a separate question about whether additionally you can do other processing during that same period?

<lmastria-DAA> TPWG Scope: The Working Group will produce Recommendation-track specifications for a simple machine-readable preference expression mechanism ("Do Not Track") and technologies for selectively allowing or blocking tracking elements.

<jchester2> Justin, I know. But we need to clarify what ESOMAR means by individual. If it is used for targeting/online ad experiences for others, even if not back to specific individual, but to a set of users that are identified by such research, that's a privacy issue under DNT, IMHO.

tl: processing during this period for the permitted uses is what should be talked about; not other specific uses, just what is allowed to process during this period per the permitted uses

ifette: if everything is the same before/after the 6-week period and you need to show compliance, what is different?

<npdoty> ifette, I think tl's point is that different data can be retained during the 6-week period

tl: was suggesting the opposite; during the period you have no permissions

<justin> npdoty, I find research/improvement/reporting to be a close call use case that could justify special treatment as just OK during grace period (or unlinkable), but if the room is against, I will concede.

<dsinger> +1 to tl that we should separate 'raw data retention period' from a possible permitted use for general use 'for a short period'

npdoty: the difference is on the retention question

<WileyS> I can already do that for security - so in the real-world this provision does nothing.

tl: the point is you can retain the whole data in the period for the purpose of processing but no other purpose

ifette: understand but not sure that works for me

jmayer: 2 points
... seems there is not close consensus on the duration

<justin> jchester2, I see, I think (would hope!) that would be prohibited, but perhaps kj could clarify for you.

jmayer: helpful to understand why 6 weeks is necessary; understand the privacy implications but want to know more about why its needed
... 2nd to clarify the role of the grace period under the proposals

<ninjamarnau> I do not think we have consensus on the duration of this grace period, I have not heard from anyone of the privacy advocates that they could live with 6 weeks

<jchester2> -q

jmayer: protocol logs as a carveout to the unlinkability rule prior to 2 weeks
... there are different analytic purposes that require other approaches (scribe: please clarify if i missed this point)

<WileyS> +q

<rvaneijk> The 'panel calibration' which Kathy and Alex brought up a number of times can legally (EU) only be done with explicit user consent, after having been provided with clear and comprehensive information. Making market research part of the DNT standard through a permitted use doesn't make it a legitimate business practice.

aleecia: three different things appear to be going on (listed them)

<amyc> i think we all understand, and it is explicitly in the spec, that DNT spec does not override local laws

wileys: the other option is to drop this altogether, that the time-period aspect could be orthogonal from the uses

<npdoty> fielding, is that right? do you agree with WileyS that you argue there should be no limits on retention in the spec?

<jmayer> My point: Under the EFF/Mozilla/Stanford proposal, this period reconciles protocol data with the general prohibition on collecting linkable data. Under other proposals, this period is connected to a standalone exception for data that is rendered unlinkable; linkable data can be collected, retained, and used for other permitted uses. The two approaches are functionally similar, but analytically a bit different.

ifette: there are two issues wrapped up here
... are audit criteria different in different periods?
... in a 6-week period there is a presumption of innocence

<fielding> to clarify, raw logfiles are needed for the security permitted use

<fielding> npdoty, http://lists.w3.org/Archives/Public/public-tracking/2012May/0338.html

<npdoty> I would expect audit criteria to be outside the standard altogether; didn't we already come to an agreement on that?

<Chris_DAA> I'd like to write another text proposal

aleecia: we have a separate issue re reporting; it sounds like we have to basic options i.e. real-time processing vs a grace period for processing

<Chris_DAA> still people in the q (before she closes this)

<fielding> (and I would expect use and retention of DNT:1 records to be limited to what is necessary for security)

<Chris_DAA> can we please process the q

<Rene> rvaneijk: it depends on national and regional legislation and market research companies are following national legislation in all countires. DNT will be a global standard

aleecia: suggest a new issue to consider what would be easier for implementations

<Rene> rvaneijk: it depends on national and regional legislation and market research companies are following national legislation in all countires. DNT will be a global standard

<justin> fielding, I don't see how this isn't fully addressed by the permitted use for security.

<ifette> ISSUE: How do we create straightforward compliance for implementers retaining data for N weeks or less?

<trackbot> Created ISSUE-174 - How do we create straightforward compliance for implementers retaining data for N weeks or less? ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/174/edit .

<fielding> justin, it should be -- which is why the N-week period is a fantasy.

rigo_: agree that ian's issue is separate and we should reopen this discussion;
... the 2nd thing is how you express what you intend to do in a policy
... we have an entanglement of issues

<WileyS> Rigo, I actually support the notion of allowing a Server of replying with the self-regulatory standard it supports as a valid DNT response (in this case, DAA).

robsherman: agree that there are things entangled; e.g. the time period vs processing/use limits
... really need to think about small companies and how they will do this

<rvaneijk> @Rene: this goes especially for NL

<justin> fielding, it clearly is. If it's overdetermined why you are allowed to retain data under DNT, not sure why that is a problem for companies.

<npdoty> fielding, justin, I think the point that you're making is that for many implementers, retention of raw log files for security purposes will be necessary anyway

robsherman: it's not clear what we are talking about re making something unlinkable for specific uses

<npdoty> fielding, justin, for the small implementer who isn't retaining logs long term for security, I would think they would benefit from a six-week grace period to remove, anonymize, data

robsherman: we may be closer together than we think if we got more specific about the actual activity of processing the dta

<WileyS> -q

<Rene> rvaneijk: okay, so this is related to the new NL law related to cookie (implementation of e-privacy directive), got it

lmastria-DAA: caution against making a simple signal account for auditing etc; that should be out of scope

<jmayer> All of this is well within scope.

lmastria-DAA: it might be fine/easy to do it, but saying whoe ecosystem must be held to it, don't think we are there yet

<npdoty> issue-75?

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

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

aleecia: next topic is issue 75

<WileyS> Jonathan - many here disagree with you - so let's at least agree that we have fundamentally different views here.

aleecia: this has been solved in the TPE, we should be able to close
... any further input?

<Chris_DAA> data retention beyond the use for "tracking" (which has not been defined yet by the working group) is OUT OF SCOPE per the charter: http://www.w3.org/2011/tracking-protection/charter.html

<tl> +q

<tl> +q

<jmayer> npdoty, fielding, justin, The E/M/S proposal facilitates easy compliance via a short-term use period for protocol information. If you're not collecting ID cookies and you dump your logs after two weeks, you're (very likely) in compliance.

ifette: in bellevue it was unlclear if all the letters in the header had consensus

<npdoty> I believe we had agreement that it's optional

aleecia: i mean this is no longer a compliance issue; it's a TPE thing

<tl> -q

<WileyS> +1 to Nick

npdoty: we had agreement in bellevue for an optional method to claim permitted uses
... shane's proposal included transparent documentation but we did not have a method yet

<fielding> as long as it is understood that what in in TPE right now doesn't match my recollection either -- why are the qualifiers in the header field?

aleecia: looking at the discoverability section?

npdoty: the spec now has technical support for the requirements

<jmayer> Clarification?

<rigo> no

<ifette> Close iSSUE-75

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

<Chris_DAA> npdoty, data retention (unless it relates to tracking) is out of scope of the charter - call for clarification by the W3C please on the charter

<jmayer> Ah, got it. So this is just a TPE issue. Seems very reasonable.

<npdoty> issue-24?

<trackbot> ISSUE-24 -- Possible exemption for fraud detection and defense -- open

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

aleecia: next is fraud as a permitted use (issue 24)

<fielding> is fraud a permitted use? umm, maybe fraud prevention

aleecia: editors has got this to two proposals
... (describing text in 6.1.1.6 Security and Fraud Prevention)

<tl> +q

<jmayer> What happened to a MUST for graduated response?

<WileyS> Roy, I suggested that "Security" is simply enough to cover both concepts (and others)

<jmayer> +q

<tl> +q to ask where's the "but you must only..."?

aleecia: what will get us to final text?

<rigo> "fraud as permitted use" is semantically interesting :)

ifette: like the text in the document; what problems exist for the current text?

<hwest> rigo, I think we should rename it "fraud prevention"...

ifette: for nick's proposal, adding graduated response as preferred is OK

<WileyS> I believe we should simply call it "Security"

<justin> ifette, Fortunately, you already have an open action on defining graduated response.

ifette: aside from that would like to see specific issues

<ifette> justin, lovely :)

npdoty: the motivation was to simplify it and include graduated response

aleecia: can you live with it with the addition of graduated response?

npdoty: yet
... (yes)

<npdoty> I would be very concerned about "illegitimate"

dwainber_: trying to do three things (please add the the irc log as I did not capture the first two)
... third is filtering out bot-driven impressions

<fielding> npdoty, why?

<WileyS> +q

<fielding> is malicious a better word to use?

<rigo> fielding, because you import all sorts of legal problems with this one word

<justin> Sure, take out fraud, illegitimate, and tracking.

<npdoty> I'm not sure why we want to take out "fraud"

<justin> Leave fraud in but add security and malicious?

<fielding> justin, yep

<justin> FINE

<npdoty> fielding, I would be concerned about what user's activity counts as legitimate or not or who would decide; yes, I would be fine with "malicious"

tl: could not find the text re global aspects of handing

<Zakim> tl, you wanted to ask where's the "but you must only..."?

aleecia: at the bottom of the section

jmayer: 3 points; first is be sure to flag an option is a must for graduated response

<Chris_DAA> guys, we gotta object to data minimization-- it's not in scope

jmayer: seems some think its close to must but some cases where graduated response may be a best practice

<fielding> npdoty, the goal would be to distinguish bots from real people -- for example, we should not count google's indexing spider as an advertising impression, yet it isn't malicious either.

<dsinger> um, the definition of graduated response is that it's the data needed to be OK, so it can't be not OK :-)

jmayer: 2nd point why i think a must makes sense
... companies can say i have no reason to suspect you, but i will keep your data around on the off-chance that you are suspect

<rigo> I remind that "graduate response" still was the NATO doctrine to the russians which contained that they would send nukes first

<bilcorry> It establishes patterns that can be used to detect account take overs. If we have no information about previous behavior, can't help users. What is the greater harm?

jmayer: 3rd point: i and others have called for industry to provide information; get that this is sensitive, but need info rather than bald assertions

aleecia: i suggest lets see the text from justin, and expect a debate

tl: re the should/must discussion, recommend reading the RFC (2119)

<jmayer> You SHOULD read about SHOULD. Classy, Tom.

<dsinger> from the RFC: "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there

<dsinger> may exist valid reasons in particular circumstances to ignore a

<dsinger> particular item, but the full implications must be understood and

<dsinger> carefully weighed before choosing a different course.

<dsinger> "

<ChrisPedigoOPA> Aleecia, can you repost the link to the Compliance doc?

<fielding> http://www.apps.ietf.org/rfc/rfc2119.html

lmastria-DAA: reality is that should will become must

vincent: question for david, how can we detect click-fraud?

<npdoty> fielding, do we not think financial permitted use would cover keeping data from bots that shouldn't be billed?

aleecia: that's not something we need to address here

<johnsimpson> who is on the phone?

<tl> +q

wileys: danger of literal interpretation of the RFC2119 language; recommend mocing graduated response into the informative text

<fielding> npdoty, yes -- I was just trying to explain why I think David W. chose illegitimate

<jmayer> IMMEDIATE RESPONSE

wileys: only have heard one example in the real world, still searching for a company that can do this dynamically

<jmayer> (please.)

wileys: appreciate the aspirational goals though

<fielding> npdoty, there are security issues with botnets, of course, but I consider those to be malicious attacks

<tl> +q to say that graduated response as a "nice to have" doesn't work for me.

<npdoty> fielding, certainly, yes

jmayer: half of DAA members kill cookes when the user opts out; the notion that this is infeasible seems questionable
... talking about graduated response
... (please add the rest of the point as needed)

<npdoty> ACTION: mayer to draft non-normative examples illustrating graduated response [recorded in http://www.w3.org/2012/10/04-dnt-minutes.html#action01]

<trackbot> Created ACTION-293 - Draft non-normative examples illustrating graduated response [on Jonathan Mayer - due 2012-10-11].

<Chris_DAA> call for the term "graduated response" to be defined

<rigo> I note Article 4 of Directive 2002/58/EC requires

<rigo> The provider of a publicly available electronic communications service must take appropriate technical and organisational measures to safeguard security of its services

<fielding> The problem with graduated response is that it assumes you haven't shared data with a third party that tells you whether or not you need to ratchet up that graduated response.

<johnsimpson> Can't hear. Use microphone

BrendanIAB: to jonathan in the case that the user has opted out, we are still using IP address identifiers for fraud/traffic etc

<jmayer> BrendanIAB, the E/M/S proposal allows using IP addresses and other protocol information for security/antifraud!

<jmayer> npdoty, I also can't understand what he's saying.

<jmayer> Sounds underwater.

<johnsimpson> just not clear...

<Chris_DAA> how does "graduated response" apply here?

BrendanIAB: re automated traffic filtering, not all filters catch all bots in real time, so there is need to process the logs after-the-fact (please correct if that was not accurate)

<jmayer> If we agree that these practices can be accomplished either through protocol data or unique ID data, why don't we agree to standardized the current industry best practice?

<npdoty> ACTION: brookman to revise security/fraud based on existing proposals [recorded in http://www.w3.org/2012/10/04-dnt-minutes.html#action02]

<trackbot> Created ACTION-294 - Revise security/fraud based on existing proposals [on Justin Brookman - due 2012-10-11].

<BrendanIAB> jmayer - I grok that IP addresses are usable, just wanted to call out that IP addresses are identifiers!

Chris_DAA: acking a solid definition of graduated response; should pause the debate

<BerinSzoka> at what point in the conversation would it be appropriate for us to finally get to the bottom of Should v Must? This seems to be a key issue that continues to be debate and, as a lawyer, I must say I'm frustrated by the conversation thus far--as well as the RFC text. For example, the definition of "must" uses the term "absolute requirement", which would suggest that "Should" is ALSO a "requirement"--just not an absolute one

<jmayer> BrendanIAB, they're linkable in many cases, for sure. That's why the E/M/S treats them as a special case.

ksmith: this is not a good place for graduated response; we should go for minimization

<BrendanIAB> I'll see if I can fix my mic for the future, I do feel like I'm underwater as well (given that I started at 2:30 AM)

<npdoty> BerinSzoka, yes, I believe "should" is a requirement that isn't absolute

<tlr> brendan, kudos for getting up this early

<ifette> Forced OS patch installation, sigh. Gotta love corporate policy and OSes that don't auto-update in a sane way, e.g. when I rebooted earlier ;-)

ksmith: graduated response is opposite of what you are likely to do in a real situation, rather collecting everything you can and then scale back as quickly as possible

<tlr> SHOULD This word, or the adjective "RECOMMENDED", mean that there

<jeffwilson> like debugging, each security scenario can be different, requiring different aproaches

<tlr> may exist valid reasons in particular circumstances to ignore a

<tlr> particular item, but the full implications must be understood and

<tlr> carefully weighed before choosing a different course.

<tlr> http://tools.ietf.org/html/rfc2119

<jmayer> RESPONSE PLZ

<Zakim> tl, you wanted to say that graduated response as a "nice to have" doesn't work for me.

<jmayer> +q

<BerinSzoka> in other words, the RFC text seems to suggest that "Should" is a requirement with exceptions, where the burden is placed upon the party NOT doing what it "Should" do to justify its invocation of an exception to the "Should"

Brooks: re clickfraud being a 1st-party case

<npdoty> I think this is a url re-direction question?

<BerinSzoka> anyway, again, I'm asking when we can discuss should v must in greater detail--NOT in the IRC

Brooks: in a redirect scenario, different parties are involved some with a service provider exception

<amyc> is wondering why the global statement about data minimization couldn't cover this, rather than adding graduated response to each permitted use

<Chapell> -q

Brooks: don't think that clickfraud is solved due to the 1st party context

<Chris_DAA> BerinSzoka, you should open an action item on should v must

<Simon> Is "data authentication" more accurate a term than "fraud"?

aleecia: may be as we look into redirects we may address this, but we haven't gotten into it deeply so far

<Chris_DAA> amyc, global data minimization is clearly out of scope for this working group

<lmastria-DAA> brooks: affiliate and click fraud has not been contemplated

npdoty: we have a section on data minimization and transparency, with wide support

<rigo> aleecia, I see the dragons that you point to

npdoty: use of graduated response was picking upon that global requirement, added this as a comforting help toward consensus

wileys: don't know if data minimization correlates with graduated response, but data minimization is undefined
... graduated response seems more proscriptive

<BerinSzoka> ok, I just created an action item on "Should v Must" https://www.w3.org/2011/tracking-protection/track/actions/295

wileys: data minization was purposely left unproscriptive

<efelten> Chris_DAA, doesn't that follow from "technologies for selectively allowing or blocking tracking elements?"

<ifette> Can we wait to see revised text?

<WileyS> data minimization only for permitted uses

<npdoty> "Additionally, the Working Group will define the scope of the user preference and practices for compliance with it in a way that will inform and be informed by the technical specification."

<npdoty> maybe there is a misunderstanding about data minimization applying beyond data retention under DNT:1?

<jmayer> Is this Lou from DAA being disruptive again?

<jmayer> Trying to argue about the group's charter?

Chris_DAA: (suggests a topic be considered here)

<dsinger> to Chris_IAB: I think we mean minimization only of the data that is in scope, i.e. (speaking roughly) 'tracking data', or PII; other data does not concern us (including unlinkable, as we explored)

aleecia: suggests this be taken offline during the break

Chris_DAA: think global data minimization is out of scope of this working group (for the record)

<dsinger> issue-72?

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

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

aleecia: issue 72

<dsinger> issue-49?

<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? -- open

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

<npdoty> thx to the scribe for making sure to get comments for the record on to the record :)

aleecia: noted as covered elsewhere but it's open; all the activity has moved, so we should close it

<Chris_DAA> efelton, the actionable word in the charter/scope doc is "tracking"

<npdoty> hearing nothing, closing 72 as subsumed by other issues

<BerinSzoka> +1 to Chris. I'm really confused as to how data minimization falls with in the scope, which, let us recall, is"The Working Group will produce Recommendation-track specifications for a simple machine-readable preference expression mechanism ("Do Not Track") and technologies for selectively allowing or blocking tracking elements."

<npdoty> close issue-72

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

aleecia: issue 31 dovetails with the last topic

<Chris_DAA> so as it may relate to tracking, let's talk about it-- but not global data minimization

aleecia: (reads from the data minimization and transparency section)

<efelten> Berin, see the third paragraph of the charter: Additionally, the Working Group will define the scope of the user preference and practices for compliance with it in a way that will inform and be informed by the technical specification. The group will actively engage governmental, industry, academic and advocacy organizations to seek global consensus definitions and codes of conduct."

<MikeZ> Why do we spend time discussing text when there is substantial doubt whether the topic is in scope of our work? Cart before horse.

<npdoty> maybe there is some simple confusion, Chris_DAA, I don't think the requirements on data minimization are for organizations' data practices in general

<tlr> +1 to Nick.

<Zakim> ifette, you wanted to say "for the permitted use" -> "for the permited uses for which the data is being retained"

aleecia: any comments other than the suggested examples?

<Chris_DAA> efelton, since the actionable word in the scope/charter is "TRACKING", we should define tracking then before moving forward

ifette: the second half of the text addresses how data is handled for other permitted uses

rigo: if you reuse data for other purposes, it's still a permitted use

<efelten> All I'm saying is, to know what the charter covers, you have to read the whole charter.

<Chris_DAA> efelton, this group's charter is actually VERY specific-- it relates to tracking

ifette: this addresses retention for a specific use, but do not mandate separating the data retained per use

<BerinSzoka> yes Ed, I see the third paragraph, but that ("define the scope of the user preference and practices for compliance with it") seems to refer back to the limiting principle of the first paragraph ("preference expression mechanism ("Do Not Track") and technologies for selectively allowing or blocking tracking elements"). So... what's tracking, again?

<Chris_DAA> efelton, maybe you think everything advertisers do with data is "tracking"-- respectfully, I would disagree with that notion

ifette: we should describe retaining minimal data for the uses valid for that data

<BerinSzoka> Unfrozen Caveman Lawyer is confused

<jmayer> Chris_DAA, BerinSzoka, the charter plainly covers defining compliance, including minimization. That hasn't been contested for over a year.

<Zakim> fielding, you wanted to say that the basic problem here is that first/third only applies to one interaction

<Chris_DAA> WHAT IS "TRACKING"? WHAT IS "TRACKING"? WHAT IS "TRACKING"? WHAT IS "TRACKING"? WHAT IS "TRACKING"? WHAT IS "TRACKING"? WHAT IS "TRACKING"?

aleecia: don't see that separate copies is not a required approach
... attach to issue 31

<dsinger> to editors: "once the period of time" --> somewhere add "has expired" !!

<Chris_DAA> npdoty, I'd like to open an issue to define "tracking" (I'll take the lead)

aleecia: anyone to provide examples per the note?

<rvaneijk> @Chirs: we are currently not discussing the def of tracking

<jmayer> Sure.

<BerinSzoka> all the more reason for an action item on that point, no?

aleecia: jonathan?

<rvaneijk> s/Chirs/Chris/

<npdoty> @Chris_DAA, you might look at issue 5 http://www.w3.org/2011/tracking-protection/track/issues/5

<justin> How about "Tracking is the collection, use, or retention of information in contravention of this standard."

<Chris_DAA> rvaneijk, as it relates to the scope, it relates to my objection

jmayer: sure

<Simon> Is the earlier discussion of compliance and retention subsumed under this issue?

<jmayer> Y'all don't say I never did anything for ya...

<npdoty> ack fielding

<Chris_DAA> justin, let's take it as an action item

<rvaneijk> @Chris: it it not the time for formal objections

fielding: general problem with this section; it's phrase as if the hold is either a 1st pr 3rd party

<ifette> Issue-31: "A third party MUST only retain that information which is still required for permitted uses, for as long as is reasonably necessary for those uses. When data is no longer required for any permited uses, it MUST NOT be retained. Data need not be stored multiple times for each permitted use, storing a single instance of the data is sufficient. … rest of existing text here"

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

fielding: on a large site the party context will vary for the same records

<Chris_DAA> thanks npdoty, is this on the agenda for Amsterdam?

fielding: how does this text account for that a site is not always the same type of party?

<ifette> ISSUE-31?

<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

aleecia: hearing suggestion that "data collected in a 3rd party context must..."

<npdoty> ACTION: fette to draft text for the agreement that multiple copies of the same data are not required [recorded in http://www.w3.org/2012/10/04-dnt-minutes.html#action03]

<trackbot> Created ACTION-296 - Draft text for the agreement that multiple copies of the same data are not required [on Ian Fette - due 2012-10-11].

<jmayer> npdoty, could you please do the ACTION thing for me?

fielding: will provide text re that

<amyc> wouldn't "data collected in third party context" apply to all of this section?

<ifette> ACTION-296: see note associated with ISSUE-31

<trackbot> ACTION-296 Draft text for the agreement that multiple copies of the same data are not required notes added

<ifette> Close ACTION-296

<trackbot> ACTION-296 Draft text for the agreement that multiple copies of the same data are not required closed

<npdoty> ACTION: fielding to update minimization text regarding data collected in a third-party context [recorded in http://www.w3.org/2012/10/04-dnt-minutes.html#action04]

<trackbot> Created ACTION-297 - Update minimization text regarding data collected in a third-party context [on Roy Fielding - due 2012-10-11].

dwainberg: data retained for permitted uses should imply by definition that you are acting as a 3rd party?

<jmayer> examples for minimization

dwainberg: we accept that service providers stand in the shoes of their served parties

<Chris_DAA> rvaneijk, I didn't file a formal objection (yet), I engaged in the discussion and objected that the discussion of data minimization is out of scope (I'm allowed to do that)

<fielding> I don't multitask very well

<fielding> ditto tlr -- it is useally negated as MUST NOT except

tlr: "must only" is ambiguous; recommending against using such phrases, for language clarity

<robsherman> +1 tlr.

<Chris_DAA> data minimization is out of scope

aleecia: we can flip it around

<npdoty> action-293?

<trackbot> ACTION-293 -- Jonathan Mayer to draft non-normative examples illustrating graduated response -- due 2012-10-11 -- OPEN

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

aleecia: justin take an action to flip this around

dsinger: please add "has expired"

<ifette> ScribeNick: ifette

Issue-64

ISSUE-64?

<trackbot> ISSUE-64 -- How do we describe non-identifiable data -- open

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

<npdoty> ACTION: mayer to draft examples for data minimization [recorded in http://www.w3.org/2012/10/04-dnt-minutes.html#action05]

<trackbot> Created ACTION-298 - Draft examples for data minimization [on Jonathan Mayer - due 2012-10-11].

<dwainberg> suggestion on retention: "Data retained by a party for permitted uses MUST be limited to the data reasonably necessary for such permitted uses, and MUST be retained no longer than is reasonably necessary for such permitted uses."

Aleecia: don't believe anything has changed overnight, believe we leave it where we left it yesterday

… much to do

… move on to service providers

<npdoty> issue-49?

<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? -- open

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

ISSUE-49

Aleecia: extensive drafts in here

… as section 3.4 and three options

… for definitions

… look at those

… first option, looking only at normative section, is <reads>

… reads This section applies to parties engaging in an outsourcing relationship, wherein one party "stands in the shoes" of another party to perform a specific task. Both parties have responsibilities, as detailed below.

A first party or a third party MAY outsource functionality to another party, in which case the third party may act as the original first party or third party under this standard, with the following additional restrictions:

Data collected by each outsourced company is separated for each party they collect data for by both technical means and organizational process, AND

The outsourced company has no independent rights to the collected information, AND

A contractual relationship exists between the outsourced and the party they collect data for that outlines and mandates these requirements.

An outsourced company acting on the behalf of another party is subject to all of the same restrictions on that party (for First or Third party, as appropriate.)

<lmastria-DAA> non-identifiable data is still very open issue

Aleecia: Moves to option 2

… Outsourced service providers are considered to be the same party as their clients if the outsourced service providers only act as data processors on behalf of that party, silo the data so that it cannot be accessed by other parties, and have no control over the use or sharing of that data except as directed by that party.

Aleecia: option 3, Service Providers acting on the behalf of a First Party and with no independent rights to use the First Party’s data outside of the context of that First Party and Permitted Uses are also considered to be acting as the First Party.
... this doesn't contemplate first/third parties but probably should

<Chris_DAA> jmayer, per your argument above, can you please demonstrate concretely how data retention is in scope of the charter? btw- doesn't matter when parties object-- DAA just got into the group officially, so now we can formally object

Shane: "Service providers acting on behalf of a.. with no rights to use … otuside of context … also considered to be acting as that party"

… shane entered this in IRC yesterday

Aleecia: Anything new, or are we just tightening these down

… think we understand differences between

<justin> WileyS, I think hwest was charged with revising these two.

<robsherman> Even where service providers are limited in their use of data, most contracts give them the right to access it for troubleshooting, etc. I think this should be noncontroversial, but does anybody agree that that kind of use doesn't cause a service provider to become a third party (under any of these 3 options)?

… are these final, to a point where we can move them closer togehter, or where we need a decision process

… more to discuss about this

<robsherman> s/does anybody agree/does anybody disagree

<Chris_DAA> if data does not relate to tracking (per the Charter scope), then it's out of scope

jmayer: these options bundle together many different design choices

<rigo> to ask whether we can merge option 2 and 3

… decisions about treatment of service provider as being synonymous with first party or not

… technical, business protections required

… issues about use direction

… what i am hoping

… process

… does it make sense to break out individual components

… or does it make sense to bundle them

<justin> Per request, current compliance spec: http://www.w3.org/TR/tracking-compliance/

aleecia: choices between these were done deliberately

<ChrisPedigoOPA> thanks Justin

… you are right that the siloing can be separated out, endless conversation about that

<jmayer> Chris, you're welcome to propose your novel charter interpretation on the mailing list. I'm trying to focus on the current conversation.

<Chris_DAA> efelton, are you offering the FTC's position on the scope of this working group?

… but the idea a SP is considered the same party, or that it acts on behalf of the same party, is fundamentally different and is on purpose between these drafts

jmayer: wanted to add EFF/stanford/mozilla as another option

aleecia: isnt that option 1?

jmayer: slight differences

… one is the requirement that the technical/business precautions <hard to scribe, he's not speaking linearly>

<efelten> Chris, all I did was quote from the charter.

… explicitly don't add consensus on this

<npdoty> if the differences are slight, then can we condense them?

… collecting/retaining data that COULD be linked across multiple first parties

… vs under "this" (not defined) is about hte use of data across multiple first parties, not collection

… one of reasons i'm concerned about bundling, easy to lose that nuance

<Chris_DAA> efelton, thanks for the clarification-- it appeared to me that you were trying to offer you analysis of the charter/scope.

aleecia: actionably out of that is a request to have that text added back to draft

… jonathan, if you can put in IRC, thanks

… perhaps hwest can take an action

… another option to 3.4 which jmayer will provide

<npdoty> ACTION: west to add a service provider option (or condense with option 1) from jmayer [recorded in http://www.w3.org/2012/10/04-dnt-minutes.html#action06]

<trackbot> Created ACTION-300 - Add a service provider option (or condense with option 1) from jmayer [on Heather West - due 2012-10-11].

… many close options

<jmayer> Here's the E/M/S language: http://jonathanmayer.github.com/dnt-compromise/compromise-proposal.html#outsourcing

… can we get down to 2 vs 4 options?

kimon: like the first definition

… ok with some of them

… question is we have a lot of text on the first, not sure i like it entirely but don't have a problem with the definition

… do we choose between definition and long text or short definition?

<fielding> I am not sure how siloing can be separated out given that it distinguishes a service provider from a third party

aleecia: can we pull out definition, and then do responsibilities of a S.P. as a separate issue

… like that approach

rigo: options 2,3 fundamentally the same

… 2 says "are considered same party IF outsourced service provider acts as a data processor"

… rob will confirm DP definition is when SP has no indepndent right to use

<efelten> Chris, I just wanted to make sure you weren't trying to claim that defining the scope of the user preference and practices for compliance with it would be outside the charter.

… so they are the same

… merge and replace with shane's suggestion

… still believe shane's suggestion too long, burns down to independent use

… believe we already agreed

aleecia: who wrote 2/3?

<Chris_DAA> npdoty, is issue 5 on the agenda for Amsterdam (sorry if you already answered this before)

shane: rob and i did 2 togehter, i wrote option 3, also wokred on option 1

<fielding> 3.1.4.2-6 should not be in the spec

WileyS: evolution of thought was again, much of this can be played into option 1

… very first AI that jmayer and I worked on

… proscriptive application vs less proscriptive

<npdoty> Chris_DAA, you can see f2f agenda here: http://www.w3.org/2011/tracking-protection/agenda-2012-10-03-F2F-Amsterdam.html we don't have issue-5 on that agenda, it was on the agenda for the last two teleconferences

<Chris_DAA> efelton, my objection was simple: general/global data minimization is out of scope

… evolution was when rob and i trying to show SP+DP were legitimately the same

<MikeZ> robsherman, agree wth your assessment of service providers

… open discussion

… 3 was to reinforce permitted use for SPs

… service providers have every need for permitted uses as well

… if we collapse the three, still same fundamental divide on specifics

… but definitionally, already there

<robsherman> Thanks, MikeZ

… just need to collapse the definitions

rvaneijk: to be clear, when it comes to independt use through permitted use, we have a difference of opinion

<fielding> Rob's mic not working

he's just speaking softly / not close to mic

<johnsimpson> microphone, please

rigo: not debating that third parties… misunderstanding shane was alluding to … even a third party of article 4 of 2000/58 obliged to make service secure

… security and fraud prevention

rvaneijk: within the purpose of the first party

<Chris_DAA> thanks npdoty, is there any way to add this in somewhere? I think it's critical to all discussions here-- helps define the charter/scope in a meaningful way

rigo: no independent right means you can tchange purpose as a party

… financial reporting

… no permitted use that would be outside of that purpose set by first party

rvaneijk: no independent product development or market research

shane, rvaneijk was saying SP gets no permitted use around e.g product development

aleecia: hearing useful to get definition first, then pull apart other issues

lou: troubled by indepdent use, think legitimate uses flow from first party to SP or third party

… need to be contemplated

… rigo talked about this

lmastria-DAA: beyond this, need to be able to say FP has indepndent right to be able to say "it's OK t use in this way, I collected with permission to do X,Y,Z"

… way this is structured doesnt contemplate that

<WileyS> Again - I believe the "product development" concept isn't well understood. If I learn through one of my clients that a server isn't performing well, then I can modify that system and all my clients benefit. This IS PERMITTED by EU law.

vinay: one example is industry reports. How many mobile users, highly aggregated that SPs provide

… same thing as a large first party doing it themselves

… example of a permitted use SP should be able to do

<WileyS> +q

kimon: how would htat work

… i drop out of first party become thid party, covered by permitted uses?

<jmayer> As I explained in Bellevue, the risk of independent use is a perverse incentive to collect and retain information that can be linked across first parties.

WileyS: first party uncovered, if third party, only permitted uses are permitted uses

<amyc> another scenario is fraud detection, where service providers use data from many first parties to identify fraud (e.g., a suspicious IP address)

kimon: if i use part of the data independently i become a third partyy

WileyS: then ahve permitted uses

… thats why they're in option 3

… if you look at this as a heirarchy / threshold

… see FP/TP/SP

… nonseniscal to in the middle say you have less access to the one at the bottom

rigo: i think for the moment if we blow the permitted uses this goes wrong

… i collect more than i would be able ot collect in third party context

WileyS: what does blow mean?

rigo: security/financial reporting are reasonable

… then product development which are in this

WileyS: we dont hae these

rigo: as long as those are not permitted uses this is not a problem

<justin> +1 to rigo

… if permitted uses go beyond, you collect in a first-party trusted contex,t hten re-purpose this later on

… for those that have a permitted use, no problem

<justin> This is all contingent upon the scope of permitted uses (whether they are blown or not).

… but we could run into a problem later

tl: if we are going to decide SPs can do a whole bunch of stuff with info throwing out the previous year of discussion re constraints of standing in shoes of FP, are there any other decisions you want us to take up?

<Zakim> fielding, you wanted to ask that 3.4.1.2-3.4.1.6 be removed

fielding: long part of the first definition be removed from 3.4.1.2-3.4.1.6 be removed, dont reflect industry practice and dont add clarity

<npdoty> I would support decreasing the length of this section; perhaps in a separate best practices document

… move this elsewhere

aleecia: appendix of best practices sounds like a viable idea

<tlr> +1

<npdoty> I do think we had agreement in Santa Clara last November that service providers would use technical means to silo data

… if we have enough to do an appendix, good concept

<tlr> I think 3.4.1.2 is long enough for an appendix of its own

<amyc> +1

ISSUE: have an appendix of best practices?

<trackbot> Created ISSUE-175 - Have an appendix of best practices? ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/175/edit .

aleecia: let the editors deal with this

… as for this specific text, lets figure out normative side first

… then do non-normative

<justin> Who is in charge of merging these three defs?

<BerinSzoka> are we ever going to break? or shall we all just die of bladder-explosion?

<amyc> are you defining blow?

… discuss more on next editors call

<justin> We can add blow to the defs.

<WileyS> -q

<johnsimpson> Chris_DAA, There is been discussion about Issue-5 on the mailing list recently. Here was my attempt to define tracking: http://lists.w3.org/Archives/Public/public-tracking/2012Oct/0028.html . Roy responded: http://lists.w3.org/Archives/Public/public-tracking/2012Oct/0040.html It would be interesting if you offered a definition.

lmastria-DAA: in response, all of these things are happening not in the wild west premise a number of folks seem to be suggesting re dat asharing amongst companies. Not reality in the market

… reality is that if data is shared, there are contracts, compliance folks, there' san industry of privacy professionals who do nothing but managet his issue

<jchester2> The reality of the market in the US is that the data is mixed and matched without regard to consumer privacy or consumer protection.

<rigo> issue-175: Plan would be to have a very simple decision of Service Provider and have a best practice or guidance document non-normatively as an attachement to the Compliance Specification

<trackbot> ISSUE-175 Have an appendix of best practices? notes added

… incumbent upon us to say you can comply with DNT or not, but not incumbent upon us to relitigate 15-20 years of internet evolution of how data flows among internet and service providers who provide a valuable function ont he backned, create innovation, ...

<hwest> Justin, I can take a first run at combining the three definition pieces

aleecia: closing the queue on this

… pen from alex

afowler: quick response to lou

… establishing expertise is important in comments

… as someone who spent 8 years auditing businesses including DAA members, can say with certanty that in engagements i was involved in, we found variance in business practices form what they were expecting in temrs of data management

… not to say there were bad intentions / illegal / unethical conduct, just that practices wer enot up to snuff in terms of what they were expressing in privacy policies / general compliance

<fielding> Note that DAA definition of "service provider" (an ISP advertiser) has nothing to do with our definitions, so please don't suggest the DAA applies to this definition.

… agree with premise that organizations largely legal/ethical/well intentioned, but as a privacy professional it's still an emerging field and this si complex, if we can help establish improvement through this standard we make the job of privacy officers stronger

aleecia:

rachel_n_thomas: alex, in response as a former CPO and a PP myself, certain difficulties when you get into client environment, disagree that a standard would make this more likely to resolve those problems

… to point about a best practices document

… point to scope/charter of recommendation track specs, encourage us not to get into policy making outside of what is necessary for the technical standard

peter-4A: not to belabour point, but struggling with scoping issue

… going into what seems to lead towards an ambitious exercise to touch on intracicies of vendor relationships, etc

… when we are driving towards TPE

… as others explained, many stautuory / regulatory issues

… attempted to address

… suggest that other bodies address those and we stay on track

<Chris_DAA> afowler, to your point, are you prepared to get specific about which companies for which you have audited, do not comply with their stated business practices? BTW- the DAA has a compliance mechanism and complaint mechanism, so perhaps you should bring your concerns with individual companies there. CBBB runs those mechanisms.

aleecia: break now

… switch scribes

aleecia: we didnt make it all the way through, missing ISSUE-156

s/156/16

… back in 30m

<npdoty> half hour break. adjourned.

<bilcorry> group is taking half-hour break

I apologize for the typos though

mac keyboard :(

<johnsimpson> Nick, what is call code again, please

<johnsimpson> Thanks

<justin> ?

<johnsimpson> are we back?

<johnsimpson> thanks, hearing nothing

<robsherman> scribenick: robsherman

<npdoty> starting up again.

<johnsimpson> thanks

aleecia: (Summarizing issues for this session.)

ISSUE-132?

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

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

<vinay> Nothing is being presented via AdobeConnect. Aleecia's computer for some reason can't share on it. Sorry!

<tl> +q

<fielding> just text in TPE

<johnsimpson> thanks, Vinay

aleecia: We've addressed this substantively, but have no text. Maybe doesn't belong in defs & compliance.

<tl> +q

… Potentially create a new section. Should someone work on text?

<johnsimpson> i thought there was text in TPE

<fielding> or do you mean retention of information from DNT:1 requests?

tl: Have TPE section on this that pretty much covers this.

<dsinger> end of section 3 of the TPE, includes "Implementations of HTTP that are not under control of the user must not generate or modify a tracking preference.'

<npdoty> I agree, TPE section seems sufficient

… In Santa Clara, we discussed examples of this — including a proxy to ensure that each HTTP request has a specified header.

… No need for more text if we comply with other requirements, but maybe add a pointer.

dwainberg: Agree w/ tl.

… Leaves open questions of who is responsible for ensuring that it's a deliberate choice and what we do if it's not.

jmayer: Agreement on "not meddling." Maybe pressure on definition of an intermediary.

… Ex: would a server-side proxy count as an intermediary? Does it matter if it's within server's control?

tl: Don't need a definition of intermediary if we say that the rules are the same.

… Whether you're a UA or intermediary or martian, we don't need to define those categories if we know the substantive obligations.

jmayer: If web server removed DNT header for certain browsers, how do we think about that?

<WileyS> +q

<fielding> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#page-10

… No problems coming from user perspective, but maybe from server perspective.

<BrendanIAB> Is the "intermediary" required just to meet the "user intent" or also the rest of the features?

tl: Can't we subject that scenario to the same test we've already described?

<npdoty> I assume that a server's compliance is considered on the whole, rather than defined as different sets of intermediaries.

jmayer: One possibility is that the server is within the control of the party running the website, so we wouldn't consider it an intermediary.

<MikeZ> +q

<tl> +q

aleecia: Question is what if we add no text, and don't use the word "intermediary"? Would we be okay with the text as it stands?

ifette: No.

jeffwilson: Do we have an open issue on where intermediary is required to sync status with JS API?

aleecia: Let's discuss tomorrow.

<fielding> note that the inbound connection of an intermediary isn't even necessarily HTTP, so it is hard to require non-meddling in general

dsinger: We expect sync, but if that's not clear we should make it clear.

<tl> +q to try and express the difference between the server (which I think is the responsibility of the person running it) and an "intermediary" as we've generally been talking about it which -- unless specifically instructed by the user shouldn't edit it.

<jmayer> s/Let's discuss tomorrow./Let's discuss tomorrow. That's a matter for the TPE document./

ifette: Procedural concern about people raising pens to respond to something that's been said rather than for clarifying question. Rely on queue.

aleecia: +1

ifette: ISSUE-132 is important specifically because of this issue. Need intermediary requirement to ensure they aren't creating an inconsistent situation. If proxy is changing header and server is ignorant of this, the intermediary creates a problem for both server and user. Not sure how to avoid this problem, but important to say that we shouldn't create these problems.

<BrendanIAB> +1 to not creating problems with JS and HTTP out of sync

aleecia: Leave this issue open but shift from Compliance to TPE?

WileyS: Seems related to requirement to honor non-compliant DNT signals. If there's an intermediary that modified DNT setting on behalf of a user, would that be compliant? May want to solve that issue before coming back to this.

aleecia: I'd like to solve this issue as it is.

<fielding> better link for intermediary definition: http://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p1-messaging.html#intermediaries

MikeZ: Agree with ifette that we need one signal. Challenge with this issue relates to discussion about the "tri-part state" and how option is presented to users. Intermediaries aren't user-facing and may not be able to present options and tradeoffs.

… Agree that if we get the spec right then this goes away, but I'm worried we haven't gotten it right.

<jmayer> We could use a networking definition of intermediary. We could use an HTTP definition. We could craft our own definition influenced by both.

tl: Parts of network infrastructure that are under control of party receiving the signal — the party has an obligation to comply, and we don't need to impose that liability on intermediaries directly.

<npdoty> WileyS, is your concern about "intermediaries" on the server-side? or about a user-controlled intermediary setting a DNT value?

<WileyS> Both sides

<WileyS> Nick, both sides

<Zakim> tl, you wanted to try and express the difference between the server (which I think is the responsibility of the person running it) and an "intermediary" as we've generally been

… Difficult to design a proxy that implements DNT correctly, but we shouldn't say that's impossible. We can have a standard that offers this and says that, if you can't do this right you shouldn't do it.

<npdoty> dsinger, I thought we had dropped the "echo" requirement as not commonly important

dsinger: How does the UA know what the server thinks it's responding to? Ex: there are old proxies that strip HTTP headers they're not familiar with, so you may think you're sending DNT:1 but not having it get through.

<dsinger> this is closely related to the user/user-agent being able to check what the server actually got. that's an open question against "what are the response and well-known resource for"?

<BrendanIAB> dsinger - you require that the JS and the HTTP header be in sync, so that you can doublecheck

<WileyS> dsinger, you'd get that in the Server response

<WileyS> dsinger, UA should be able to see the disconnect between signal sent and response received

rvaneijk: Sometimes ISPs add subscriber IDs to headers. When speaking about intermediaries, is that something we should address?

… If DNT is valid, this kind of injection of headers with IDs conflicts with the idea of DNT. Not sure how to address this specifically, but I am concerned about it.

<dsinger> to WileyS: I think if someone changed your DNT:1 to DNT:0 you'd see the "I got consent" response. But if it got deleted, you only know "I behave according to 3rd party rules" and you don't know if your DNT:1 made it or not. At least, it's worth checking that we cover this.

aleecia: Add another compliance section for ISPs. Don't know if we want to go down that path, but not sure there's another option.

<WileyS> dsigner, I'm fairly certain we do but easy enough to run this use case against the TPE

<fielding> It is easier just to say that an intermediary must relay any received user preference if the information received in the request is forwarded.

… Any thoughts on how to address this?

<BrendanIAB> To rvaneijk point - I think this is out of scope of the DNT group, and really is part of HTTP 1.2?

<BrendanIAB> Given that Tracking Protection work is for expression of a preference, rather than eliminating data on the HTTP request.

rvaneijk: Separate issue about ISPs injecting HTTP headers.

npdoty: Understand the privacy concern. Not sure if we want to address it here. I think the expectation of many in the TPWG is that we're dealing with endpoints and are technology-agnostic. So rather than focusing on specific methods of tracking, the requirements on the recipient are the same. (That is, it doesn't matter whether party gets an identifier through a cookie or through an HTTP header.)

rvaneijk: Treat this as data?

aleecia: Or treat the ISP as a third party?

bryan: This is separate from what we're focusing on here.

<fielding> hah

<Zakim> fielding, you wanted to suggest It is easier just to say that an intermediary must relay any received user preference if the information received in the request is forwarded.

fielding: ^^^

aleecia: Sounds like this is more TPE than compliance.

<npdoty> issue: requirements on intermediaries/isps and header insertion that might affect tracking

<trackbot> Created ISSUE-176 - Requirements on intermediaries/isps and header insertion that might affect tracking ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/176/edit .

fielding: Don't know.

<rvaneijk> s/Treat this as data?/Treat this as data append?

aleecia: Straw poll: problems with fielding's proposal?

<npdoty> ACTION: vaneijk to draft explanation on intermediaries and inserted headers [recorded in http://www.w3.org/2012/10/04-dnt-minutes.html#action07]

<trackbot> Sorry, couldn't find vaneijk. You can review and register nicknames at <http://www.w3.org/2011/tracking-protection/track/users>.

<npdoty> ACTION: van eijk to draft explanation on intermediaries and inserted headers [recorded in http://www.w3.org/2012/10/04-dnt-minutes.html#action08]

<trackbot> Created ACTION-301 - Eijk to draft explanation on intermediaries and inserted headers [on Rob van Eijk - due 2012-10-11].

<npdoty> action-301: see issue-176

<trackbot> ACTION-301 Eijk to draft explanation on intermediaries and inserted headers notes added

<tl> +q

efelten: tl talked about the possibility that an intermediary could satisfy the requirements of the spec (ex., gets informed consent from user to become first party).

… If intermediary figured out how to do that, could it inject a DNT on behalf of the user?

fielding: My proposed text would require proxy to forward DNT:0 that came from the browser rather than being able to replace it with DNT:1.

<fielding> I agree with ifette, but he can have the action

ifette: Disagree with Roy's text. Not strong enough to simply relay a preference received from browser. "Relay" should be changed to "be consistent with" because we have the issue of header vs JS API. If browser is in an inconsistent state, that creates a problem.

aleecia: Can fielding/ifette work on this in IRC?

<ifette> I would suggest that "an intermediary must not add or change any signal that will result in a server receiving an inconsistent DNT state when looking at the DNT value expressed in the header vs the DNT value expressed via the JavaScript API"

tl: I am concerned that fielding's proposal would remove the possibility of several sophisticated implementations, and I don't think we need it because there's already an obligation to represent the will of the user.

<jeffwilson> ksmith +1

ksmith: If you're going to have a JS API, you can't allow intermediary to change header.

<bryan> I also agree that specifically forbidding technical solutions that are aligned with DNT's intent (preference of the user) is a bad thing

<WileyS> Use case population: 1

tl: Disagree. I have multiple browsers. I also have a proxy that adds DNT header. And I have a database that decides which sites get DNT:1 vs DNT:0. Finally, I use browser plugins. This whole thing is compliant.

<dsinger> suggest we set functional rules,

<fielding> not following how tl's case is prevented by intermediary being consistent

bryan: We shouldn't overstate this problem. tl's example is a factor of the scalability of DNT.

… We should be careful about overly restricting the possibility of new solutions to this problem.

fielding: I didn't see anything in tl's description that would suggest an intermediary that would override DNT value.

<dsinger> you should be able to have your preference in the cloud and have a JS API and a proxy both of which use the cloud setting, in all your devices

tl: My proxy on my gateway is the only thing that sets DNT header.

fielding: So then there's no DNT header to change.

<BerinSzoka> like most typical users, Tom runs a proxy server on his gateway... presumably, cURL is involved, too

dwainberg: This depends on requirement that DNT signal reflect user's explicit, deliberate choice.

… If we're going to go down the road of imposing obligations on intermediaries then we need to define what an intermediary is.

aleecia: We'll need to do that.

<fielding> and specifically, this would be for intermediaries that forward any information in the received request

dwainberg: If we're going to discuss it, then we need to do so as a threshold matter.

tl: I can live with a rule that prohibits modifying or removing a DNT signal.

<Chapell> +q

ifette: "an intermediary must not add or change any signal that will result in a server receiving an inconsistent DNT state when looking at the DNT value expressed in the header vs the DNT value expressed via the JavaScript API"

<BrendanIAB> I don't think that a rule "you cannot modify a sent DNT header" is reasonable, because it precludes the possibility of an ISP level consent management system.

<Chapell> chapell is tempted to raise his voice to zakim

tl: I can think of different text with fewer words.

<BrendanIAB> Since the queue is closed, sign me up to help wordsmith

aleecia: Let's leave the issue open, and tl will come up with competing text that we can discuss via the mailing list.

<tl> Suggestion: "If an HTTP request includes a DNT header, do not modify or remove it."

<tl> +q

ifette: Possible to create an intermediary that's compliant. I just think that it's difficult, and any text that we come up with needs to maintain that consistency.

tl: +1

<Chapell> TL: how does your rule apply to to non-compliant DNT headers?

<npdoty> ACTION: lowenthal to draft intermediary requirements, without implementation details (with Brendan) [recorded in http://www.w3.org/2012/10/04-dnt-minutes.html#action09]

<trackbot> Created ACTION-302 - Draft intermediary requirements, without implementation details (with Brendan) [on Thomas Lowenthal - due 2012-10-11].

<bryan> one of the main weaknesses of such a blanket restriction is that the "user" in DNT is not always the owner of the device e.g. for kiosk browsers

<Chapell> TL: not trying to beat the drum of the apache announcement, but your rule seems at odd with Apache's treatment of IE

<fielding> tl, text doesn't work because it may not be HTTP on both sides of intermediary

<tl> Chapell: Thou shalt not modify or remove DNT headers. Don't second-guess them.

<Chapell> TL: not really answering my question

<tl> fielding: Patch, plz.

<fielding> my original wording ;-)

jmayer: Two buckets to think through: (1) intermediaries shouldn't modify or delete DNT headers if the user is actually controlling/setting it. (2) intermediary that is used for a purpose other than UA (ex., web server software) and wants to make a claim about DNT compliance.

<tl> Chapell: Yes. It does. Do not modify or remove a DNT header, even if you think it's wrong.

<Chapell> TL: in your opinion, doesn't the Apache announcement re: violate your proposed rule?

<fielding> Chapell, of course it does.

… Resolution would be to split into (1) intermediaries that touch packets in flight, and (2) software and hardware vendors that provide non-UA and want to make claims about DNT compliance.

<Walter> For what reason would you alter a DNT header?

<Chapell> Fielding: then I absolutely object to TL's language

<tl> Chapell, fielding: I think that anyone who used Apache would have to change the default config to comply with DNT.

rvaneijk: This is in the context of non-repudiation.

ifette: Integrity.

<Chapell> TL: unlike certain religious leaders, browsers are not infallible

<Chapell> (:

<fielding> It is impossible to comply with DNT right now.

<tl> Chapell: Intermediates should not second-guess clients.

<bryan> the notion that a UA (of which there may be many that a user uses) is always and distinctly managed by the specific user making a request (when that user may have logged into a service without modifying the UA settings), is a key weakness

ifette: Non-repudiation is when someone can prove that you said something at a later point in time. Integrity is proving that what you said remains intact.

aleecia: Appreciates ifette's pen-raising.

<Chapell> TL: again, the browsers are not infallible...

<fielding> huh?

tl: Roy and Alan both object to a rule prohibiting modifying/removing DNT signals.

<fielding> tl, I was proposing such a rule

<Walter> rigo: I think that actually is sensible for the multi-domain issue

<bryan> +1 to the objection on an explicit rule

dwainberg: Why is a server an intermediary if a browser is not?

<tl> fielding: I thought you said that my rule nixed Apache?

<dsriedel> @TL: is apache an intermediary and not the "end-point" in the conversation between the browser and the server (apache)?

<npdoty> (for the notes, some non-scribes are using : to direct comments to others, not scribing what the recipient is saying)

<fielding> Apache httpd has origin server, proxy, and reverse proxy functionality

jmayer: Agree w/ aleecia that these are distinct issues. But they tend to get lumped into "intermediary compliance" and we should better distinguish them.

<tl> Revised suggestion: "If a communication includes a DNT signal, do not modify or remove it."

aleecia: jmayer to create an issue.

<efelten> scribenick: efelten

<tl> Chapell, fielding &^

<npdoty> how does this differ from issue-132?

aleecia: Will finish the queue

<dsinger> from the point of view of HTTP, the server and the user-agent are the end-points; from the point of view of compliance, the user and the service are.

npdoty: Queue was closed, people using fingers to speak.

<Chapell> mutual

<dsinger> so, "intermediary" is ambiguous until you talk about the context

tl: Modified language to try to address concerns from Chapell, fielding etc. What do they think of the new language?

<fielding> that is another issue

aleecia: Won't solve in this session.

<Walter> would "intentionally" be helpful in this context?

<fielding> origin server

<tl> Walter: no

<BrendanIAB> There's a difference between "second guessing" and "having user configuration"

dsinger: "intermediary" ambiguous. Talking about HTTP protocol, or DNT compliance? It matters which context we're talking in.

<BrendanIAB> If the intermediary was configured by the user, then the intermediary isn't second guessing the browser signal, and should be able to modify.

… modifying user expression between user and UA is an intermediary for DNT purposes, but not an HTTP intermediary.

<jmayer> ISSUE: Should we specify compliance requirements for software and hardware other than user agents? For example, is a web server package compliant if it tweaks DNT headers?

<trackbot> Created ISSUE-177 - Should we specify compliance requirements for software and hardware other than user agents? For example, is a web server package compliant if it tweaks DNT headers? ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/177/edit .

xxx: Let's use the queue.

<dwainberg> dsinger, yes, but I think it's between the user and the recipient party

<npdoty> s/xxx/Chapell/

<vinay> s/xxx/chapell

<justin> Difference between stripping and ignoring.

… Does the Apache decision violate tl's rule. Don't think that's fair.

… [questions legitimacy of process]

<WileyS> +1 to Alan

<dwainberg> outside of that HTTP protocol context, then, browsers, servers, etc. are all intermediaries -- in your formulation

<tl> Scribe note: at no point have I stated that Apache would break my rule. Roy said that. I'm not sure I agree.

aleecia: We have text from Ian, text from Roy, text from tl. Let's capture those, an action for each against ISSUE-132.

<fielding> An intermediary must relay any received user preference if the information received in the request is forwarded.

<WileyS> Actually the UA is an intermediary as well. This is between a user and a Server.

<ifette> ISSUE-132: I would suggest that "an intermediary must not add or change any signal that will result in a server receiving an inconsistent DNT state when looking at the DNT value expressed in the header vs the DNT value expressed via the JavaScript API"

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

<justin> There should be transparency regardless. Intermediaries should not strip, we can have the discussion later about whether end parties can dispute/ignore/etc and whether/how that should be conveyed back.

aleecia: move on to new topic

<ifette> ISSUE-32?

<trackbot> ISSUE-32 -- Sharing of data between entities via cookie syncing / identity brokering -- open

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

… ISSUE-32 now

… queue should be open now

ISSUE-32

… ACTION-106 against ISSUE-32

… Have text from mailing list from Vincent. Spent time on this. No complaints on mailing list.

… [reads text]

<bryan> (what I wanted to say) re what Tom noted, if an intermediary does have evidence that a DNT signal does not reflect the intent of the user then it should have latitude to modify the signal

<npdoty> Chapell, I think that tl's rule is suggesting that intermediaries should not remove an existing header, and does not speak to the question of how servers must respond to headers they believe do not respect the user's preference

<WileyS> Justin, if UAs (as an intermediary to the user) can alter a user's express choice, then other intermediaries should be able to correct this.

… text has been revised several times. Are we ready to adopt it?

<tl> I think that server is the responsibility of the recipient controlling it.

hwest: May be simple definitional thing: ID brokering means something different to me. Need to avoid terminology conflict.

<tl> npdoty: I'm having difficulty loading the tracker. Is it just me?

<justin> WileyS, bryan, Why not leave to end server? Why are intermediaries policing?

vincent: Text meant to be about cookie synching. But cookie synching is just one way to implement this, mean to be more general.

aleecia: More generally, synchronization between parties?

vincent: yes

<Chapell> dpdoty: i'll take a look at the text when TL revises. as written, I believe that it says something else

ifette: Don't see normative text here. No MUST, SHOULD etc. Need to fix

<tl> npdoty: Just came back for me.

<Chapell> Sorry NPDoty

aleecia: [points to normative text at end]

<tl> npdoty: Still very slow for me though.

dwainberg: Not sure I understand what this does that's not already in the spec elsewhere.

<tl> ISSUE-132 My text suggestion: "If a communication includes a DNT signal, do not modify or remove it."

aleecia: Asked and answered in email. Points to email from Vincent on March 21

<BrendanIAB> dwainberg - what it does is prevent the inclusion of HTML elements by a 3rd party to another 3rd party.

amyc: +1 dwainberg, don't understand what this changes.

… what does this limit that is not already limited?

vincent: Depends whether exceptions are transitive for third parties. If not transitive, this might change what's allowed.

rigo: This is the auction case we wanted to cover, in the transitive permissions discussion with Brooks.

<vinay> Fielding - correct. For some reason, Aleecia couldn't share her screen.

… Transitivity covers part of what you want. This is limitation on transitivity.

<BerinSzoka> once again, I'm disturbed that we're tossing around terms that aren't defined. How many lawyers are there in the room, anyway?

<vinay> Here is the page she is looking at -- http://www.w3.org/2011/tracking-protection/track/issues/32

<fielding> tl, my language is better

jmayer: Suggest we not have language on cookie synching. Should have general discussion of unique IDs and sharing thereof. That should be sufficient.

… Don't need to address this specific present business practice.

<Zakim> ifette, you wanted to ask how this specific text would affect redirects

ifette: Looking at text, know we have open issue on redirects.

<tl> fielding: Can you re-paste?

<robsherman> +q to raise a drafting point

… Not clear what "must not transmit" means for redirects.

<fielding> An intermediary must relay any received user preference if the information received in the request is forwarded.

… If want to restrict back-end cookie synching, that's fine. But worry about possible complications with redirects.

… Not comfortable with this text until more clarity on some use cases.

<BerinSzoka> to put this in engineer-friendly terms: building a spec without clear definitions is a bit like building a house without a foundation: the taupe shutters might be very pretty, but when the first wind of criticism blows in the real world...

<tl> fielding: I want to be explicit that the two things you shouldn't do are: (1) remove or (2) modify a DNT signal.

… Would be more comfortable if it were more specific about identifier synching, but think this may already be covered by third-party sharing language.

<Walter> BerinSzoka: +1

… Might be agreeing with Jonathan.

<Chris_DAA> fyi, "identity brokering" is not a term of art in the ad industry

Brooks: Text uses terms of art like SSP, DSP, which should be defined if used.

<Marc> +1 to Brooks

… Language needs to be more careful.

aleecia: Is this a drafting issue, or do you have a problem with the substance?

<npdoty> q

<vinay> +1 to Brooks

Brooks: Would have to see redrafted language to know.

<robsherman> -q

<fielding> tl, which isn't relevant because the forwarded request is a different message, and thus neither removed nor modified

<BerinSzoka> is anyone keeping a list of key undefined terms? That might be helpful if this bird is actually supposed to fly anytime soon...

<npdoty> good volunteering, BerinSzoka

aleecia: Queue is empty. Vincent, please give a quick summary. Do we still need this, and why?

<tl> fielding: What?

<WileyS> +q

Vincent: Depends on transitivity of exceptions. If not transitive, this isn't needed. If transitive, need something along these lines.

… If you're transmitting IDs, probably need some language.

aleecia: Postpone this issue, come back after we have worked out transitivity.

WileyS: Is there still a question about transitivity of permitted uses? Though it was already decided as transitive.

<fielding> tl, A ---> intermediary ---> B , there is no implication that the A side is even using the same protocol as B, let alone the same message

<jmayer> We do not have consensus on transitivity of permitted uses or user-granted exceptions.

rigo: [comic relief]

<BerinSzoka> +1

<BerinSzoka> looks like schunter couldn't handle the "vibrate" mental image

… Vincent is trying to determine what the transitivity of permission for user-granted exception means.

<tl> fielding: When you're relaying or forwarding a message, it's the same message.

<npdoty> jmayer, if you have an alternative to the text that rigo has proposed on transitivity of exceptions (which I believe is now in the TPE, via dsinger), it would be good to document that

… Already discussed at some point, even in a transitive situation, might hit somebody who user explicitly says not to allow.

<fielding> read the text you proposed

… Suggest Vincent's concern is already covered by current text on transitivity.

<jchester2> +q

WileyS: If you agree in EU with financial fulfillment requirements, then this is still a non-issue.

<tl> fielding: If I whisper my communique in the ear of a messenger who writes it down to communicate it to a deaf messenger who sends it via morse over a telegraph, it's still the same message.

… Can expand this issue to user-granted exceptions, but it's a null issue for permitted uses.

aleecia: What I'm hearing: I have a chain from A to B to C, even though user has said no specifically to B, data would be able to go through B to C for permitted uses?

… Right?

WileyS: yes

rigo: WileyS, do you think the financial permitted use cover the whole ad exchange scenario?

wileys: Yes, that's a requirement of logging.

aleecia: Then what does it mean to send DNT:0 to party B?

<jmayer> To be clear: this is Shane's interpretation of EU law. Many would disagree with that interpretation.

WileyS: [scribe missed the response. WileyS, help please.]

rigo: If permitted use given to first party site-wide, what you're suggesting seems very broad.

<jchester2> Can Shane place in IRC some use cases of how even with DNT 1 sent, ad entities will be able to process the data under the proposed permitted uses?

WileyS: Disagree with premise that permitted uses equal everything.

… Important to understand how ad exchanges and cookie synching work.

Walter: Introduces self. Works for Open Rights group.

<jchester2> -q

… Don't follow the argument for why accounting requirements would allow party B to do tracking.

<fielding> tl, I think we have to agree to disagree -- message is a defined term in HTTP, so trying to "improve" the text by assuming some other ambiguous use of the same english term is not productive.

aleecia: Rigo and WileyS should discuss.

<jchester2> +Felten

<Chapell> I'm sorry - but can someone let me know who our new guest is?

<Chapell> I didn't pick up on the intro

<tl> fielding: Good thing I didn't use the word "message" then, isn't it?

… Defer issue. Larger issue has surfaced for discussion.

<Chapell> a quick note in IRC would be helpful

<tlr> s/Open Rights group/Vrijschrift/

<Chapell> Invited expert? W3C Staff?

… Move on to URL redirection, ISSUE-97

<Walter> Ok, I'll reintroduce myself

<Chapell> Thanks Walter

<Walter> I'm a standin for Jim Killock of Open Rights Groups

<tlr> Walter is an Invited Expert. He is with Vrijschrift.

<WileyS> Another consumer advocate/regulator invited expert?

<Chapell> I'm confused - sorry - Vrijschrift is the same as Open Rights Group

<Chapell> ?

<fielding> tl, good point, but you didn't use forward either

<Walter> no, it is not

rigo: WileyS and I have to discuss this. Seems to be a misunderstanding about the transitive permissions issue.

<Walter> Vrijschrift is kind of a 'sister' to ORG

… Will discuss what the status of ad exchanges is under permitted uses.

<Walter> Vrijschrift is a Dutch civil society group

<Walter> tlr: BTW: what are the wifi details? I'm on a laggy GPRS-connection now

Marc: Thanks.

<WileyS> civil society group = consumer advocate in our terms :-)

<ifette> ISSUE-97?

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

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

ISSUE-97

aleecia: Redirection might depend on how we address first parties.

<tl> fielding: I think I'm not following you again.

<ifette> wifi password is cookiemonster

<fielding> tl, it's 3:47am here -- I am not following me

<Chapell> Walter: Thanks

… have some proposed language. Reads use case from Justin.

<tl> +q

<Chapell> .... when were you guys added to the group?

<WileyS> Ian - wouldn't you have to be on the WiFi for the password to be useful? :-)

<susanisrael> walter: wifi id and password behind you on whiteboard

ifette: If you click on something and that results in a redirect chain, think everyone who gets redirected through is part of the chain.

… all should be considered first parties.

<Chapell> Ahhh... never mind. I see Killock

<Walter> susanisrael: thanks

tl: Disagree with ifette. Have previously submitted text on this.

<justin> My language is based substantially on earlier text from tl

<dsinger> I cannot see how the user thought they were interacting with service in the middle of getting to the site they thought they were visiting is a 1st party

… parties in redirect chain might or might not be first parties, depending on whether user would expect the party to be involved. See previous text for details.

<tl> +q

ifette: User expectation is dangerous to rely on. Many users don't understand who might be involved.

<jmayer> +q

<Chris_DAA> +1 to Ian- call for definition of the term "user exception" as it relates to this doc

… Hard to define in an arbitrary interaction how integral a party is to the interaction.

… If you click on an ad, whoever is hosting the ad is a first party.

… If redirected to another site, you're viewing that site so it's a first party.

<jmayer> We already have consensus on the user expectations test for whether a party is a first party or third party.

<dtauerbach> are we talking only about clicks?

<jmayer> I'm surprised that Ian finds that unsettled.

… If intermediate redirect through an ad verification service, that's a first party too.

<WileyS> Jonathan, you have that in your draft text but there is an option that specifically doesn't rely on that

tl: User would understand that?

ifette: That should be basis for definition.

<jmayer> WileyS, not party size, first party vs. third party.

s/should/shouldn't/

npdoty: All of the first-party definitions we have now involve user expectations.

<rigo> issue-32: This has a relation to the transitive permissions coming out of the first party getting permissions for its third parties. Shane offered the interpretation that permitted uses of financial and audit recording would allow all data exchanges needed to use an ad auction system. The participants of the auction would use all the data coming from the first party under financial and audit. Rigo expressed the opinion that this is stretching the semantic content

<trackbot> ISSUE-32 Sharing of data between entities via cookie syncing / identity brokering notes added

<rigo> of financial and audit into meaning every commercial interaction as every commercial interaction involves by definition a financial transaction.

<Zakim> bryan, you wanted to assert that if the intermediate locations are part of the first party, they should not be considered a 3rd party

<fielding> are we talking about this now? http://lists.w3.org/Archives/Public/public-tracking/2012Oct/0055.html

… If communicating with a party makes it a first party, then everybody is a first party.

<WileyS> Jonathan, our proposal does NOT sit on user expectation: requires corp affilation and easily discoverability

<WileyS> Jonathan, for first party.

<jmayer> WileyS, you're again talking about party size.

<dsinger> OK, if the re-directs are through sites in the same party, that we can handle

<vinay> Roy - no, this: http://lists.w3.org/Archives/Public/public-tracking/2012Jun/0106.html

<susanisrael> nick i think that the use of "user expectation" in those definitions should be reconsidered

bryan: As long as all intermediaries are part of the first party, consider them as first parties.

<dsinger> 'sites that are not the same party as a first party'

<WileyS> Joanthan, okay, let me go check the definition of 1st party again.

aleecia: I'm hearing that redirects within a party don't take you outside first party status. Don't think there's disagreement about that.

<BerinSzoka> maybe we should actually define terms, just a little, before using them?

<dsinger> to Berin :-)

<Chris_DAA> too complex, I agree -- Complexity is specifically out of scope per our charter: "While guidelines that define the user experience or user interface may be useful (and within scope), the Working Group will not specify the exact presentation to the user."

<fielding> heh, thanks vinay, but I was just pointing out my message on first party definition

tl: Let's look at definitions of first and third parties. Let's stick with the definitions we have for first and third parties.

<npdoty> susanisrael, WileyS, I think the concept of "interaction" (sometimes "meaningful interaction") is affected by user's expectation

<Chris_DAA> sorry, wrong one "The Working Group will not design mechanisms for the expression of complex or general-purpose policy statements."

… Let's not make exceptions for specific use cases. Suggest no text on redirection.

<vinay> fielding - oh, got it!

justin: +1

jmayer: +1 to tl.

<WileyS> Nick, need more objective measures - "user expectation" is not easily measured

<tlr> Chris, that language was also known as the "do not reinvent P3P" clause in the charter.

<tl> fielding: Let's put our proposals in the issue (132), and and come back to it later =]

… Once we have agreement that user expectations should generally guide first/third parties, no need to reopen for specific use cases.

<npdoty> WileyS, but you agree that meaningful interaction with a widget makes it a first party?

<hwest> Jonathan, there have been a number of us that have been continually concerned by this idea and asking the question across the board, including myself.

<ninjamarnau> I'm concerned about labelling redirect chains all first parties would lead to blowing these chains up to gain first party rights for more involved services.

<WileyS> Nick, yes - and we've even defined what meaningful interaction does and does not mean.

<bryan> if a 1st party site is architected with distributed resources which are integrated using redirect, they represent a single meaningful interaction of the user when a click results in a chain of redirection though them

aleecia: [not as chair] If we adopt ifette's proposal, couldn't a first party make anybody else a first party by redirecting through a long chain of others?

<JC> +q

<BerinSzoka> Unfrozen Caveman Lawyer is very confused by all these undefined terms being thrown around. he has used this magical real-time collaboration tool that he does not understand to create a list of undefined terms. he invites you all to add to the bottom, and insert comments (ctrl-alt-M), but not to delete or edit the work done by others http://goo.gl/DZAak

ifette: Yes, my definition would imply the whole redirect chain are first parties.

<Chris_DAA> tlr, agree that we should not contemplate something so complex as P3P here. Goal should be simplicity. This is nothing but complex.

<jmayer> +q

<justin> +q

aleecia: Hard for users to know/expect what is going on.

<jmayer> Ian earlier: users don't get what's going on in there browser. Ian now: if it's in the address bar, that's cool.

<jmayer> s/there/their/

ifette: Perhaps, but that's what my definition implies.

ksmith: Agree with ifette, at least to the extent that others are integral to providing the primary content.

<tl> +q

aleecia: Can this be handled via the service provider language?

<tl> +q to say omgserviceproviders!

<npdoty> WileyS, hwest, justin - the current draft doesn't have additional text on meaningful interaction, does someone have that?

<jmayer> npdoty, meaningful interaction == user expectations.

ifette: Redirect might or might not be integral to serving content, depending on use case.

… How do I know what the user expects if I user a standard URL shortener that collects analytics?

s/I user/I use/

<JC> -q

<justin> npdoty, 3.5.1.2.3 --- User Interaction With Third Party Content

… Would be disappointed if I don't get the data.

<rachel_n_thomas> clearly we need a definition of "user expectation" for this conversation to be fruitful.

<fielding> I personally think that defining user expectations by the URI or domain is ridiculous -- what a user sees is hypertext or an image and they are selecting the semantics portrayed by that link, not a URI owner

jmayer: Response to ifette: service provider language lets you use a service provider for link statistics.

… Does that satisfy your use case?

<npdoty> hwest, WileyS, are you comfortable with the 3.5.1.2.3 text on interaction? (yes, it does rely on user expectations as well)

ifette: No. Not clear who it's a service provider to. The user who is using the URL shortener?

aleecia: Might not be a contractual relationship in that use case.

<WileyS> Nick, can you paste a link to the version you're looking at?

<npdoty> http://www.w3.org/TR/tracking-compliance/#user-interaction-with-third-party-content

<npdoty> (apologies, a link is obviously more useful than the TOC numbers)

jmayer: Seems like a substantive disagreement. If user on forum posts link using link shortener, I don't think link shortener should be tracking users who click.

… Doesn't seem consistent with user expectation.

aleecia: Close queue, toward lunch.

<ninjamarnau> +1 jmayer

<rachel_n_thomas> there is absolutely a contractual relationship involved in the case of a URL shortener, contrary to aleecia's assertion. the contractual relationship is between the user (consumer) and the URL shortener website itself.

<rachel_n_thomas> that would make it a first party.

<BerinSzoka> during lunch, I invite you all to add to this list of key undefined terms http://goo.gl/DZAak

justin: There are two definitions of first/third parties in the draft. Link shorteners aren't first parties under either definition.

<Zakim> tl, you wanted to say omgserviceproviders!

<WileyS> Nick, the "average" modifier in the definition was added outside of the standard process. I'd like to request that be removed as I believe that's the linking element you're seeing as "user expectation".

tl: Clarifications...

… Which user's expectations? Should be the user who is clicking a link.

<jmayer> justin, I thought we'd decided to go with user expectations over pure ownership.

… Service provider to whom? Whoever makes an agreement with the provider. Probably the person using the shortener service in ifette's use case.

<jmayer> In part because we never could button down what the ownership would be of.

<npdoty> WileyS, is your concern just with the word "average"? and you're okay with the user's knowing and intentional expectation

… If the shortener is not evident to the user, and user sends DNT:1, shortener service should comply with third party rules.

<WileyS> Nick, "intentially communicated" - no "expectations" in the text.

… can still gather unsinkable stats, and permitted uses as third party

… Not everybody who receives an HTTP request is a first party.

s/unsinkable/unlinkable/

<justin> jmayer, I think user expectations are implicit in the second definition as well --- I'm just noting that under the second option that came from the industry proposal, url shorteners are third parties.

rigo: Don't want to barrage users with consent dialogs.

<npdoty> WileyS, sorry, I'm not referring to "user expectations" literally in text, but versions of definitions that refer to user knowledge or user intention

<jmayer> justin, if the ownership test applies to the domain name in the URL bar, then shorteners are first parties.

<tl> Whenever Ed is scribing, I feel incredibly long-winded. Ed's amazingly good at distilling the gist of folks' sentiments.

aleecia: quick straw poll. Who else in room agrees with Ian's position.

… some tepid support.

s/some/a little/

<rachel_n_thomas> strong "tepid" support for ian's position.

<WileyS> Nick, intent does not mean expectation - but in both cases a definition should be provided with examples. We give examples of what would NOT meet an intentional action by a user. Doesn't rely on their "expectations" which can't be measured.

<MikeZ> strong tepid support for Ian's position. Would like to see the actual language.

<justin> The ownership test applies to the site the user "visits" . . .

<MikeZ> Do we now need to define "stong tepid support"?

<BerinSzoka> Caveman lawyer has added "visit" to his list of key undefined terms

<BerinSzoka> http://goo.gl/DZAak

<BrendanIAB> Visit? Is it "click on a URL" or "have a URL displayed in my URL bar"?

<npdoty> ACTION: fette to draft definition of "visit" [recorded in http://www.w3.org/2012/10/04-dnt-minutes.html#action10]

<trackbot> Created ACTION-303 - Draft definition of "visit" [on Ian Fette - due 2012-10-11].

<ksmith> Would the 3rd party promotion idea promote a url shortener to 1st party?

… Asks ifette to propose specific language on redirects.

<fielding> the current text is not consensus

<rvaneijk> @BrendanIAB: what about QR code?

<johnsimpson> current text does it

<schunter> http://kantjil.nl/en/?page_id=2584

<BrendanIAB> QR codes are a massive security vuln!

<npdoty> ACTION: fette to draft proposal on url re-direction [recorded in http://www.w3.org/2012/10/04-dnt-minutes.html#action11]

<trackbot> Created ACTION-304 - Draft proposal on url re-direction [on Ian Fette - due 2012-10-11].

matthias: [arrangements for dinner at downtown Dutch/Indonesian restaurant]

<BrendanIAB> But that's an implementation case - the QR provider translates the code into a URL.

<rvaneijk> @BrandanIAB: so we have agreement that redirects through QR codes is not ok?

<BerinSzoka> - what about cURL? countless users want to know!

<Walter> Kantjil is fine

<npdoty> break for lunch. back in an hour.

<BrendanIAB> Not at all - QR is a different protocol - a method of taking an image and turning it into a URL

<dsinger> issue-140?

<trackbot> ISSUE-140 -- Do we need site-specific exceptions, i.e., concrete list of permitted thirdparties for a site? -- closed

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

<dsinger> scribenick: dsinger

<BerinSzoka> hoorah for well-timed breaks!

<npdoty> issue-122?

<trackbot> ISSUE-122 -- Should we have use limitations on referrer data? -- open

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

aleecia: break now between 2 sessions and we'll end early
... for those on phone, screen sharing broken

…we ended up talking this over, and agreed to come back, and never did. Now we do

…there might not be a godo technical way to limit xmitting referrers; well, some browsers can, some not

<fielding> er, only the header fields -- they are not the only way to refer

… we can't prohibit it, but we could suggest it as a good practice

<tl> +q

… no text, no action items, only discussion

<tl> +q

<jmayer> +q

<WileyS> +q

<npdoty> issue-122?

<trackbot> ISSUE-122 -- Should we have use limitations on referrer data? -- open

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

<fielding> Why would we want to limit referrals?

<npdoty> I think the question is whether there would be additional limitations beyond existing third-party requirements

tl: are we talking about collection, retention, or use? maybe whether the browser sends it or not helps, but is almost orthogonal?

<WileyS> +1 to Tom

<robsherman> +1

<BrendanIAB> +1 to "why should we limit the *sending* of HTTP REFERER when DNT:1 is set?"

tl: would prefer that this is covered by the principles, rather than write explicit text

aleecia: does anyone want text?

<npdoty> no interest in the room on writing text.

<npdoty> close issue-122

<trackbot> ISSUE-122 Should we have use limitations on referrer data? closed

….hearing no, issue-122 is CLOSED

<npdoty> issue-69?

<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

<johnsimpson> Did we address Issue 16 what is colection in th4 morning?

<tl> +q

<npdoty> jmayer, WileyS, are you in the q for issue 69?

aleecia: introduces issue. now, we have an optional set of flags. could it be more readily found than in a privacy policy

<tl> +q to say that this have been overtaken by events. Close?

<jmayer> -q

…anyone to describe min. notice?

<WileyS> -q

<jmayer> (pass)

<Zakim> tl, you wanted to say that this have been overtaken by events. Close?

tl: overtaken by events?

aleecia: looks like issue-69 is CLOSED!

<npdoty> close issue-69

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

<npdoty> issue-65?

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

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

aleecia: we were supposed to have 2 competing proposals and a decision process; and they thought and didn't write

<justin> To be clear, ISSUE-69 is addressed through the explicit and informed consent requirement, the contours of which are still being debated.

… we now feel we don't need text on logged in and logged out

jmayer: confirming: this has become a specific instance of a general issue of when a user grants an exception. The general contours may well subsume this.

<jmayer> s/may well/do/

<npdoty> I think we're dropping this section: http://www.w3.org/TR/tracking-compliance/#logged-in

WileyS: when we talk about user consent for an exception, that would overtake this

<justin> Yes, what WileyS has said.

aleecia: close 65?

<fielding> they are out-of-band

<npdoty> does the TPE not point to the out-of-band section in Compliance?

<fielding> npdoty, seriously?

dsinger: we might need to discuss this in OOB exceptions tomorrow

rachel: are we thereby deleting 6.3.2?? usually closing issues would mean no change.

aleecia: yes, we delete the section, and logged-in/out are not otherwise mentioned

<npdoty> ACTION: brookman to remove 6.3.2 on logged in transactions [recorded in http://www.w3.org/2012/10/04-dnt-minutes.html#action12]

<trackbot> Created ACTION-305 - Remove 6.3.2 on logged in transactions [on Justin Brookman - due 2012-10-11].

justin: deleting as we speak!

<BrendanIAB> OK - what happened over lunch?

<BrendanIAB> I'm not listening in to the same call as I was an hour ago!

<npdoty> close issue-65

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

aleecia: we can close issue 65!!

….3 down!

issue-54?

<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

<justin> tl is this true?

aleecia: this is an old issue; it's a first party.

… anyone disagree?

<WileyS> +q

<tl> justin: Is what?

npdoty: to clarify: I understand I got some 1st party data, and now I am a 3rd party I can use that data?

aleecia: no, that's not what I thought

<jmayer> +q

WileyS: this is a similar discussion to logged-in/out, as to what the scope of the consent is

<justin> http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#first-party-data

<robsherman> +q

<justin> This is the language currently in the text to address this issue.

<npdoty> it might be behavioral from your behavior on the first-party site, right?

JC: reminds that this is not 'tracking' data, but data voluntarily given by the user

<tl> +q

<amyc> nick, this is about registration info

Chris: if not related to targetting, then out of scope

<justin> It's clearly targeting.

<vinay> its personalization, not targeting (in my opinion)

<amyc> it is registration info that the user has explicitly provided

<Chris_DAA> point of order: if it's not based on targeting or tracking, it's out of scope for this working group

<BerinSzoka> I, for one, would find it amazingly useful to clarify, at some point, what is, and what is not, in scope, by defining tracking

jmayer: phrase differently. We got consensus to close issues. Is this true: "in the absence of consensus, you cannot use info a 1st party gets to target on another website"

JC: what do you mean by 'gets'

aleecia: info provided as part of reg. info

<npdoty> do we expect a different outcome if the data was provided explicitly to the first party or was just collected while I was browsing a first party site?

<fielding> no

<fielding> it is allowed by DNT

jmayer: is it: no you can't, unless the user gave consent

<Chris_DAA> tlr, can you please weigh in about the scope question that we keep raising, but Aleecia keeps shutting down categorically?

JC: disagree. DNT does not apply, when the user freely gave info, and it's not tracking. out of scope and close?

<Chris_DAA> +1 to JC

<fielding> DNT does not impact first party personalization, period.

jmayer: is this a special instance of a more general question? can 3rd parties use information they got as a 1st party?

aleecia: beginning to get the issue

<Chris_DAA> "what we allow 3rd parties to do" is not in scope here

<eberkower> But this doesn't say anything about the involvement of third parties

justin: the issue, as given yesterday: go to a sales site, look at something, visit a new site, see an ad from the sales site that's related to my looking

<Chris_DAA> what is in scope is tracking (though that term is not defined by consensus)

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

justin: there is text,

ifette: can we re-title or get a new issue?
... use of 1st party data in a 3rd party context?

<ifette> "Use of data obtained as a first party in a third party context"

<Chris_DAA> jmayer and all, I don't see in the Charter anywhere, "what we allow or disallow 3rd parties to do" (if it is in the charter, please point it out for all of us)

JC: tracking data collected in a 1st party context is not usable; registration information is not tracking info, and is

<justin> I don't think we've talked through the distinction between registration info and passively observed first-party data.

sherman: you cannot collect new data, but if the user gave it to you, such that the user clearly intended you to have it, can you use it?

<BerinSzoka> Could someone please clarify to me how this relates to our scope limitation (tracking)?

sherman: when in a 3rd party context, no, you cannot collect new data. but, when you were GIVEN data in a 1st party context, can you use that?

aleecia: does this clarify?

<johnsimpson> can you please restate?

<fielding> how does the third party know who the user is?

<justin> fielding, by reading a previously placed first party cookie, most like.

<npdoty> I think Rob's explanation fits with Ian's re-titling of the issue

wainberg: not sure we are agreed. is this ANY data provided by the user, or just 'registration data'?

<justin> There is no text ATM distinguishing between observed and declared data.

WileyS: terms we use are 'observed data' and 'declared data', think that's the distinction, and we agree on observed and are discussing declared

<npdoty> do we believe that we will come to different conclusions for data declared to a first party than data observed in a first party context?

<fielding> and there is a cookie and it corresponds to a registered user and there is no consent?

notes we have no definition of 'registration data'

<ifette> gah irc lag

<Walter> Zakim: I've been waving my hand a few times

<ifette> So do we have two issues, "observed" and "declared" data?

<ifette> walter, you're looking for "q+"

tl: clarify: a 1party, when 1st, collected some info (observation or declaration), applies to a number of situations

<Walter> ifette: thanks

…issue is, when as a 3rd party, use the data it legit. gathered as a 1st party?

<fielding> tl, *and* there is no specific consent for that purpose?

dsinger: think this is only for the subset that is declared data

<justin> In the current text, usage is not limited to declared data. I would happy to revise, however.

<aleecia> Giving this a try: can first parties use declared data while in a 3rd party context?

<ifette> aleecia, is the "observed" data still an open separate issue then?

tl: previously we took the example of facebook, it might *worry* users that they are being tracked, so be imprudent, but we wouldn't say. so, is it OK to use declared data, yes, you can (unless you said you wouldn't of coyrse)

<jmayer> If this is about information given to a first party with consent to reuse it in a third-party setting, then it seems just a special case of user-granted exceptions. If this is about information given to a first party without consent to reuse it in a third-party setting, then it seems to be a proposed new permitted use.

WileyS: rejoices at the agreement, but takes an action to define declared data

<Chris_DAA> I maintain that first party data is out of scope here

justin: see 6.1.2.3??

<justin> Ack, sorry working of the newer version.

tl: before we write a defn of declared data, do we want a difference between declared and observed data?

WileyS: we previously agreed that observed data was not usable

[disagreement from the room]

tl: does not agree we agreed that

<WileyS> My bad - apologies everyone

<justin> Sorry, 6.1.1.3 in the third public working draft.

<aleecia> which section are we in?

<npdoty> ACTION: wiley to define "declared" data (which might be relevant to issue-54) [recorded in http://www.w3.org/2012/10/04-dnt-minutes.html#action13]

<trackbot> Created ACTION-306 - Define "declared" data (which might be relevant to issue-54) [on Shane Wiley - due 2012-10-11].

tl: do we have a different rule for USING observed vs. declared data?

<BrendanIAB> My points are being covered by the current discussion.

… can we avoid defining the distinction?

<BrendanIAB> Given that, from a technical POV, I could convert my "observed" data into "declared" by changing everything to POSTs

WileyS: so, this means ALL data (declared or observed) in a 1st party context is OK to use?

<justin> That is what the draft currently says, tl

<aleecia> seeing jmayer in a moment

tl: ALL data you legitimately have is OK to use. Not share, but you can use it. That's the idea.

[it may be imprudent]

jmayer: tl clarify? I signed up for a sweepstakes and gave some info, and they got my explicit consent. Can that site use that in a 3rd party context?

tl: don't get the question: the user DELIBERATELY gave info (e.g. form submit), and then ...

jmayer: can they use it? we say fair enough, go ahead.

sherman: lots of back-n-forth. checking existing text

<npdoty> http://www.w3.org/TR/tracking-compliance/#first-party-data

section 6.1.1.3

[reads 6.1.1.3]

<npdoty> one of the suggestions for that section is that it might be unnecessary, because of that agreement

tl: notes that nowhere is there a prohibition on this, so maybe this is a note rather than suggesting it's an exception to a prohibit

amyC: want to check where we are going. does DNT even govern declared data at all, as opposed to observed? it might lead to bizarre scenarios ('do you really want to fill in this survey? you have DNT on!')

aleecia: the text currently covers both declared and obsered and allows use (it may be imprudent)

<johnsimpson> +q

<amyc> we used to have "transactional data" defined

<vinay> +1 to Alan.

<BerinSzoka> again, folks, I have a running list of undefined terms. feel free to add to it http://goo.gl/DZAak

<justin> Yes, Chapell, that could happen.

<BerinSzoka> +2 to Alan

<vinay> This is a large expansion of scope

<npdoty> Chapell, I understand that you are objecting to that outcome, is that right?

<justin> Isn't that iAds?

achapell: take a hypothetical: can Apple take an iTunes playlist and set up an ad network and use that data for targetting?

<eberkower> That's what I thought he was describing - iAds

<ifette> Aleecia, Can we have some queue management? Certain people seem to get to reply to every single statement being made..

tl: maybe the rules for 1st parties are not sufficiently restrictive. unless we choose to restrict 1st parties, this is a natural outcome

<WileyS> All of this conversation centers around 1st party consent structures

achapell: I think I see where this is going. what harms are we getting at?

aleecia: is surprised at Tom's position.

<BerinSzoka> In the immortal words of Admiral Stockdale: Who am I? Why am I here?

<justin> The implication of this language is obvious. Tracking is doing what is prohibited in the spec. The spec is designed to prevent cross-site collection and usage. First party data usage gets around this problem.

<vinay> Would www.acme.com be able to run a site retargeting campaign on foo.com (unrelated site) if the only data they are using is data collected on acme.com?

chrisPedigo: ebay's privacy policy would probably say that they won't do that; it might be imprudent

<BrendanIAB> Using data collected in a 1st party context in a 3rd party context is not tracking - the initial 1st party would not be able to add any new data from the 3rd party context.

<vinay> Tom is saying that this use case is allowable; regardless of dnt signal

<ifette> roy, if only you were here ;-)

<justin> Please let's return to the queue.

<susanisrael> they might have to use a new privacy policy only prospectively

achapell: they were in the data business before. they might be encouraged back in

ifette: please only q-jump to clarify
... does DNT have anything to say about data users explicity provide? we should open that issue.

aleecia: agreed, open issue

<WileyS> Ian - we already have that draft text in the CS doc

dwainberg: echo Alan's concerns. also some questions

<WileyS> Ian - this was the language Justin B. and I were working on (user consent)

… what is the scope of the use? probably 'used by or on behalf of other parties?'

<ifette> ISSUE: Make sure in the spec that we clarify information provided explicitly by a user (e.g. data typed into a form on a site with a clear privacy policy) is not subject to DNT.

<trackbot> Created ISSUE-179 - Make sure in the spec that we clarify information provided explicitly by a user (e.g. data typed into a form on a site with a clear privacy policy) is not subject to DNT. ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/179/edit .

<npdoty> I think first parties giving observed data to third parties for some other use is one of the few things prohibited in first-party compliance

… what about observed data collected when using the declared data? can that be joined back?

<robsherman> +q

<npdoty> implied consent? or just not explicitly prohibiting?

… does this create an implied consent for 1st parties to 'track' despite what their policy or other docs say

<BrendanIAB> It sounds like there's confusion between "track" and "target"

Walter: why are we here? DNT is about the context in which data is collected and used.

<efelten> Neither "track" nor "target" appears in this text.

<rigo> This is all a problem of a missing purpose binding

<aleecia> Proposal: we scope this to declared data, not all data, and can everyone live with that?

… if you have a personal interest in say butchering, and professionally you visit an animal rights group, there might be … problems

<susanisrael> i don't think we are here to permit users to control "context" but maybe we are using language differently

<BrendanIAB> efelten - but the dialogue is referencing both regularly.

<eberkower> or the more philosophical, "when is a first party a third party"

… privacy policies tend to be vague

<rigo> so "for the purpose it was collected for" would resolve all, but also may create the obstacles to creative re-use. Obstacles we wanted to avoid. bummer

… notes also that sensitive data (e.g. health) even if declared, cannot be used in a 3rd party context

<amyc> declared data should be out of scope period

<justin> I can live with declared data or all data. Scoping to declared adds a layer of complexity, but I could live with it.

… suggest we are silent on the subject

<jmayer> +q

Ninja: 2nding Walter. Also do we have consensus: if former-1st now-3rd party sends ads based on declared data, can they append new data from the 3rd party context?

<justin> I think existing text covers this.

room: agreed, that no they cannot, it's not permitted by today's rules.

<Chapell> npdoty: yes, that would seem like a problematic outcome

Rachel: amazing how many questions about what it means 'do not track', and would like to see an issue on 'what does it mean to track?' (and hence what is DNT?)

<justin> Tracking is doing what is prohibited in the document.

issue-5?

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

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

<npdoty> Chapell, I think you'd like to talk with robsherman

issue 5 is raised but not opened, but

Rachel: how do we get from Raised to Opened?

aleecia: the chair is not choosing to open it at this time.

<efelten> We had that conversation a year ago.

Rachel: so, when?

<ifette> What is the difference between "raised" and "open"?

<justin> ninjamarnau, The non-normative examples make clear that the former first party is not adding the third party data to the user profile.

<fielding> It has been at the end of the agenda for several months

aleecia: has been on the agenda

<BerinSzoka> If Aleecia is saying it's on the agenda, why can't it be opened?

aleecia: has been going on for a while

Rachel: disappointed

<Chapell> npdoty; i'm not sure what you mean by talk to robsherman

<fielding> And every week new items are added in front of it on the agenda.

<WileyS> Can we get a committment to move it to the front of an agenda?

<BerinSzoka> I'm confused. what does it mean for a topic not to be opened?

<Chris_DAA> I also would like to see it OPEN

ifette: please clarify raised vs. opened

<Chris_DAA> Can w3c staff please define the process for opening an item

<npdoty> we usually have assigned action items when we open an issue, though people have offered text for issues that are just raised

<ninjamarnau> justin, thank you. Following this discussion I just wanted to make sure, that this is still the consensus of the group. This is not always the case with former decisions we made :)

<justin> http://www.w3.org/2006/07/SWD/wiki/IssuesProcess

aleecia: raised may be parked because of dependency, opened means we are working on it

<WileyS> Nick, so are you suggesting procedurally this should be moved to open?

ChrisIAB: would like to see it opened before LC

jmayer: are we now on issue-5? 'what is tracking?'

<justin> Link above defines RAISED and OPEN

<susanisrael> where did david offer a definition that was not screamed about?

<MikeZ> We cannot move to Last Call until we Open issue #5: define "tracking"

<WileyS> Nick, we can then add an action to capture the text that David W. provide attached to Issue #5?

<aleecia> MikeZ: I hear that you would like that.

<WileyS> Susan, on the public mailing list

ChrisPedigo: can a 1st party share that data with a 3rd? and the document currently prohibits 1st party sharing

<BerinSzoka> could someone from W3C just confirm that issued that have been raised but not opened WILL be opened and resolved (closed) before moving to last call?

<Chris_DAA> dsinger, yes, that's correct, I'd like to see Issue 5 OPENED and discussed (and real consensus reached) before last call. Logically.

wainberg: what about use on behalf of another party (but not share the data)?

chrisP: yes, they could

<aleecia> close queue

dwainberg: does that create an incentive to create owned ad networks?

<rachel_n_thomas> i would again ask that someone point me to the distinction - in the W3C process doc or elsewhere - where the terms "raised issue" and "open issue" are defined. and the process by which a raised issue is moved to an open issue such that formal debate (and not just "throwing it aorund") can occur on Issue 5 "what is tracking"

ChrisP: but the users know the 1st party, and have a relationship that they can use to complain etc.

dwainberg: but do they understand the 3rd party context?

<Chapell> If first parties are allowed to create their own ad networks under the DNT track standard, I'm struggline to see how that is a good outcome for privacy.

<WileyS> Rachel, http://www.w3.org/2006/07/SWD/wiki/IssuesProcess

<npdoty> Chapell, I'm suggesting that it would be productive for you to have a discussion at some point with robsherman about this issue

<vinay> +1 to chapell

dwainberg: not sure that users will get the explanation from e.g. a ToS

<susanisrael> Shane: re definition raised on mailing list, i think it may be worth discussing the limits of this channel ( vs. calls) for determining whether people object.

<ninjamarnau> +1 chapell

<Chapell> DNT = anti-competitive

ChrisP: but it cannot be contrary to the ToS

<vinay> +1 to chapell again

aleecia: back to q

<WileyS> Susan, fair - but typically often react more violently on the email list so its at least a good litmus test

<Chapell> Thanks to the advocates for their 'compromise' -- giving the first parties a blank check

johnsimpson: is fine with using data you willingly provided. less sure about about observed data

… is dubious about declared, but more so about observed data

<Zakim> dsinger, you wanted to say that he firmly believes declared data is not tracking

<aleecia> Declared data becomes scope for 6.1.1.3, which requires a defn

<JC> +1 to dsinger

<Chapell> DSinger - ok ,but can we define what we mean by declared data

<adrianba> dsinger: hearing a consensus on declared data - this group is Do Not Track about tracking and i think we should agree that declared data is out of scope

<Brooks> Of course it isn't tracking - because tracking isn't defined

<efelten> Is there any alternative text proposed for 6.1.1.3?

<justin> Chapell, Can first parties use declared and observed data in third party context under DAA principles? I would presume so based on the definition of Mutlti-Site data.

robsherman: maybe in a lot of rat-holes. when you are a 3rd party, user has control. when 1st, there are less restrictions

<rigo> I still think that the change of context will blow into hour face

<MikeZ> DAA agrees that first party data, declared and observed, should be out of scope of this spec. That's part of the DAA code.

<Chapell> Justin - there are three representatives from the DAA here, I suggest you ask them (:

robsherman: tl gave an example of facebook personalization (50 friends liked this page) and that should not be controversial

<rigo> s/hour/our/

<justin> Chappel, ha fair point.

<MikeZ> That being said, this discussion maybe out of scope of the charter, so reserving that right to object.

<vinay> MikeZ - does the DAA spec allow a first party to use observed data to target an ad on an unrelated site? I thought that required teh AdChoices icon

<vinay> its as simple as a site retargeting campaign

danauerbach: clarifying that in the FB case we know who you are from your logged in cookie, we know how many freinds liekd it, we tell you and collect nothing

<vinay> does that require AdChoices?

<Chapell> MikeZ we have driven the bus so far past the charter that I suggest we keep driving because we're almost to the other side of the globe

aleecia: clarify, who you are, that you are logged in, and your friends are all declared data

danA: feels that 'these tracking cookies' should not be used

<jchester2> +Dan

ifette: we have opened 179 on declared data. hope we have consensus on that.

… if we do reach consensus on splitting, maybe we are further apart on observed data

jmayer: agree with Dan A, has been sig. debate for some time. proposal I worked on with Tom and Peter did have text on this issue

… would like to be concrete. "If the info you gave to the 1st party is used in a 3rd party context in a way that the data can be linked to the 3rd party context, not OK"

… but if privacy preserving, you could do that

… so instead of drawing lines around former/current, one line about unlinkability defines everything

[room] different issue?

<Brooks> Having trouble following a conversation which relies on undefined terms

aleecia: split into two issues, or connect to linkability?

<rigo> Brooks, do you mean the definition of tracking?

WileyS: surely unlinkable data is out of scope.

<justin> I think the cookie/unique ID issue is a separate point.

jmayer: doesn't work the way you might think

… our decision could be 'you get to use unlinkable data, but not linkable data'

<justin> It's related, and this issue is dependent, but the language does not need to address this language.

[scribe confesses he doesn't understand jmayer and may have scribed badly]

<susanisrael> sympathy for scribe

<rigo> justin, the problem is the context shift. And context is important to users. All the blow-ups (like the teacher-with-a-beer-case) where an information being accepted in one context brought into another context and blowing there

<npdoty> I think WileyS is pointing out that unlinkable-data-only wouldn't require additional text because we already rule that out of scope; jmayer just wants to note that the silence is still a valid option to handle this question

aleecia: shane has action to explain what declared data means. we could (a) make 6.1.13 specific to declared (b) leave as-is, apply to declared and observed (c) delete section, and do it in terms of unlinkable

<npdoty> three options:

<ifette> can we get a quick straw poll?

<adrianba> s/6.1.13/6.1.1.3/

<Chapell> TLR: this is coming apart at the seams. Is the goal of this WG to put third parties out of business and allow first parties to do whatever in the hell they want?

<npdoty> 1) action against Shane and declared ata only

<Chris_DAA> Ian's calling for a straw poll

<jmayer> My point, in short: We could draw the line at linkability. That's independent of whether you think unlinkable data is in scope. (I think it is, Shane thinks it isn't.)

aleecia: for editors, please capture those 3, and the actions

<Chapell> TLR: if that's the goal, then lets just be up front and put that in our charter

<justin> rigo, But no new sharing occurs here. The context is still cabined to the individual user.

<johnsimpson> casnnot hear use mi8ke

<npdoty> 2) current text (you can use 1st-party observed or declared data)

aleecia: if you have unlinkable data, how can you be linking it to a person?

<npdoty> 3) you can't do this at all (except when it's unlinkable somehow)

<justin> Option 3 is contingent upon whether the EFF/Stanford/Mozilla proposed limiting the use of unique IDs is accepted. It does not need to be addressed here.

<ifette> could we get a straw poll on "People should be able to use 1st-party declared data in a third party context yes/no", "People should be able to use 1st-party observed data in a third party context yes/no"

<amyc> +1 justin

<tlr> chapell, if you think this discussion is going in the wrong direction, I suggest you get in the queue.

<npdoty> +1 to ifette's version of the poll questions

jmayer: there are a bunch of ways. work to date has focused on 3rd parties. could apply to 1st-become-3rd

<Chapell> I am in the Que, at least I think I am

[scribe is still confused]

<Brooks> q

<Brooks> q

<Brooks> q

<Chapell> But Zakim constantly tells me I'm out

<ifette> could we get a straw poll on "People should be able to use 1st-party declared data in a third party context yes/no", "People should be able to use 1st-party observed data in a third party context yes/no"

<ifette> \

<MikeZ> Vinay, you are generally correct that retargeting requires AdChoices icon. The current discussion and use cases don't jibe one for one with the DAA principles so let me retract that "official" statement on behalf of DAA.

aleecia: Ian asked for straw poll. Ian will suggest text

<BrendanIAB> Yes!

<ifette> could we get a straw poll on "People should be able to use 1st-party declared data in a third party context yes/no", "People should be able to use 1st-party observed data in a third party context yes/no"

<npdoty> "People should be able to use 1st-party declared data in a third party context yes/no"

"People should be able to use 1st-party declared data in a third party context yes/no"

<johnsimpson> +1

<jmayer> Is the question ALL first-party declared data?

<johnsimpson> yes

<dtauerbach> i think yes

<jmayer> Or SOME first-party declared data?

<rigo> amy, justin, context switch and its disastrous effects are not dependent on sharing

<ifette> could we get a straw poll on "People should be able to use 1st-party declared data in a third party context yes/no", "People should be able to use 1st-party observed data in a third party context yes/no"

<Chapell> Chapell raises his pen

mixed results on poll 1, but clearly favoring yes

<ifette> it was like 80 yes / 20 no

<johnsimpson> please use the mike

<ifette> on the first question

<WileyS> Not mixed - more like 80

<BerinSzoka> so 50-3 is "mixed results"? wow

<rigo> ifette, it was 60/40

<npdoty> on the first question: lots of people favoring yes / some people favoring no

<WileyS> Not mixed - more like 85% yes, 15% no

People should be able to use 1st-party observed data in a third party context yes/no

<ChrisPedigoOPA> +1 Wiley

<rigo> WileyS, ifette, no way!

<johnsimpson> No on observed data

<Chris_DAA> rigo, it was 80/20

<BrendanIAB> Yes!

<Chapell> We continue to vote on things without defining them

<fielding> no

<dtauerbach> for me, this depends a lot on how the linking from 1st party to 3rd party context happens

<johnsimpson> No on observed data

<jmayer> Again, ALL observed data? Or SOME observed data?

<Chapell> What is "Observed" What is "Declared"

<WileyS> Mixed on #2 - 50/50 split with about half the room not voting

<Chris_DAA> 80/20 is actually fair

<BerinSzoka> how hard would it be to have an actual voting mechanism here rather than just eyeballing these votes?

<rigo> should we have a vote on whether it was 80/20 or 60/40?

<ChrisPedigoOPA> not mixed more like 60-40 yes

preponderance for yes, but not so large (and fewer indicating)

<rachel_n_thomas> "closer to" is not a valid polling strategy, straw or otherwise.

<Chris_DAA> rigo, would love to have an actual vote

<BrendanIAB> No!

<johnsimpson> yes to unlinability

<Chapell> +1 to brooks

finally jmayer's concept of unlinkability?

<rigo> I still believe that people would rather accept sharing than change of context

<johnsimpson> Yes on linkability

aleecia: the question is deleting this section

dwainberg: should the text be silent, or contain affirmative text

<susanisrael> i thought we were having a poll on what should be permitted as opposed to what should be included in doc

<fielding> for those who don't understand, straw polls are not decisions

if you collect data as a 1st party, you may not use it as 3rd party unless it is unlinkable. yes/no?

<johnsimpson> Yes support that

very little support, and a lot of opposition

<ChrisPedigoOPA> fwiw, the straw poll was 80-20 against Jonathan's proposal

achapell: back to clarifying questions. some orgs have multiple people

<BerinSzoka> I think we need a better TWPG Expression Mechanism

<vinay> s/achapell/chester

answer - this is a sense of the room, do we have rough consensus?

<WileyS> Chris - it was closer to 95% against, 5% for Jonathan's option

rigo: would like to offer a 4th option. we have fun discussing a vertical issue square.

<ifette> Amy, I suggest going through http://www.reddit.com/r/aww/ -- it will make you feel better

… people feel bad, because it might favor large central entities. users should be able to opt out.

<Chris_DAA> WileyS, I think you are right (but it's just a feeling)

<Chapell> This process has become a sham - if the idea was to give the user control, we are not providing that control

… if you legit. acquire data in one context, and use it in another, people may freak

(so it may be imprudent)

<BerinSzoka> Rigo: Did you call that the "Bus Problem?" I missed something...

<vincent> BerinSzoka, buzz not bus

<aleecia> It's context collapse as Walter raised

<BerinSzoka> oh.... fair

<fielding> generally speaking, we don't need to tell sites that they shoudn't freak out users, unless of course it is a freaking site

… option 4: is to limit the 1st party to using the data in the context for which it was collected.

[room] define context?

<BerinSzoka> wait, that was a "fun" proposal?

<robsherman> +q

<amyc> @ifette, I feel much better now

<ChrisPedigoOPA> Roy, exactly

<ifette> :)

… context could be … thinks … the overall relationship to that 1st party site.

<ChrisPedigoOPA> first parties aren't going to freak out their users

<ChrisPedigoOPA> they want them to come back

<susanisrael> I appreciate Rigo's effort to explain the basis for objections. It seems though that this is really about whether people understand the scope of the consent they give to first parties-not our work here.

… so, 1st party data is restricted to 1st party contexts. 3rd party data is restricted to 3rd party context.

<Chris_DAA> frist party data use is out of scope per the charter (charter based objection to this dialog)

aleecia: different between context and 'as a party'?

<ChrisPedigoOPA> Chris_DAA, agreed

rigo: … thinks… can't answer off the top of his head. could explore 1st party defn so that if data is collected as a 1st party

<Chris_DAA> ChrisPedigoOPA, get it on the record

rigo: context would mean my relation to the 1st party as a 1st party.

<Marc> +q

<Chapell> PR Wire: October 4, 2012 --- Zappos.com applauds the great work by the W3C (and on a TOTALLY unrelated note, announces the Zappos ad network)

<susanisrael> i think Rigo is accurately describing the basis of the objections to these scenarios we voted on as I understand them, which was helpful. But I don't think those objections make sense in this spec.

<ChrisPedigoOPA> first party data use is out of scope for this group

<tlr> strong +1 to David

<tlr> *brief* text proposals would be great

<jmayer> What's there to write up? It's been written for half a year.

dsinger: suggests that people write text so people can understand what is suggested

<justin> Yes, we do not need text here.

<justin> We have to turn this into two options, and the cookie issue will be decided at a different time.

<Chris_DAA> longevity doesn't = "rightness" (ref gender rights violations)

aleecia: maybe we are running out of options. we are supposed to be q-closed, and moving on. we will continue to explore the 3 options

<vinay> +1 for Marc

<vinay> Well said!

Marc: finds this astounding. this changes who is collecting.

<ChrisPedigoOPA> disagree

<justin> rachel_n_thomas, Can first parties use their own data to serve ads offsite under DAA rules?

<Walter> Anyway, if the spec moves this way it will run counter to EU data protection principles

<justin> Since Google, Facebook, and Amazon are DAA members, I suspect so!

<Walter> and not an easy sell to regulators

troessler: friendly amendment. we thought we knew what it was. we rapidly found options. there may be more. we'll have a call and an agenda, where we'll take specific proposals to change the text

<adrianba> ScribeNick: adrianba

ISSUE-119?

<trackbot> ISSUE-119 -- Specify "absolutely not tracking" -- open

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

ISSUE-119

<Chapell> Regulators in the U.S. have been very active on DNT to date -- presumably to address privacy issues

aleecia: poorly named absolutely not tracking
... we have text which was ninja's proposal

<susanisrael> I agree with Thomnas that people did not understand the straw poll and the basis for the discussion. Sometimes explanatory comments without the goal of closing an issue -like Rigo's and David's comments- are useful.

<Chapell> I would encourage those same regulators - to the extent that they are also tasked with anti-competitive issues - to step in and participate with the same level of enthusiasm

aleecia: one of the things we talked about on the phone was non-normative text saying expect this not be widely used
... that might be a good addition
... we also talked many times that this is the wrong name - perhaps not retaining, roy had suggested anonymous

<WileyS> +q

<ifette> is this a TPE or complaicne issue?

<susanisrael> rigo asks to be added to the q

aleecia: this crosses between docs but we're talking about compliance doc

<Chapell> dpdoty: I would appreciate it if my comments here are not sanitized off of the minutes from this discussion

ACTION-110?

<trackbot> ACTION-110 -- Ninja Marnau to write proposal text for what it means to "not track" -- due 2012-02-10 -- PENDINGREVIEW

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

<npdoty> s/dpdoty:/npdoty,/

<vinay> What are they not interested in? (We don't know what 'not interested in tracking' is)

dsinger: you said this is for few sites - i think quite a few web sites not interested in tracking you and one of motivations is to say i'm not interested and not tracking you
... not sure it's a small number of sites

<vinay> Is it -- they do not retain any data beyond completing the service they provide?

<vinay> Or something else?

aleecia: [reads text from ACTION-110]

<jchester2> Plus we need to give sites--and I think there will be many who wish to act responsibly in a DNT world, will want to signal they do no tracking.

<Chris_DAA> CHAIRS- Please open ISSUE-5 first, before ISSUE-10 is discussed

<ninjamarnau> we need to remember that we are talking about third party context. The original idea came from a time where first parties were still in scope.

<ifette> Can we please enforce the queue? This is really not a "quick clarification question"

lmastria-DAA: want to be crystal clear - no one in ad industry interested in me specifically - they care about audience segments

ifette: i heard aleecia say this is on compliance and also a tpe part - we'll leave the tpe part for that discussion

<schunter> To Chris_DAA: Why do you believe that we need to discuss our definition of "tracking" before defining a "party"?

ifette: i don't understand why this needs to be in compliance doc - if this is all you do then you're already in compliance
... 6 week retention period is even more liberal than this
... question about expressing this in tpe doc but for compliance we need say nothing

<jchester2> +q

aleecia: i hear this may be a definition of the flag that may belong in tpe

<npdoty> +1 to ifette, I don't think this is needed in the compliance document

ifette: fine way to characterise it, yes

aleecia: that's what this may end up being

<Chris_DAA> schunter, issue 119 is about "not track" (what is track then?)

WileyS: i request that we remove this text completely
... sites can implement or not implement DNT

<vinay> +1 to Shane

<tl> +q to say DDG

WileyS: creating a "i implement better than you" is not necessary

<Chris_DAA> schunter, sorry, I mean't issue 110

<schunter> The proposal is to send "3"

<npdoty> is WileyS agreeing with ifette that we don't need this text in the compliance doc?

aleecia: contrast that to ifette's view yesterday to make it easy for small sites to show compliance easily?

<Chris_DAA> not 10 :)

<fielding> http://lists.w3.org/Archives/Public/public-tracking/2012Feb/0403.html

WileyS: you implement DNT and send back the appropriate response or in the well known resource

<susanisrael> npdoty, i think yes, shane is agreeing with ian

<schunter> answer "Tk:3" or a "3" in the tracking status resource

<dsinger> it may be that you can say "I respect 3rd party rules with no exceptions", and that is enough

<schunter> Yes. This makes life easier for small parties since they have 1 section less to read (at the same implementation complexity)

<npdoty> fielding, are you still happy with: http://lists.w3.org/Archives/Public/public-tracking/2012Sep/0144.html

<tl> dsinger: Even that is weaker than some of the organizations we're talking about, like DDG.

WileyS: trying to set a graduated scale of implementations of DNT is not helpful for the outcome and no business case that requires this outcome
... why would anyone need to do something else

<BerinSzoka> Caveman Lawyer is confused again. Defining "not tracking"' (110) before defining "tracking" (5) makes about as much sense as hunting mammoth before making spears

aleecia: because some people think implementing DNT implies that they do tracking if they don't

WileyS: but they can have clarifying text to say this - they don't need the flag

<Chris_DAA> schunter, I meant we should not be discussing ISSUE-110 before opening ISSUE-5 (and defining tracking before we define "not track")

<ifette> This whole discussion is now TPE focused not compliance focused

rigo: we had discussion on the mailing list

<schunter> to Chris_DAA: Thanks!

rigo: when ninja wrote this we had hope of alignment with EU stuff

<ksmith> I almost hate to ask - but how can we define "not tracking" when we dont define "tracking"?

rigo: want to come back to ian who said want to have a simple thing
... don't necessarily need different signal

<vinay> not to seem pedantic, but if we are creating a super-DNT, why should we stop there? Why not a DNT-light for companies that won't impleemnt DNT (like Duck Duck Go) but wants to do something?

rigo: but have to go through all the specs to verify doesn't apply to me

<vinay> It seems silly to create use cases for small majority of sites

rigo: then can safely send DNT 1 back

<fielding> npdoty, yes, assuming we define tracking

<BerinSzoka> vinay: I'm concerned about cURL and the tens of hundreds of users affected by the interaction of DNT with cURL

rigo: just want to provide a shortcut in spec and this doesn't discriminate

<ifette> Rigo, I agree with you, but I think we will have that when we say "If you dump all the data in 6 weeks and don't do X" we will have that

schunter: agree with Shane and Rigo
... no need for flag saying nicer than the nice guys

<BerinSzoka> +q

schunter: i comply with strictest set of requirements
... what rigo says is have rules of thumb for sites - if you only configure this way then it is safe to send this header back

<MikeZ> +q

schunter: not normative - just guidance

<ifette> Rigo?

schunter: simple guidance for simple sites without reading 100 pages

<ifette> Rigo, I agree with you, but I think we will have that when we say "If you dump all the data in 6 weeks and don't do X" we will have that

<WileyS> Non-normative - not a new value in the TPE or a definition. that works for me

<ifette> i think i have an action to draft that text

schunter: suggest drop this definition and i'm wondering also i don't do any tracking at all flag

<BerinSzoka> Caveman Lawyer is getting angry. He doesn't function well without clear defined terms. Brings out his inner Saber-tooth Tiger

aleecia: hearing proposal from shane and matthias to not have normative text and maybe have guidance

dwainberg: i agree and had proposed on mailing list that we drop this

<rigo> ifette, I nearly think so, but I learned you could full targeted advertisement within the timeframe of 6 weeks of data retention, so beware of chilling effects ...

dwainberg: i don't think it is in scope to promote practices of particular groups

<schunter> message: we have two sets of compliance regimes: one for 1st parties and one for 3rd parties. I believe this is complicated enough and does not adding a third regime called "no tracking at all".

<aleecia> why is there marketing here?

dwainberg: the marketing efforts of one particular company

<aleecia> It's a use case, not a marketing issue. It's an actual barrier to implementation

<jmayer> I don't see any marketing. Aleecia proposed a reasonable use case.

<npdoty> http://lists.w3.org/Archives/Public/public-tracking/2012Sep/0115.html

<vinay> Aleecia - Duck Duck Go wants to distinguish itself from other companies that implement just DNT

dwainberg: if we do create this and i don't want to it should use consistent language

bryan: i think this will be not that helpful
... always people who think we could have done better

<npdoty> my proposal would not define a new term, provides TPE mechanism to identify permitted uses claimed: http://lists.w3.org/Archives/Public/public-tracking/2012Sep/0115.html

bryan: they can build an industry in verifying that people went above and beyond
... we don't need something like that in the spec

jchester2: i think this is important to provide to sites

<bryan> some group will think always DNT is not strong enough, and they can augment the status resource with certifications that are industry-driven and define how the site goes "beyond the call of DNT"

jchester2: probably mostly not commercial sites but i don't rule that our

s/our/out/

scribe: i think this is incredibily helpful

<schunter> note: We could rename "3" to "no tracking"

<bryan> my point was new input, i.e. that we already have a means to address this without any new standardized indication

dsinger: i should have been clearer - i think there is a problem for sites in a 3rd party context that will be viewed with suspicion if they don't do anything

<WileyS> Matthias, this would require defining "tracking" :-)

dsinger: we need some guidance - i don't mind if it is a specific flag or just guidance about what to set
... we don't want to make life difficult for small sites on the internet
... or even large sites that have some resources like this that just don't do tracking
... otherwise i think it will be apparently hostile

<npdoty> dwainberg, it sounds like you'd also be okay with permitted use indicators (including no permitted uses), as I'd proposed?

aleecia: was that volunteering to write non-normative text

<schunter> WileyS: I disagree: The semantics of this "no tracking" are the permitted behavior for 3rd parties (longer text: no tracking except to the limited extend permitted to third parties)

dsinger: yes, i'll work with matthias

<Zakim> tl, you wanted to say DDG

<susanisrael> if the queue were open, I would have said that david's comment just now suggests to me that what he is really asking for is not a "super dnt" but a "non-commercial site" designation.

<keith> Critical to remember that we already have an effective self-reg program that protects consumers and preserves critical role that advertising plays for the Internet.

tl: the reason that we get sites like DDG is because they see what we're working on and they think this is do not track, it's how much tracking is allowed and we want a way to say we really don't track

<efelten> Matthias, couldn't a first party send "3" under the current proposal, to say that it is abiding voluntarily by the 3rd party provisions? Think the existing spec allows this.

<rachel_n_thomas> * rachel_n_thomas raises her pen

<rigo> efelten, it would also mean that it considers itself a 3rd party

<jmayer> This is an optional flag. What's the big deal?

rachel_n_thomas: defining tracking or do not track would be helpful in having this discussion
... without the definitions the folks not in the room won't feel represented

<Zakim> ifette, you wanted to say we're really talking about TPE issues now

<susanisrael> jmayer: i think commercial companies are concerned that they will be asked to meet any higher standard that is introduced, but I could be wrong.

<justin> The point is assumed for the record that DAA wants us to define tracking. Noted for posterity. Consider it a standing objection.

ifette: i think there's some overlap for the new action and what i was trying to get to earlier which is simple compliance
... i think this falls under simple compliance
... if my text doesn't cover this use case then i've failed
... there's a question about going above and beyond which i think is a tpe question
... is this something we should expect in the compliance doc or is it for tpe about if i can express this

<npdoty> I think there might be agreement that we don't need this in the Compliance doc?

ifette: majority of what i heard were tpe but the actions are on compliance

<WileyS> Tom, how would replying to DNT and not providing a single permitted use not meet the same outcome?

aleecia: maybe can merge the actions - you guys can figure that out
... will it end up in compliance or tpe - it depends on the text

<npdoty> ifette, do you have a separate action for this?

aleecia: for now we'll discuss in compliance but may land in tpe

<ifette> npdoty i had an action to define a six week grace period

<ifette> which i believe would cover this

BerinSzoka: would be nice to have lots of terms defined

<npdoty> ifette, got it, I wasn't sure which would cover

BerinSzoka: i'm a little surprised that you've been at this for a while without defining all the terms

<rachel_n_thomas> berin's list: https://docs.google.com/document/d/1JBfkFnVQ8miH3kgxxreyz2LQj6vl5BfACfNUIGK8l2Y/edit#

<ifette> npdoty, i do seem to have amassed a few actions today :)

BerinSzoka: glad we're defining not tracking but think some are more important
... wondering if we're going to have these opened - don't understand difference between OPEN and RAISED
... we don't understand the terms of the deal - contracts 101

<vincent> how is that new? we got the same question 5 min ago?

BerinSzoka: shared the document with questions

aleecia: thank you for doing that work
... first part of first day we went into definitions early on purpose

<BerinSzoka> For the fifth time, here's my list of terms that seem to be undefined http://goo.gl/DZAak

aleecia: secondly, we've agreed this won't be not tracking - the action has a title that we're not actually doing

<WileyS> tl, question again, if a site provides a response and then doesn't list a single permitted use as being held out in their response, how is this different than your intended outcome? Doesn't this meet the same outcome?

MikeZ: what we're doing is defining a spec for users to express their preferences
... this doesn't have anything to do with that

<BerinSzoka> my point was more general than this particular issue: let's define what, in general, we're talking about

MikeZ: putting this into the spec implies that if you don't respond in this way then you must be tracking

<ChrisPedigoOPA> Good Point Zaneis

MikeZ: we shouldn't create a presumption that people who don't do DNT are tracking

Chapell: thinking about a small web site - i don't understand many of these definitions so how will a small web site
... what happens when a regulator comes calling for a deceptive statement

aleecia: spec needs to be better written before we're done

<BerinSzoka> BINGO: Folks, if you want this spec to be enforceable by regulators, it has to be very, very clear

<npdoty> WileyS, I largely agree, though I think we need to define the fields so that there is a way to say that no permitted uses are claimed

<aleecia> http://www.w3.org/2011/tracking-protection/agenda-2012-10-03-F2F-Amsterdam.html

dwainberg: is there a possibility that there is a third party that this applies to?
... could this ever possibly apply in a 3rd party case?

<WileyS> Nick, those codes are mostly in the TPE now, right?

aleecia: you could imagine it in first or third party
... the question is if a first party would like to communicate this

<npdoty> WileyS, yes, I definitely think this is a TPE question; I have a proposal to update the TPE to clarify that

<Chris_DAA> BerinSzoka, to that point, FTC is in the room, so perhaps efelton could help us understand how the FTC might enforce all of this in the US?

<WileyS> Nick, agree that the "draft" definitions of the permitted uses are still unsettled but assuming that was the case then this is solved, correct?

dwainberg: spec doesn't apply in general to first parties

<WileyS> Nick, okay - sounds like we're on the same page on this one.

aleecia: it's not that spec doesn't apply to first parties - it does, they have few limitations - they do need to ack

<npdoty> WileyS, I believe my text (a small change on the qualifier flag, probably) would resolve this entirely, without defining new terms

<WileyS> Nick, like it - look forward to seeing it.

<npdoty> ACTION: singer to propose non-normative text on 119 (with schunter) [recorded in http://www.w3.org/2012/10/04-dnt-minutes.html#action14]

<trackbot> Created ACTION-307 - Propose non-normative text on 119 (with schunter) [on David Singer - due 2012-10-11].

aleecia: going take a break - back in half an hour, get as much done as we can, then leave early for dinner

<npdoty> WileyS, (from a few weeks back) http://lists.w3.org/Archives/Public/public-tracking/2012Sep/0115.html

<npdoty> break.

<npdoty> cheers to adrianba and dsinger for keeping up with scribing!

<dsinger> dinner location: http://maps.google.com/maps?q=Kantjil+En+De+Tijger,+Spuistraat,+Amsterdam,+The+Netherlands&hl=en&ll=52.369337,4.879303&spn=0.020988,0.034032&sll=37.0625,-95.677068&sspn=55.060677,69.697266&oq=kantijl+&hq=Kantjil+En+De+Tijger,+Spuistraat,+Amsterdam,+The+Netherlands&radius=15000&t=m&z=15

<johnsimpson> we back?

<BrendanIAB> Hmm, seems like I could have napped for another few minutes.

<aleecia> getting back to it

<vinay> Matthais has put info for dinner on board

<vinay> name, address will be added to board shortly

<vinay> Aleecia: just one behind on various issues. Will drop last section to end early and make it early for dinner

<npdoty> scribenick: vinay

Aleecia: Tomorrow is primarily Matthais

<schunter> http://kantjil.nl/contact

Host will give us take-away lunch tomorrow <clap>

<BerinSzoka> can we get buttermilk to go?

<npdoty> "have really taken amazingly good care of us" -- +1

<npdoty> issue-144?

<trackbot> ISSUE-144 -- User-granted Exceptions: Constraints on user agent behavior while granting and for future requests? -- open

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

Issue 144 - USer granted Exceptions

<ChrisPedigoOPA> Berin, not until you define buttermilk

Raised against compliance, but Matthais has been handling it in TPE

<jmayer> +q

Aleecia Suggestion: Change 144 from compliance to TPE (where it belongs)

<justin> Can we turn the screens back on?

<jmayer> +q

t1: can we get what we're discussing on the screens

aleecia: i'm plugged in. We'll look into it

<npdoty> s/t1/tl/

<BerinSzoka> Caveman Lawyer welcomes further input as to key undefined terms http://goo.gl/DZAak

<johnsimpson> vinay can you share?

aleecia: going to move it to TPE where it belongs

jmayer confused in moving it over to TPE

<npdoty> s/jmayer confused/jmayer: confused/

Aleecia - if you join the AdobeConnect, we cna try sharing again for remote users

<dsinger> even if it stays in compliance, I think it'll be much easier to discuss after tomorrow's issues are considered

jmayer: This issue seems to have the same flavor of compounding the error of putting more stuff in TPE that didn't belong there to begin with
... perhaps it makes sense to move stuff that may not fit well in TPE into Compliance

aleecia: suggest as an action item editors to look it over and then come up with a proposal

dsinger: it would be easier to discuss this after tomorrow
... we will be discussing exception mechanisms tomorrow

<WileyS> +1 to DSinger

dsinger: keep this as an open item for now

<jmayer> Fine by me.

<npdoty> ACTION: singer (with justin) to coordinate which document contains exceptions [recorded in http://www.w3.org/2012/10/04-dnt-minutes.html#action15]

<trackbot> Created ACTION-308 - (with justin) to coordinate which document contains exceptions [on David Singer - due 2012-10-11].

Aleecia: keep this open for now. And, Justin and DAvid to have a discussion on where Issue 144 should live

<npdoty> issue-60?

Next issue - issue 60

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

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

Aleecia: Question -- will a recipient know itself whether it is a first party or a third party

<tl> +q

<fielding> that sense would be wrong

Aleecia: A -- not always, but most of the time will. Heard sense that there may be some use cases where the party may not know (operating in an iframe)
... may not have anything in particular to do right now
... may be an example of moving something from open to raised

<tl> -q

Aleecia: we are on track to handle this already from handling the first and third party definitions
... anyone object to parking this for now?

<justin> fielding has been clear that he has issues on the distinction between first and third parties

npdoty: Roy - can you elaborate on why you think Aleecia may not have current state right?

fielding: the notion that a party knows what party it is is wrong

<tl> +q

Aleecia: Correction -- started the conversation that a first party won't know

<npdoty> most of the time parties will be correct in their expectation of their party status

Correction: Most of the time, parties will be accurate in knowing whether it is a first or a third party
... suggestion -- leave it as raised rather than closed
... deal with defining first/third parties before doing this

rachel: clarifying question -- are we downgrading it since its open now?

<justin> This language is also relevant: http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html#unknowing-exception

<fielding> most of the time, parties do not know when they are a first party because being a first party implies knowing why the user made a request; a site certainly knows when it is obeying first party or third party requirements

Aleecia: after we have the definitions for 1st/3rd party done, we should then come back to this. but, shouldn't actively discuss it now. Just don't want to lose it for the future

<fielding> tl, no

t1: don't parties have all of the info they need to always know?

<npdoty> s/t1/tl/

<justin> fielding does not care for the high confidence test

ifette: i don't think its that simple
... i like the idea of circulating back at the end after knowing the definitions

<Chris_DAA_> +1 to Ian and Aleecia

t1: no objections to circulating back at the end

aleecia: okay, done!

<Chris_DAA_> we should do the same for ALL definitions, including "track" and "tracking"

<tl> fielding, please explain.

aleecia: now looking on to issue 73
... analytics silos

<ifette> 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

<ifette> ISSUE-89?

<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 - -didnt have actions on this

scribe: had two positions taken

<justin> This is addressed elsewhere.

scribe: Tom thought tracking should come down to the former; roy thought it was the latter
... think its been handled (implicitly) by decisions already made

<fielding> the definition is written like the LGPL license -- it uses nonsense phrases to be a first party (sufficient to be sued but not to defend) and says that otherwise you are a third party

scribe: do we need to take this on?
... suggestion - not close 89, but also not actively work on it
... move it as well to pending

wileys: issue 89 duplicative of Issue 5?

Aleecia: remind me of issue 5

Shane: its the definition of tracking
... if we had that definition, this may be done

Aleecia: Issue 5 is a separate task

<justin> +1 to WileyS

Shane: The way I hear you -- Issue 89's response is close with a 'see specification'
... doesn't see much sense to keep it open

<BerinSzoka> Caveman Lawyer insists Issue 5 (defining tracking) is the most important issue--but laments that it isn't even "open"

dsinger: close without prejudice

<npdoty> maybe WileyS's point is that it's too broad to have a distinct issue

Aleecia: anyone want to keep it open?

Chris_daa - but will speak when turn on queue

dwainberg: spec as it is now doesn't create incentives to provide customization in privacy friendly ways
... would like to keep it open to allow for this

Aleecia: i think you've suggested a new issue
... and backed an idea from Nick on creating an appendix to promote best practices on privacy friendly solutions

npdoty: not sure what title for issue would be

Aleecia: Appendix for pointers for privacy enhancing ways to perform business practices

something like that

<justin> Shouldn't necessarily be limited to appendix.

<npdoty> issue-175?

<trackbot> ISSUE-175 -- Have an appendix of best practices? -- raised

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

Chris_Daa: can't see fit to close issue 89 until have group consensus on definition of tracking
... request this stay open, and then revisit it until after 5 is resolved

Walter: Wondering where it was being fixed elsewhere?

Aleecia was fine with Chris' comment (not going to fight it)

<npdoty> dwainberg, do you think issue 175 works for what you were raising? "Have an appendix of best practices?"

Aleecia: to walter -- 'see the spec'. Mostly what we focused on was cross-site issues, but not exclusively. Should it be a or b? Mostly a, with a little b. Rather than explaining all of that, instead just say see the spec

<npdoty> do we want to postpone 89 then?

<justin> This concern is addressed specifically by the debate around use of first party data that we spent the previous hour discussing.

Aleecia: hearing 'add a note to 89 that we will close this after Issue 5 is closed

move it to raise

and add a dependency so we don't drop it on the floor

Nick: Can we use postpone?

Aleecia: yes

<justin> Seconded

<dwainberg> npdoty, not entirely.

Issue 73

Analytics Siloing

<Chris_DAA_> vinay, did you log my objection to closing Issue 89 until we open and close Issue-5 (with a group consensus)?

<dwainberg> but, it can wait for isse 5, as has been proposed

Aleecia: had an action for jonathan

Chris_DAA - I believe so.

<Chris_DAA_> vinay, yes, i see it now- IRC seems to be case sensitive, so it didn't show up red on my side

Aleecia: Thread tapered off
... What is the state of this now, and where would you like to go to move this forward?

<npdoty> 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

<aleecia> http://lists.w3.org/Archives/Public/public-tracking/2011Nov/0015.html

Aleecia: will put in to IRC

<aleecia> http://lists.w3.org/Archives/Public/public-tracking/2011Nov/0030.html

Aleecia: first link was original text
... second link is the response

ifette: is this subsumed by the text we provide about service providers?

aleecia: it might be. Just wanted to make sure we're on the same page.
... startign to see a theme
... anyone pushing back? not closing this, just past this text since we moved on to other items
... anyone disagree?

<npdoty> should we be marking in the editors' draft that issue-73 is relevant to that section?

aleecia: not ready to close it yet

ifette: can we note in the issue that this is subsumed?

Aleecia: Can you do that?

ifette: sure (in a depressed voice)

Issue 99 now

Aleecia: thread went off the rails

<ifette> ISSUE-73: This is largely subsumed by new text on service providers, so people should look at that text and raise any issues they have with _that_ text, not the old text in this issue/action

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

Aleecia: lets see if we can focus it again. very long thread. picked out three bits of text that seem most relevant

<aleecia> http://lists.w3.org/Archives/Public/public-tracking/2012Jun/0264.html

<fielding> issue-99?

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

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

Aleecia: lot of grumpiness that may not be as relevant

<aleecia> http://lists.w3.org/Archives/Public/public-tracking/2012Jun/0431.html

Aleecia: first is Ian's in response to Action 187
... second is Rob's response

<aleecia> http://lists.w3.org/Archives/Public/public-tracking/2012Jun/0442.html

Aleecia: time in between, with some other discussions
... third is comments from Rigo
... for Ian's -- "Reading Text"
... when the user is interacting with the identify provider, it is clearly a first party
... but what happens afterwards?
... rob's proposal - can't use the data beyond authentication unless needed for business needs

<robsherman> +q

Aleecia: can we replace that with 'other permitted uses'?
... rob may not accept it

<justin> Or consent/UGE

Aleecia: finally - from rigo -- different suggestion that OOB always trumps
... not proposed text, but an idea on how this might work
... dont have proposed text along these lines yet
... two texts, with possibility that a 3rd person might

<Chris_DAA_> Rigo, what is an "identity provider"?

Rachel: Helpful to walk through proposals. In one of them, there was a use of 'first party'.

<Chris_DAA_> rigo, that's not an industry term I'm familiar with?

Rachel: will be hard to close this until we clarify what first party is

Aleecia: won't close this todya, but can discuss it

Rachel: Would be tough to discuss without knowing what 1st party is

jmayer: suggest we don't have text on it
... interaction with widgets and interaction with websites should be accurate to cover this use case

<rachel_n_thomas> noting that discussion based definitions that do not yet exist is fine as a hypothetical exercise, but not to inform formal decisionmaking related to the standard.

jmayer: suppose SSO on website, the widget use case is a nice example, but it doesn't seem to me that we don't need a separate section to address it

<justin> I disagree jmayer, I don't know how the ID provider fares after authentication.

jmayer's response to Justin's question: login process is well definied

scribe: he's right that post-log in, it will vary

<susanisrael> vinay i thought jonathan was saying login process NOT well defined

scribe: some situations it will follow to be a first party; other situations will not be followed as a first party

<Chris_DAA_> rigo is no longer in IRC? does he know that? This is his issue, and I have questions

<aleecia> rigo+

<susanisrael> rigo is trying to get back on irc

<npdoty> susanisrael, I think jmayer is saying that it is clear/well-defined that an identity provider would be a 1st party during the authentication process

jmayer: can you let the minutes know whether you said 'login process was well defined' or 'login process was not well defined'?

<robsherman> -q

<rigo> Chris_DAA_, what is your question?

<Chris_DAA_> see you now rigo

jmayer: place where he thinks justin and he has a bit of back and forth is what happens after you sign in

<Chris_DAA_> Rigo, what is an "identity provider"?

<susanisrael> ok i am sorry if i misunderstood jmayer

<rigo> can someone re-paste the message from me that Aleecia mentioned?

jmayer: in the majority of cases, he doesn't see the ID provider as a first party because the ID provider fades into the background

<aleecia> http://lists.w3.org/Archives/Public/public-tracking/2012Jun/0442.html

<Chris_DAA_> rigo, that's not an industry term I'm familiar with?

<justin> I think I agree with that result, but I'm not sure it's clear from the text. The widget example doesn't get that deep.

jmayer: but in cases that the ID provider stays involved (like a FB example), then they are remaining a first party
... it depends on website design

<rigo> Chris_DAA_, this is a well defined term from single sign on scenarios

<npdoty> I believe the definition of corporate-affiliates/easy-discoverable is the breadth of a party

Chrispedigo: What definition of first party is he using? His or the one we're discussing with affiliates?

jmayer: might be conflating two issues: 1) extent of a party; 2) 1st vs 3rd party

<Chris_DAA_> rigo, can you please point to the definition in the record? I couldn't find it

<ifette> And there can be more than one first party on a given page

<ifette> e.g. after you interact with a widget

<aleecia> Train for dinner leaves in 20 minutes

<aleecia> And this is our last issue

<ifette> so brief answers please :)

chrispedigo: trying to get a sense on which definition of 1st party he's using

<justin> ChrisPedigoOPA I don't think it matters.

aleecia: if you disagree, let us know

<npdoty> ChrisPedigoOPA, I think he's referring to meaningful interaction; and that both optional definitions refer to interaction

<rigo> Chris_DAA_, look at http://en.wikipedia.org/wiki/Identity_provider which points you to the SAML Specification

jmayer: if you went with ownership approach, it makes it a much harder case for the ID provider to continue to be a first party after login-flow

<tlr> chris_DAA, look at any of the common identity systems. OpenID, SAML, ... all use the term consistently.

<ifette> Can we pelase stick to the queue? Jonathan seems to be answering every single question

<justin> The widget exception is in the second definition as well . . .

<ifette> but many of us had proposed text

<rigo> SAML is an OASIS Specification

<ifette> and are not answering every question in real time

<npdoty> +1 justin, both options refer to interactions

<Chris_DAA_> ok rigo, has the wikipedia definition been entered into the record here in this forum?

<aleecia> to add to issue-99: action-187, http://lists.w3.org/Archives/Public/public-tracking/2012Jun/0431.html, silence

aleecia; add to issue 99

<ksmith> I think it matters in that JMayer proposed we remove this issue based on the fact that it is covered in the text. However, it is only covered in text that is in his definition for 1st party, which is still up for debate

dwainberg: question -- given Rob's language, what is the difference between this and calling an ID provider a 3rd party and giivng it a permitted use?

<WileyS> +q

dwainberg: and is there anything in the permitted use section that needs to change?

<ifette> we do need to say something, as we want to allow customization by that login provider on the page

dwainberg: is something missing from there?

<npdoty> I think dwainberg is going further to say that identity providers is always a third party, and we have permitted uses

rob: in the time of progress from june and now, things have changed

<jmayer> ksmith, that's right. One of the reasons domain ownership is so problematic is we have to start making one-off exceptions for particular business practices.

rob: some example about castles and bridges
... made progress on permitted uses

<justin> ifette, is that sufficient for you?

Aleecia: action is for Rob to edit last line that removes everything after so that things are covered by permitted uses/first party

<aleecia> Identity providers must not use user data beyond the purpose of

<aleecia> identification and authentication

<robsherman> +q

Aleecia: that is the full proposal from rob

<ifette> ISSUE-99?

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

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

Aleecia: three proposals that are flushed out better. trying to fly thru this to get to dinner

Lou: still struggle with this as to what's a first party. a bit of a challenge
... going back to Chapell's point from before, it seems that what we're doing is looking for edge cases that suggest that we don't really know what tracking is to then assume that everything's underneath it
... there are frameworks in place that deal with this
... government bodies that haven't gotten around this issue

<robsherman> rvaneilk, I need to think more about your language, but are you okay modifying to say "Identity providers that do not otherwise qualify as first parties" or similar? I'm thinking about Jonathan's Facebook example — on many websites, we are an identity provider but also provide other social services that people engage with, and I don't want this to be read that we cannot use data as a first party simply because we're ALSO an identity provider.

Lou: until we get those definitions settled, we're spending many cycles talking past each other

<robsherman> s/rvaneilk/rvaneijk

ifette: one of the important things we're trying to capture is that you want continued experiences from the ID provider (after logging in via facebook, can still see enhanced experiences by them)
... rob's proposal is really a 1-time use; just outsourcing the account. Ian's proposal allows for personalization after login

Aleecia: we still have both texts

<npdoty> is personalization after the login flow a case of multiple first parties?

Aleecia: thanks kevin for dropping out of queue
... move forward with there

three proposals

one from rob, one from ian, and silence

move on to dinner

<BrendanIAB> enjoy your foods!

move on to TPE from there

<npdoty> adjourned for dinner.

<johnsimpson> When will you discuss getting to last call?

<ifette> Also, the fact that we have options and confusion here points to having text to make sure this is clear...

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/tl: dnt will effect changes to data storage/tl: Perhaps I misunderstand. If you don't think that DNT requires you to change how you store data about people, what did you think we were doing here?/
Succeeded: s/you/Kathy/
Succeeded: s/aaa/lou/
Succeeded: s/identifiers/IP address identifiers/
FAILED: s/Chirs/Chris/
FAILED: s/does anybody agree/does anybody disagree/
Succeeded: s/lou/lmastria-DAA/
FAILED: s/156/16/
FAILED: s/Let's discuss tomorrow./Let's discuss tomorrow. That's a matter for the TPE document./
FAILED: s/Treat this as data?/Treat this as data append?/
FAILED: s/xxx/Chapell/
FAILED: s/xxx/chapell/
FAILED: s/Open Rights group/Vrijschrift/
FAILED: s/should/shouldn't/
FAILED: s/there/their/
FAILED: s/I user/I use/
FAILED: s/unsinkable/unlinkable/
FAILED: s/some/a little/
FAILED: s/may well/do/
FAILED: s/hour/our/
FAILED: s/6.1.13/6.1.1.3/
FAILED: s/achapell/chester/
FAILED: s/dpdoty:/npdoty,/
FAILED: s/our/out/
FAILED: s/t1/tl/
FAILED: s/jmayer confused/jmayer: confused/
FAILED: s/t1/tl/
FAILED: s/rvaneilk/rvaneijk/
Found ScribeNick: npdoty
Found ScribeNick: bryan
Found ScribeNick: ifette
Found ScribeNick: robsherman
Found ScribeNick: efelten
Found ScribeNick: dsinger
Found ScribeNick: adrianba
Found ScribeNick: vinay
Inferring Scribes: npdoty, bryan, ifette, robsherman, efelten, dsinger, adrianba, vinay
Scribes: npdoty, bryan, ifette, robsherman, efelten, dsinger, adrianba, vinay
ScribeNicks: npdoty, bryan, ifette, robsherman, efelten, dsinger, adrianba, vinay
Default Present: BrendanIAB?, Telegraaf, fielding, johnsimpson, Jonathan_Mayer
Present: BrendanIAB? Telegraaf fielding johnsimpson Jonathan_Mayer Bryan_Sullivan
Got date from IRC log name: 04 Oct 2012
Guessing minutes URL: http://www.w3.org/2012/10/04-dnt-minutes.html
People with action items: brookman eijk fette fielding justin lowenthal mayer singer van vaneijk west wiley with