See also: IRC log
<trackbot> Date: 21 December 2011
<tl> it's frustrating that zakim doesn't recognize its name unless it is followed by a comma
<aleecia> dsinger: thank you. I had not known that, and that's really helpful.
<npdoty> http://www.w3.org/2011/12/14-dnt-minutes
schunter1: Comments on the minutes?
... Nope.
... Review of next face-to-face meeting logistics.
<schunter1> Avenue de Beaulieu 25, Brussels
<schunter1> http://www.novotel.com/gb/hotel-2122-novotel-brussels-centre-tour-noire/index.shtml
<npdoty> http://ec.europa.eu/oib/buildings_en.cfm
schunter1: Discussion of where the meeting might be, where to get a hotel.
... Brussels has good public transportation, isn't large.
... There may be an outreach event.
<aleecia> (my wishes for feeling better soon, and could the person coughing please mute?)
<JC> Conference Computers, Privacy and Data Protection same week
<JC> ... in Brussels
<npdoty> issue-4?
<trackbot> ISSUE-4 -- What is the default for DNT in client configuration (opt-in or opt-out)? -- pending review
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/4
Discussion of ISSUE-4.
<npdoty> so we're agreed that it's up to the user agent to determine how to decide the user's preference?
<dsinger> issue-13?
<trackbot> ISSUE-13 -- What are the requirements for DNT on apps/native software in addition to browsers? -- pending review
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/13
<npdoty> schunter1, hang on, we have comments on issue 4
tl: We addressed this some time ago in October.
schunter1: Ok, we're close, suggest moving.
<aleecia> text on issue-4:
<aleecia> PROPOSED LANGUAGE in FPWD:
<aleecia> The goal of this protocol is to allow a user to express their personal
<aleecia> preference regarding cross-site tracking to each server and web
<aleecia> application that they communicate with via HTTP, thereby allowing each
<aleecia> server to either adjust their behavior to meet the user's expectations
<aleecia> or reach a separate agreement with the user to satisfy both parties.
<aleecia> Key to that notion of expression is that it must reflect the user's
<aleecia> preference, not the preference of some institutional or
<aleecia> network-imposed mechanism outside the user's control.
<aleecia> The remainder of this specification defines the protocol in terms of
<aleecia> whether DNT is enabled or not enabled. We do not specify how that
<aleecia> preference is configured: the user agent is responsible for
<aleecia> determining the user experience by which this preference is set.
<aleecia> For example, a user might configure their own user agent to tell
<aleecia> servers "do not track me cross-site", install a plug-in or extension
<aleecia> that is specifically designed to add that expression, or make a choice
<aleecia> for privacy that then implicitly includes a tracking preference (e.g.,
<aleecia> "Privacy settings: high"). For each of these cases, we say that DNT is
<aleecia> enabled.
<aleecia> +1 on that
jmayer: Clarifying the standard of review for PENDING REVIEW -> CLOSED. Suggest consensus on text is necessary.
<aleecia> yep
tl: was the text in the FPWD the same as when we agreed prior?
jmayer: language is about personal preference, with is a value suggested by Mozilla, others by user expectation.
... key to that is user's preference, not set by institution. We talked about SHOULDs, and where institutions SHOULD NOT
<npdoty> +1, I'm not sure I like this institutional language, which I thought was covered by Issue 95
<fielding> The goal of this protocol is to allow a user to express their personal preference regarding cross-site tracking to each server and web application that they communicate with via HTTP, thereby allowing each server to either adjust their behavior to meet the user's expectations or reach a separate agreement with the user to satisfy both parties. Key to that notion of expression is that it must reflect the user's preference, not the preference of some institution
<fielding> network-imposed mechanism outside the user's control.
<fielding> The remainder of this specification defines the protocol in terms of whether DNT is enabled or not enabled. We do not specify how that preference is configured: the user agent is responsible for determining the user experience by which this preference is set.
<fielding> For example, a user might configure their own user agent to tell servers "do not track me cross-site", install a plug-in or extension that is specifically designed to add that expression, or make a choice for privacy that then implicitly includes a tracking preference (e.g., "Privacy settings: high"). For each of these cases, we say that DNT is enabled.
tl: text language in defaults in user agents was agreed on 26th, but may not be in WD. also discussed at f2f, with recommendations for non-user agents
matthias: should be user preference
<npdoty> I'm not sure the text concludes that there shouldn't be a default
<KevinT> point re: mobile apps I would like to raise
jmayer: language doesn't convey what I agree with: "conveys a user preference" isn't what I'd like. If you get DNT:1, you have to honor it regardless if set by institution. Then discussion of what institutions should & shouldn't do.
... you're taking a position of where it can be set
tl: Recall the institutional language is separate from the default language.
<schunter1> Aleecia: tri-value: yes/no/not set.
<npdoty> who wants to take on the action to re-draft that text?
Aleecia: Good discussion on this on mailing list. Suggestion was three-way setting: DNT-1, DNT-0, DNT-unset. Don't think that agreement is captured by language, is important. Would like it to be airtight. Suggest one more round of language edits.
<fielding> umm, disagree ... the language reflects the intended seamantics
schunter1: On Issue 4, there's agreement in principle, we'll work on smoothing language and try to close next time.
<tl> i can do it
<tl> [just got diconnected[
schunter1: Looking for volunteers to redraft.
roy: This needs to be about user choice.
<npdoty> are the default settings in my browser not considered to be my preference?
aleecia: I'm thinking about a three-state header, a separate issue.
<aleecia> issue-78?
<trackbot> ISSUE-78 -- What is the difference between absence of DNT header and DNT = 0? -- pending review
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/78
roy: You're thinking about issue 78.
aleecia: Yep.
... This should be a user preference.
jmayer: language should be one on user agents, and one on institution or proxy. Renaming these issues to be clearer.
... Want to make clear, for what it's worth, don't have my support on issue-4. Don't see it as necessarily about user expression
... without getting into that debate now, let's make that an explicit issue.
<sidstamm> +1 on jmayer's plan of action (though I may not agree with his position)
jmayer: What intermediaries get to do & not do should stay open, but closing issue-4 is ok
<npdoty> does issue-95 cover jmayer's concern on intermediaries?
jmayer: language in issue-4 conflates outcomes and motivation, let's have a section on what browsers can do by default and one section on intermediaries
schunter: closing issue-4
<fielding> I think the intermediary issue is 81
schunter: disagree user agent should set DNT on user preference?
<npdoty> fielding, 81 is the response header issue
jmayer: if user sets, of course. Debate is about defaults.
... if browser or network provider has it on by default, that's different; we should talk about that more
dsinger: If we say "it's a user preference," what can a service do if it knows it was set by an intermediary.
<fielding> yes, that is what the language is intended to say
<npdoty> +1 on the concern
<tl> +1
schunter1: Server shouldn't be able to blame intermediaries. DNT: 1 means DNT: 1.
<npdoty> fielding, you do believe that a server should be able to ignore the signal if it thinks an intermediary inserted the preference?
roy: If DNT: 1 isn't a user preference, I'm going to ignore it.
<JC> How does one know if it is a user preference or not?
roy: There are possible bugs in intermediaries and servers, might have to ignore headers for implementaton.
<JohnSimpson> agree with JC, how do you know if user preference or not?
<schunter1> Roy makes a case that if buggy headers are received, then server implementors may ignore the flag.
schunter1: If a company puts on DNT for employees, servers should honor that.
roy: Might allow from small companies, not large companies.
<jmayer_> Why, Roy?
<sidstamm> this is good conversation, but I don't see how this is about issue 4 anymore...
<fwagner> do not agree with Matthias - this can be done by central browser settings of the company
<schunter1> Example: certain proxy sets DNT=1 by default.
<schunter1> SQUID...
<jmayer_> What if the intermediary only sets if no header present?
roy: If we allow this, why not just punt to regulators?
<aleecia> meanwhile, issue-13 proposed text in FPWD:
<aleecia> This specification uses the term user agent to refer to any of the
<aleecia> various client programs capable of initiating HTTP requests,
<aleecia> including, but not limited to, browsers, spiders (web-based robots),
<aleecia> command-line tools, native applications, and mobile apps [HTTP11].
<npdoty> we still have a comment on issue-13 from KevinT
<fielding> If DNT is not a user preference then there is no reason to waste the bytes and time by adding it to the protocol -- we should just give up and rely on regulators to state the requirements on data sharing.
schunter1: Moving on.
<sidstamm> a?
<sidstamm> I'll wait until kevin is done
<sidstamm> we're not talking about issue 13 yet are we?
KevinT: Mobile use case - what about platform intermediaries? Maybe not necessarily mobile only. Non-browser apps.
<alex> alex is AlexDeliyannis
<schunter1> let's revisit ISSUE-13
KevinT: e.g. an OS-wide DNT flag.
<aleecia> tl: this is about issue-13 text, I believe
<aleecia> um, sorry about the : there
<sidstamm> queue is not workin' for me today.
tl: There's an implementation of this in Boot to Gecko. Can set DNT preference in OS, any app can read from JavaScript API. Might even allow modifying in future.
<aleecia> I think what Tom is saying is lovely, but doesn't address how we might (or might not) change issue-13?
roy: This seems like out of scope configuration.
<npdoty> sidstamm, did you still want to comment on issue-4?
<dsinger> issue-13?
<trackbot> ISSUE-13 -- What are the requirements for DNT on apps/native software in addition to browsers? -- pending review
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/13
schunter1: Closed Issue 4, moved to Issue 13.
<sidstamm> thank you
jmayer: on issue-13, talking about language for non-web apps?
<dsinger> I cannot see how it is relevant what the name of the software the user uses is; 'browser', 'help viewer', 'application', etc...
jmayer: would suggest we add non-normative language on how this might apply elsewhere. We're focused on web context, but smart phones and tablets shouldn't be back to square one when what we do translates there.
... the spec is targeted to the web, but could be in a native environment; we might note that.
schunter: all we do relates to HTTP. issue-13 says doesn't apply if not HTTP. resist the idea of extending
<dsinger> yes, we're talking about HTTP user agents (at the user end)
schunter: can have different specs on different protocols
<sidstamm> +1 on dsinger's point -- lets focus on HTTP user agents (all software that speaks HTTP for the user)
dsinger: agree. Don't care if it's a browser, application, etc. - HTTP, we're done.
<fwagner> +1 on davids point
schunter: if it's not HTTP, it's not covered. Could be another spec
<dsinger> also agree we're in HTTP only (for now)
jmayer: Suggests two things. First, note this applies to mobile more broadly than some read it, should clarify. Second, if we're scoping this to HTTP, would be a shame if a company said "fine, we'll use FTP"
... at minimum some non-normative language around SPDY. failing to future-proof
<npdoty> I think jmayer's point is that we could have a non-normative comment to suggest that this could apply to other protocols (which I could support)
<aleecia_> +1 personally
dsinger: We're defining an HTTP header. We don't need to say anything at all about other protocols
... can extend later, or others can
jmayer: don't agree. Don't see why saying things non-normative would be out of scope
dsinger: happy to read text you propose but don't see how you could do it
<sidstamm> I think this is a new issue
<npdoty> dsinger: I'm not sure how you'd do it, but I'm happy to read text you propose.
schunter: suggest closing this, but can perhaps take a new issue for non-normative
<npdoty> what would the new issue be called?
<sidstamm> "should the TPE be extended to other protocols?"
<aleecia> (Sid's title works for me)
<fielding> jmayer, sorry missed your q on IRC ... the reason for deliberately ignoring portions of the network that override user preferences is because we are trying to develop a protocol that behavioral advertising networks will be willing to adhere to as a reasonable cost of business. Sending a corporate preference or an ISP preference is not reasonable -- it means we just won't implement this protocol, and would instead go back to cookie-based, non-standard means of
<fielding> determining that preference which would less likely be gamed by intermediaries.
<aleecia> (perhaps "beyond HTTP" at the end)
<npdoty> ISSUE: should/could the tracking preference expression be extended to other protocols beyond HTTP?
<trackbot> Created ISSUE-108 - Should/could the tracking preference expression be extended to other protocols beyond HTTP? ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/108/edit .
<aleecia> text on issue-78:
schunter1: Moving to Issue 78.
<aleecia> The DNT field-value sent by a user agent must begin with the character
<aleecia> "1" (%x31) if DNT is enabled and there is not, to the user agent's
<aleecia> knowledge, a specific exception for the origin server targeted by this
<aleecia> request. If DNT is enabled and there is a specific exception for the
<aleecia> target origin server via some mechanism understood by the user agent,
<aleecia> then the DNT field-value sent by a user agent must begin with the
<aleecia> character "0" (%x30).
<aleecia> so I'm not seeing "unsent"?
<dsinger> issue-78?
<trackbot> ISSUE-78 -- What is the difference between absence of DNT header and DNT = 0? -- pending review
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/78
<aleecia> Maybe I'm missing something
<amyc> on 78, I think DNT0 should be non-exclusive means for indicating user override
roy: Some request for clarifications on intermediaries.
<amyc> user agent may not know about override
<sidstamm> +1 to dsinger
dsinger: No header is a separate state.
roy: Ok.
<WileyS> Are we using the queue today?
<schunter1> sometimes ;-)
<npdoty> Shane is suggesting that we could consider other values besides 0 and 1 (to be discussed later in this call, if we stick to agenda)
WileyS: Issue 78 is a broader issue about DNT values. We haven't fully set out the structure of those values. Could close if absence of header is DNT: 0 (?).
<sidstamm> agree with npdoty
npdoty: This is about what an unset header means. That's it. Think we can close it with some clarification.
<jmayer_> +1
<WileyS> Agreed - current langauge proposes what DNT:0 means - would strip that.
<schunter1> Unset means either that DNT is not enabled or that the user agent (maybe old) does not support DNT.
<aleecia> um.
<sidstamm> lack of header does not imply any value
<aleecia> +1 sid
<WileyS> +1
<JohnSimpson> +1
<npdoty> so should we move on beyond issue-78? (currently hearing silence)
<eberkower> I hear silence\
<aleecia> I'm not sure the text captures that, but perhaps it will when we have multiple issues all together in place?
<eberkower> ah - much better
<JC> +1 sid
matthias1: Would clarify - absence of a header means not enabled or not supported, don't say what 0 means.
<aleecia> jmayer: If you don't see a header, it's a different state.
<aleecia> ... not "unspecified or the same thing as DNT:0" which is not what we've agreed upon
<aleecia> ...it is a separate state of there's nothing here
<aleecia> That's a rather large suggestion. Frank, what do you have in mind?
fwagner: Unsure if we defined the default state. Default may vary by language or region.
matthias1: DNT: 1 and 0 are preferences. Otherwise, send nothing.
<fielding> That may be my mistake ... I could have sworn I added the text that Aleecia sent about no header meaning that no preference given (and other defaults may depend on region, other cookies, etc.) ... but now I can't find it in TPE
<aleecia> Ah! That's where Frank was going.
<aleecia> I'm pretty sure we didn't remove it at the f2f
roy: Thought I added text about no header = up to region, just no expressed preference.
<schunter1> ACTION: rfielding revise language in spec to address ISSUE-78 [recorded in http://www.w3.org/2011/12/21-dnt-minutes.html#action01]
<trackbot> Sorry, couldn't find user - rfielding
<schunter1> ACTION: fielding revise language in spec to address ISSUE-78 [recorded in http://www.w3.org/2011/12/21-dnt-minutes.html#action02]
<trackbot> Created ACTION-41 - Revise language in spec to address ISSUE-78 [on Roy Fielding - due 2011-12-28].
<fielding> Section 5: If no DNT preference is received, it may indicate either that the user has chosen to allow cross-site tracking or that their user agent does not support this protocol for expressing DNT (e.g., user agents deployed prior to this protocol's existence). In the absence of regulatory, legal, or other requirements, servers are free to interpret the lack of a DNT header as they find most appropriate for the given user, particularly when considered in light
<fielding> the user's privacy expectations and cultural circumstances.
<aleecia> We might need to review half a dozen issues together
<dsinger> issue-81?
<aleecia> issue-81 suggestion:
<trackbot> ISSUE-81 -- Do we need a response at all from server? -- pending review
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/81
<aleecia> We currently discuss the format of the headers and under what
<aleecia> conditions they shall be sent. The fact that a header is needed in
<aleecia> some cases seems to be no longer disputed at this point.
schunter1: moving on to issue 81
... think issue 81 can be closed
roy: I sent a response on this to the mailing list.
<dsinger> how frequently? in what way?
schunter1: We'll discuss in other issues when the response should be sent, what it'll look like.
<aleecia> Happy to close with a note of "yes" and pointer to other issues
<aleecia> PROPOSED Resolution FPWD:
<aleecia> DNT-extension = %x21-2B / %x2D-7E ; visible ASCII
<aleecia> except ","
<npdoty> issue-47, issue-48, issue-51, 105, 106, 107 also relevant to specifics about what kind of response
schunter1: Moving to issue 82.
<dsinger> issue-82?
<trackbot> ISSUE-82 -- Should the DNT header be extensible with additional parameters? -- pending review
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/82
schunter1: Thinking we have good enough language to close the issue.
... Closing.
<aleecia> issue-84 -
schunter1: Moving to Issue 84.
<aleecia> PROPOSED Resolution FPWD:
<aleecia> Section 4.2 contains a proposal of the Dom interfaces:
<aleecia> www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
<WileyS> We address this a bit in Issue 31
<aleecia> So again issue-84 to be closed with "yes"?
schunter1: There's a proposed JavaScript API.
tl: Problem - any client-side exception list necessarily has conflict with a DOM flag. Generating inconsistencies between the two.
<dsinger> issue-84?
<trackbot> ISSUE-84 -- Do we need a JavaScript API / DOM property for client-side js access to Do Not Track status? -- pending review
<trackbot> http://www.w3.org/2011/tracking-protection/track/issues/84
tl: Problems with embedded scripts.
schunter1: Solution?
tl: Nope, this is a problem.
<tl> jmayer, this is a solution?
schunter1: Suggest accepting language, postponing.
tl: No. This is a fundamental problem. HTTP perspective != DOM perspective, no solution for the problem.
jmayer: I agree with tl on the problems, per my slides from Princeton. One easy way to implement would be for the server to insert into its own JavaScript the status of DNT.
... for now avoid implementing a DOM API and just suggest to servers that this would be one easy way to do it
aleecia: Sid dropped, he wants to be involved in this.
tl: Support dropping explicit API, non-normative language for workaround.
<schunter1> ACTION: jmayer proposes non-normative language to obtain DNT info in Javascript; would replace DOM-API [recorded in http://www.w3.org/2011/12/21-dnt-minutes.html#action03]
<trackbot> Created ACTION-42 - Proposes non-normative language to obtain DNT info in Javascript; would replace DOM-API [on Jonathan Mayer - due 2011-12-28].
<npdoty> so we should continue discussion of this issue on the mailing list? unless everyone is willing to give up on the DOM proposal
<aleecia> mailing list sounds good to me
<JohnSimpson> mailing list sounds good
schunter1: Moving to Roy's proposal on response headers.
roy: Nothing to present today.
<npdoty> http://lists.w3.org/Archives/Public/public-tracking/2011Dec/0118.html
schunter1: Moving to site-specific exceptions.
npdoty: Reviewing Shane's (and my) proposal. User agent-managed exceptions. Third-party only has to pay attention to the DNT value it receives.
... User agent prompts for exception. Exceptions stored as (first party, third party).
... Some open Qs on fingerprinting, JS-accessible list of exceptions.
<aleecia> Things I like about this: not cookie based; matches exception for a third party to the first party context
tl: Like simple server logic. Avoids reasoning about signals. Like not being cookie based. Like first party-third party pairing.
<tl> +1
WileyS: Aim was a simple proposal. Query/polling-based - doesn't occur with every event. Introduces notion of web-wide exception (*, third party).
<aleecia> ...and that might help in the EU context where we cannot always have a global opt out / opt in
WileyS: Going to take a lot more discussion, but good progress.
tl: See web-wide exceptions as just a special case of a first party / third party pairing.
... Preserves the things I like about this approach.
npdoty: Yes, you can represent a web-wide exception the same way. You could do things much more complicated in the user agent, too. How much do we want to set in the spec? How much flexibility do we want to leave to user agents?
<aleecia> -1
<aleecia> (sorry - I should have jumped in and did not)
jmayer: We should say something about exceptions in browsers that don't support this exception API.
<aleecia> I'm in favor of moving this into the spec but leaving it open
schunter1: Suggestion that we put this into the spec, but more discussion necessary.
<aleecia> It's going to be easier to see things in one place, I think
npdoty: In spec language, should be able to import easily.
<npdoty> so I'll send this language to Roy to import into the draft
schunter1: Convert remaining Qs into new issues.
<npdoty> and then we'll also need to create new group ISSUES for the open issues we have in this proposal
schunter1: Next meeting 1/4.
<npdoty> including the issue that jmayer has raised about alternate opt-outs (perhaps scoped to when browsers have not implemented this yet)
<schunter1> ACTION: npdoty specify the proposed text for opt-back-in and send it to roy with open issue spelled out [recorded in http://www.w3.org/2011/12/21-dnt-minutes.html#action04]
<trackbot> Created ACTION-43 - Specify the proposed text for opt-back-in and send it to roy with open issue spelled out [on Nick Doty - due 2011-12-28].
<fwagner> Merry christmas, happy new year to all of you !
<npdoty> jmayer, if you have more comments on the API being heavyweight, we should talk about that
<npdoty> trackbot, end meeting