IRC log of webappsec on 2013-11-19

Timestamps are in UTC.

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