IRC log of dnt on 2011-10-12

Timestamps are in UTC.

16:06:28 [RRSAgent]
RRSAgent has joined #dnt
16:06:28 [RRSAgent]
logging to http://www.w3.org/2011/10/12-dnt-irc
16:06:29 [aleecia]
zakim, unmute me
16:06:29 [Zakim]
aleecia should no longer be muted
16:06:37 [enewland]
Aleecia: still working on that.
16:06:46 [aleecia]
zakim, mute me
16:06:46 [Zakim]
aleecia should now be muted
16:06:50 [tlr]
rrsagent, make log public
16:06:50 [npdoty]
clp, there was a corrected link for the minutes sent as an email reply
16:06:53 [enewland]
....action for Shane Wiley, to draft text for issues 23 and issue 24
16:07:01 [enewland]
Zakim, ISSUE 23
16:07:02 [dsriedel]
zackim, mute me
16:07:05 [Zakim]
I don't understand 'ISSUE 23', enewland
16:07:05 [tlr]
I believe he sent regrets
16:07:13 [npdoty]
ISSUE-23?
16:07:13 [trackbot]
ISSUE-23 -- Possible exemption for analytics -- raised
16:07:13 [trackbot]
http://www.w3.org/2011/tracking-protection/track/issues/23
16:07:20 [enewland]
....Shane does not appear to be on the call. we are closing this action.
16:07:22 [sean]
sean has joined #dnt
16:07:23 [aleecia]
zakim, unmute me
16:07:24 [dsriedel]
zakim, mute me
16:07:24 [enewland]
ISSUE-24?
16:07:24 [trackbot]
ISSUE-24 -- Possible exemption for fraud detection and defense -- raised
16:07:24 [trackbot]
http://www.w3.org/2011/tracking-protection/track/issues/24
16:07:25 [npdoty]
ACTION-5?
16:07:25 [trackbot]
ACTION-5 -- Shane Wiley to draft proposed text to resolve ISSUE-23 and ISSUE-34 (organizations should commit to blah, must do the following things) -- due 2011-10-03 -- OPEN
16:07:25 [trackbot]
http://www.w3.org/2011/tracking-protection/track/actions/5
16:07:31 [Zakim]
aleecia should no longer be muted
16:07:35 [Zakim]
dsriedel should now be muted
16:07:44 [npdoty]
ACTION-12?
16:07:44 [trackbot]
ACTION-12 -- Nick Doty to write a proposal on what DNT means to 3rd parties (for davidwainberg) -- due 2011-10-04 -- OPEN
16:07:44 [trackbot]
http://www.w3.org/2011/tracking-protection/track/actions/12
16:07:46 [enewland]
Aleecia: it is premature to close it, with involved people not on the call
16:07:48 [Zakim]
+ +1.202.744.aamm
16:07:48 [ksmith]
ksmith has joined #dnt
16:07:55 [npdoty]
dwainberg, any updates?
16:08:02 [enewland]
Matthias: we will leave the Action 5 open
16:08:09 [alex]
alex has joined #dnt
16:08:32 [enewland]
....any update from dwainberg on Action 12?
16:08:45 [enewland]
dwainberg: Thought that was dispensed with on the other call
16:08:49 [Zakim]
+??P2
16:09:06 [enewland]
Matthias: Aleecia and I will follow up over email
16:09:10 [aleecia]
JC also not able to join today, I believe
16:09:42 [Zakim]
+[Microsoft.aa]
16:09:47 [Kimon]
Kimon has joined #dnt
16:09:56 [tlr]
action-13?
16:09:56 [trackbot]
ACTION-13 -- Thomas Lowenthal to propose a strawman proposal spec for a mandatory DNT server response -- due 2011-10-10 -- PENDINGREVIEW
16:09:56 [trackbot]
http://www.w3.org/2011/tracking-protection/track/actions/13
16:10:00 [tlr]
zakim, unmute me
16:10:00 [Zakim]
Thomas should no longer be muted
16:10:06 [tlr]
http://www.w3.org/2011/tracking-protection/track/actions/pendingreview
16:10:16 [tlr]
http://www.w3.org/2011/tracking-protection/track/actions/13
16:10:16 [enewland]
tl: I also have Action 13.
16:10:34 [aleecia]
Regrets list is now: JC Cannon, Jonathan Mayer, Shane Wiley
16:10:34 [enewland]
tlr: That is going to be part of the discussion later on in the call
16:10:40 [JC]
JC has joined #DNT
16:11:03 [tlr]
q+
16:11:05 [tlr]
ack thomas
16:11:09 [enewland]
Matthias: the next item is for the editor of the compliance spec, Sean, to summarize the discussion that happened in the past week
16:11:33 [enewland]
Sean: We are summarizing all of the issues and putting them into outline form. Based on that we will try to create an outline for the strawman doc.
16:11:48 [enewland]
...we hope to have an outline of a strawman doc on Friday and then to proceed from there.
16:11:55 [tlr]
JC, where are you on action-14?
16:11:57 [tlr]
action-14?
16:11:57 [trackbot]
ACTION-14 -- JC Cannon to write straw man proposal on response from server being optional (related to Issue-81) -- due 2011-10-10 -- OPEN
16:11:57 [trackbot]
http://www.w3.org/2011/tracking-protection/track/actions/14
16:12:18 [enewland]
Justin: do you want me to summarize the comments on the list serve on the first party/third party issue?
16:12:27 [aleecia]
I thought the point of this call was a different spec...
16:12:32 [enewland]
...there were competing specs on the first party and third party issues from jmayer and tl
16:12:45 [enewland]
... Jmayer basically said there should be no must obligations on first parties
16:13:01 [enewland]
.... tl had a number of should recommendations. That first parties should take certain actions
16:13:22 [enewland]
.... it is probably fair to say that for the most part the comments on the list were more along the lines of jmayer's recommendation
16:13:43 [enewland]
.... the one caveat was that as Lee and maybe Brett pointed out, first parties should not be able to collect data and then use it to work around the third party prohibition
16:14:05 [enewland]
... perhaps it would make sense to have must not language saying that they must not evade the intention of dnt by using data in unexpected ways
16:14:39 [tlr]
issue-89?
16:14:43 [aleecia]
Issue: might want prohibitions on first parties re-selling data to get around the intent of DNT
16:14:48 [enewland]
.... there were also two specs on third parties. not really competing but differing. Jmayer's was about what happens when third party is using data for analytics purposes. TL had more detailed proposal on third parties in general. There was not much discussion on this, but more discussion on Aleecia's question, possibly ISSUE - 89
16:15:07 [enewland]
.... Discussion as to whether this should be about behavioral advertising or collection
16:15:12 [dsinger_]
I do feel that if ANY party is continuing to track in the presence of DNT, they MUST respond saying so and why - in this case, I am first party and exempt.
16:15:24 [enewland]
.... work on the document will consider those issues and we can have more substantive discussion on the call re: those issues next week
16:15:39 [tlr]
trackbot, ping?
16:16:10 [enewland]
TL: one component of first/third party issue. In addition to first party collecting and then providing PII to third parties despite DNT, there is also a Q of whether third parties should only be able to outsource info to other third parties that respect DNT. But this is already captured in discussion on the mailing list
16:16:30 [clay_opa_cbs]
zakim, aakk is clay_opa_cbs
16:16:30 [Zakim]
+clay_opa_cbs; got it
16:17:01 [enewland]
Sean: we are moving forward as quickly as we can on the spec
16:17:12 [Zakim]
+ +1.202.546.aann
16:17:17 [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. -- raised
16:17:20 [trackbot]
http://www.w3.org/2011/tracking-protection/track/issues/89
16:17:23 [trackbot]
Created ISSUE-91 - Might want prohibitions on first parties re-selling data to get around the intent of DNT ; please complete additional details at http://www.w3.org/2011/tracking-protection/track/issues/91/edit .
16:17:26 [trackbot]
Sorry, tlr, I don't understand 'trackbot, ping?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
16:17:29 [enewland]
Justin: it was really useful to see Roy's draft spec
16:17:45 [aleecia]
that's some slow (re: trackbot)
16:17:52 [tlr]
zakim, mute me
16:17:52 [Zakim]
Thomas should now be muted
16:18:13 [enewland]
Matthias: we will continue this discussion next week with Aleecia chairing
16:18:18 [enewland]
... moving on to new business
16:18:27 [npdoty]
Topic: Tracking Preference Expression, Response Headers
16:18:31 [fielding]
related sections in draft: http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#responding
16:18:37 [alex__]
alex__ has joined #dnt
16:19:05 [enewland]
.... any comments on the editor's draft that roy sent around yesterda
16:19:25 [enewland]
Roy: if you see something missing or out of place, let us know
16:20:14 [schunter]
DISCUSSION STRUCTURE for RESPONSES:
16:20:14 [schunter]
1. GOALS: What does the response header tries to achieve?
16:20:14 [schunter]
2. CRITERIA: What criteria do we use to assess quality?
16:20:14 [schunter]
3. OPTIONS: What alternative implementations exist?
16:20:16 [enewland]
Matthias: moving on to the discussion of the response headers. there has already been lively discussion on the mailing list. People asked why response headers are useful and asked what options exist for response headers. I suggested a structure for this discussion.
16:21:20 [enewland]
... question of whether you need to reflect the input value or not. And question of how to keep this compatible with existing structure of the web, eg caching
16:21:32 [enewland]
....I propose having three categories of input -- goals, criteria, and options.
16:21:42 [tl]
+?
16:21:44 [tl]
tl has joined #dnt
16:21:47 [tl]
+?
16:22:01 [tl]
+q
16:22:23 [enewland]
.... For example, a goal would be telling the browser what the server will do. A criteria of efficiency of implementing would be an example criteria.
16:22:35 [enewland]
... Are there questions on the proposed structure?
16:22:51 [aleecia]
ack tl
16:23:44 [enewland]
tl: one commentary, you are referring to very concrete goals. as if we want to know all the possible values of a particular implementation in advance. We need to recognize that innovation we may not know about is an important goal to be considered. Even if we do not know what someone will do with a particular feature, if that feature is amenable to future implementations then we should err on the side of that feature.
16:24:08 [enewland]
Matthias: So you are proposing a criteria that is future-proof and extensable?
16:24:19 [schunter]
CRITERIA: extensible / future proof
16:24:27 [enewland]
tl: It should be extensible and future proof
16:24:29 [Zakim]
-dmckinney
16:24:46 [aleecia]
q+
16:25:01 [schunter]
q?
16:25:12 [enewland]
adrian: there may be future uses we don't know about.
16:25:13 [ksmith]
q+
16:25:19 [aleecia]
zakim, unmute me
16:25:19 [Zakim]
aleecia was not muted, aleecia
16:25:32 [enewland]
... this is something we should consider in the discussion but it shouldn't necessarily trump other considerations
16:25:54 [tl]
q?
16:26:08 [npdoty]
ack aleecia
16:26:09 [enewland]
Matthias: need to consider cost of including it
16:26:29 [schunter]
Aleecia-GOAL: Transparency reasons: What happened
16:26:39 [enewland]
Aleecia: going back to our Boston discussions. People were interested in having a response header for transparency reasons. Might also help users opt back in for specific companies.
16:26:50 [dsinger__]
dsinger__ has joined #dnt
16:26:51 [jules]
jules has joined #dnt
16:27:01 [enewland]
... this way a company can remind users they have opted out.
16:27:12 [enewland]
.... there were comments that a response header could be useful for auditing.
16:27:16 [schunter]
GOAL: Auditing: WHat is going on?
16:27:28 [rvaneijk]
it is useful for compliance as well
16:27:45 [npdoty]
I think Aleecia's last "have opted out" refers to "have opted back in"
16:27:47 [enewland]
... also there was a sense that we only hold those to a DNT standard those companies who have opted in to being held to that standard
16:27:59 [tlr]
q?
16:28:04 [enewland]
... and a header would help make that happen. so that the assumption isn't that companies are complying with DNT
16:28:12 [jules]
jules polonetsky is here,
16:28:24 [dsinger__]
Q+
16:29:03 [enewland]
Ksmith: making sure this is exensible is very important. but it doesn't make a ton of sense to include things that we don't see the value of now. By definition, extensible just means it is easy to add things on in the future. Best to keep things clear and simple now.
16:29:18 [tl]
q?
16:29:22 [ksmith]
q-
16:29:26 [BrianTs]
BrianTs has joined #dnt
16:29:38 [dsinger]
dsinger has joined #dnt
16:29:40 [schunter]
q?
16:29:49 [tlr]
Note that these were goals from the Boston discussion.
16:29:50 [enewland]
matthias: what is potential use of the header? Aleecia said auditing, transparency, and ensuring that respecting DNT is an opt in for companies
16:30:05 [npdoty]
ack dsinger__
16:30:13 [enewland]
dsinger_: in terms of goals, if a site is continuing to track you, if it thinks it has a valid reason - it is a first party, you have opted to be tracked - the user should know that.
16:30:34 [enewland]
.... if the site claims that it is not tracking you then the user has a right to remember that. if it ends up that that isn't true then the user may have some recourse.
16:30:45 [jkaran]
q+
16:30:45 [tl]
q+
16:31:13 [enewland]
jkaran: how many users actually know what a response header is?
16:31:31 [aleecia]
(presumably they would not see it, but browsers could build in a UI.)
16:31:31 [enewland]
.... what is the point of talking about a response header when users don't know what that is or will never see it
16:31:33 [npdoty]
ack jkaran
16:31:40 [Zakim]
+[Apple]
16:31:48 [Zakim]
-dsinger
16:31:59 [enewland]
Matthias: you are saying that the information that is communicated should be useful to the end users or shouldn't be there?
16:32:07 [dsinger]
zakim, [apple] has dsinger
16:32:07 [Zakim]
+dsinger; got it
16:32:12 [dwainberg]
q+
16:32:18 [ksmith]
q+
16:32:18 [schunter]
q?
16:32:34 [dsinger]
…my browser might log it; might warn me that site XXXX is still tracking me, and so on.
16:32:36 [npdoty]
ack tl
16:32:46 [enewland]
jkaran: I am just not sure what users would do with this information. If the goal is for auditing or security reasons, that makes sense, but stating as a goal that this information would be in the header for user usage maybe doesn't align with what users can understand.
16:33:00 [enewland]
tl: The response header will be mediated by the browser, etc.
16:33:25 [fielding]
q+
16:33:33 [dsinger]
…agrees with the speaker; users do not see TLS transaction details, but the browser can warn/advise of its use nonetheless
16:33:45 [enewland]
tl: we are providing the tools at the technical level for the user's agent to interpret it in a way that might be useful to the user. Like an icon
16:33:49 [npdoty]
s/the speaker/tl/
16:33:59 [npdoty]
ack dwainberg
16:33:59 [schunter]
q?
16:34:16 [enewland]
dwainberg: we have talked about use of the response header for auditing in general. I am curious how it would be used for auditing.
16:34:34 [enewland]
... And i would propose that if we are going to have a response header and auditing is a rational for that, then we need to craft that response just for auditing needs.
16:34:51 [enewland]
... perhaps only need a static instead of a logical response
16:34:55 [clay_opa_cbs]
+q
16:34:58 [tl]
q+
16:35:32 [justin]
q+
16:35:32 [enewland]
.... I am interested to hear what the auditing that people have in mind would look like
16:36:06 [enewland]
dwainberg: For me, an audit is some process by which you confirm that something is or is not happening
16:36:11 [clp]
auditing -- 3rd party research of log data across sites finds ways to see if when claimed behavior is true
16:36:32 [justin]
I think jonathan would argue that "auditing" = "enforceability" in this context (Section 5 liability)
16:36:58 [enewland]
Aleecia: to summarize other peoples' points in Boston. As a couple of examples, this would be a way to confirm that those who claim to be honoring DNT are in fact doing so.
16:37:01 [rvaneijk]
auditing -- from a user's perspective a mechanism to check whether dnt is being honored or nog
16:37:03 [npdoty]
justin, I think those are actually two separate goals
16:37:08 [enewland]
....we also heard about third party verification - which trustee was interested in pursuing
16:37:19 [enewland]
.... another possibility is it would be useful to know how many sites have DNT enabled
16:37:31 [clp]
auditing for adoption rates
16:37:44 [tl]
q?
16:37:52 [npdoty]
+1 on crawling, quantification, 3rd-party documentation of sites that respect DNT
16:38:11 [enewland]
.... would help with potential FTC evaluations
16:38:12 [dsinger]
…my UA might keep a log of (a) sites that claim to respect DNT (b) sites that do not respond (c) sites that claim to be exempt. I could also build a proxy that does that for e.g. my company
16:38:30 [dsinger]
zakim, who is making noise?
16:38:38 [tlr]
zakim, mute tl
16:38:38 [Zakim]
tl should now be muted
16:38:41 [Zakim]
dsinger, listening for 10 seconds I heard sound from the following: ??P2 (68%), schunter (9%), +385221aagg (14%), dwainberg (13%)
16:38:41 [justin]
npdoty, fair enough, but that's the argument I've heard most often from those that want it (I'm not one of them)
16:38:44 [enewland]
dwainberg: if auditing/enforcability is an important rational then it's important to drill down a bit more
16:38:49 [tlr]
ack thomas
16:39:05 [tlr]
zakim, mute me
16:39:05 [Zakim]
Thomas should now be muted
16:39:28 [npdoty]
ack ksmith
16:40:04 [clp]
+q
16:40:12 [schunter]
Roy: we need to create distinct goals by clarifying terms. Each type of audit should be a different goal of the protocol
16:40:17 [dsinger]
q+
16:40:23 [enewland]
ksmith: We have already stated that the header is not for the user anyway. The header doesn't do anything that the privacy policy doesn't do
16:40:23 [Brett]
Maybe not in a privacy policy, but in a machine readable, standard location, not necessarily in the header.
16:40:34 [npdoty]
who said that the header wasn't for the user anyway?
16:40:43 [ninjamarnau]
i think a response header offers the possibility of an automated notification of the user, in which way soever
16:40:46 [schunter]
OPTION1: Response header
16:40:50 [enewland]
.... we only need it in the response header if we want the browser to act on it
16:40:51 [schunter]
OPTION2: well-known location
16:40:57 [schunter]
q?
16:41:00 [enewland]
.... otherwise it could all be handled in a privacy policy
16:41:01 [fielding]
Proposal: define a well-known location (URI) on site for machine-readable indication of compliance
16:41:05 [npdoty]
ack fielding
16:41:12 [schunter]
OPTION3: Human-readable privacy policy
16:41:13 [aleecia]
It seems entirely reasonable that a browser would want to react to it, actually
16:41:28 [enewland]
fielding: I wrote down four goals so far. Auditing, transparency, opt in, and one other.
16:42:03 [npdoty]
s/one other/measurement/
16:42:33 [enewland]
...we should define a well-known URI where we would have a machine readable doc, such as a json response, that would be a short set of attributes that would be fully extensible - is tracking being used for this site? is tracking required for this site? That would be an easy way to determine compliance, deployment, etc.
16:42:49 [Zakim]
-fielding
16:42:58 [tlr]
ack thomas
16:42:59 [fielding]
oops
16:43:07 [enewland]
.... the second proposal would be to, instead of using a header field, adding a new status code in http.
16:43:09 [tlr]
zakim, mute me
16:43:09 [Zakim]
Thomas should now be muted
16:43:14 [enewland]
Matthias: this discussion should come later.
16:43:19 [fielding]
go ahead, I am done talking ... will call back in
16:43:24 [npdoty]
q?
16:43:26 [rvaneijk]
q+
16:43:37 [tlr]
ack t
16:43:38 [enewland]
Matthias: so why do we want the protocol
16:43:46 [tlr]
whooops
16:43:55 [justin]
q-
16:43:57 [enewland]
...four reasons, compliance, auditing, measurement, and opt out
16:43:58 [dsinger]
q-
16:44:07 [tlr]
queue=clay_opa_cbs,tl,clp,rvaneijk
16:44:11 [npdoty]
ack clay_opa_cbs
16:44:25 [npdoty]
q+
16:44:40 [Zakim]
+fielding
16:44:55 [enewland]
clay_opa: Roy's comments mirrored what i was thinking. A machine-readable static file would be best.
16:45:09 [Zakim]
+ +1.415.734.aaoo
16:45:12 [enewland]
.... maybe different 200 codes
16:45:32 [schunter]
q?
16:45:32 [enewland]
... the main reason i wouldn't want to completely add to the response header, is that for each and every response sent back, you are adding extra bytes
16:45:33 [dsinger]
q+
16:45:40 [npdoty]
ack tl
16:46:19 [enewland]
tl: I think that having an individual response for each user, saying what the site is doing for that user that can then be interpreted by that users browser is important
16:46:20 [KevinT]
zakim, aaoo is kevint
16:46:20 [Zakim]
+kevint; got it
16:47:03 [aleecia]
q+
16:47:07 [enewland]
.... that is a goal we should be working toward here. If sites are doing any sort of opting back in behavior, they should be giving that user information about how they are treating that user. So that the user can react appropriately. it's a use case we shouldn't be dismissing.
16:47:16 [npdoty]
ack clp
16:47:27 [npdoty]
q-
16:47:36 [enewland]
clp: When i talked to the Chrome guys in boston, they asked what the goal was. I would state it this way, during the transition we also have an educational role.
16:48:13 [enewland]
....imagine a browser that had a paranoid mode or learning mode, where the background of each page could be colored based on how the server was responding. then the user can try to avoid certain pages
16:48:22 [enewland]
....the goal would be to educate the user
16:48:24 [schunter]
GOAL is transparency, isnt it?
16:48:59 [npdoty]
ack rvaneijk
16:49:02 [tlr]
q+
16:49:08 [enewland]
rvaneijk: I would phrase this as a consent feedback mechanism
16:49:24 [enewland]
.... especially in the EU, it is useful for the user to know whether the opt in has been acknowledged or not
16:49:52 [clp]
traffic light - red for not respected DNT, green for respecting it
16:49:57 [enewland]
....I work for the dutch data protection authority, but at the moment i speak for myself.
16:50:09 [dwainberg]
q+
16:50:20 [Brett]
q+
16:50:25 [enewland]
dsinger; the reason to put it in the response is that it is sometimes contextual whether you are tracking or not.
16:50:25 [Zakim]
-PederMagee
16:50:38 [schunter]
CRITERIA: Express fine-grained track/no-track for pieces of a site
16:51:15 [npdoty]
s/dsinger;/dsinger:/
16:51:20 [enewland]
....on the argument about adding bytes - doesn't seem to be a warning. The error codes are orthogonal. Don't want to change 200 or 404 to pack two answers into the same value.
16:51:22 [ksmith]
Is it safe to summarize the last several comments as "A header needs to be sent so that the browser has the opportunity to change the user's experience accordingly?"
16:51:24 [fielding]
q+
16:51:31 [npdoty]
ack dsinger
16:51:31 [tlr]
q- later
16:51:37 [npdoty]
ack aleecia
16:51:38 [enewland]
....whether you are being tracked and whether the base request is being satisfied are two different issues
16:52:13 [enewland]
.... to echo points said before. We have two dynamic issues. FIrst we are dealing with a specific issue who has opted back into certain sites. In other cases, we have a company that is first party in one context and third party in another.
16:52:23 [Zakim]
-AmyC
16:52:29 [schunter]
q?
16:52:42 [enewland]
....however, we can have a file that is dynamically generated, that can be a per user, per use contextual piece of information just as a header would be.
16:52:54 [tl]
+q
16:52:58 [enewland]
.... there are things that a browser can do getting a header response that a browser can't do getting info from a text file.
16:52:59 [npdoty]
q+
16:53:39 [fielding]
q-
16:53:44 [aleecia]
will summarize
16:53:57 [tlr]
q-
16:53:57 [npdoty]
ack dwainberg
16:54:38 [enewland]
Brett: Something interesting surfaced in this discussion. It feels like we are asking the user to check a do-not-track me box and then telling them they will still be tracked in lots of ways.
16:54:51 [Zakim]
- +1.202.744.aamm
16:54:58 [enewland]
.... if the response is truly contextual or if we believe the tracking site is indeed allowed an exception, then that could be reflected in the header.
16:55:22 [npdoty]
ack Brett
16:55:24 [npdoty]
ack tl
16:55:25 [enewland]
.... the header could say, i see that you say DNT, but i am tracking you for the following reasons. And to me this is a reason why we want a header. So that users understand what is going on. Transparency.
16:55:49 [aleecia]
basically: Tom's point is that the response can vary by user (a given user opts back in, another doesn't) and David's point was that sites can vary (1st party in one case, 3rd party in another) - so a response is contextual. My point was that we can have dynamically generated text files, not just dynamically generated headers. No need for it to be a static file. However, there may be reasons why a browser can do things differently based on header v. known locat
16:55:49 [aleecia]
file. That seems the important question.
16:56:00 [aleecia]
Tom: you're dropping out
16:56:04 [clp]
youe audio breadking up
16:56:23 [enewland]
tl: To respond to Aleecia's comment about the different functionality of the generated page and the header response. A dynamically generated page may not have the level of per request granularity tha tthe header response does.
16:56:43 [dsinger]
the snag with a separate transaction is that the server now has to try to work out what the other transaction(s) you are asking about were about
16:56:46 [aleecia]
I'm not understanding this in part from drop out
16:57:07 [schunter]
q?
16:57:15 [aleecia]
So I'm getting "yes, it make a difference" but I didn't understand why
16:57:51 [enewland]
npdoty: If i had to load a file every time i made a request of a third party, this would hurt our efficiency requirements.
16:58:02 [tlr]
tl's argument was that, if things are dynamic, then a well-known location is associated with some sort of possibly tenuous state.
16:58:03 [Zakim]
-Sean
16:58:05 [tlr]
ack thomas
16:58:09 [tlr]
ack npd
16:58:09 [npdoty]
ack npdoty
16:58:10 [enewland]
matthias: moving on, the question is once we generate options, what are the criteria?
16:58:14 [clp]
some of it was e.g. servers do time-outs and special cases only they understand, dynamically, can say now I am DNT off, not a document choice but contextual to the resonse.
16:58:33 [enewland]
.... one requirement is the caching requirement.
16:58:45 [enewland]
.... the protocol is good if it doesn't destroy the caching mechanisms of the web.
16:59:03 [schunter]
schunter has joined #dnt
16:59:11 [tlr]
q+
16:59:42 [enewland]
X: You can't have large dynamic sites shut down all cacheabilithy for their sites.
16:59:44 [Brett]
q+
16:59:48 [npdoty]
s/X/fielding/
17:00:02 [tlr]
q-
17:00:10 [tlr]
q+
17:00:54 [enewland]
.... you need to find ways to mitigate that if you have the response. One way is to have a static machine readable file. The other is to have a separate resource so that if the client wants to knows a domain's policy on tracking before it accesses other resources on the site, it could retrieve that. This is not an expensive operation
17:01:16 [schunter]
CRITERIA: caching compatibility
17:01:18 [enewland]
.... this has the added benefit of being applicable to third parties. Third parties can say themselves what they are willing to honor re: DNT
17:01:25 [schunter]
OPTION: data at well-known URI
17:01:36 [aleecia]
(it might make sense for someone to do some quick math as to if there's an efficiency gain from headers v. files, and if so, is it by enough to matter. This seems like the sort of thing we can answer.)
17:01:37 [Zakim]
-[Apple]
17:01:43 [enewland]
.... even moderately busy websites have to process things on the order of 10k requests per second.
17:01:54 [Zakim]
+[Microsoft.aaa]
17:02:09 [schunter]
q?
17:02:16 [npdoty]
ack Brett
17:02:46 [amyc]
amyc has joined #dnt
17:02:49 [enewland]
Brett: If every response is unique, that could break caching. The scope of this is pretty large. b/c every image in every page could be doing caching.
17:03:19 [enewland]
....but this is largely true because any asset i request on the web, just about, includes a cookie that is unique to me. How do we set unique cookies on a per user basis and not break caching?
17:03:47 [Zakim]
- +1.202.546.aann
17:03:50 [enewland]
X: Usually, either there is one resource that sets the cookie, so that all of your javascript files, images, etc do not set cookies
17:04:03 [npdoty]
s/X/fielding/
17:04:07 [clp]
So why can't that work the same way, most of a page will be from known sources, share DNT?
17:04:07 [schunter]
q?
17:04:12 [aleecia]
But cookies are sent automagically?
17:04:14 [enewland]
....the sites are designed to handle this.
17:04:28 [tl]
+q
17:04:30 [enewland]
Brett: so it is the same issue?
17:04:42 [enewland]
fielding: sites are designed to handle scalability/caching for those particular resources
17:04:57 [aleecia]
ack Thomas
17:04:57 [tlr]
ack thomas
17:05:48 [Brett]
If you delegate to a particular resource, isn't that basically the same as standard location?
17:05:55 [tl]
q-
17:06:04 [enewland]
Thomas: what about delegating active response to a particular set of resources
17:06:24 [aleecia]
+1
17:06:29 [enewland]
....could we design an approach that is static for static resources and that indicates that there is something dynamic to be found on the tracking resources on the side.
17:06:54 [schunter]
OPTION: static headers for elements that never track (like ¨i am neutral¨) and then having headers for ¨I am a tracking element and I accept your choice to not be tracked¨
17:06:55 [enewland]
....it sounds to me as though there ought to be a way to replicate the dynamic cookie pattern in this case.
17:07:28 [clay_opa_cbs]
+1 Thomas
17:07:31 [tl]
q+
17:07:31 [ninjamarnau]
good point
17:07:33 [enewland]
....any site used for purpose of tracking is going to be marked as non-cacheabe
17:07:35 [tlr]
zakim, mute me
17:07:35 [Zakim]
Thomas should now be muted
17:07:37 [tlr]
q?
17:07:38 [aleecia]
I didn't follow Roy's last point
17:08:10 [enewland]
s/..../fielding
17:08:39 [fielding]
I mentioned on the mailing list that caching is not a problem if the response is only made on resources that are already non-cacheable -- like the resources that do tracking.
17:08:47 [schunter]
q?
17:08:48 [aleecia]
I would think you could have static content flag itself as static, and still requires a response header.
17:08:50 [enewland]
matthias: the main point is it's not a good idea to require a response header all over the site as this would limit cacheability.
17:09:01 [tl]
unmuting
17:09:03 [Zakim]
-efelten
17:09:14 [tlr]
fielding, what about redirecting the user to a unique, one-time, cacheable URI each time?
17:09:29 [tlr]
there are wrinkles here that I think we need to think about.
17:09:38 [enewland]
tl: if we think we only need a dynamic response for content flagged as non-cacheable then we also need specific policies for content that is cacheable
17:09:51 [fielding]
tlr, the redirect would then contain the response
17:09:58 [enewland]
....we should be able to prohibit tracking for cacheable content
17:10:23 [Zakim]
-Brett
17:10:26 [rvaneijk]
q+
17:10:32 [clp]
Simplicity
17:10:33 [enewland]
Matthias: beside cacheability, are there other criteria for determining whether a protocol is good or bad
17:10:46 [Zakim]
-npdoty
17:10:50 [tl]
ack tl
17:11:22 [tl]
...and we should require a static "will not track" header on cacheable content
17:11:43 [enewland]
rvaneijk: i am still puzzled. as far as i understand, when a client requests a page that is cached, the server will extend an e-tag to determine if the page has changed and this will still trigger a clickstream
17:12:15 [enewland]
....and if you are serving ads from different websites, it is still possible for user to be tracked across several websites
17:12:26 [tl]
+q
17:12:48 [enewland]
fielding: i wasnt suggested that tracking not apply to cacheable response. I was saying we don't need to X. We are talking about shared caching.
17:12:54 [aleecia]
I'm not sure we can know apriori when something is or is not tracking, for all time in the future (or even for today)
17:13:00 [rvaneijk]
ok tnx
17:13:07 [schunter]
q?
17:13:11 [tl]
ack rvaneijk
17:13:13 [rvaneijk]
q-
17:13:28 [aleecia]
That was the part of Roy's comment I hadn't understood
17:13:30 [hefferjr]
"Shared caching" also describes "Content Delivery Networks" (such as Akamai)
17:13:38 [enewland]
tl: if we have decided that cached content doesnt require a response header than we have failed.
17:13:49 [amyc]
q+
17:13:53 [enewland]
...this means there is a piece of content for which a user can't tell whether or not their request is being honored
17:14:06 [fielding]
s/need to X/need to respond uniquely to the client on every response, including those for cacheable content/
17:14:22 [enewland]
....if we go in the direction of saying that cached content does not have an individualized response header, then we should say that cached content MUST NOT be used for tracking
17:15:13 [enewland]
matthias: if we go back to the criteria, then for tl, an important criteria is that users are able to tell if they are being tracked or not. and to be able to tell this from all elements
17:15:16 [ksmith]
ksmith has left #dnt
17:15:17 [justin]
I don't think anyone is arguing that Tracking from cached content is allowable in response to a DNT header.
17:15:21 [Zakim]
- +385221aagg
17:15:44 [aleecia]
q+
17:15:53 [tl]
ack tl
17:15:57 [enewland]
tl: i want to distinguish between elements that have individualized headers and those that say 'this element is never used for tracking'
17:15:58 [tlr]
"I'm the home page. I'm not tracking you, but the image over there might."
17:16:03 [tlr]
tl, is that roughly the meaning you're after?
17:16:11 [enewland]
matthias: to summarize the options:
17:16:23 [schunter]
OPTION: well known URI
17:16:30 [schunter]
OPTION: Different types of headers
17:16:37 [tlr]
q?
17:16:52 [tl]
tlr, that's more detailed. more like "i'm the homepage|background image|favicon. i'm cached and never used for tracking"
17:16:58 [enewland]
tlr: another is fine grained responses
17:17:24 [aleecia]
Was Charles
17:17:33 [tlr]
s/tlr:/clp:/
17:18:02 [aleecia]
To inject one more point: tracking can be browser fingerprinting. Works fine with static content.
17:18:22 [aleecia]
So I don't get why static content *cannot* be tracking, as per Roy
17:18:24 [enewland]
X: another option might be no header response?
17:18:26 [aleecia]
ack aleecia
17:18:32 [schunter]
OPTION: No header/response
17:18:53 [fielding]
OPTION: error response status code for indicating "must opt in"
17:19:10 [tlr]
q+
17:19:13 [tlr]
ack amyc
17:19:15 [tl]
ACTION: tl to update mandatory response header proposal to acknowledge caching concerns
17:19:16 [trackbot]
Created ACTION-16 - Update mandatory response header proposal to acknowledge caching concerns [on Thomas Lowenthal - due 2011-10-19].
17:19:33 [tlr]
OPTION: specific HTTP error response
17:19:45 [aleecia]
Isn't this a different issue?
17:19:45 [enewland]
XX: i want to add an option for a specific error response in http. To indicate that a client has to opt in. You can't use my service unless you opt in.
17:19:56 [aleecia]
s/XX/Roy/
17:20:00 [tlr]
q+
17:20:30 [enewland]
Matthias: moving on. Technical discussion of how a site knows if it is first or third party. Second, how do you tell people they should opt back in.
17:20:39 [enewland]
....we can discuss either of them
17:20:50 [aleecia]
opt back in would be easier
17:20:55 [clp]
agree
17:21:00 [tlr]
ack thomas
17:21:00 [jkaran]
agree
17:21:46 [tlr]
zakim, mute me
17:21:46 [Zakim]
Thomas should now be muted
17:21:52 [enewland]
tlr: let's discuss opting back in. But first, one other quick thing. Tom and Roy should feel free to do a lot of cross review with Action item 16 so we make sure we have something technically practical
17:22:11 [enewland]
Matthias: I will send an email out kicking this off.
17:22:15 [tlr]
s/we have something technically practical/we have something they agree is technically practical/
17:23:00 [enewland]
....next meeting is next week. same time, same place.
17:23:25 [clp]
laughs
17:23:26 [aleecia]
are we adjourned?
17:23:29 [Zakim]
-clay_opa_cbs
17:23:32 [clp]
bye
17:23:44 [tlr]
ack thoas
17:23:46 [tlr]
ack thomas
17:24:06 [Zakim]
-??P57
17:24:23 [enewland]
tlr: Register for face to face. Registration is extended until 21st of October.
17:24:27 [ninjamarnau]
thanks for extending the deadline
17:25:16 [enewland]
enewland has left #dnt
17:25:18 [Zakim]
-kevint
17:25:25 [Zakim]
-JKaran
17:25:32 [Zakim]
-Justin
17:25:35 [Zakim]
- +1.813.366.aaii
17:25:37 [Zakim]
-[Microsoft.aa]
17:25:37 [Zakim]
-[Microsoft]
17:25:38 [Zakim]
-dwainberg
17:25:40 [Zakim]
-heather
17:25:41 [Zakim]
-[Microsoft.a]
17:25:41 [Zakim]
-schunter
17:25:41 [Zakim]
- +1.813.366.aall
17:25:42 [Zakim]
-dsriedel
17:25:43 [Zakim]
-??P2
17:25:46 [Zakim]
-ninja
17:25:48 [Zakim]
-tl
17:25:50 [Zakim]
-Thomas
17:25:52 [Zakim]
-RobertVanEijk
17:25:59 [aleecia]
RRSAgent, set logs world-visible
17:26:12 [aleecia]
trackbot, end meeting
17:26:12 [trackbot]
Zakim, list attendees
17:26:12 [Zakim]
As of this point the attendees have been npdoty, aleecia, Thomas, +1.609.981.aaaa, tl, schunter, +49.431.98.aabb, PederMagee, +1.212.631.aacc, +1.949.851.aadd, ninja, dsriedel,
17:26:13 [trackbot]
RRSAgent, please draft minutes
17:26:13 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/10/12-dnt-minutes.html trackbot
17:26:14 [trackbot]
RRSAgent, bye
17:26:14 [RRSAgent]
I see 1 open action item saved in http://www.w3.org/2011/10/12-dnt-actions.rdf :
17:26:14 [RRSAgent]
ACTION: tl to update mandatory response header proposal to acknowledge caching concerns [1]
17:26:14 [RRSAgent]
recorded in http://www.w3.org/2011/10/12-dnt-irc#T17-19-15
17:26:16 [Zakim]
... fielding, JKaran, efelten, +385221aaee, RobertVanEijk, dsinger, +1.206.658.aaff, AmyC, heather, +385221aagg, +1.202.637.aahh, adrianba, dwainberg, +1.813.366.aaii, [Microsoft],
17:26:21 [Zakim]
... Brett, Erica, +1.215.591.aajj, +1.908.541.aakk, dmckinney, +1.813.366.aall, Sean, +1.202.744.aamm, clay_opa_cbs, +1.202.546.aann, +1.415.734.aaoo, kevint