Web Application Security Working Group Teleconference

<trackbot> Date: 07 May 2014

<scribe> Meeting: WebAppSec WG Teleconference, 7-May-2014

<scribe> Agenda: http://lists.w3.org/Archives/Public/public-webappsec/2014May/0003.html

<mkwst_> zakim's being weird. :(

<wseltzer> some scribe instructions: http://www.w3.org/2008/xmlsec/Group/Scribe-Instructions.html

Welcome Dan Veditz as co-chair

<devd> bhill: EKR steps down after years of work as chair. Thanks to EKR for all his good work over the years! congrats to dveditz for being new chair and thanks to dveditz.

<devd> bhill: TPAC is end of October in San Jose/bayarea. Call for exclusions still open on UI Security and SRI

Minutes Approval

http://www.w3.org/2011/webappsec/draft-minutes/2014-04-23-webappsec-minutes.html

minutes approved

Tracker actions

http://www.w3.org/2011/webappsec/track/actions/open?sort=owner

<wseltzer> action-167?

<trackbot> action-167 -- Devdatta Akhawe to Respond to list queries about hints for content-addressable storage -- due 2014-04-16 -- OPEN

<trackbot> http://www.w3.org/2011/webappsec/track/actions/167

<grobinson> muted, sorry

<wseltzer> action-169?

<trackbot> action-169 -- Devdatta Akhawe to Read and respond to use of sri hashes for caching/alternate locations: http://lists.w3.org/archives/public/public-webappsec/2014mar/0103.html -- due 2014-04-16 -- OPEN

<trackbot> http://www.w3.org/2011/webappsec/track/actions/169

<devd> I will just go ahead and change the due dates

actions 167 and 169, regarding content-addressable-storage with SRI, will update due-dates

<devd> for action 167 and 169

<wseltzer> action-168?

<trackbot> action-168 -- Brad Hill to Raise to the list handling of csp associated with installed apps as possible spec note -- due 2014-04-16 -- OPEN

<trackbot> http://www.w3.org/2011/webappsec/track/actions/168

mkwst: the issue with ServiceWorker isn't mutation of the policy per-se, but differnent resolution of resource loads associated with a different policy

devd: there are issues over on GitHub for ServiceWorker to review on this

ACTION mkwst to review ServiceWorker issues relevant to CSP

<trackbot> Error finding 'mkwst'. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.

ACTION mwest2 to review ServiceWoker issues relevant to CSP from GitHub

<trackbot> Created ACTION-172 - Review servicewoker issues relevant to csp from github [on Mike West - due 2014-05-14].

<devd> mkwst_: Mike will talk about ServiceWorker + Security at the Blink conference next week

<devd> bhill2: mkwst_ Recommendation that CSP policy in manifest file and HTTP header for packaged apps should be the same

ACTION-180?

<trackbot> Sorry, but ACTION-180 does not exist.

ACTION-170?

<trackbot> ACTION-170 -- Brad Hill to Arrange some joint meeting time with svg wg -- due 2014-04-30 -- OPEN

<trackbot> http://www.w3.org/2011/webappsec/track/actions/170

ACTION-166?

<trackbot> ACTION-166 -- Mike West to to add an explicit "privacy considerations" section to sri -- due 2014-03-19 -- OPEN

<trackbot> http://www.w3.org/2011/webappsec/track/actions/166

Spec issues in Github

https://github.com/w3c/webappsec/issues

<devd> No updates

ISSUE-58, late-binding of policies

<devd> discussed in review of action items

[CSP] SVG-in-img implementation difference

<devd> bhill2: waiting for input for svg wg

<devd> bhill2: if SVG is isolated, then we don't need to worry about internal image loaded.

CSP and mixed content

http://lists.w3.org/Archives/Public/public-webappsec/2014Apr/0057.html

devd: there is considerable difference in browsers about treatment of mixed-content and they are strengthening it

mkwst: annevk would like fetch to explain the behavior of browsers, current behavior is unspecified

devd: don't want use of CSP to be inconsistent with existing behavior in non-CSP

dveditz: user has option to override blocking

mkwst: for active mixed content,behavior today in chrome is just to block
... and a warning in developer tools, gives user option to turn off blocking in UI
... not compatible with CSP
... suggested a different keyword
... spec should not prevent user from turning this off

devd: agree this may be needed, not sure why it belongs in CSP

tanvi: CSP is about expressed intent by author, mixed content blocking is about protecting users from possibly mistakes by authors, with an out
... no way to override for CSP
... no way to override with HSTS, either

<devd> bhill2: wonder what's the behavior we will get that is not already expressible via HSTS + default-source

<devd> mkwst_: Anne wants a mechanism to explain what browsers do today

bhill2: what is the behavior we want that is not implied by HSTS or default-src: https

there is also this: http://www.w3.org/TR/2010/REC-wsc-ui-20100812/

http://www.w3.org/TR/2010/REC-wsc-ui-20100812/#securepage

dveditz: seems to make more sense to define it as part of Fetch, not as part of CSP

<devd> tanvi: we definitely should define it, regardless of where it goes

<devd> mkwst_: is there a w3c plan for FETCH ?

<devd> mkwst_: the SRI spec also references SRI

<devd> wseltzer: we should talk to Philippe Le Hegaret for HTML5 WG to talk about fetch

<devd> mkwst_: The SRI spec also references FETCH

CSP, Fetch, and frame-ancestors

http://lists.w3.org/Archives/Public/public-webappsec/2014Apr/0051.html

<wseltzer> ACTION: wseltzer to talk with plh about FETCH and CSP, invite conversation with WebAppSec [recorded in http://www.w3.org/2014/05/07-webappsec-minutes.html#action01]

<trackbot> Created ACTION-173 - Talk with plh about fetch and csp, invite conversation with webappsec [on Wendy Seltzer - due 2014-05-14].

<grobinson> Did anyone else just get booted from the call?

<grobinson> will do

dveditz: like X-Frame-Options, may not be modeled in terms of Fetch, which is document-based, and doesn't have a notion of nested browsing contexts

<devd> bhill2: XFO/frame-ancestors happens after the document is in the browser and we walk up the tree

<devd> mkwst_: so maybe this needs to be part of the HTML spec

mkwst: if we define failure of frame-ancestors as throwing a network error, that comes from fetch today

<devd> mkwst_: but the problem is that we treat frame-ancestors/XFO as network error

<devd> bhill2: maybe the more analagous behavior is how to deal with broken XML

<devd> bhill2: because we got the content but the client can't render it

<devd> ACTION: bhill2 raise frame-ancestors/fetch/neterror on list [recorded in http://www.w3.org/2014/05/07-webappsec-minutes.html#action02]

<trackbot> Created ACTION-174 - Raise frame-ancestors/fetch/neterror on list [on Brad Hill - due 2014-05-14].

<devd> 08:049 - 08:054 TOPIC: CSP, Fetch, and Service Workers

CSP, Fetch, and Service Workers

http://lists.w3.org/Archives/Public/public-webappsec/2014Apr/0049.html

devd: issue here is that names of contexts are now surfaced to developers rather than just being browser-internal
... so we should pick good names

http://fetch.spec.whatwg.org/#concept-request-client

<devd> dveditz: popups are just like navigations. people have wanted CSP to talk about navigations and maybe some day we will handle that too

<devd> dveditz: we should worry about adding those exact sort of escape hatches as for onbeforeunload

in current CSP 1.1 we already say popups are controlled by child-src

does the handle/reference between a script-opened popup and a user-opened one make a security difference?

<mkwst_> (we pulled popups out of CSP 1.1 in https://github.com/w3c/webappsec/commit/9b7a618aca1f9fcbc99f9887df60ccd98d9c7654; punted to 1.2 for discussion around `window.open`)

<mkwst_> ISSUE-57 for CSP 1.2

<mkwst_> (http://www.w3.org/2011/webappsec/track/issues/57)

ACTION bhill2 to post TPAC dates to list for next F2F

<trackbot> Created ACTION-175 - Post tpac dates to list for next f2f [on Brad Hill - due 2014-05-14].