See also: IRC log
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
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> Eduardo's comments on MWABP
Adam: prefer server-side detection, but may need to use client-side detection for some other things
<francois> fd's comments on MWABP
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> latest MWABP draft
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
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> fd's report on CT and same-origin policy
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