W3C home > Mailing lists > Public > public-bpwg@w3.org > May 2009

[minutes] Tuesday 5 May 2009 Teleconf

From: Francois Daoust <fd@w3.org>
Date: Tue, 05 May 2009 17:02:09 +0200
Message-ID: <4A0054F1.7090802@w3.org>
To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
Hi,

The minutes of today's call are available at:
   http://www.w3.org/2009/05/05-bpwg-minutes.html
... and copied as text below.

Main discussion on content transformation and same origin policy. Final 
resolution is as follows:
[[ Links re-writing is strongly NOT RECOMMENDED because it jeopardizes 
the same-origin policy if no appropriate security measures are taken on 
the proxy. Main areas affected are DOM access, Cookies, and XHR calls. 
When links are re-written, proxies SHOULD ensure that the resulting 
content is purely static, and SHOULD therefore remove all scripting and 
cookies from the content served to the client. ]]

Francois.


-----
05 May 2009

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/public-bpwg/2009May/0004.html

    See also: [3]IRC log

       [3] http://www.w3.org/2009/05/05-bpwg-irc

Attendees

    Present
           adam, jo, Francois, DKA, EdC, miguel, jeffs, SeanP, rob,
           abel_on_IRC

    Regrets
           Kai, Manrique, BruceLawson, Yeliz, DavidStorey, SangwhanMoon,
           tomhume

    Chair
           DKA

    Scribe
           jeffs

Contents

      * [4]Topics
          1. [5]Last week's call review
          2. [6]Mobile Web Application Best Practices
          3. [7]CT - same origin policy
      * [8]Summary of Action Items
      _________________________________________________________

Last week's call review

    Review of last teleconf call by Francois

    some small changes by Adam, expect publishing by end of this wk or
    beginning of next wk

    2nd thing: waiting for ed & outreach group to publish new
    accessibility draft

    francois will check w them and publish new draft when they agree.

    most of the content transformation topics put off for this mtg

    chose to use existing HTTP RFC rather than defining our own
    definitions

    Dan: are we done w same-origin & MIME type issues?

    Francois: waiting for feedback before submitting IETF form

Mobile Web Application Best Practices

    Dan & Francois: as far as MWABP goes, getting closer to being ready
    but a couple of topics still need discussion

    <EdC> Basically, sections 3.6.1-3.6.2 of MWABP.

    Francois: some topics to be discussed w Francois & Eduardo: DevDesc
    repository, capability detection, & a few others
    ... suggests Adam may be able to talk about sec 3.6

    <francois> [9]Eduardo's comments on MWABP

       [9] http://lists.w3.org/Archives/Public/public-bpwg/2009Apr/0040.html

    Adam: prefer server-side detection, but may need to use client-side
    detection for some other things

    <francois> [10]fd's comments on MWABP

      [10] http://lists.w3.org/Archives/Public/public-bpwg/2009Apr/0044.html

    Adam: we should review Eduardo's comments, we should ensure rigorous
    & correct statements in our document (re 3.6.1-3.6.2)
    ... agrees w Eduardo things are somewhat over-simplified & these
    sections could become more rigorous... Eduardo refers to his
    comments again

    <francois> [11]latest MWABP draft

      [11] 
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20090405

    Adam: mostly just fixed typos, bigger issues responded to on the
    email thread
    ... mainly sections 3.6.1-3.6.2 need discussion

    Dan: who wants to intro topic & make a proposal for today's call?
    ... or do we need to examine &beforehand, do that on thread and find
    our way to resolution on next week's call

    Adam: still working out what the right thing is to propose, awaiting
    more community feedback

    Francois: need more review by non-techie point of view of some
    examples in BP
    ... we need to give someone the Task of reviewing the examples to
    make sure as many ppl as possible will understand them

    I'll try to drum up some more review, like I did w transcoding issue

    I'll try to drum up some more review on CHW blog, like I did w
    transcoding issue

    Dan: wants an action plan

    jeffs: I'll take an action if Adam (or someone else) will too

    Dan: talked about need for review and process

    <francois> [some sections with examples to review at some point:
    3.4.10 on Set-Cookie, 3.5.10.2 on viewport]

    Adam: suggests review from non-engineering perspective important now
    ... will also push next draft around at work for review & comment

    part of both reviewing myself & seeking input via CHW blog is to get
    not-so-tech folks

CT - same origin policy

    Dan: moving on to content transformation
    ... on to same-origin policy

    Francois: last f2f pointed us to existing test suites to use to test
    out

    <francois> [12]fd's report on CT and same-origin policy

      [12] http://lists.w3.org/Archives/Public/public-bpwg/2009Apr/0014.html

    Francois: there are existing if not-complete test suites around,
    problem is same-origin policy is a fairly large umbrella
    ... no 2 browsers alike re same-origin, HTML 5 defining (for 1st
    time in stds work)
    ... some ongoing work in WebApps group to define how to allow
    X-posting, moving target right now
    ... in the end, CT proxy must not introduce a new origin... need
    more info written into the Guidelines
    ... going to pass 3 proposal solution

    <francois> PROPOSED RESOLUTION 1: Since there doesn't appear to be a
    way in which the URI sent to the User Agent can be manipulated to
    preserve security related to

    <francois> same origin policies it is permissible for a CT proxy to
    act on content

    <francois> in so that security is nonetheless preserved as adjudged
    by conformance

    <francois> tests that are to be researched. If no such security
    tests can be found

    <francois> then there cannot be conformance associated with link
    rewriting and it cannot be permissible for CT proxies to do so.

    <francois> PROPOSED RESOLUTION 2: Links re-writing is strongly NOT
    RECOMMENDED because it jeopardizes the same-origin policy if no
    appropriate security

    <francois> measures are taken on the proxy. When links are
    re-written, proxies MUST ensure that the resulting content is purely
    static, and MUST therefore remove all scripting and cookies from the
    content served to the client.

    Francois: talking about proposed resolutions

    <francois> PROPOSED RESOLUTION 3: Links re-writing is strongly NOT
    RECOMMENDED because it jeopardizes the same-origin policy if no
    appropriate security measures are taken on the proxy. Areas affected
    include DOM access, Cookies, and XHR calls.

    Francois: not for prop 1, would go for prop 3

    <EdC> I'd rather go for 2.

    +1 on proposal 3

    <DKA> +1 on 3

    <jo> +1 to proposal 2

    Dan & Francois: discussion of proposals

    I like the simplicity and clarity and security of #3

    <EdC> Comment: what are the "appropriate measures on the proxy"? If
    no definition, then the proposed resolution is vague.

    <EdC> Re: prop. 3.

    SeanP: making suggestion for other wording
    ... only say not recommended BP way to handle things

    Francois: how is that diff than #3?

    IMHO, proposed resolution #3 makes the most sense and is the easiest
    to work with

    SeanP: are we saying not recommended even if CT is behaving?

    <rob> +1 on 3 and on 2

    Francois: needs to be strongly recommended against in all cases,
    only used because there is no other way now to accomplish some tasks

    +1 on 3

    Ed: sees #2 as a reinforcement of #3
    ... do we know what "approp security measures" are (re #3)?

    Francois: we have to talk about what they are, lists some references
    & what areas primarily effected
    ... no way to normatively tell what yuo need to do to remove the
    security risk

    Ed: this is a bit farther than what I was recommending
    ... what are the measures the proxy could take to make this okay?
    ... we need to say what to do on the proxy

    Francois: we can say more informatively than normatively in this
    area

    Ed: is there any existing doc saying what approp sec measures are?
    Francois: nope

    Ed & Francois: back and forth on availability & criticality (or not)
    of documentation on what exactly for servers to do

    Ed: review of prop #2 details w Francois
    ... asking about where proposed measures found by Francois

    Francois: talked about orgs he spoke w about the issue
    ... talked about recommendations he got from discussions

    Ed: discussion of same-origin policy XSS issues
    ... speaking in favor of #2 (as giving more info) over #3

    Francois: fine w that but thinks may be excessively restrictive

    Ed: 1st prop is a solution, but harsh... the 2nd is a solution, but
    less harsh... the 3rd is no solution at all

    Dan: before we take a vote on this, is there other work from which
    we can leverage ideas & policy recommendations?

    Francois: not sure

    Dan: will try to find more info on this

    <DKA> +1 on 3

    what is wrong w #3 with examples? I am afraid of too much
    specificity on this

    <SeanP> 3 for me

    Dan: if work on HTML5 is picked up it will become de facto, we don't
    want to bump into their work

    <francois> +1 on 3, 0 on 2.

    <EdC> +1 on 2

    +1 on 3

    <jo> +1 on 2

    <rob> +1 on 3 or 2

    <jo> [I think it's meaningless to say "appropriate"]

    <SeanP> sean didn't hear it either

    Jo: thinks we will get lots of push-back & complaints

    Rob: said that 2 and 3 basically say the same thing but 2 is a bit
    more explicit about how to stay secure than 3

    Dan & Jo: back & forth on what other group is shaping up as defacto
    std

    Francois: want to avoid too restrictive a BP, but thinks no danger
    of contradicting work of others

    Dan: want to avoid things too restrictive as leading to ppl not
    attending to this BP

    Jo: then the conformance statement (strongly rec'd rather than must
    not) helps

    Dan: reading "must" statements

    Jo: "strongly not recommended" would be okay

    Dan: looking for a "middle way"

    <francois> PROPOSED RESOLUTION 2: Links re-writing is strongly NOT
    RECOMMENDED because it jeopardizes the same-origin policy if no
    appropriate security measures are taken on the proxy. When links are
    re-written, proxies SHOULD ensure that the resulting content is
    purely static, and SHOULD therefore remove all scripting and cookies
    from the content served to the client.

    <EdC> What about replacing the MUST with something like: STRONGLY
    NOT RECOMMENDED to send anything else than static content...

    Dan: restating the exact normative language we must use

    <francois> +1

    <EdC> add " Areas affected include DOM access, Cookies, and XHR
    calls." after "taken on the proxy."

    <DKA> +1

    <SeanP> +0.5 (I like 3 better, but this is OK)

    is that an exhaustive list of the areas affected??

    <EdC> "main areas affected..." ?

    <rob> +1 but 3 is still good too

    I also like #3 better for the simplicity and flexibility

    <EdC> +1 on 2

    but can live with adjusted #2

    <francois> PROPOSED RESOLUTION 2: Links re-writing is strongly NOT
    RECOMMENDED because it jeopardizes the same-origin policy if no
    appropriate security measures are taken on the proxy. Main areas
    affected are DOM access, Cookies, and XHR calls. When links are
    re-written, proxies SHOULD ensure that the resulting content is
    purely static, and SHOULD therefore remove all scripting and cookies
    from the content served to the client.

    <jo> +1 with EdC's proposal

    +1

    <EdC> +1

    Dan: I must leave, new chair or close off call now?
    ... after we take a resolution

    RESOLUTION: Links re-writing is strongly NOT RECOMMENDED because it
    jeopardizes the same-origin policy if no appropriate security
    measures are taken on the proxy. Main areas affected are DOM access,
    Cookies, and XHR calls. When links are re-written, proxies SHOULD
    ensure that the resulting content is purely static, and SHOULD
    therefore remove all scripting and cookies from the content served
    to the client.

    Dan: trying to pass mantle to Jo, instead call is done _grin_

    <jo> [bye]

    bye

Summary of Action Items

    [End of minutes]
Received on Tuesday, 5 May 2009 15:02:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:00 UTC