Mobile Web Best Practices Working Group Teleconference

HTTP/HTTPS Links Rewriting

<francois> comment from Thomas

Francois: There was a discussion by Thomas Roessler. He makes the point that rewriting HTTPS links changes the origin from the standpoint of the origin server.
... The new origin becomes the host name of the CT proxy.
... There could be a security problem with cross site scripting with the change of origin.
... An attack could steal user information.
... This is a new use case brought by Thomas.

Rob: It's a valid concern every time you change the URL to point to a different server, whether you use HTTP or HTTPS.
... We don't allow any scripts to get to the handset at all.

Francois: That's what I thought since there is hardly any support for scripts on old devices.

<Zakim> jo, you wanted to ask how we reconcile and approach of preventing scripts at all with the need to send script to meet the requirements of mobile Web apps

Rob: No script at all is sent to the handset. That should prevent scripts running in one window from access data from another window.

Francois: So what should we do with the guidelines?

Jo: I suppose the same thing applies to cookies.

Jo: The working group would like to promote the use of scripts. How do we reconcile these?

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.

EdC: Aren't we devoting a lot of time to what we shouldn't do: link rewriting?

Jo: we are wondering whether it is technically possible to rewrite links safely

Sean: Our CT proxy does not send JavaScript to the client if the content is transformed.

EdC: Not sure that we should be going to this level of detail in the guidelines.
... Shouldn't we instead have a session on security considerations and mention things like HTTPS link rewriting, cookies, referer, etc.

<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

Francois: We need to understand how it will work and how to put it in the guidelines.

Jo: We probably need at this point about what we want to do going forward on this point.
... 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.
... I think I could do 1 but not 2. Sean and/or Rob and/or EdC would need to write something else.

Jo: I think we wouldn't have a useful document if we did 1, so if we are to continue with the document then someone needs to do 2.

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.

<Zakim> jo, you wanted to respond that the issue goes broader than just the server and the user concerned in any one request

EdC: In general URL rewriting will happen, so it is hard to stop some transformations and not others.

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.

Francois: I wonder what real difference is between the two choices.

Jo: If we put in anything like this it needs to be normative.
... and needs to have conformance implications.

<Zakim> rob, you wanted to support Jo's (2) i.e. to include Eduardo's "Security Considerations" chapter in a normative way

Rob: We've already mentioned that URLs do get rewritten. So I think we should say the conditions that this should be done.

Sean: I agree with Rob. I could help him out with the text.

Francois: I agree with the direction and would like to see some text.

Jo: I think we need to bring this up in the BPWG. I think the entire group needs to give its opinion on.
... The BPWG needs to give its opinion on whether we can actually make a BP on link rewriting.
... I think we need to be perfectly clear that we are issuing something close to a best practice.

<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?

Jo: 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.

<Zakim> rob, you wanted to say there must be value in expressing best practices in a sensitive area (egsecurity)

<EdC> not so fast...Sean seems to have lost track...

Francois: I would suggest that we action Rob to come up with something that we be valuable on rewriting links.

<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

<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]

Francois: Second we should go to the BPWG to get the approval on whether we should issue a best practice on this.

Sean: Not sure I understand why the doc stands or falls on this.

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.

Sean: It is not necessary to do link rewriting if the CT proxy is in "proxy mode".

<francois> ACTION: robert to start putting together a set of guidelines that could help address the security issues triggered by links rewriting. [recorded in http://www.w3.org/2008/12/16-bpwg-minutes.html#action01]

<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].

<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.

Francois: What about when a page is broken into segments?

Sean: There are toolbars that have links that point to the CT proxy for moving between the segments.

<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?

<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 .

<francois> ACTION-860?

<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

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/860

Francois: There are a couple old issues that can be closed.

<francois> close ACTION-860

<trackbot> ACTION-860 Add clarification to HTTPS rewriting to make it clear that the via header MUST be added closed

<francois> ACTION-864?

<trackbot> ACTION-864 -- Jo Rabin to redraft HTTPS section for discussion on list -- due 2008-10-20 -- CLOSED

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/864

<francois> close ACTION-864

<trackbot> ACTION-864 Redraft HTTPS section for discussion on list closed

<francois> ACTION-859

<francois> ACTION-859?

<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

<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/859

LC-2040 - On properly defining the X-Device-* headers

Francois: The problem is that "X-" is supposed to be experimental and we are saying that these headers should be used.
... 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.
... We probably will have a hard time getting all the way to rec with "X-" in the guidelines.

Francois: If we do it properly we might want to create a proper header field.

EdC: There are standards out there that define "X-" header fields. One example is the UA-Prof standard.
... 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.

Francois: Did UAProf register the "X-" header fields with the IETF?

<jo> how about inbound-*

EdC: No.

Francois: We could possibly get away with what we have since it is existing practice.
... There are 2 registries--a temporary one and a permanent one.

<Zakim> tomhume, you wanted to clarify what we're recommending as best practice today

Francois: Addressing the temporary one is defining it in the guidelines and putting it in an email.

Tom: What are we talking about recommending?

<Zakim> jo, you wanted to answer tom

Francois: Add the new header and then say that you need to handle both.

Sean: Don't really understand why we need to change this given what Eduardo said.

<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)

<Zakim> tomhume, you wanted to find it a bit weird to recommend doing something which will deliver little value today

Jo: The HTTP RFC says you can use any header you want and implementions should ignore what they don't understand.

Rob: Agree with Sean and Eduardo.

Tom: Aren't we trying to be somewhat pragmatic and make things work with what's out there?

Francois: We may at some point get a red flag if we keep things like they are now. Not sure.
... We will cancel the next two calls. Next call will be Jan. 6.
... Will bring up the links rewriting issue with the BPWG on Thursday.
... Not sure if there will be a resolution.