Mobile Web Best Practices Working Group Teleconference

Francois: Heiko is moving to another role so will not be joining this call or future calls

HTTPS links re-writing

<francois> FD's email to IETF TLS WG

<francois> "Since this is a man-in-the-middle attack, it would be interesting to

<francois> know how browsers react in that case. It should be have been made clear

<francois> to the user which site he connected to (www.proxy.com instead of

<francois> www.amazon.com)."

Francois: Any view? I don't think mobile browsers indicate HTTPS connections. Does anyone?

tomhume: Fixed web uses have address bar and security icon.
... this is missing in a mobile context

SeanP: Padlock security icon is on many mobile browsers but info page must be viewed to display URL

Andrew: I disagree with the quotation about man-in-the-middle attack. The user will have to be advised, so it's not an attack.

francois: Agrees that the use of "attack" is not quite correct but point is that there is no indication to the user that the page is intercepted

Andrew: there is visual indication on Vodafone pages of CT in process

<Zakim> jo, you wanted to suggest that the wording we have proposed should cover this so why don't we see how it flies

Francois: Happy with outcome of discussion last week on HTTP. Jo, do you need more?

Jo: Have enough for editing guidelines. Will post proposed text on list.

<jo> ACTION: Jo to redraft HTTPS section for discussion on list [recorded in http://www.w3.org/2008/10/14-bpwg-minutes.html#action01]

<trackbot> Created ACTION-864 - Redraft HTTPS section for discussion on list [on Jo Rabin - due 2008-10-21].

LC-2019: POST/GET conversion

<francois> LC-2019 comment

rob: comment was we should add note that posts should not be translated into gets and vice versa

francois: this is in the HTTP standard. Do we need to restated this?

<Zakim> jo, you wanted to suggest that we elaborate the bit on changing HEAD to GET to say that other conversions are not allowed

rob: Agreed. No strong feeling either way.

Jo: Let's say Head to Get is OK but other method changing must not be done

<francois> PROPOSED RESOLUTION: re. LC-2019, amend text on conversion between HEAD and GET to say that other conversions are not allowed, and resolve partial to LC-2019

rob: Good point; let's do it.

<rob> +1

<jo> +1

<francois> +1

+1

<tomhume> +1

RESOLUTION: re. LC-2019, amend text on conversion between HEAD and GET to say that other conversions are not allowed, and resolve partial to LC-2019

LC-2034: Applicable HTTP methods (§4.1.1)

<francois> LC-2034

rob: Other exotic methods available. We are only concerned with Get, Post and Head.

francois: Comment was that there could be new methods in the future

Brian: Heard that Connect method could be used for adaptation but a Connect is a clear indication that user wants a secure connection to the end server

Rob: A Connect should indicate "no adaptation - just tunnel"

,,, worth mentioning Connect in guide lines

<Zakim> jo, you wanted to say that as Rob puts it, the scope is limited to HEAD GET and POST don't think we should mention CONNECT

Brian: Cannot have adaptation with Connect

<francois> "The scope of content that proxies transform is typically limited to GET, POST and HEAD HTTP requests. Proxies should not intervene in other HTTP methods."

<jo> PROPOSED RESOLUTION: ref LC-2034, we clarify that the scope of the document is limited to GET, POST, HEAD requests and their responses

<rob> +1

<francois> +1

<SeanP> +1

Andrew: But HTTPS links can e rewriten on HTTP pages. then CT proxy becomes a content server.

<jo> PROPOSED RESOLUTION: ref LC-2034, we clarify that the scope of the document is limited to GET, POST, HEAD requests and their responses and resolve "no"

<francois> +1

+1

<tomhume> +1

Brian: There should be no use of Put method in CT

rob: Put is used for creating web sites rather than browsing

SeanP: Agree. Why did we put it in in the first place?

francois: It was included as a common HTTP method

<Zakim> tomhume, you wanted to point out that other applications beyond browsers might be passed through transforming proxies

tomhume: Not a method used by browsers but there may be other applications that use Put

<Zakim> jo, you wanted to point out to tom that the document says that its scope is browsing only

jo: We are careful to limit discussion to the browsing context and CT proxy should be sure that it is dealing with a browser. We can not practically discuss every application.

RESOLUTION: ref LC-2034, we clarify that the scope of the document is limited to GET, POST, HEAD requests and their responses and resolve "no"

LC-1997, LC-2006, LC-2014, LC-2046: Original HTTP headers in X-Device-foo

<francois> LC-1997

<francois> LC-2006

<francois> LC-2014

francois: Tried to gather statistics on refused pages. One figure from Brian - thanks.

<Zakim> rob, you wanted to summarise that IF headers are changed THEN x-device- echoing is useful

rob: If we allow user agent header then echoing the header is a good idea. Raises original question of whether we should rewrite headers.

<Zakim> jo, you wanted to say that LC-1997 suggests that since the world is flat there is no need for spherical geometry

jo: LC-1997 is more of a political statement. Think that it is OK to change the accept headers if a CT proxy. Separate question is whether we should change the user-agent header.

<jo> PROPOSED RESOLUTION: ref LC-1997, 2006 and 2014, we say that if a proxy changes headers then it must include a new X-Device- header, it should not change headers "unnecessarily" and it should not delete headers

<Zakim> jo, you wanted to answer bryan

Bryan: Reason to send original heads is to provide statistical information to site owners to allow them to better serve their users

jo: Other reasons for the original headers. In some sites more than the user-agent is used to decide what content to return.

SeanP: Novarra has been sending out x-device headers for sometime and has heard that content providers use these to determine what content to send out

<francois> LC-2046 on HTTP headers deletion

<jo> PROPOSED RESOLUTION: ref LC-1997, 2006 and 2014, 2046 we say that if a proxy changes headers then it must include a new X-Device- header, it should not change headers "unnecessarily" and it should not delete headers

jo: Thinks that it is not necessary to change headers other than accept and accept-charset - if one leaves aside for a moment the question of User Agent (and UAProf)

Bryan: Knows that users use user-agent and UAProf

andrews: concerned that the proposed resolution is strong and a major addition to existing guide lines. Needs careful consideration.

SeanP: Unclear what we are discussing

<Zakim> jo, you wanted to say that one person's unnecessary is another person's essential

<francois> section 4.1.5 on Alteration of HTTP Header Values

jo: We need to focus on what other headers may or may not be removed which could be used by sites in ways unpredicted by us.

<francois> Headers that may need to be changed:

<francois> - User-Agent

<francois> - UAProf

jo: Which headers need to be changed?

<francois> - Accept

<francois> - Accept-Charset

rob: No statistical evidence about sites that complain about wrong browsers.
... Long tail sites are likely to complain.

Bryan: Echo point about the long tail. This is where CT realy adds value.

andrews: do we need to change UAProf?

<francois> - Accept-Encoding

<francois> - Accept-Language

SeanP: Novarra changes accept-encoding and accept-language

<jo> [so it's basically Accept-*]

<jo> perhaps we should say "replace" rather than "change" when referring to this

andrews: Does "change" include "remove"

rob: Headers are not removed.

<SeanP> I'll be there.

francois: Will prepare a detailed agenda for the face-to-face next week

<tomhume> thanks all