See also: IRC log
<trackbot> Date: 19 November 2013
<bhill2> :(
<bhill2> wseltzer, is Zakim not set for the end of daylight time in the US?
<bhill2> Meeting: WebAppSec WG Teleconference, 19-Nov-2013
<gopal> this is gopal
<gopal> for some reason mic is not working, I can hear you
<bhill2> (gopal - lots of noise from your line)
<gopal> I'll dial out and try again
<bhill2> klee, care to introduce yourself?
<bhill2> haven't seen you here before?
<klee> I've been on the last couple calls?
<bhill2> apologies
<klee> I'm Ken Lee, security engineer @ etsy
<klee> I usually don't say anything in these mtgs
<bhill2> :)
<bhill2> agenda: http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/0013.html
scribenick ekr
<scribe> scribenick: ekr
<bhill2> http://www.w3.org/2013/10/22-webappsec-minutes.html
<bhill2> https://www.w3.org/2011/webappsec/track/actions/open?sort=owner
abarth: I haven't done anything
<abarth> ekr: :)
… push everything back to 12/12
abarth: my job is just to record what happens
<abarth> I know :)
<bhill2> glenn: if you are paying attn on irc, any thoughts / updates on https://www.w3.org/2011/webappsec/track/actions/151
<glenn> ... typing ...
<glenn> thanks for reminder, I will attend to this during this week; am presently in Philippines working on aid and recovery effort
<dveditz> did I lose the call?
<dveditz> :-) ok. saw typing but no sound
<bhill2> glenn: good luck, and good priorities
<bhill2> :)
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/0007.html
bhill2: latest comments were from dan… dan proposed not to add unsafe inline
… two ways of looking at constructed URI schemes. My proposal was to have these grouped under "self" where directive doesn't have unsafe inline or unsafe eval. When directive does have an unsafe inline then group under that.
… this is content that originates from same origin
abarth: a content injection vulnerability could allow data uri injection
bhill2: data and js should fall under unsafe inline. blob and filesystem fall under unsafe eval
dveditz: ...
bhill2: wherever the directive would have paid attention to an unsafe-* keyword we would follow that
abarth: maybe we should make these apply to all resources for futureproofing
… suppose in future we add unsafe-inline keyword to IMG SRC we would get weird behavior
… could head this off at the pass by adding support to all directives
bhill2: interesting....
<bhill2> that was deveditz
dveditz: my other proposal was that to use these, you would have to specifically whitelist the scheme
abarth: that proposal matches
chrome
... my experience dealing with authors is that they have
trouble whitelisting data uris
dveditz: from that perspective, brad's proposal is clearer
nobody really has strong opinions
[… lots of discussion about what's clearer...]
bhill2: does anyone have an opinion who isn't a browser author
… We have a clear question we can ask.
… if we have consensus that either is ok except for clarity; let's ask the list
dveditz: propose that we support them everywhere and see if people are confused?
<bhill2> ACTION abarth update CSP to make unsafe-inline, unsafe-eval universal constructs
<trackbot> Created ACTION-152 - Update csp to make unsafe-inline, unsafe-eval universal constructs [on Adam Barth - due 2013-11-26].
dveditz: need to go looka t FirefoxOS
<wseltzer> we can write a page on webplatform docs to explain
abarth: will write up the proposal from a few minutes ago and then reserach that this doesn't mess up our use case
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/0008.html
bhill2: we originally said that workers inherited document csp policies
… the latest proposal after some discussion on the list is that workers should be governed by frame-src not script-src
abarth: two issues (1) what controls loading of worker and (2) while it's executing, what controls further loading
Sorry, got thrown out of room
calling back in
Back
<bhill2> dveditz: proposal to inherit policy of creating resource is what we do for srcdoc now
dveditz: only concern with frame src is what might break
<bhill2> dveditz: concern with switching to frame-src is what might break that depended on script-src
<bhill2> dveditz: makes policy of using headers delivered with worker script more sensible than with script-src
<bhill2> grobinson: for now we are implmenting 1.0 spec at Mozilla as we implement SharedWorkers
<bhill2> ... frame-src is confusing at first, but confusing
bhill2, should I take back over?
abarth(?): other option would be to create a worker src
<bhill2> bhill2: maybe add child-src as a synonym for frame-src for compat, applies to workers, frames, pop-ups
… other things coming related to this: html imports, service workers, ???
… current plan is that imports are like script-src subject to same policy of parent document
… service workers work a lot like shared workers, makes sense to have them be similar to shared workers
can whoever just spoke say again?
grobinson, can you re-state?
<bhill2> grobinson: other option is to create worker-src
thanks
dveditz: easy to create a new directive when we invent a new thing. if we invent something and them move it, we break a lot of poeple
abarth: more sympathetic to ahving the worker use the CSP policy that came with its resource than to change from script-src to frame-src
???: two different issues, what can workers do vs. what can a document create a worker from
dveditz: hearing strong agreement for using header policy to define policy for workers
… nonagreement about moving to frame-src
bhill2: not opposed to worker-src vs. frame-src. script-src seems inappropriate
… child-src as a synonym for frame-src would be ok
abarth: if the worker shared memory with the main document (if js were thread safe) would you feel differently
bhill2: yeah...
… but that's not how workers operate right?
abarth: half-way in between
dveditz: but can XHR requests back to self with credentials
bhill2: is any of that stuff that iframe origin can't do
abarth, dveditz: worker capabilities are a subset of iframe capabilities
bhill2: agreement that current specified behavior just doesn't work for shared workers
abarth: only point of disagreement is what directive controls loading of worker itselv
dveditz: right. script-src doesn't work but not clear if we want new directive or child-src
grobinson: frame-src seems like it has a confusing name but right semantics. would make sense to control with same directive (child-src)
abarth: webapps has a dom worker proposal
… specific proposal would be to have some way to have a trust boundary for dom worker
abarth: this points more towards child-src being good future proofing
grobinson: child-src seems better than worker-src
<bhill2> ACTION bhill2 propose more precise text for child-src directive idea
<trackbot> Created ACTION-153 - Propose more precise text for child-src directive idea [on Brad Hill - due 2013-11-26].
action bhill2 to propose more precise language for directives for shared worker
<trackbot> Created ACTION-154 - Propose more precise language for directives for shared worker [on Brad Hill - due 2013-11-26].
oop
<bhill2> ACTION dveditz update CSP to reflect that workers use policy resource is delivered with
<trackbot> Created ACTION-155 - Update csp to reflect that workers use policy resource is delivered with [on Daniel Veditz - due 2013-11-26].
dveditz: currently the spec says that src-doc chouls inherit policy parent but don't talk about loading
s/chould/should/
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Oct/0105.html
bhill2: [summarizes mailing list]
<bhill2> gmaone, can you summarize your understanding of David Huang's mail?
bhill2: browsers will composite seamless iframes together....
gmaone: protection needs to be applied if any ancestors are from another origin
… same site can composite whatever it wants
… import input protection when composited with foreign data
gmaone, thanks
bhill2: no action needed
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/0001.html
grobinson: need to rely on plugin to enforce CSP
… in the case of object-src none we should refuse to load any plugins
dveditz: even with non-problematic plugins, we can at best control initial load
… but Java is a particularly hard case
bhill2: since we have two implementations that share this bug, should we add some extra text
abarth: one thing to keep in mind is that there are plugins which don't load resources.
… e.g., gears plugin
cory: non-url-based plugins use current resource
… so if self was set, that would work
abarth: one way to get this behavior would be to treat the plugin that had url of containing document for the initial load
???: for object-src none, don't load. For objects with no url, match against self
… from there the plugin can load what it likes
abarth: one way to interpret it is that the plugin can either determine what the plugin will do or it can't. if it can, use that url, otherwise use document url
<bhill2> ACTION abarth clarify plugin-src behavior: if able to determine resource, self or none
<trackbot> Created ACTION-156 - Clarify plugin-src behavior: if able to determine resource, self or none [on Adam Barth - due 2013-11-26].
<wseltzer> new charter: http://www.w3.org/2013/07/webappsec-charter.html