19:59:44 RRSAgent has joined #webappsec 19:59:44 logging to http://www.w3.org/2014/11/03-webappsec-irc 20:00:13 Zakim has joined #webappsec 20:00:18 zakim, this is 92794 20:00:18 ok, bhill2; that matches SEC_WASWG()3:00PM 20:00:21 + +1.646.355.aacc 20:00:42 +??P5 20:00:47 Meeting: WebAppSec Teleconference 3-Nov-2014 20:00:53 Chairs: bhill2, dveditz 20:00:57 Zakim, ??P5 is me 20:00:57 +gmaone; got it 20:01:10 Agenda: http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0002.html 20:01:15 + +1.415.736.aadd 20:01:58 zakim, aacc is deian 20:01:58 +deian; got it 20:01:59 jww has joined #webappsec 20:02:02 zakim, who is here? 20:02:02 On the phone I see +1.206.753.aabb, +1.206.876.aaaa, mkwst, [IPcaller], deian, gmaone, +1.415.736.aadd 20:02:04 On IRC I see jww, Zakim, RRSAgent, bhill2, gmaone, tanvi, deian, schuki, Josh_Soref, tobie, timeless, mkwst___, freddyb, renoirb, terri, wseltzer, trackbot 20:02:13 dave-goog has joined #webappsec 20:02:14 zakim aadd is jww 20:02:34 +terri 20:02:51 zakim, aaaa is drx-goog 20:02:51 +drx-goog; got it 20:03:58 +[Microsoft] 20:04:04 + +1.415.857.aaee 20:04:19 dev has joined #webappsec 20:04:48 dwalp has joined #webappsec 20:05:01 zakim, aaee is dev 20:05:01 +dev; got it 20:05:02 dveditz has joined #webappsec 20:05:51 scribenick: dev 20:05:56 +[Mozilla] 20:06:03 scribe: Devdatta Akhawe 20:06:07 Zakim, mozilla has dveditz 20:06:07 +dveditz; got it 20:06:18 zakim, [Mozilla] has deveditz 20:06:18 +deveditz; got it 20:06:25 zakim, [Microsoft] had dwalp 20:06:25 I don't understand '[Microsoft] had dwalp', bhill2 20:06:34 zakim, [Microsoft] has dwalp 20:06:34 +dwalp; got it 20:06:39 zakim, who is here? 20:06:39 On the phone I see +1.206.753.aabb, drx-goog, mkwst, [IPcaller], deian, gmaone, +1.415.736.aadd, terri, [Microsoft], dev, [Mozilla] 20:06:41 [Microsoft] has dwalp 20:06:41 [Mozilla] has deveditz 20:06:41 On IRC I see dveditz, dwalp, dev, drx-goog, jww, Zakim, RRSAgent, bhill2, gmaone, tanvi, deian, schuki, Josh_Soref, tobie, timeless, mkwst___, freddyb, renoirb, terri, wseltzer, 20:06:41 ... trackbot 20:06:45 melinda has joined #webappsec 20:07:08 TOPIC: Minutes Approval 20:07:12 regrets+ wseltzer 20:07:49 RESOLVED by unanimous consent: minutes from TPAC are approved 20:07:59 TOPIC: Agenda Bashing 20:08:23 bhill2 adding item: David Ross and Terri Oda to follow up on EPR 20:08:38 TOPIC: TPAC Summary 20:10:00 Zakim, aadd is jww 20:10:00 +jww; got it 20:13:27 TOPIC: EPR follow-up from David Ross and Terri Oda 20:13:36 TOPIC: EPR / dross 20:13:37 scribenick: bhill2 20:13:47 does david have a irc handle ? 20:13:53 dross: Spent some time going thru web app manifest 20:13:53 dev: drx-goog 20:13:56 ... we could use that 20:14:00 or dross. :) 20:14:11 ok .. bhill2 is scribing .. sorry :) 20:14:12 ... but would still need a header to tell the browser that EPR is enabled for this site 20:14:21 -mkwst 20:14:50 ... currently this works by sending a synchronous request 20:15:00 ... lots of pushback on that by browsers for perf reasons 20:15:09 ... thinking about ways to work around that 20:15:19 ... started discussion of that, just moved it to webappsec list 20:15:30 +mkwst 20:15:35 ... can discuss further there, possible to avoid any synchronous requests 20:15:51 ... idea there is basic level policy that comes with the header 20:16:00 ... mitigates xss in scenario where manifest is not yet loaded 20:16:24 ... overall manifest spec makes a lot of sense to hold EPR manifest 20:16:31 ... still requirement for a response header, whatever it is called 20:16:42 terri: talked to folks at sysapps about implementation of manifest 20:16:52 ... one thing holding up implementation was knowing exactly when and how it 20:17:10 ... needs to be loaded so we should talk to them about that, whether it should be 20:17:16 ... sync for package apps 20:17:27 ... similar proposal dead in water b/c of this, will probably be pushback 20:17:44 devditz: earlier version of CSP had synchronous fetch of policy-uri 20:17:48 ... got booted for similar concerns 20:18:07 dev: for CSRF, reasonable to say it's only needed once you've visited site and have a cookie 20:18:25 drx-google: no way to do anything in that case anyway, no info at all when first request is sent 20:18:46 ... not authN until actually interacting, should have manifest by then 20:18:53 dev: we already have CSP... 20:19:03 ... no story for CSRF, EPR can help there 20:19:08 terri: we do have Origin header 20:19:13 dev: is anyone implementing? 20:19:29 bhill2: Origin header is mandatory for CORS. 20:19:47 dveditz: CORS has different behavior when you do redirects, useful for CSRF. 20:19:50 dveditz: problem is that cors truncates on redirects, so not useful for other things 20:21:05 bhill2: regarding XSS. of that 20% which could be prevented by EPR, how much could be prevented by CSP? 20:21:10 dross: Lots of overlap there. 20:21:20 dross: reflected XSS can be mitigated with CSP. 20:21:28 dveditz: how does EPR help for stored XSS? 20:21:29 dveditz: does EPR help for stored XSS? 20:21:31 dross: It does not. 20:21:50 dveditz: CSP can help with stored XSS. 20:22:03 dveditz: CSRF mitigations are valuable, as we have XSS mitigations with CSP. 20:22:24 bhill2: should give clear guidance to authors as to which (EPR or CSP) they should use and why, given overlap. 20:22:57 dross: Can determine what that guidance should be. 20:23:19 dross: In packaged applications, if you want unsafe-eval, you could do that and still use EPR to mitigate the threat. 20:23:27 dross: There's value in having another option. 20:23:36 dveditz: other thing is to consider how this works with priority of constituencies 20:23:44 ... have run into issues with CSP on that, EPR could be worse 20:24:22 +tanvi 20:24:24 http://www.w3.org/TR/html-design-principles/#priority-of-constituencies 20:24:28 bhill2: http://www.w3.org/TR/html-design-principles/#priority-of-constituencies 20:25:23 bhill2: How much of EPR should live in this group? 20:25:32 bhill2: joint deliverable with sysapps/webapps? 20:25:46 bhill2: would like to get away from the tradition of monkeypatching. 20:26:05 terri: not entirely clear how the manifest spec is working. 20:26:05 bhill2 has joined #webappsec 20:26:36 bhill2: dross, can you introduce your proposal to Marcos, et al? 20:26:50 bhill2: how would they feel about adding this to Manifest? which venue would they prefer? 20:26:54 dross: sure. 20:27:20 TOPIC: Re: Frame Ancestors and Referrer 20:27:50 bhill2: objecting generally to idea of a "none" referrer policy. 20:28:14 no 20:28:17 bhill2: does anyone else object to "none"? 20:28:27 dveditz: I have some concerns 20:28:35 dveditz: but everywhere folks rely on referrer, they're already unhappy. 20:28:50 bhill2: don't want to close it out here, if no one wants to represent that side, let's punt back to the list. 20:29:03 TOPIC: Re: [SRI] To trust or not to trust a CDN 20:29:11 http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0238.html 20:30:23 bhill2: 20:30:34 bhill2: trending towards conclusion that defense in depth is a good thing. 20:31:10 bhill2: punted the idea of applying hash source to out-of-line content. 20:31:18 bhill2: investigate for CSP vNext? 20:31:44 dveditz: SRI spec uses ni:/// syntax, why couldn't we treat those as a scheme source expression? 20:31:45 dveditz: can we use ni:// url as a construct like we do blob: or data: ? 20:32:03 dev: question is do we need to to it right now? 20:32:04 dev: do we need to do it right now? 20:32:25 dev: what is size of the policy at that point... keep adding hashes too? 20:32:35 dveditz: have to whitelist CDN, so whitelist specific path, ... 20:32:41 .. or just put the hash in 20:32:56 ... it'd be long, and icky, but if you care that's what you could do 20:33:05 jww: there is currently a way to handle all these cases 20:33:12 ... we don't need to worry about it yet 20:33:46 bhill2: does the URL production for level 2 forbid NI? 20:34:12 mkwst: fairly certain ni:// scheme could be used in a source expression and that would work 20:34:14 mkwst: ni would work as a scheme source expression 20:34:34 bhill2: just a scheme source? 20:34:46 mkwst: triple slashes would cause problems, no authority section 20:34:59 -drx-goog 20:35:16 ... only could whitelist all ni: as a scheme 20:35:51 bhill2: will create an issue to track the idea. 20:35:58 ISSUE can we produce a full ni:/// uri as a CSP source? 20:36:21 TOPIC: CfC: Mixed Content to Last Call? 20:36:28 http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0182.html 20:36:50 bhill2: there's a CfC. discussion on the mailing list. 20:36:59 bhill2: any questions for folks who like to talk and not type? 20:37:16 bhill2: note that last call means there's still room for comments. 20:37:18 why does rfc 6920 introduce '///' for ni:? 20:37:29 it's not a hierarchical scheme 20:37:49 dveditz: it can be. 20:37:59 ni://[authority]/[digest] 20:38:03 we're not using that. 20:38:08 but there's no reason we couldn't... 20:38:13 TOPIC: Minimum viable SRI 20:38:18 http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0184.html 20:39:00 ah, didn't read far enough 20:39:36 TOPIC: FYI: Starting on CSP Next. 20:39:42 http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0176.html 20:40:32 TOPIC: Do we want a way to hash data: and blob: uris? 20:40:33 not an objection, but I want to note that I was hearing a lot of hopes for SRI outside of webappsec and some of the use cases may be broken in the minimum-viable. should be interesting as we trim things down. 20:41:16 http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0171.html 20:41:27 terri: can you send a summary of those use cases? 20:42:12 bhill2: will let us know what we should focus on for next iteration. 20:42:36 bhill2: manifest. blob: data:. they want to whitelist a specific data URI in CSP without whitelisting data as a scheme. 20:42:48 bhill2: perhaps we could use hash sources for data: or blob: contents. 20:43:09 dev: ties into how do we specify ni:/// etc... presumably their use case would be solved 20:43:55 bhill2: could be simpler.... 20:44:08 dveditz: if there is hash in policy, would have to hash all data: uris? 20:45:10 ... potentially a perf hit for all script attributes 20:46:36 dveditz: would be useful, most obvious is with SRI integration 20:47:10 ISSUE explore how to identifiy specific data: uris, etc. more granular than scheme 20:47:25 dveditz: more worried about blob 20:48:04 TOPIC: ACTION-196: Remove intranet/internet section 20:48:04 from Mixed Content spec 20:48:09 TOPIC: ACTION-196: Remove intranet/internet section 20:48:09 from Mixed Content spec 20:48:15 http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0155.html 20:50:03 mkwst: would be unfortunate to let this drop on the floor, interest from Chrome in blocking access to private networks 20:50:11 ... lot of things problematic about allowing that access 20:50:20 ... more to consider than blanket restrictions than were in MIX 20:50:25 ... so not a problem to remove it from MIX 20:50:33 ... but would be a problem to remove it without a plan to resolve it. 20:50:54 terri: talking to folks about web of things there is more of a need than people realize 20:51:00 ... we can reopen perhaps? 20:52:01 bhill2: we can bring this to attention of web of things interest group 20:52:14 ... possibly get requirements or problem defintion from them 20:52:24 TOPIC: [CSP] Implementer differences: window.open 20:52:30 http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0237.html 20:53:04 kevinHill: does window.open for about:blank inherit origins? 20:53:57 mkwst: this is a bypass and I'll need to look at chrome's impl to match what FF is doing 20:54:35 -[Mozilla] 20:54:37 -jww 20:54:37 -dev 20:54:38 -[Microsoft] 20:54:38 -[IPcaller] 20:54:40 zakim, who is here? 20:54:41 -mkwst 20:54:41 On the phone I see +1.206.753.aabb, deian, gmaone, terri, tanvi 20:54:41 On IRC I see bhill2, melinda, dveditz, dwalp, dev, Zakim, RRSAgent, gmaone, tanvi, deian, schuki, Josh_Soref, tobie, timeless, mkwst___, freddyb, renoirb, terri, wseltzer, trackbot 20:54:43 -gmaone 20:54:44 -terri 20:54:45 -tanvi 20:54:47 -deian 20:54:51 zakim, [Microsoft] has KevinHill 20:54:51 sorry, bhill2, I do not recognize a party named '[Microsoft]' 20:54:59 zakim, list attendees 20:54:59 As of this point the attendees have been +1.206.876.aaaa, +1.206.753.aabb, mkwst, [IPcaller], +1.646.355.aacc, gmaone, +1.415.736.aadd, deian, terri, drx-goog, +1.415.857.aaee, 20:55:00 dev has left #webappsec 20:55:03 ... dev, dveditz, deveditz, dwalp, jww, tanvi 20:55:06 melinda has left #webappsec 20:55:08 zakim, aabb is KevinHill 20:55:08 +KevinHill; got it 20:55:23 rrsagent, make minutes 20:55:23 I have made the request to generate http://www.w3.org/2014/11/03-webappsec-minutes.html bhill2 20:55:28 rrsagent, set logs public-visible 21:05:00 disconnecting the lone participant, KevinHill, in SEC_WASWG()3:00PM 21:05:03 SEC_WASWG()3:00PM has ended 21:05:03 Attendees were +1.206.876.aaaa, +1.206.753.aabb, mkwst, [IPcaller], +1.646.355.aacc, gmaone, +1.415.736.aadd, deian, terri, drx-goog, +1.415.857.aaee, dev, dveditz, deveditz, 21:05:03 ... dwalp, jww, tanvi, KevinHill 21:15:29 i/bhill2: Origin header is mandatory for CORS./scribenick: mkwst___ 21:15:57 bhill2 has joined #webappsec 21:16:15 rrsagent, make minutes 21:16:15 I have made the request to generate http://www.w3.org/2014/11/03-webappsec-minutes.html wseltzer 21:17:40 i/dev: ties into how do we specify/scribenick: bhill2 21:17:43 rrsagent, make minutes 21:17:43 I have made the request to generate http://www.w3.org/2014/11/03-webappsec-minutes.html wseltzer 22:07:01 bhill2 has joined #webappsec 23:20:51 bhill2 has joined #webappsec 23:28:42 Zakim has left #webappsec 23:32:19 bhill2_ has joined #webappsec