See also: IRC log
http://lists.w3.org/Archives/Public/public-webappsec/2011Dec/0001.html
<bsterne> thanks
<bsterne> http://www.w3.org/2011/webappsec/track/actions/open
bhill2: I am coordinating with w3c staff to get mercurial repository mirrored to w3c-test.org
issue remains open
ekr: second open issue to abarth
abarth: failed to complete this, please postpone due date to next call
<jrossi> anne, are you around?
<jrossi> question regarding Action-11 for you
bhill2: anne can't make this call generally, so his issues may need to have the call moved temporarily if live discussion needed
ekr: next item, number 19, clarify policy on html
loaded via object tag. remains open, to be discussed later on this call
... next item, number 20, widgets liason
bhill2: didn't get to it, please postpone due date one month
ekr: next item, number 23, draft spec language for sandbox directive
<anne> jrossi: what's the question?
abarth: defined correctly, ready for closure, will get refined as HTML closes their changes to the spec
<anne> jrossi: I added a comment to http://www.w3.org/2011/webappsec/track/actions/11
<anne> jrossi: last week I think
anne, we will close 11
<anne> jrossi: the week before last week even :)
action 16 remains open, if you want to provide new milestones
<jrossi> anne: adam's going to look at your comment and confirm for you
<jrossi> anne: I'm just IRC proxying from the call :-)
ekr: back to issue-26, basic test setup
<anne> bhill2: so I did realize today http://lists.w3.org/Archives/Public/ietf-http-wg/2011OctDec/0341.html might be problematic, but then I've no idea when HTTP will be done so whether you want to wait for that, dunno
<anne> bhill2: as for milestones, we can go to Last Call as I said on the list; after that it's up in the air
gopal: we now have a repository with two tests
checked in and folders setup, quite a few CORS tests already exist for
webkit
... figuring out how to automate tests and how to use test harness
... also figuring out how to use multiple domains
ekr: so issue remains open?
gopal: this is a long running thing
... in repository there a lot of tests
bhill2: testing including server-side php execution is paused pending mirroring of repo to w3c-test.org by w3c techncial staff
erk: can we close this?
bhill2: mirroring to working server is in critical path, move to pending review once we can see if they're resovled?
ekr: remaining issues are for abarth to raise some discussions on the list
<abarth> hi ekr
abarth: didn't get to for Thanksgiving week, will do soon
bhill2: proxying anne to voice, ready for LC,
further progression may be path dependency on HTTPbis in IETF
... proposes to issue formal CfC on LC of CORS
ACTION bhill2 to send out CfC for CORS advancement to Last Call to public-webappsec and public-webapps
<trackbot> Created ACTION-29 - Send out CfC for CORS advancement to Last Call to public-webappsec and public-webapps [on Brad Hill - due 2011-12-13].
bhill2: (ekr, I'm assigning that action to myself since trackbot can't find you)
<ekr> ACTION: erescorl to test [recorded in http://www.w3.org/2011/12/06-webappsec-minutes.html#action01]
<trackbot> Created ACTION-30 - Test [on Eric Rescorla - due 2011-12-13].
<ekr> ACTION: abarth to Edit Firefox compatible CSP/Workers interaction into document [recorded in http://www.w3.org/2011/12/06-webappsec-minutes.html#action02]
<trackbot> Created ACTION-31 - Edit Firefox compatible CSP/Workers interaction into document [on Adam Barth - due 2011-12-13].
<bsterne> consensus on CSP interaction with Worker is that new Worker inherits the CSP of the page that created it and will be subject to restrictions imposed by the inherited policy
ekr: next agenda item: what is the policy for html generated by plugins or object tag?
abarth: object tag is very flexible thing that
can hold plugin or iframe, when it holds an iframe, should it be held to iframe
or object src directive?
... thought is that we should test behavior, go with agreed behavior or
discuss further if implementations differe
jrossi: for IE's implementation, iframes are treated like a plugin, for purposes of sandbox not just a frame
correction: jrossi: object tag should have object-src, when used through object tag
abarth: agreed, should be syntax-oriented, not semantics-oriented
bsterne: agreed, FF is also syntax-oriented
abarth: will test webkit behavior in this regard
<ekr> ACTION: bsterne to Document object tag/HTML interaction (issue 8) as "should be syntax-oriented, not semantics-oriented" [recorded in http://www.w3.org/2011/12/06-webappsec-minutes.html#action03]
<trackbot> Created ACTION-32 - Document object tag/HTML interaction (issue 8) as "should be syntax-oriented, not semantics-oriented" [on Brandon Sterne - due 2011-12-13].
bsterne: still my position that sandbox should be
a CSP 1.1 feature
... status is that FF is actively working on it, full time person, but got a
late start
... would prefer that spec reflect current reality of implementation, would be
a shame if mozilla were penalized with the perception of an incomplete
implementation when there were months to years of time for interested parties
to express desire to have this in the spec
... as MSFT will have an incomplete implementation only, would prefer 1.0 to
not have sandbox so Mozilla can "get full credit" as it were
jrossi: Don't think this is right time to decide
what should be in the spec, CR is the right time to mark features as at risk by
virtue of not being implemented
... especially as FF is already starting to implement, prefer to keep in the
spec, encourage other implementors
... when CR time comes, if at risk from lack of implementations, strike it
then
... flipside is that there is no 1.1. spec for now, credit wise, MSFT wants
credit for shipping something that was in spec as a proposed directive for some
time
ekr: brandon, if time comes to go to last call and Mozilla is done, do you object to having sandbox in 1.0? or only if you don't have it done?
bsterne: I would be happy to have it in if we are done, hesitant to say yes though to extra work of having to back it out later
ekr: if decided now, somebody will be unhappy, postponed, only maybe somebody's happy
jrossi: yes, postpone the decision until it will impede progress
bsterne: want to reserve right to back it out if Mozilla can't get it in
bhill2: rules of spec advancement don't allow
preferencing a particular implementor
... current charter requires 2 complete implementations, so we can add it and
be in the spirit of Brandon's request
... but we can't specifically privilege Mozilla to prevent advancement, if,
e.g. Opera implements everything in time for CR