W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > October 2008

[minutes] CT Call Tuesday 14 October 2008

From: Francois Daoust <fd@w3.org>
Date: Tue, 14 Oct 2008 17:43:26 +0200
Message-ID: <48F4BE1E.1010608@w3.org>
To: public-bpwg-ct <public-bpwg-ct@w3.org>

Hi,

The minutes of today's discussion are available at:
  http://www.w3.org/2008/10/14-bpwg-minutes.html

... and copied as text below.

Note there will be no "call" tomorrow, since we'll have a working 
group's F2F on Monday and Tuesday.


Resolutions taken during the call:
- 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
- ref LC-2034, we clarify that the scope of the document is limited to 
GET, POST, HEAD requests and their responses and resolve "no"
- and we had a long talk on changing HTTP headers which I'll try to 
summarize so that we may come to a conclusion next week.

Francois.


14 Oct 2008

    [2]Agenda

       [2] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Oct/0018.html

    See also: [3]IRC log

       [3] http://www.w3.org/2008/10/14-bpwg-irc

Attendees

    Present
           jo, SeanP, andrews, tomhume, Francois, rob, Bryan_Sullivan

    Regrets
    Chair
           francois

    Scribe
           andrews

Contents

      * [4]Topics
          1. [5]HTTPS links re-writing
          2. [6]LC-2019: POST/GET conversion
          3. [7]LC-2034: Applicable HTTP methods (§4.1.1)
          4. [8]LC-1997, LC-2006, LC-2014, LC-2046: Original HTTP
             headers in X-Device-foo
      * [9]Summary of Action Items
      _________________________________________________________

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

HTTPS links re-writing

    <francois> [10]FD's email to IETF TLS WG

      [10] 
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Oct/0014.html

    <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
    [11]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> [12]LC-2019 comment

      [12] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2019

    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> [13]LC-2034

      [13] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/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> [14]LC-1997

      [14] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/1997

    <francois> [15]LC-2006

      [15] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2006

    <francois> [16]LC-2014

      [16] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/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> [17]LC-2046 on HTTP headers deletion

      [17] 
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2046

    <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> [18]section 4.1.5 on Alteration of HTTP Header Values

      [18] 
http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/#sec-altering-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

Summary of Action Items

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

    [End of minutes]
Received on Tuesday, 14 October 2008 15:44:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 14 October 2008 15:44:01 GMT