14:57:51 RRSAgent has joined #bpwg 14:57:51 logging to http://www.w3.org/2008/12/16-bpwg-irc 14:57:53 RRSAgent, make logs public 14:57:53 Zakim has joined #bpwg 14:57:55 Zakim, this will be BPWG 14:57:55 ok, trackbot; I see MWI_BPWG(CTTF)10:00AM scheduled to start in 3 minutes 14:57:56 Meeting: Mobile Web Best Practices Working Group Teleconference 14:57:56 Date: 16 December 2008 14:58:00 Chair: francois 14:58:11 Agenda: http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0032.html 15:00:27 tomhume has joined #bpwg 15:00:37 MWI_BPWG(CTTF)10:00AM has now started 15:00:45 +??P19 15:00:48 SeanP has joined #bpwg 15:00:51 zakim, ??P19 is me 15:00:51 +tomhume; got it 15:01:00 rob has joined #bpwg 15:01:17 hey guys 15:01:38 + +1.630.414.aaaa 15:01:46 Zakim, aaaa is me 15:01:46 +SeanP; got it 15:02:02 +Francois 15:02:06 + +0207287aabb 15:02:16 jo has joined #bpwg 15:02:36 zakim, aabb is me 15:02:36 +rob; got it 15:02:50 zakim, code? 15:02:50 the conference code is 2283 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), jo 15:04:04 + +03531522aacc 15:04:08 zakim, who is here? 15:04:18 + +41.31.972.aadd 15:04:20 zakim, aacc is me 15:04:33 On the phone I see tomhume, SeanP, Francois, rob, +03531522aacc, +41.31.972.aadd 15:04:46 +jo; got it 15:04:59 On IRC I see jo, rob, SeanP, tomhume, Zakim, RRSAgent, francois, trackbot, dom 15:05:52 zakim, aadd is EdC 15:06:09 +EdC; got it 15:06:09 EdC has joined #bpwg 15:06:31 Scribe: SeanP 15:06:38 Scribenick: SeanP 15:06:49 Topic: HTTPS Links Rewriting 15:07:13 -> http://lists.w3.org/Archives/Public/public-bpwg-comments/2008OctDec/0007.html comment from Thomas 15:07:52 Francois: There was a discussion by Thomas Roessler (sp?) make the point that rewriting HTTPS links changes the origin from the standpoint of the origin server. 15:08:13 ...The new origin becomes the host name of the CT proxy. 15:08:34 q+ 15:08:47 ...There could be a security problem with cross site scripting with the change of origin. 15:09:09 ...An attack could steal user information. 15:09:28 ...This is a new use case brought by Thomas. 15:09:33 ack rob 15:09:58 Rob: It's a valid concern every time you change the URL to point to a different server, whether you use HTTP or HTTPS. 15:10:27 ...We don't allow any scripts to get to the handset at all. 15:10:56 Francois: That's what I thought since there is hardly any support for scripts on old devices. 15:11:40 q+ to ask how we reconcile and apporach of preventing scripts at all with the need to send script to meet the requirements of mobile Web apps 15:11:52 ack jo 15:11:52 jo, you wanted to ask how we reconcile and apporach of preventing scripts at all with the need to send script to meet the requirements of mobile Web apps 15:11:53 Rob: No script at all is sent to the handset. That should prevent scripts running in one window from access data from another window. 15:12:09 Francois: So what should we do with the guidelines? 15:12:24 Jo: I suppose the same thing applies to cookies. 15:12:35 +q 15:13:00 ...The working group would like to promote the use of scripts. How do we reconcile these? 15:13:57 Rob: The same thing is true for cookies. If the content is mobile friendly, then we don't change things. If it is adapted, then no script is sent to the client. 15:14:00 ack EdC 15:14:31 EdC: Aren't we devoting a lot of time to what we shouldn't do: content rewriting? 15:14:49 s/content/link/ 15:15:35 Jo: We are saying that links can be rewritten under specific circumstances. 15:15:46 +q 15:16:35 s/We are saying that links can be rewritten under specific circumstances./we are wondering whether it is technically possible to rewrite links safely/ 15:17:38 ack EdC 15:18:22 Sean: Our CT proxy does not send JavaScript to the client if the content is transformed. 15:18:49 EdC: Not sure that we should be going to this level of detail in the guidelines. 15:19:00 q+ to say we should not include details of the internal operation of the proxy but we can refer to externally measurable properties 15:19:31 ...Shouldn't we instead have a session on security considerations and mention things like HTTPS link rewriting, cookies, referer, etc. 15:19:57 ack jo 15:19:57 jo, you wanted to say we should not include details of the internal operation of the proxy but we can refer to externally measurable properties 15:20:06 Francois: We need to understand how it will work and how to put it in the guidelines. 15:20:31 Jo: We probably need at this point about what we want to do going forward on this point. 15:21:39 ...We have at least 2 choices: 1) Link rewriting is not condoned because it has unintended consequences. 2) We could say that link rewriting should be avoided in certain circumstances. 15:22:32 ...I think I would do 1 but not 2. Sean and/or Rob and/or EdC would need to write something else. 15:22:41 +q 15:22:49 ack EdC 15:23:04 ...I think we wouldn't have a useful document if we did 1, so we probably need to do 2. 15:23:23 s/would do 1 /could do 1 / 15:24:17 s/we probably need to do 2/if we are to continue with the document then someone needs to do 2/ 15:24:44 EdC: We could say there are a certain number of transformations that have security implications. I wouldn't put all the details of link rewriting in the body of the document. 15:25:11 q+ to respond that the issue goes broader than just the server and the user concerned in any one request 15:25:20 ack jo 15:25:20 jo, you wanted to respond that the issue goes broader than just the server and the user concerned in any one request 15:25:36 ...In general URL rewriting will happen, so it is hard to stop some transformations and not others. 15:26:51 Jo: The issue is that some servers may allow it and some may not allow it. We have ruled out the signaling that Eduardo has mentioned. We won't be able to put that in *this* document. It will need to be in another document. 15:27:53 Francois: I wonder what real difference is between the two choices. 15:28:17 Jo: If we put in anything like this it needs to be normative. 15:28:34 ...and needs to have conformance implications. 15:28:46 q+ to support Jo's (2) i.e. to include Eduardo's "Security Considerations" chapter in a normative way 15:28:55 ack rob 15:28:55 rob, you wanted to support Jo's (2) i.e. to include Eduardo's "Security Considerations" chapter in a normative way 15:29:44 Rob: We've already mentioned that URLs do get rewritten. So I think we should say the conditions that this should be done. 15:29:56 q+ 15:30:04 ack SeanP 15:31:29 Sean: I agree with Rob. I could help him out with the text. 15:31:46 Francois: I agree with the direction and would like to see some text. 15:31:49 q+ to wonder if there are issues beyond scripting and cookies that need to be considered here. origin of http requests changing? 15:32:32 Jo: I think we need to bring this up in the BPWG. I think the entire group needs to give its opinion on. 15:33:07 q+ to say there must be value in expressing best practices in a sensitive area (egsecurity) 15:33:51 Jo: The BPWG needs to give its opinion on whether we can actually make a BP on link rewriting. 15:34:33 ...I think we need to be perfectly clear that we are issuing something close to a best practice. 15:35:01 ack tomhume 15:35:01 tomhume, you wanted to wonder if there are issues beyond scripting and cookies that need to be considered here. origin of http requests changing? 15:35:25 ...We need to say something that is very clear. If we can't be clear enough on those issues, we need to be willing to abandon the CT guidelines. 15:36:50 ack rob 15:36:50 rob, you wanted to say there must be value in expressing best practices in a sensitive area (egsecurity) 15:37:09 not so fast...Sean seems to have lost track... 15:38:54 Francois: I would suggest that we action Rob to come up with something that we be valuable on rewriting links. 15:39:02 I wondered whether it'd be worth - now or shortly after the call - enumerating the problem areas we can see wrt security - partic. given that the list seems to grow steadily 15:39:33 [jo notes that dealing with this issue is key - we need a complete and definitive description - the CT doc stands or falls by this question] 15:39:39 ...Second we should go to the BPWG to get the approval on whether we should issue a best practice on this. 15:40:08 q+ 15:40:13 ack SeanP 15:41:01 Sean: Not sure I understand why the doc stands or falls on this. 15:42:32 Jo: Link rewriting is central to CT. If there is any question about security, then we can't make a best practice on link rewriting. 15:44:15 Sean: It is not necessary to do link rewriting if the CT proxy is in "proxy mode". 15:44:29 ACTION: robert to start putting together a set of guidelines that could help address the security issues triggered by links rewriting. 15:44:29 Created ACTION-893 - Start putting together a set of guidelines that could help address the security issues triggered by links rewriting. [on Robert Finean - due 2008-12-23]. 15:44:30 There may be (1) circumstances where security can conclusively never be enforced, ever (2) circumstances where security can be conclusively enforced if very specific conditions are fulfilled (3) the whole rest of unclear situations. 15:44:42 Francois: What about when a page is broken into segments? 15:45:22 Sean: There are toolbars that have links that point to the CT proxy for moving between the segments. 15:46:27 ISSUE: does BPWG feel it can write Best Practices on links rewriting in the CT guidelines? Or that it cannot be a best practice? 15:46:28 Created ISSUE-285 - Does BPWG feel it can write Best Practices on links rewriting in the CT guidelines? Or that it cannot be a best practice? ; please complete additional details at http://www.w3.org/2005/MWI/BPWG/Group/track/issues/285/edit . 15:46:56 ACTION-860? 15:46:57 ACTION-860 -- Jo Rabin to add clarification to HTTPS rewriting to make it clear that the via header MUST be added -- due 2008-10-13 -- CLOSED 15:46:57 http://www.w3.org/2005/MWI/BPWG/Group/track/actions/860 15:47:06 Francois: There are a couple old issues that can be closed. 15:47:09 close ACTION-860 15:47:09 ACTION-860 Add clarification to HTTPS rewriting to make it clear that the via header MUST be added closed 15:47:12 ACTION-864? 15:47:12 ACTION-864 -- Jo Rabin to redraft HTTPS section for discussion on list -- due 2008-10-20 -- CLOSED 15:47:12 http://www.w3.org/2005/MWI/BPWG/Group/track/actions/864 15:47:22 close ACTION-864 15:47:22 ACTION-864 Redraft HTTPS section for discussion on list closed 15:47:26 ACTION-859 15:47:28 ACTION-859? 15:47:28 ACTION-859 -- François Daoust to contact IETF TLS group and advise them of what we are thinking and ask for guidance on what to recommend to Content Provider about detecting the presence of a man-in-the-middle proxy -- due 2008-10-14 -- CLOSED 15:47:28 http://www.w3.org/2005/MWI/BPWG/Group/track/actions/859 15:48:45 Topic: LC-2040 - On properly defining the X-Device-* headers 15:49:21 Francois: The problem is that "X-" is supposed to be experimental and we are saying that these headers should be used. 15:50:11 ...The proper way of doing it is to register the header fields in the IETF. It's not that hard. The problem is that in practice, there is already a mess around these headers. 15:50:41 ...We probably will have a hard time getting all the way to rec with "X-" in the guidelines. 15:51:33 +q 15:51:40 ack EdC 15:51:47 ...If we do it properly we might want to create a proper header field. 15:52:13 EdC: There are standards out there that define "X-" header fields. One example is the UA-Prof standard. 15:53:00 ...There are already implementations out there that use the "X-Device" header fields, so implementation will need to deal with both types of headers if we changed it. 15:53:33 Francois: Did UAProf register the "X-" header fields with the IETF? 15:53:36 how about inbound-* 15:53:41 EdC: No. 15:54:15 Francois: We could possibly get away with what we have since it is existing practice. 15:54:43 q+ to clarify what we're recommending as best practice today 15:54:51 ...There are 2 registries--a temporary one and a permanent one. 15:55:10 ack tomhume 15:55:10 tomhume, you wanted to clarify what we're recommending as best practice today 15:55:17 ...Addressing the temporary one is defining it in the guidelines and putting it in an email. 15:55:44 Tom: What are we talking about recommending? 15:55:45 q+ to answer tom 15:56:15 ack jo 15:56:15 jo, you wanted to answer tom 15:56:36 Francois: Add the new header and then say that you need to handle both. 15:56:42 q+ 15:56:49 ack SeanP 15:57:13 q+ also to support Eduardo's pragmatic point that X-Device- is already in use and so probably always has to be supported (like x-wap-profile is still in use today) 15:58:10 Sean: Don't really understand why we need to change this given what Eduardo said. 15:58:18 ack rob 15:58:19 rob, you wanted to support Eduardo's pragmatic point that X-Device- is already in use and so probably always has to be supported (like x-wap-profile is still in use today) 15:58:33 q+ to find it a bit weird to recommend doing something which will deliver little value today 15:58:41 ack tomhume 15:58:41 tomhume, you wanted to find it a bit weird to recommend doing something which will deliver little value today 15:58:43 +q 15:58:50 Jo: The HTTP RFC says you can use any header you want and implementions should ignore what they don't understand. 15:59:13 Rob: Agree with Sean and Eduardo. 15:59:14 ack EdC 16:00:08 Tom: Aren't we trying to be somewhat pragmatic and make things work with what's out there? 16:00:51 jo has left #bpwg 16:01:09 -jo 16:01:16 Francois: We may at some point get a red flag if we keep things like they are now. Not sure. 16:02:48 Francois: We will cancel the next two calls. Next call will be Jan. 6. 16:03:06 ...Will bring up the HTTPS rewriting issue with the BPWG on Thursday. 16:03:25 ...Not sure if there will be a resolution. 16:03:44 -SeanP 16:03:49 -rob 16:03:50 -tomhume 16:03:52 -Francois 16:03:54 MWI_BPWG(CTTF)10:00AM has ended 16:03:56 Attendees were tomhume, +1.630.414.aaaa, SeanP, Francois, +0207287aabb, rob, +03531522aacc, +41.31.972.aadd, jo, EdC 16:05:58 RRSAgent, draft minutes 16:05:58 I have made the request to generate http://www.w3.org/2008/12/16-bpwg-minutes.html francois 16:39:49 trackbot has joined #bpwg 16:45:33 rob has left #bpwg 18:00:04 Zakim has left #bpwg