15:54:15 RRSAgent has joined #webappsec 15:54:15 logging to http://www.w3.org/2012/05/02-webappsec-irc 15:54:27 zakim, this will be 92794 15:54:27 I do not see a conference matching that name scheduled within the next hour, bhill2 15:54:32 rrsagent, begin 15:54:46 hmm, looks like we may not have a reservation anyway 15:59:12 bhill2: does it mean the bridge is not available? 15:59:32 let me try again 15:59:39 zakim, this is 92974 15:59:39 sorry, bhill2, I do not see a conference named '92974' in progress or scheduled at this time 15:59:53 zakim this is 92794 16:00:00 zakim, this is 92794 16:00:17 sorry, bhill2, I do not see a conference named '92794' in progress or scheduled at this time 16:02:20 sorry folks, looks like the staff didn't get the reservation set up in time 16:02:23 bridge is unavailable 16:06:22 JeffH has joined #webappsec 16:09:17 getting a slow start today, waiting for folks to arrive in person 16:09:46 I have put in a request for the phone bridge for tomorrow, Philippe is following up. Possibility of getting it enabled later today. 16:17:18 plh has joined #webappsec 16:26:02 phone bridge should be available within the 1/2 hour 16:29:14 ekr has joined #webappsec 16:30:14 scribenick: ekr 16:30:16 abarth has joined #webappsec 16:30:39 bhill2: start installing your vms 16:30:54 zakim, list conference 16:30:54 I don't understand 'list conference', plh 16:31:00 zakim, list conferences 16:31:00 I see T&S_Track(dnt)12:00PM, XML_EXI()12:30PM, Team_(wf)16:00Z, Style_CSS FP()12:00PM, SW_RDB2RDF(TR)12:00PM, SW_RDFWG()11:00AM active 16:31:04 also scheduled at this time are IA_WebApps(F2F)9:00AM, WAI_PF()12:00PM, VB_VBWG(SCXML)12:00PM, T&S_EGOV(UseWebTech)12:00PM, SEC_WASWG()12:00PM 16:31:18 zakim, this is waswg 16:31:18 plh, I see SEC_WASWG()12:00PM in the schedule but not yet started. Perhaps you mean "this will be waswg". 16:31:23 zakim, this will be waswg 16:31:23 ok, plh; I see SEC_WASWG()12:00PM scheduled to start 31 minutes ago 16:32:57 SEC_WASWG()12:00PM has now started 16:33:04 + +1.650.693.aaaa 16:33:27 bridge is up 16:34:17 +??P15 16:34:19 zakim aaaa is bhill2 16:34:35 who just joined? 16:35:43 sorry to yank the rug, but we are headed next door to webapps to discuss last call comments for CORS 16:35:54 will be back at 10:15, and I will leave the bridge open 16:36:21 -??P15 16:38:35 jeffh: the current spec is baffling if you're not a browser implementor 16:39:18 ... I told Anne that already 16:39:36 q+ 16:40:25 oops 16:40:26 q- 16:40:47 [discussion about how to pass this information back.] 16:44:19 ekr has joined #webappsec 16:47:24 ekr has joined #webappsec 16:47:40 Scribing will be happening in webapps for now 16:48:44 + +1.858.485.aabb 16:53:17 - +1.858.485.aabb 16:55:42 dveditz has joined #webappsec 16:56:50 gopal has joined #webappsec 16:57:11 which room are you meeting in 16:57:47 gopal: the one with all the people in it 16:57:56 (didn't catch the name on the way in) 16:58:11 what happened to saturn 16:58:12 --not-- the one with the sign outside saying webapp security 16:58:20 ok 16:58:23 talking about CORS 16:58:33 joint with webapps, guess we're in their room for that 16:58:33 will be there 17:12:45 jrossi has joined #webappsec 17:17:42 ekr has joined #webappsec 17:21:54 tanvi has joined #webappsec 17:21:59 +[Microsoft] 17:28:32 abarth has joined #webappsec 17:34:46 zakim, who is here 17:34:46 bhill2, you need to end that query with '?' 17:34:50 zakim, who is here? 17:34:50 On the phone I see +1.650.693.aaaa, [Microsoft] 17:34:51 On IRC I see abarth, tanvi, jrossi, gopal, dveditz, plh, JeffH, RRSAgent, Zakim, bhill2, anne, gioma1, trackbot, bhill22, caribou 17:36:40 ekr has joined #webappsec 17:36:48 ACTION to bhill2 to integrate jeffh comments into sec considerations in CORS 17:36:48 Sorry, couldn't find user - to 17:37:01 ACTIN bhill2 to integrate jeffh comments int sec considerations in CORS 17:37:11 ACTION bhill2 to integrate jeffh comments int sec considerations in CORS 17:37:11 Created ACTION-58 - Integrate jeffh comments int sec considerations in CORS [on Brad Hill - due 2012-05-09]. 17:38:11 It seems the conference bridge's audio has stopped. 17:38:28 jrossi: we had problems with feedback 17:38:53 Ah, I see. I'm fine with just watching the IRC if you guys take good notes. :-) 17:39:09 can you hear now? 17:39:18 we can hear you 17:39:21 I think we hear you 17:39:40 next agenda item: CSP 1.0 outstanding issues 17:40:38 can you still hear us? 17:40:49 cuts out most of the time, just bits and pieces 17:40:49 we all came to microsoft's campus, where are you? ;-) 17:40:55 haha, wrong campus! 17:41:04 http://www.w3.org/2011/webappsec/track/issues/open 17:41:12 jrossi: most of us are far from the mic, we'll try to get closer when we say something substantive 17:41:18 right now there's lots of mumbling 17:41:29 that's probably it, I think noise cancellation is just kicking in since you're far away 17:41:31 abarth: I thought we resolved issue 8 a while ago 17:41:57 if *you* have noise cancellation you might try turning it off if you have a headset 17:42:03 issue 35: 17:42:05 puhley has joined #webappsec 17:42:10 that way your own noise won't cut our softer sounds off 17:42:28 i'm muted 17:42:55 dveditz: A lot of proxies will mangle this anyway 17:43:01 bhill2: this came out of IETF 17:43:25 dveditz: mozilla's solution was to have an intersecting policy 17:43:37 ... I don't think we can say don't combine this 17:43:51 abarth: if there is a comma, there is an error processing case. 17:44:09 dveditz: the proxies will just merge them anyway. 17:44:33 abarth: how shall we handle the error of the server sending multiple errors and the proxy combining them. 17:44:42 dveditz: I can see how this happens. 17:45:26 JeffH has joined #webappsec 17:46:04 [... discussion...] 17:46:14 Abarth and Dveditz suggest that comma be illegal. 17:46:24 abarth: how shall we handle it? 17:46:41 dveditz: I would prefer an intersecting policy 17:47:51 ekr: why not treat it as an ilelgal policy? 17:48:55 abarth: what should be the behavior if you get a policy without any of the known directives? 17:49:05 dveditz: shouldn't that be default source = none 17:50:44 tanvi/dveditz: why not take the most restrictive? 17:50:51 abarth: it's not clear which one it is? 17:51:00 ... and now you're into intersecting policies 17:51:09 bhill2: this text I sent is designed to create this. 17:51:16 s/create/cover/ 17:52:47 abarth: turns out that comma is forbidden but we recover 17:53:03 ... I suggest that with comma we set the policy to some invalid policy. 17:53:19 bhill2: like default src = none 17:53:35 abarth: yeah, and I would probably log in the error console. 17:54:39 ekr: how should we handle other cases where the policy is invalid, 17:54:49 abarth: e.g., directive name == backspace or dollar sign 17:55:14 abarth: currently it gets parsed as a directive name. It's illegal but causes no failure. 17:56:35 ekr: the general philosophy is that if you can make sense of it, do it? 17:57:21 abarth: it's semicolon delimited, so if I don't understand the thing in between the semicolons, then I ignore it. 17:57:37 ekr: Do we want to revisit the design decisions (a) no intersection and (b) non-restrictive default policies. 17:57:43 tanvi1 has joined #webappsec 17:58:11 dveditz: I wasn't paying that much attention before, but I would still prefer intersection 17:58:36 bhill2: the argument last time was that intersection was hard 17:58:49 dveditz: yah, it's not perfect. It does tend towards breaking the page. 17:59:12 bhill2: what about combining only policies of type src list 17:59:56 abarth: most important thing is for it to be extensible. 18:00:16 ... want to have something good I can take back to websec 18:00:33 ... can't merge on a directive by directive basis 18:01:13 ... I see policy combination as really complicated and benefit is not that large 18:01:29 dveditz: what is the proposed handling if we get a comma? 18:01:56 abarth: the thought is that since it is syntactically invalid, the policy is now default source none and print something to the debug console. 18:03:16 dveditz: seems like ignoring everything after the comma is consistent with first policy wins, but maybe we don't know which order the proxies assemble the headers in 18:03:50 ekr: right, but this means that a bad policy is ultra-dangerous as opposed to breaking everything 18:04:01 bhill2: philosophy has always been that this is a safety belt 18:05:08 abarth: we find that when people deploy CSP, they find that there aren't a lot of violations and so they aren't sure policy is running. 18:05:32 ... I would like to have some way to ask it. 18:06:32 bhill2: what if there is some proxy elsewhere. 18:07:57 ekr: what if there are multiple proxies? This makes it very dangerous... 18:08:13 abarth: do proxies like this really exist? 18:08:41 tanvi: so if we have two headers right now we do nothing? 18:09:05 tanvi: the other thing about intersecting policies is if we have meta tag and policy URI we might have to deal with this. 18:09:13 abarth: meta tag used to be trumped by header 18:09:53 abarth: something else I want to talk about for 1.1--there is a use case to modify policy at run time. It's delicate to do that in a good way 18:10:11 bhill2: how he handle combination logic, then this impacts how things behave in the future 18:10:40 ... in the future, we are going to have proxies which do CSP injection, then this won't work with any future meta tag 18:11:11 abarth: maybe say you must only send one policy and then if you receive two you fail in some obnoxious way. 18:11:33 and if we add a new way to get policies we specify a combination mechanism then. 18:12:23 bhill2: this still leaves it open how people who do want to do policy injection. We should give them some advice. 18:12:32 abarth: those people are more able to adapt. 18:13:24 bhill2: well, WAFs don't adapt much 18:13:59 ekr: well, the reason we didn't do it was because it was hard. If these guys want to try it, then good for them, but we don't have to 18:14:21 abarth: my current proposal {two policies, comma in header} --> enforce default src=none 18:14:45 bhilll2: so no meta tag? 18:15:06 ... may need to discuss it later 18:15:18 s/may need to discuss it/it's on the agenda/ 18:15:31 bhill2: is now a good time to discuss the meta tag for 1.0? 18:15:39 plh has left #webappsec 18:15:43 abarth: I think we should talk about that in 1.1 18:15:51 ... it's related to other things in 1.1 18:16:39 bhill2: the question of meta in 1.0 has to be on our agenda. shall we revisit it now because it may impact the combination logic. 18:16:43 dveditz: how so? 18:16:52 +??P1 18:16:59 ... other headers with meta tags have had the header override the meta tag 18:17:26 -??P1 18:17:29 tanvi: what if we forbid duplication now and then specify merging in 1.1? 18:17:37 travis: historically don't meta tags trump headers 18:17:45 dveditz: tuypically the other way around 18:18:08 travis: from a security perspective, that seems ok, but practiclaly don't you want the opposite 18:18:16 abarth: that's just the way the web is even if it's backwards 18:18:29 travis: well, in some cases IE does that 18:18:47 dveditz: it's a matter of who wants what -- web pae authors versus site operators 18:19:29 travis: personally I want to not see meta tags in 1.0 so we finish 18:19:33 http://www.w3.org/2011/webappsec/track/issues/open 18:19:50 taking a break till 11:30 18:24:27 abarth has joined #webappsec 18:25:17 http://www.w3.org/TR/CSP/ 18:25:41 Travis has joined #webappsec 18:26:15 tanvi has joined #webappsec 18:29:36 ekr has joined #webappsec 18:29:52 we are back 18:30:37 topic is ISSUE #8 18:32:36 balance between the user's preferences and the site authors 18:33:31 dveditz: both user and site operator are concerned about attacks and the user can always override the site's preferences as a technical matter 18:33:51 abarth: my sense is that we agree about principles, and the details are a matter of the implementations which vary anyway 18:34:10 dveditz: if the UA lets the user add extensions, we are still respecting CSP in a reasonable way. 18:34:58 abarth: I view the current text as sort of aspirational. 18:35:24 ... as an example, in Chrome a content script can load images from its own extension package regardless of CSP 18:35:51 ekr: I propose we mark this closed and move onto meta and sandbox 18:36:05 bhill2: we have requests from a bunch of people to restore the meta tag 18:36:30 ... my summary is that there are a lot of site admins who can't set headers but would like to use CSP 18:36:46 ... so this is worth the risk 18:37:34 abarth: my sense is that this interacts with CSP 1.1 proposed features such as the ability to query policy 18:38:04 dveditz: I'm much more concerned with a DOM API to set policy than I am about a meta tag 18:38:23 abarth: is there anyone who thinks this should be in 1.0? 18:38:35 tanvi:we'll need to discuss anyway 18:39:04 dveditz: one concern about injectable policy via meta is leak via reporting. maybe add same origin requirement for reports in meta 18:39:19 ... would also like to restrict meta to HEAD 18:39:58 abarth: how would you feel if we restricted meta tag to HEAD. How would you feel if someone injected it later? 18:40:03 dveditz: I think that's cheating 18:40:27 abarth: so only if it's in head and available at the start. 18:40:35 ... example is gmail 18:41:19 dveditz: what if I had a meta tag that said "allow deferred DOM API CSP injection later" 18:42:01 bhill: use cases is restrictive server environments 18:42:19 ... maybe these use cases can't meaningfully consume reports anyway 18:43:31 dveditz: might be willing to stick to simplest sue cases 18:43:37 s/sue/use/ 18:43:58 tanvi: what would requirements be: meta tag == no report, meta tag must be in HEAD, must be no header 18:44:09 abarth: + must be inserted by parser 18:45:21 [discussion about what 'inserted by parser'] 18:45:23 + +1.858.485.aacc 18:46:51 [discussion about what we are trying to achieve by restricting this?] 18:47:05 bhill2: if you can inject script then it's game over 18:47:17 ... I'm not sure there is any reason to restrict it from being added by script 18:47:17 +??P2 18:49:06 dveditz: the spec should just recommend that it go early. 18:49:56 bhill2: if you screw up before the meta, you're on your own 18:50:07 dveditz: want same origin reports 18:50:23 tanvi: don't want same origin reports--encourage people to use header instead of meta tag 18:51:47 bhill2: if you're only able to run static comment anyway 18:51:55 ... how many scenarios is this relevant for? 18:52:31 tanvi: the only places this is really going to happen are corp environments and those people should go talk to their admins 18:52:35 abarth: my notes say 18:53:02 Bringing back the tag, 18:53:02 Must be in the 18:53:04 Header trumps tag 18:53:05 First tags wins 18:53:06 report-uri doesn’t work 18:53:07 Guidance that delaying the header isn’t wise 18:54:40 dveditz: meta must come through parser. 18:54:56 bhill2: what's the security benefit here? All you can do is inject a new policy? 18:55:50 abarth: my preference is to not care how the data is inserted. 18:56:14 abarth: suggestion is to use no insertion after ready state. 18:57:46 Zakim: ??P2 is gioma1 18:58:16 ekr: what's the security reason for this? 18:58:31 bhill2: It seems like an implementation simplification 18:58:37 ekr: ok 19:01:32 - +1.858.485.aacc 19:02:41 abarth has joined #webappsec 19:03:33 -[Microsoft] 19:04:10 ekr has joined #webappsec 19:20:30 ekr has joined #webappsec 19:23:45 topic: should we have meta in 1.0 or not? 19:24:00 nobody in room wants it in 1.0. people on list have requested ti 19:24:14 dveditz: we are probably closer to meta than sandboz 19:24:25 bhill2: if all implementors agree they don't want to do meta in 1.0 19:25:02 ... then it doesn't need to be in 1.0 spec. by comparison, sandbox has some implementation. but no implementations, then meta loses... 19:25:35 tanvi: just because it's not in 1.0 doesn't mean people don't do it 19:25:43 abarth: my plan is to ahve it with a prefix 19:27:11 resolved: meta will be in 1.1 due to lack of implementor support for having it in 1.0. we will attempt to specify it early in 1.1. 19:27:36 tanvi has joined #webappsec 19:28:25 what happened with onload vs inserted by the parser. i believe we decided the policy should be set onload? or did we decide not to specify that 19:29:06 bhill2: anyone want to revisit consensus on sandbox. We had interest from implementors on doing it, and we're going to re-check implementation status at CR...? 19:29:09 abarth was going to use wording along the lines of "before document readystate" 19:31:11 does microsoft have the full csp 1.0 implemented? 19:33:54 abarth: can we have a feature that we may drop if we do not have two implementations? 19:34:02 philippe: you need to mark it as "at risk" 19:35:53 philippe: if you mark it as at risk, you don't need to recycle to LCWD if you drop it. 19:38:34 proposed resolution: we mark this at risk and then if we don't have two implementations, it gets dropped. 19:41:02 bhill2: can MS live with having this in 1.1? 19:41:21 travis: main concern is that it not just look like a MS feature 19:41:52 bhill2: jacob is willing to specify this 19:42:24 abarth: we outsource parsing to HTML5 19:42:57 dveditz: what if HTML5 changes? 19:43:04 abarth: they need to retain backcompat 19:43:36 bhill2: propose that we punt this to 1.1 since MS won't have a complete implementation anyway. Then we can move to LC soon. 19:43:47 ... will raise on list 19:43:59 action: abarth to create 1.1 impl by end of week 19:43:59 Created ACTION-59 - Create 1.1 impl by end of week [on Adam Barth - due 2012-05-09]. 19:45:40 resolved: we will punt Sandbox to 1.1 pending approval on list. 19:46:55 dveditz: what about future compatibility for more specific policies, e.g., src lists that specify directories 19:47:21 ... if we come up with a compatible syntax now. 19:47:49 abarth: proposal, allow full URLs but truncate to the origin. 19:50:01 script-src http://example.com http://foo.com/bar/qux 19:50:40 dveditz: if someone types in https://www.google.com/ that is ignored because of trailing slash 19:50:42 script-src 'self' http://dev1.addons.phx1.mozilla.com https://addons-dev-cdn.allizom.org/ 19:53:10 proposal: allow urls, and truncate them to the origin. 19:54:20 this ends up whitelisting an entire origin, when perhaps you just want to whitelist a path. 19:54:27 so perhaps we shoudl version cps? 19:54:31 *csp? 19:54:57 script-src and scipt-src-path 19:56:56 we could add a version to the specified policy. if the version =1.1, then allow paths in sources. if the version is 1.0, then ignore sources with paths. 19:57:31 choices appear to be a) version CSP header, b) duplicate directives in the future, c) degredation of hosts with paths 19:58:16 a) means two headers always. CSP2 clients need to look for both headers, sites may just leave CSP1 clients insecure 19:58:41 b) pretty much the same on a directive level -- either duplicate, or leave CSP1.0 clients as insecure as non-CSP clients 20:05:06 action: dveditz to write a message to the mailing list describing his proposal for how to handle URLs with paths (truncate to the origin) 20:05:06 Created ACTION-60 - Write a message to the mailing list describing his proposal for how to handle URLs with paths (truncate to the origin) [on Daniel Veditz - due 2012-05-09]. 20:05:56 dveditz: people also want to be able to specify plugins by media type. E.g,, flash but no java 20:13:32 action: abarth to merge bhill's policy combination text into the CSP document 20:13:32 Created ACTION-61 - Merge bhill's policy combination text into the CSP document [on Adam Barth - due 2012-05-09]. 20:14:49 http://www.w3.org/Security/wiki/Content_Security_Policy 20:15:01 https://mikewest.org/2012/05/content-security-policy-feature-detection 20:21:38 are you people talking about clickjacking? I heard "...ckjacking" but it's all silence and some word here and here on the SIP bridge :( 20:25:22 jrossi1 has joined #webappsec 20:28:17 talking about CSP 1.1 propsed features right now 20:28:25 I will try to turn up the microphone 20:28:51 i believe the anti-clickjacking discussion is tomorrow 20:30:39 http://lists.w3.org/Archives/Public/public-webappsec/2011Dec/0016.html 20:43:26 Topic: CSP access API? 20:43:31 http://www.w3.org/Security/wiki/Content_Security_Policy#Proposals_for_Version_1.1 20:44:43 peleus: what happens if you try to eval() with SCP 20:44:45 CSP 20:45:04 abarth: throw a security exception 20:45:38 abarth: why is this useful? Avoid reporting errors for feature tests 20:46:58 Topic: frame-ancestor or frame-options 20:47:16 abarth: maybe we can get this back in 20:49:33 jeffh: now is a good time to participate in websec 20:49:50 abarth: maybe it should be possible for IETF documents to specify CSP directives 20:50:45 i have a couple of potential additions i'd like to bring up 20:50:49 bhill2: two ways to look at the world. (1). Anything new is CSP 1.1. (2) anything that changes how things work is CSP 1.1 and anything else is just new directives 20:50:57 tanvi: you have access to the wiki? 20:51:20 I just added some stuff 20:51:34 sure, i'll do that 20:53:44 added 20:53:58 topic: script-hash 20:54:05 peleus: this seem like it's a maintainability issue 20:54:11 dveditz: this starts to get pretty long 20:54:40 ... what about policy-uri? 20:55:26 this way you could imbed third party script that you trust (ex: facebook like widget) and know that if facebooks servers gets compromised, the hash won't match and your page won't be vulnerable 20:55:35 (regarding script-hash) 20:57:37 tanvi1 has joined #webappsec 20:57:53 script-src http://google-analytics.com [###]. so only http://www.google-analytics.com/ga.jsworks, and nothing else from google-analytics works. 20:58:47 tanvi has joined #webappsec 21:00:10 topic: no-user-js 21:00:22 tanvi: idea to prevent against self-xss. 21:00:28 no longer allow js: in address bar 21:00:46 but you could still get people to do "open" 21:01:33 idea would be to require special to activate the web console in these cases (where policy is provided) 21:02:04 dveditz: not sure how serious this is.... it is for fb and twitter 21:02:32 really only applies to a subset of sites. 21:03:13 ekr: this is a social engineering question 21:03:38 dveditz: interesting idea but not sure I want to jump right in on it. 21:04:58 next topic: restrict script to sources with specific content types 21:05:39 peleus: this causes a lot of problems 21:06:00 tanvi: idea here is to restrict scripts to a specific set of content-types 21:07:40 abarth: historically, this has been something people have ignored, so there will be a lot of collateral damage 21:08:01 ... having it be opt-in 21:08:20 ekr: you could have the white-list in the directive 21:08:30 abarth: etter to ahve it be binary 21:09:04 topic: form-action 21:10:19 bhill2: HTML5 makes form tag injection easier 21:11:38 abarth: this seems like it would help defend agains that and be within the scope of the kind of stuff we have done 21:11:45 topic: plugin-types 21:11:54 dveditz: syntax seems complicated 21:11:58 ... argue about it later 21:12:15 abarth: seamless with parent 21:12:36 ... iframe can resized like a div. 21:13:38 ... right now it's single origin 21:13:51 ... might be nice to have a directive that allows it even without same origin 21:14:04 ekr: this seems like it's conceptually new since it's not a restriction 21:14:13 travis: IE already allows iframe resizing 21:14:18 abarth: this is a little different 21:15:02 ... put it here so the group is aware of it. not sure where it goes 21:15:47 topic: jsonp with padding 21:16:10 bhill2: a lot of people want to have safe JSONP 21:16:28 ... jsonp-src : a list of domains 21:16:38 ... jsonp-sink: a list of safe function names 21:16:52 ... idea is that you could apply it to existing legacy code 21:23:17 bhill2: two objections from lcamtuf: (1) this doesn't solve jsonp being interpreted as scripts (2) it may not actually permit a lot of valid jsonp 21:24:12 ekr: this seems like a good idea, but not sure it can be made to work 21:25:35 abarth: I had one more... meta-referrer 21:26:54 finally, more granular origin list 21:28:25 tanvi: who has implemented meta tag for referer? 21:29:13 dveditz: should this be a meta tag? separate or in csp? 21:29:27 abarth: this feels like a policy thing 21:29:54 dveditz: I agree with that for things that are specified as headers.... 21:31:24 Morton has joined #webappsec 21:31:45 bhill: distinction between proposals that rev the spec and proposals that add new directives 21:33:36 bhill: what are examples of reving the spec? policy-uri, more granular origins 21:34:35 abarth is currently modifying the page to divide between experimental and proposals for 1.1 21:36:21 abarth: excited about form action 21:37:08 abarth: plugin types might be a good one 21:37:24 bhill2: negative plugin tyes? 21:45:18 abarth has joined #webappsec 22:07:13 rrsagent, create minutes 22:07:13 I have made the request to generate http://www.w3.org/2012/05/02-webappsec-minutes.html ekr 22:07:54 rrsagent, make public 22:07:54 I'm logging. I don't understand 'make public', ekr. Try /msg RRSAgent help 22:08:28 RRSAgent, please make logs world-visible 22:17:12 mkwst has joined #webappsec 22:20:49 https://trac.webkit.org/browser/trunk/LayoutTests/http/tests/security/contentSecurityPolicy 22:27:37 tanvi1 has joined #webappsec 22:27:58 tanvi1 has joined #webappsec 22:28:11 tanvi1 has joined #webappsec 22:28:25 tanvi has joined #webappsec 22:32:00 Peleus has joined #webappsec 22:51:07 -??P2 22:54:08 puhley has joined #webappsec 23:19:32 ekr has joined #webappsec 23:26:15 Hope your VM is up 23:26:28 please switch to branch testJam 23:26:45 and add your tests on this branch 23:57:49 tanvi1 has joined #webappsec 23:58:05 - +1.650.693.aaaa 23:58:06 SEC_WASWG()12:00PM has ended 23:58:06 Attendees were +1.650.693.aaaa, +1.858.485.aabb, [Microsoft], +1.858.485.aacc