IRC log of bpwg on 2008-12-16

Timestamps are in UTC.

14:57:51 [RRSAgent]
RRSAgent has joined #bpwg
14:57:51 [RRSAgent]
logging to http://www.w3.org/2008/12/16-bpwg-irc
14:57:53 [trackbot]
RRSAgent, make logs public
14:57:53 [Zakim]
Zakim has joined #bpwg
14:57:55 [trackbot]
Zakim, this will be BPWG
14:57:55 [Zakim]
ok, trackbot; I see MWI_BPWG(CTTF)10:00AM scheduled to start in 3 minutes
14:57:56 [trackbot]
Meeting: Mobile Web Best Practices Working Group Teleconference
14:57:56 [trackbot]
Date: 16 December 2008
14:58:00 [francois]
Chair: francois
14:58:11 [francois]
Agenda: http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Dec/0032.html
15:00:27 [tomhume]
tomhume has joined #bpwg
15:00:37 [Zakim]
MWI_BPWG(CTTF)10:00AM has now started
15:00:45 [Zakim]
+??P19
15:00:48 [SeanP]
SeanP has joined #bpwg
15:00:51 [tomhume]
zakim, ??P19 is me
15:00:51 [Zakim]
+tomhume; got it
15:01:00 [rob]
rob has joined #bpwg
15:01:17 [tomhume]
hey guys
15:01:38 [Zakim]
+ +1.630.414.aaaa
15:01:46 [SeanP]
Zakim, aaaa is me
15:01:46 [Zakim]
+SeanP; got it
15:02:02 [Zakim]
+Francois
15:02:06 [Zakim]
+ +0207287aabb
15:02:16 [jo]
jo has joined #bpwg
15:02:36 [rob]
zakim, aabb is me
15:02:36 [Zakim]
+rob; got it
15:02:50 [jo]
zakim, code?
15:02:50 [Zakim]
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 [Zakim]
+ +03531522aacc
15:04:08 [jo]
zakim, who is here?
15:04:18 [Zakim]
+ +41.31.972.aadd
15:04:20 [jo]
zakim, aacc is me
15:04:33 [Zakim]
On the phone I see tomhume, SeanP, Francois, rob, +03531522aacc, +41.31.972.aadd
15:04:46 [Zakim]
+jo; got it
15:04:59 [Zakim]
On IRC I see jo, rob, SeanP, tomhume, Zakim, RRSAgent, francois, trackbot, dom
15:05:52 [francois]
zakim, aadd is EdC
15:06:09 [Zakim]
+EdC; got it
15:06:09 [EdC]
EdC has joined #bpwg
15:06:31 [SeanP]
Scribe: SeanP
15:06:38 [SeanP]
Scribenick: SeanP
15:06:49 [SeanP]
Topic: HTTPS Links Rewriting
15:07:13 [francois]
-> http://lists.w3.org/Archives/Public/public-bpwg-comments/2008OctDec/0007.html comment from Thomas
15:07:52 [SeanP]
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 [SeanP]
...The new origin becomes the host name of the CT proxy.
15:08:34 [rob]
q+
15:08:47 [SeanP]
...There could be a security problem with cross site scripting with the change of origin.
15:09:09 [SeanP]
...An attack could steal user information.
15:09:28 [SeanP]
...This is a new use case brought by Thomas.
15:09:33 [francois]
ack rob
15:09:58 [SeanP]
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 [SeanP]
...We don't allow any scripts to get to the handset at all.
15:10:56 [SeanP]
Francois: That's what I thought since there is hardly any support for scripts on old devices.
15:11:40 [jo]
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 [francois]
ack jo
15:11:52 [Zakim]
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 [SeanP]
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 [SeanP]
Francois: So what should we do with the guidelines?
15:12:24 [SeanP]
Jo: I suppose the same thing applies to cookies.
15:12:35 [EdC]
+q
15:13:00 [SeanP]
...The working group would like to promote the use of scripts. How do we reconcile these?
15:13:57 [SeanP]
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 [francois]
ack EdC
15:14:31 [SeanP]
EdC: Aren't we devoting a lot of time to what we shouldn't do: content rewriting?
15:14:49 [SeanP]
s/content/link/
15:15:35 [SeanP]
Jo: We are saying that links can be rewritten under specific circumstances.
15:15:46 [EdC]
+q
15:16:35 [jo]
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 [francois]
ack EdC
15:18:22 [SeanP]
Sean: Our CT proxy does not send JavaScript to the client if the content is transformed.
15:18:49 [SeanP]
EdC: Not sure that we should be going to this level of detail in the guidelines.
15:19:00 [jo]
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 [SeanP]
...Shouldn't we instead have a session on security considerations and mention things like HTTPS link rewriting, cookies, referer, etc.
15:19:57 [francois]
ack jo
15:19:57 [Zakim]
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 [SeanP]
Francois: We need to understand how it will work and how to put it in the guidelines.
15:20:31 [SeanP]
Jo: We probably need at this point about what we want to do going forward on this point.
15:21:39 [SeanP]
...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 [SeanP]
...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 [EdC]
+q
15:22:49 [francois]
ack EdC
15:23:04 [SeanP]
...I think we wouldn't have a useful document if we did 1, so we probably need to do 2.
15:23:23 [jo]
s/would do 1 /could do 1 /
15:24:17 [jo]
s/we probably need to do 2/if we are to continue with the document then someone needs to do 2/
15:24:44 [SeanP]
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 [jo]
q+ to respond that the issue goes broader than just the server and the user concerned in any one request
15:25:20 [francois]
ack jo
15:25:20 [Zakim]
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 [SeanP]
...In general URL rewriting will happen, so it is hard to stop some transformations and not others.
15:26:51 [SeanP]
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 [SeanP]
Francois: I wonder what real difference is between the two choices.
15:28:17 [SeanP]
Jo: If we put in anything like this it needs to be normative.
15:28:34 [SeanP]
...and needs to have conformance implications.
15:28:46 [rob]
q+ to support Jo's (2) i.e. to include Eduardo's "Security Considerations" chapter in a normative way
15:28:55 [francois]
ack rob
15:28:55 [Zakim]
rob, you wanted to support Jo's (2) i.e. to include Eduardo's "Security Considerations" chapter in a normative way
15:29:44 [SeanP]
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 [SeanP]
q+
15:30:04 [francois]
ack SeanP
15:31:29 [SeanP]
Sean: I agree with Rob. I could help him out with the text.
15:31:46 [SeanP]
Francois: I agree with the direction and would like to see some text.
15:31:49 [tomhume]
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 [SeanP]
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 [rob]
q+ to say there must be value in expressing best practices in a sensitive area (egsecurity)
15:33:51 [SeanP]
Jo: The BPWG needs to give its opinion on whether we can actually make a BP on link rewriting.
15:34:33 [SeanP]
...I think we need to be perfectly clear that we are issuing something close to a best practice.
15:35:01 [francois]
ack tomhume
15:35:01 [Zakim]
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 [SeanP]
...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 [francois]
ack rob
15:36:50 [Zakim]
rob, you wanted to say there must be value in expressing best practices in a sensitive area (egsecurity)
15:37:09 [EdC]
not so fast...Sean seems to have lost track...
15:38:54 [SeanP]
Francois: I would suggest that we action Rob to come up with something that we be valuable on rewriting links.
15:39:02 [tomhume]
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]
[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 [SeanP]
...Second we should go to the BPWG to get the approval on whether we should issue a best practice on this.
15:40:08 [SeanP]
q+
15:40:13 [francois]
ack SeanP
15:41:01 [SeanP]
Sean: Not sure I understand why the doc stands or falls on this.
15:42:32 [SeanP]
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 [SeanP]
Sean: It is not necessary to do link rewriting if the CT proxy is in "proxy mode".
15:44:29 [francois]
ACTION: robert to start putting together a set of guidelines that could help address the security issues triggered by links rewriting.
15:44:29 [trackbot]
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 [EdC]
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 [SeanP]
Francois: What about when a page is broken into segments?
15:45:22 [SeanP]
Sean: There are toolbars that have links that point to the CT proxy for moving between the segments.
15:46:27 [francois]
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 [trackbot]
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 [francois]
ACTION-860?
15:46:57 [trackbot]
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 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/860
15:47:06 [SeanP]
Francois: There are a couple old issues that can be closed.
15:47:09 [francois]
close ACTION-860
15:47:09 [trackbot]
ACTION-860 Add clarification to HTTPS rewriting to make it clear that the via header MUST be added closed
15:47:12 [francois]
ACTION-864?
15:47:12 [trackbot]
ACTION-864 -- Jo Rabin to redraft HTTPS section for discussion on list -- due 2008-10-20 -- CLOSED
15:47:12 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/864
15:47:22 [francois]
close ACTION-864
15:47:22 [trackbot]
ACTION-864 Redraft HTTPS section for discussion on list closed
15:47:26 [francois]
ACTION-859
15:47:28 [francois]
ACTION-859?
15:47:28 [trackbot]
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 [trackbot]
http://www.w3.org/2005/MWI/BPWG/Group/track/actions/859
15:48:45 [SeanP]
Topic: LC-2040 - On properly defining the X-Device-* headers
15:49:21 [SeanP]
Francois: The problem is that "X-" is supposed to be experimental and we are saying that these headers should be used.
15:50:11 [SeanP]
...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 [SeanP]
...We probably will have a hard time getting all the way to rec with "X-" in the guidelines.
15:51:33 [EdC]
+q
15:51:40 [francois]
ack EdC
15:51:47 [SeanP]
...If we do it properly we might want to create a proper header field.
15:52:13 [SeanP]
EdC: There are standards out there that define "X-" header fields. One example is the UA-Prof standard.
15:53:00 [SeanP]
...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 [SeanP]
Francois: Did UAProf register the "X-" header fields with the IETF?
15:53:36 [jo]
how about inbound-*
15:53:41 [SeanP]
EdC: No.
15:54:15 [SeanP]
Francois: We could possibly get away with what we have since it is existing practice.
15:54:43 [tomhume]
q+ to clarify what we're recommending as best practice today
15:54:51 [SeanP]
...There are 2 registries--a temporary one and a permanent one.
15:55:10 [francois]
ack tomhume
15:55:10 [Zakim]
tomhume, you wanted to clarify what we're recommending as best practice today
15:55:17 [SeanP]
...Addressing the temporary one is defining it in the guidelines and putting it in an email.
15:55:44 [SeanP]
Tom: What are we talking about recommending?
15:55:45 [jo]
q+ to answer tom
15:56:15 [francois]
ack jo
15:56:15 [Zakim]
jo, you wanted to answer tom
15:56:36 [SeanP]
Francois: Add the new header and then say that you need to handle both.
15:56:42 [SeanP]
q+
15:56:49 [francois]
ack SeanP
15:57:13 [rob]
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 [SeanP]
Sean: Don't really understand why we need to change this given what Eduardo said.
15:58:18 [francois]
ack rob
15:58:19 [Zakim]
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 [tomhume]
q+ to find it a bit weird to recommend doing something which will deliver little value today
15:58:41 [francois]
ack tomhume
15:58:41 [Zakim]
tomhume, you wanted to find it a bit weird to recommend doing something which will deliver little value today
15:58:43 [EdC]
+q
15:58:50 [SeanP]
Jo: The HTTP RFC says you can use any header you want and implementions should ignore what they don't understand.
15:59:13 [SeanP]
Rob: Agree with Sean and Eduardo.
15:59:14 [francois]
ack EdC
16:00:08 [SeanP]
Tom: Aren't we trying to be somewhat pragmatic and make things work with what's out there?
16:00:51 [jo]
jo has left #bpwg
16:01:09 [Zakim]
-jo
16:01:16 [SeanP]
Francois: We may at some point get a red flag if we keep things like they are now. Not sure.
16:02:48 [SeanP]
Francois: We will cancel the next two calls. Next call will be Jan. 6.
16:03:06 [SeanP]
...Will bring up the HTTPS rewriting issue with the BPWG on Thursday.
16:03:25 [SeanP]
...Not sure if there will be a resolution.
16:03:44 [Zakim]
-SeanP
16:03:49 [Zakim]
-rob
16:03:50 [Zakim]
-tomhume
16:03:52 [Zakim]
-Francois
16:03:54 [Zakim]
MWI_BPWG(CTTF)10:00AM has ended
16:03:56 [Zakim]
Attendees were tomhume, +1.630.414.aaaa, SeanP, Francois, +0207287aabb, rob, +03531522aacc, +41.31.972.aadd, jo, EdC
16:05:58 [francois]
RRSAgent, draft minutes
16:05:58 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/12/16-bpwg-minutes.html francois
16:39:49 [trackbot]
trackbot has joined #bpwg
16:45:33 [rob]
rob has left #bpwg
18:00:04 [Zakim]
Zakim has left #bpwg