- From: Francois Daoust <fd@w3.org>
- Date: Tue, 05 May 2009 17:02:09 +0200
- 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