16:06:28 RRSAgent has joined #dnt 16:06:28 logging to http://www.w3.org/2011/10/12-dnt-irc 16:06:29 zakim, unmute me 16:06:29 aleecia should no longer be muted 16:06:37 Aleecia: still working on that. 16:06:46 zakim, mute me 16:06:46 aleecia should now be muted 16:06:50 rrsagent, make log public 16:06:50 clp, there was a corrected link for the minutes sent as an email reply 16:06:53 ....action for Shane Wiley, to draft text for issues 23 and issue 24 16:07:01 Zakim, ISSUE 23 16:07:02 zackim, mute me 16:07:05 I don't understand 'ISSUE 23', enewland 16:07:05 I believe he sent regrets 16:07:13 ISSUE-23? 16:07:13 ISSUE-23 -- Possible exemption for analytics -- raised 16:07:13 http://www.w3.org/2011/tracking-protection/track/issues/23 16:07:20 ....Shane does not appear to be on the call. we are closing this action. 16:07:22 sean has joined #dnt 16:07:23 zakim, unmute me 16:07:24 zakim, mute me 16:07:24 ISSUE-24? 16:07:24 ISSUE-24 -- Possible exemption for fraud detection and defense -- raised 16:07:24 http://www.w3.org/2011/tracking-protection/track/issues/24 16:07:25 ACTION-5? 16:07:25 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 http://www.w3.org/2011/tracking-protection/track/actions/5 16:07:31 aleecia should no longer be muted 16:07:35 dsriedel should now be muted 16:07:44 ACTION-12? 16:07:44 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 http://www.w3.org/2011/tracking-protection/track/actions/12 16:07:46 Aleecia: it is premature to close it, with involved people not on the call 16:07:48 + +1.202.744.aamm 16:07:48 ksmith has joined #dnt 16:07:55 dwainberg, any updates? 16:08:02 Matthias: we will leave the Action 5 open 16:08:09 alex has joined #dnt 16:08:32 ....any update from dwainberg on Action 12? 16:08:45 dwainberg: Thought that was dispensed with on the other call 16:08:49 +??P2 16:09:06 Matthias: Aleecia and I will follow up over email 16:09:10 JC also not able to join today, I believe 16:09:42 +[Microsoft.aa] 16:09:47 Kimon has joined #dnt 16:09:56 action-13? 16:09:56 ACTION-13 -- Thomas Lowenthal to propose a strawman proposal spec for a mandatory DNT server response -- due 2011-10-10 -- PENDINGREVIEW 16:09:56 http://www.w3.org/2011/tracking-protection/track/actions/13 16:10:00 zakim, unmute me 16:10:00 Thomas should no longer be muted 16:10:06 http://www.w3.org/2011/tracking-protection/track/actions/pendingreview 16:10:16 http://www.w3.org/2011/tracking-protection/track/actions/13 16:10:16 tl: I also have Action 13. 16:10:34 Regrets list is now: JC Cannon, Jonathan Mayer, Shane Wiley 16:10:34 tlr: That is going to be part of the discussion later on in the call 16:10:40 JC has joined #DNT 16:11:03 q+ 16:11:05 ack thomas 16:11:09 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 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 ...we hope to have an outline of a strawman doc on Friday and then to proceed from there. 16:11:55 JC, where are you on action-14? 16:11:57 action-14? 16:11:57 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 http://www.w3.org/2011/tracking-protection/track/actions/14 16:12:18 Justin: do you want me to summarize the comments on the list serve on the first party/third party issue? 16:12:27 I thought the point of this call was a different spec... 16:12:32 ...there were competing specs on the first party and third party issues from jmayer and tl 16:12:45 ... Jmayer basically said there should be no must obligations on first parties 16:13:01 .... tl had a number of should recommendations. That first parties should take certain actions 16:13:22 .... 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 .... 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 ... 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 issue-89? 16:14:43 Issue: might want prohibitions on first parties re-selling data to get around the intent of DNT 16:14:48 .... 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 .... Discussion as to whether this should be about behavioral advertising or collection 16:15:12 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 .... 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 trackbot, ping? 16:16:10 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 zakim, aakk is clay_opa_cbs 16:16:30 +clay_opa_cbs; got it 16:17:01 Sean: we are moving forward as quickly as we can on the spec 16:17:12 + +1.202.546.aann 16:17:17 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 http://www.w3.org/2011/tracking-protection/track/issues/89 16:17:23 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 Sorry, tlr, I don't understand 'trackbot, ping?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help 16:17:29 Justin: it was really useful to see Roy's draft spec 16:17:45 that's some slow (re: trackbot) 16:17:52 zakim, mute me 16:17:52 Thomas should now be muted 16:18:13 Matthias: we will continue this discussion next week with Aleecia chairing 16:18:18 ... moving on to new business 16:18:27 Topic: Tracking Preference Expression, Response Headers 16:18:31 related sections in draft: http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#responding 16:18:37 alex__ has joined #dnt 16:19:05 .... any comments on the editor's draft that roy sent around yesterda 16:19:25 Roy: if you see something missing or out of place, let us know 16:20:14 DISCUSSION STRUCTURE for RESPONSES: 16:20:14 1. GOALS: What does the response header tries to achieve? 16:20:14 2. CRITERIA: What criteria do we use to assess quality? 16:20:14 3. OPTIONS: What alternative implementations exist? 16:20:16 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 ... 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 ....I propose having three categories of input -- goals, criteria, and options. 16:21:42 +? 16:21:44 tl has joined #dnt 16:21:47 +? 16:22:01 +q 16:22:23 .... 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 ... Are there questions on the proposed structure? 16:22:51 ack tl 16:23:44 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 Matthias: So you are proposing a criteria that is future-proof and extensable? 16:24:19 CRITERIA: extensible / future proof 16:24:27 tl: It should be extensible and future proof 16:24:29 -dmckinney 16:24:46 q+ 16:25:01 q? 16:25:12 adrian: there may be future uses we don't know about. 16:25:13 q+ 16:25:19 zakim, unmute me 16:25:19 aleecia was not muted, aleecia 16:25:32 ... this is something we should consider in the discussion but it shouldn't necessarily trump other considerations 16:25:54 q? 16:26:08 ack aleecia 16:26:09 Matthias: need to consider cost of including it 16:26:29 Aleecia-GOAL: Transparency reasons: What happened 16:26:39 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__ has joined #dnt 16:26:51 jules has joined #dnt 16:27:01 ... this way a company can remind users they have opted out. 16:27:12 .... there were comments that a response header could be useful for auditing. 16:27:16 GOAL: Auditing: WHat is going on? 16:27:28 it is useful for compliance as well 16:27:45 I think Aleecia's last "have opted out" refers to "have opted back in" 16:27:47 ... 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 q? 16:28:04 ... and a header would help make that happen. so that the assumption isn't that companies are complying with DNT 16:28:12 jules polonetsky is here, 16:28:24 Q+ 16:29:03 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 q? 16:29:22 q- 16:29:26 BrianTs has joined #dnt 16:29:38 dsinger has joined #dnt 16:29:40 q? 16:29:49 Note that these were goals from the Boston discussion. 16:29:50 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 ack dsinger__ 16:30:13 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 .... 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 q+ 16:30:45 q+ 16:31:13 jkaran: how many users actually know what a response header is? 16:31:31 (presumably they would not see it, but browsers could build in a UI.) 16:31:31 .... 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 ack jkaran 16:31:40 +[Apple] 16:31:48 -dsinger 16:31:59 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 zakim, [apple] has dsinger 16:32:07 +dsinger; got it 16:32:12 q+ 16:32:18 q+ 16:32:18 q? 16:32:34 …my browser might log it; might warn me that site XXXX is still tracking me, and so on. 16:32:36 ack tl 16:32:46 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 tl: The response header will be mediated by the browser, etc. 16:33:25 q+ 16:33:33 …agrees with the speaker; users do not see TLS transaction details, but the browser can warn/advise of its use nonetheless 16:33:45 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 s/the speaker/tl/ 16:33:59 ack dwainberg 16:33:59 q? 16:34:16 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 ... 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 ... perhaps only need a static instead of a logical response 16:34:55 +q 16:34:58 q+ 16:35:32 q+ 16:35:32 .... I am interested to hear what the auditing that people have in mind would look like 16:36:06 dwainberg: For me, an audit is some process by which you confirm that something is or is not happening 16:36:11 auditing -- 3rd party research of log data across sites finds ways to see if when claimed behavior is true 16:36:32 I think jonathan would argue that "auditing" = "enforceability" in this context (Section 5 liability) 16:36:58 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 auditing -- from a user's perspective a mechanism to check whether dnt is being honored or nog 16:37:03 justin, I think those are actually two separate goals 16:37:08 ....we also heard about third party verification - which trustee was interested in pursuing 16:37:19 .... another possibility is it would be useful to know how many sites have DNT enabled 16:37:31 auditing for adoption rates 16:37:44 q? 16:37:52 +1 on crawling, quantification, 3rd-party documentation of sites that respect DNT 16:38:11 .... would help with potential FTC evaluations 16:38:12 …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 zakim, who is making noise? 16:38:38 zakim, mute tl 16:38:38 tl should now be muted 16:38:41 dsinger, listening for 10 seconds I heard sound from the following: ??P2 (68%), schunter (9%), +385221aagg (14%), dwainberg (13%) 16:38:41 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 dwainberg: if auditing/enforcability is an important rational then it's important to drill down a bit more 16:38:49 ack thomas 16:39:05 zakim, mute me 16:39:05 Thomas should now be muted 16:39:28 ack ksmith 16:40:04 +q 16:40:12 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 q+ 16:40:23 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 Maybe not in a privacy policy, but in a machine readable, standard location, not necessarily in the header. 16:40:34 who said that the header wasn't for the user anyway? 16:40:43 i think a response header offers the possibility of an automated notification of the user, in which way soever 16:40:46 OPTION1: Response header 16:40:50 .... we only need it in the response header if we want the browser to act on it 16:40:51 OPTION2: well-known location 16:40:57 q? 16:41:00 .... otherwise it could all be handled in a privacy policy 16:41:01 Proposal: define a well-known location (URI) on site for machine-readable indication of compliance 16:41:05 ack fielding 16:41:12 OPTION3: Human-readable privacy policy 16:41:13 It seems entirely reasonable that a browser would want to react to it, actually 16:41:28 fielding: I wrote down four goals so far. Auditing, transparency, opt in, and one other. 16:42:03 s/one other/measurement/ 16:42:33 ...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 -fielding 16:42:58 ack thomas 16:42:59 oops 16:43:07 .... the second proposal would be to, instead of using a header field, adding a new status code in http. 16:43:09 zakim, mute me 16:43:09 Thomas should now be muted 16:43:14 Matthias: this discussion should come later. 16:43:19 go ahead, I am done talking ... will call back in 16:43:24 q? 16:43:26 q+ 16:43:37 ack t 16:43:38 Matthias: so why do we want the protocol 16:43:46 whooops 16:43:55 q- 16:43:57 ...four reasons, compliance, auditing, measurement, and opt out 16:43:58 q- 16:44:07 queue=clay_opa_cbs,tl,clp,rvaneijk 16:44:11 ack clay_opa_cbs 16:44:25 q+ 16:44:40 +fielding 16:44:55 clay_opa: Roy's comments mirrored what i was thinking. A machine-readable static file would be best. 16:45:09 + +1.415.734.aaoo 16:45:12 .... maybe different 200 codes 16:45:32 q? 16:45:32 ... 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 q+ 16:45:40 ack tl 16:46:19 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 zakim, aaoo is kevint 16:46:20 +kevint; got it 16:47:03 q+ 16:47:07 .... 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 ack clp 16:47:27 q- 16:47:36 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 ....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 ....the goal would be to educate the user 16:48:24 GOAL is transparency, isnt it? 16:48:59 ack rvaneijk 16:49:02 q+ 16:49:08 rvaneijk: I would phrase this as a consent feedback mechanism 16:49:24 .... especially in the EU, it is useful for the user to know whether the opt in has been acknowledged or not 16:49:52 traffic light - red for not respected DNT, green for respecting it 16:49:57 ....I work for the dutch data protection authority, but at the moment i speak for myself. 16:50:09 q+ 16:50:20 q+ 16:50:25 dsinger; the reason to put it in the response is that it is sometimes contextual whether you are tracking or not. 16:50:25 -PederMagee 16:50:38 CRITERIA: Express fine-grained track/no-track for pieces of a site 16:51:15 s/dsinger;/dsinger:/ 16:51:20 ....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 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 q+ 16:51:31 ack dsinger 16:51:31 q- later 16:51:37 ack aleecia 16:51:38 ....whether you are being tracked and whether the base request is being satisfied are two different issues 16:52:13 .... 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 -AmyC 16:52:29 q? 16:52:42 ....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 +q 16:52:58 .... 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 q+ 16:53:39 q- 16:53:44 will summarize 16:53:57 q- 16:53:57 ack dwainberg 16:54:38 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 - +1.202.744.aamm 16:54:58 .... 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 ack Brett 16:55:24 ack tl 16:55:25 .... 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 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 file. That seems the important question. 16:56:00 Tom: you're dropping out 16:56:04 youe audio breadking up 16:56:23 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 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 I'm not understanding this in part from drop out 16:57:07 q? 16:57:15 So I'm getting "yes, it make a difference" but I didn't understand why 16:57:51 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 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 -Sean 16:58:05 ack thomas 16:58:09 ack npd 16:58:09 ack npdoty 16:58:10 matthias: moving on, the question is once we generate options, what are the criteria? 16:58:14 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 .... one requirement is the caching requirement. 16:58:45 .... the protocol is good if it doesn't destroy the caching mechanisms of the web. 16:59:03 schunter has joined #dnt 16:59:11 q+ 16:59:42 X: You can't have large dynamic sites shut down all cacheabilithy for their sites. 16:59:44 q+ 16:59:48 s/X/fielding/ 17:00:02 q- 17:00:10 q+ 17:00:54 .... 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 CRITERIA: caching compatibility 17:01:18 .... 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 OPTION: data at well-known URI 17:01:36 (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 -[Apple] 17:01:43 .... even moderately busy websites have to process things on the order of 10k requests per second. 17:01:54 +[Microsoft.aaa] 17:02:09 q? 17:02:16 ack Brett 17:02:46 amyc has joined #dnt 17:02:49 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 ....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 - +1.202.546.aann 17:03:50 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 s/X/fielding/ 17:04:07 So why can't that work the same way, most of a page will be from known sources, share DNT? 17:04:07 q? 17:04:12 But cookies are sent automagically? 17:04:14 ....the sites are designed to handle this. 17:04:28 +q 17:04:30 Brett: so it is the same issue? 17:04:42 fielding: sites are designed to handle scalability/caching for those particular resources 17:04:57 ack Thomas 17:04:57 ack thomas 17:05:48 If you delegate to a particular resource, isn't that basically the same as standard location? 17:05:55 q- 17:06:04 Thomas: what about delegating active response to a particular set of resources 17:06:24 +1 17:06:29 ....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 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 ....it sounds to me as though there ought to be a way to replicate the dynamic cookie pattern in this case. 17:07:28 +1 Thomas 17:07:31 q+ 17:07:31 good point 17:07:33 ....any site used for purpose of tracking is going to be marked as non-cacheabe 17:07:35 zakim, mute me 17:07:35 Thomas should now be muted 17:07:37 q? 17:07:38 I didn't follow Roy's last point 17:08:10 s/..../fielding 17:08:39 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 q? 17:08:48 I would think you could have static content flag itself as static, and still requires a response header. 17:08:50 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 unmuting 17:09:03 -efelten 17:09:14 fielding, what about redirecting the user to a unique, one-time, cacheable URI each time? 17:09:29 there are wrinkles here that I think we need to think about. 17:09:38 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 tlr, the redirect would then contain the response 17:09:58 ....we should be able to prohibit tracking for cacheable content 17:10:23 -Brett 17:10:26 q+ 17:10:32 Simplicity 17:10:33 Matthias: beside cacheability, are there other criteria for determining whether a protocol is good or bad 17:10:46 -npdoty 17:10:50 ack tl 17:11:22 ...and we should require a static "will not track" header on cacheable content 17:11:43 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 ....and if you are serving ads from different websites, it is still possible for user to be tracked across several websites 17:12:26 +q 17:12:48 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 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 ok tnx 17:13:07 q? 17:13:11 ack rvaneijk 17:13:13 q- 17:13:28 That was the part of Roy's comment I hadn't understood 17:13:30 "Shared caching" also describes "Content Delivery Networks" (such as Akamai) 17:13:38 tl: if we have decided that cached content doesnt require a response header than we have failed. 17:13:49 q+ 17:13:53 ...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