20:39:55 RRSAgent has joined #webappsec 20:39:55 logging to http://www.w3.org/2013/11/19-webappsec-irc 20:39:57 RRSAgent, make logs world 20:39:57 Zakim has joined #webappsec 20:39:59 Zakim, this will be WASWG 20:39:59 I do not see a conference matching that name scheduled within the next hour, trackbot 20:40:00 Meeting: Web Application Security Working Group Teleconference 20:40:00 Date: 19 November 2013 20:57:37 glenn has joined #webappsec 21:06:41 ccarson has joined #webappsec 21:11:18 Zakim, this will be WASWG 21:11:18 ok, wseltzer; I see SEC_WASWG()5:00PM scheduled to start in 49 minutes 21:22:26 terri has joined #webappsec 21:51:39 gopal has joined #webappsec 21:54:32 SEC_WASWG()5:00PM has now started 21:54:34 bhill2 has joined #webappsec 21:54:34 + +1.781.369.aaaa 21:54:43 - +1.781.369.aaaa 21:54:44 SEC_WASWG()5:00PM has ended 21:54:44 Attendees were +1.781.369.aaaa 21:54:56 zakim, this will be 92974 21:54:56 I do not see a conference matching that name scheduled within the next hour, bhill2 21:55:05 :( 21:55:26 wseltzer, is Zakim not set for the end of daylight time in the US? 21:56:11 SEC_WASWG()5:00PM has now started 21:56:12 +BHill 21:56:42 rrsagent, begin 21:56:53 Meeting: WebAppSec WG Teleconference, 19-Nov-2013 21:56:59 Chairs: bhill2, ekr 21:57:06 Agenda: http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/0013.html 21:57:15 rrsagent, make minutes 21:57:15 I have made the request to generate http://www.w3.org/2013/11/19-webappsec-minutes.html bhill2 21:57:19 rrsagent, set logs public-visible 21:57:32 + +1.781.369.aaaa 21:57:34 - +1.781.369.aaaa 21:57:34 + +1.781.369.aaaa 21:57:45 dveditz has joined #webappsec 21:57:53 +??P2 21:58:08 Zakim, ??P2 is gmaone 21:58:08 +gmaone; got it 21:58:45 this is gopal 21:58:59 zakim, aaaa is gopal 21:58:59 +gopal; got it 21:59:06 for some reason mic is not working, I can hear you 21:59:13 zakim, who is making noise? 21:59:25 bhill2, listening for 11 seconds I heard sound from the following: BHill (4%), gopal (80%) 21:59:32 zakim, mute gopal 21:59:32 gopal should now be muted 21:59:49 (gopal - lots of noise from your line) 21:59:49 I'll dial out and try again 22:00:23 -gopal 22:00:52 zakim, code? 22:00:52 the conference code is 92794 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), wseltzer 22:01:04 +??P4 22:01:05 ccarson has joined #webappsec 22:01:09 zakim, ??p4 is I 22:01:09 +wseltzer; got it 22:01:24 +gopal 22:01:30 + +1.503.712.aabb 22:01:36 +[Mozilla] 22:01:52 ekr has joined #webappsec 22:01:54 +CCarson 22:02:01 zakim, who is here? 22:02:01 On the phone I see BHill, gmaone, wseltzer, gopal, +1.503.712.aabb, [Mozilla], CCarson 22:02:03 zakim, aabb is terri 22:02:04 On IRC I see ekr, ccarson, dveditz, bhill2, gopal, terri, glenn, Zakim, RRSAgent, gmaone, neilm, timeless, trackbot, wseltzer 22:02:04 +terri; got it 22:02:11 zakim, ekr is at Mozilla 22:02:11 I don't understand 'ekr is at Mozilla', ekr 22:02:21 zakim, Mozilla has ekr 22:02:21 +ekr; got it 22:02:58 grobinson|laptop has joined #webappsec 22:03:46 +abarth 22:04:16 abarth has joined #webappsec 22:04:34 +[Mozilla.a] 22:04:57 zakim, mozilla.a has grobinson 22:04:57 +grobinson; got it 22:05:03 klee has joined #webappsec 22:06:09 klee, care to introduce yourself? 22:06:14 haven't seen you here before? 22:06:20 I've been on the last couple calls? 22:06:27 apologies 22:06:29 I'm Ken Lee, security engineer @ etsy 22:06:37 I usually don't say anything in these mtgs 22:06:42 :) 22:06:51 agenda: http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/0013.html 22:07:13 scribenick ekr 22:07:20 scribenick: ekr 22:07:23 TOPIC: Minutes approval 22:07:24 http://www.w3.org/2013/10/22-webappsec-minutes.html 22:08:02 TOPIC: Tracker 22:08:06 https://www.w3.org/2011/webappsec/track/actions/open?sort=owner 22:08:22 terri_ has joined #webappsec 22:08:31 +[IPcaller] 22:08:42 Zakim, dveditz is Ipcaller 22:08:42 sorry, dveditz, I do not recognize a party named 'dveditz' 22:08:58 Zakim, Ipcaller is dveditz 22:08:58 +dveditz; got it 22:09:02 abarth: I haven't done anything 22:09:08 ekr: :) 22:09:18 … push everything back to 12/12 22:09:25 abarth: my job is just to record what happens 22:09:36 I know :) 22:10:06 glenn: if you are paying attn on irc, any thoughts / updates on https://www.w3.org/2011/webappsec/track/actions/151 22:10:22 ... typing ... 22:10:53 thanks for reminder, I will attend to this during this week; am presently in Philippines working on aid and recovery effort 22:10:58 did I lose the call? 22:11:16 :-) ok. saw typing but no sound 22:11:23 glenn: good luck, and good priorities 22:11:26 :) 22:11:39 zakim, drop wseltzer 22:11:39 wseltzer is being disconnected 22:11:40 -wseltzer 22:11:47 TOPIC: blob, filesystem, etc. URIs in CSP 22:11:47 http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/0007.html 22:12:08 +??P10 22:12:11 zakim, ??p10 is I 22:12:11 +wseltzer; got it 22:12:20 bhill2: latest comments were from dan… dan proposed not to add unsafe inline 22:13:25 … 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. 22:13:32 … this is content that originates from same origin 22:13:50 abarth: a content injection vulnerability could allow data uri injection 22:14:20 bhill2: data and js should fall under unsafe inline. blob and filesystem fall under unsafe eval 22:14:36 dveditz: ... 22:14:55 bhill2: wherever the directive would have paid attention to an unsafe-* keyword we would follow that 22:15:08 abarth: maybe we should make these apply to all resources for futureproofing 22:15:37 … suppose in future we add unsafe-inline keyword to IMG SRC we would get weird behavior 22:15:49 … could head this off at the pass by adding support to all directives 22:16:01 bhill2: interesting.... 22:16:11 that was deveditz 22:16:37 dveditz: my other proposal was that to use these, you would have to specifically whitelist the scheme 22:17:01 abarth: that proposal matches chrome 22:18:50 abarth: my experience dealing with authors is that they have trouble whitelisting data uris 22:19:32 dveditz: from that perspective, brad's proposal is clearer 22:20:49 nobody really has strong opinions 22:25:26 [… lots of discussion about what's clearer...] 22:25:36 bhill2: does anyone have an opinion who isn't a browser author 22:25:44 … We have a clear question we can ask. 22:26:05 … if we have consensus that either is ok except for clarity; let's ask the list 22:26:29 dveditz: propose that we support them everywhere and see if people are confused? 22:27:01 ACTION abarth update CSP to make unsafe-inline, unsafe-eval universal constructs 22:27:01 Created ACTION-152 - Update csp to make unsafe-inline, unsafe-eval universal constructs [on Adam Barth - due 2013-11-26]. 22:27:13 dveditz: need to go looka t FirefoxOS 22:27:39 we can write a page on webplatform docs to explain 22:28:55 abarth: will write up the proposal from a few minutes ago and then reserach that this doesn't mess up our use case 22:29:10 TOPIC: handling workers, sharedworkers, etc. 22:29:11 http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/0008.html 22:29:54 bhill2: we originally said that workers inherited document csp policies 22:30:14 … the latest proposal after some discussion on the list is that workers should be governed by frame-src not script-src 22:31:15 abarth: two issues (1) what controls loading of worker and (2) while it's executing, what controls further loading 22:31:23 -[Mozilla] 22:31:54 Sorry, got thrown out of room 22:31:55 calling back in 22:32:39 +[Mozilla] 22:32:39 Back 22:33:17 dveditz: proposal to inherit policy of creating resource is what we do for srcdoc now 22:33:32 dveditz: only concern with frame src is what might break 22:33:37 dveditz: concern with switching to frame-src is what might break that depended on script-src 22:33:57 dveditz: makes policy of using headers delivered with worker script more sensible than with script-src 22:34:45 grobinson: for now we are implmenting 1.0 spec at Mozilla as we implement SharedWorkers 22:34:53 ... frame-src is confusing at first, but confusing 22:34:59 bhill2, should I take back over? 22:35:12 abarth(?): other option would be to create a worker src 22:35:49 bhill2: maybe add child-src as a synonym for frame-src for compat, applies to workers, frames, pop-ups 22:35:53 … other things coming related to this: html imports, service workers, ??? 22:36:15 … current plan is that imports are like script-src subject to same policy of parent document 22:36:38 … service workers work a lot like shared workers, makes sense to have them be similar to shared workers 22:37:09 can whoever just spoke say again? 22:37:17 grobinson, can you re-state? 22:37:19 grobinson: other option is to create worker-src 22:37:23 thanks 22:38:00 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 22:38:49 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 22:39:17 ???: two different issues, what can workers do vs. what can a document create a worker from 22:39:36 dveditz: hearing strong agreement for using header policy to define policy for workers 22:39:41 … nonagreement about moving to frame-src 22:40:10 bhill2: not opposed to worker-src vs. frame-src. script-src seems inappropriate 22:40:26 … child-src as a synonym for frame-src would be ok 22:41:16 abarth: if the worker shared memory with the main document (if js were thread safe) would you feel differently 22:41:21 bhill2: yeah... 22:41:30 … but that's not how workers operate right? 22:41:56 abarth: half-way in between 22:42:10 dveditz: but can XHR requests back to self with credentials 22:42:35 bhill2: is any of that stuff that iframe origin can't do 22:42:49 abarth, dveditz: worker capabilities are a subset of iframe capabilities 22:43:16 bhill2: agreement that current specified behavior just doesn't work for shared workers 22:43:43 abarth: only point of disagreement is what directive controls loading of worker itselv 22:44:03 dveditz: right. script-src doesn't work but not clear if we want new directive or child-src 22:44:26 grobinson: frame-src seems like it has a confusing name but right semantics. would make sense to control with same directive (child-src) 22:44:53 abarth: webapps has a dom worker proposal 22:45:39 … specific proposal would be to have some way to have a trust boundary for dom worker 22:46:14 abarth: this points more towards child-src being good future proofing 22:46:24 grobinson: child-src seems better than worker-src 22:47:02 ACTION bhill2 propose more precise text for child-src directive idea 22:47:03 Created ACTION-153 - Propose more precise text for child-src directive idea [on Brad Hill - due 2013-11-26]. 22:47:03 action bhill2 to propose more precise language for directives for shared worker 22:47:03 Created ACTION-154 - Propose more precise language for directives for shared worker [on Brad Hill - due 2013-11-26]. 22:47:08 oop 22:48:26 ACTION dveditz update CSP to reflect that workers use policy resource is delivered with 22:48:26 Created ACTION-155 - Update csp to reflect that workers use policy resource is delivered with [on Daniel Veditz - due 2013-11-26]. 22:48:27 dveditz: currently the spec says that src-doc chouls inherit policy parent but don't talk about loading 22:49:34 s/chould/should/ 22:50:01 TOPIC: UISecurity and seamless iframes 22:50:04 http://lists.w3.org/Archives/Public/public-webappsec/2013Oct/0105.html 22:50:29 -gopal 22:50:52 bhill2: [summarizes mailing list] 22:51:28 gmaone, can you summarize your understanding of David Huang's mail? 22:52:39 bhill2: browsers will composite seamless iframes together.... 22:52:57 gmaone: protection needs to be applied if any ancestors are from another region 22:53:07 … same site can composite whatever it wants 22:53:26 … import input protection when composited with foreign data 22:53:29 s/region/origin 22:53:41 gmaone, thanks 22:53:56 bhill2: no action needed 22:54:11 TOPIC: plugin-src none and resource loading 22:54:12 http://lists.w3.org/Archives/Public/public-webappsec/2013Nov/0001.html 22:56:16 grobinson: need to rely on plugin to enforce CSP 22:56:29 … in the case of object-src none we should refuse to load any plugins 22:56:48 dveditz: even with non-problematic plugins, we can at best control initial load 22:56:57 … but Java is a particularly hard case 22:57:14 bhill2: since we have two implementations that share this bug, should we add some extra text 22:57:42 abarth: one thing to keep in mind is that there are plugins which don't load resources. 22:57:49 … e.g., gears plugin 22:58:26 cory: non-url-based plugins use current resource 22:58:30 … so if self was set, that would work 22:58:51 abarth: one way to get this behavior would be to treat the plugin that had url of containing document for the initial load 22:59:28 ???: for object-src none, don't load. For objects with no url, match against self 22:59:36 … from there the plugin can load what it likes 23:00:03 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 23:00:30 ACTION abarth clarify plugin-src behavior: if able to determine resource, self or none 23:00:30 Created ACTION-156 - Clarify plugin-src behavior: if able to determine resource, self or none [on Adam Barth - due 2013-11-26]. 23:01:25 -[Mozilla] 23:01:25 new charter: http://www.w3.org/2013/07/webappsec-charter.html 23:01:35 zakim, list attendees 23:01:35 As of this point the attendees have been BHill, +1.781.369.aaaa, gmaone, gopal, wseltzer, +1.503.712.aabb, CCarson, terri, ekr, abarth, [Mozilla], grobinson, dveditz 23:01:39 -abarth 23:01:41 -dveditz 23:01:42 -wseltzer 23:01:43 rrsagent, make minutes 23:01:43 I have made the request to generate http://www.w3.org/2013/11/19-webappsec-minutes.html bhill2 23:01:44 -CCarson 23:01:48 rrsagent, set logs public-visible 23:01:49 -gmaone 23:01:50 bhill, thanks for closing the minutes 23:01:57 thanks for scribing 23:02:03 -BHill 23:02:22 -terri 23:02:42 grobinson|laptop has joined #webappsec 23:05:22 sorry - is the call over? 23:07:03 yes 23:07:11 wrapped at 3 23:07:23 disconnecting the lone participant, [Mozilla.a], in SEC_WASWG()5:00PM 23:07:24 SEC_WASWG()5:00PM has ended 23:07:24 Attendees were BHill, +1.781.369.aaaa, gmaone, gopal, wseltzer, +1.503.712.aabb, CCarson, terri, ekr, abarth, [Mozilla], grobinson, dveditz 23:07:48 thanks bhill2 - got disconnected for a minute