01:00:20 sicking has joined #webappsec 01:05:01 gopal has joined #webappsec 07:16:33 bhill2 has joined #webappsec 07:17:55 Zakim has joined #webappsec 07:18:10 zakim, this is 92794, you little bastard 07:18:11 sorry, bhill2, I do not see a conference named '92794, you little bastard' in progress or scheduled at this time 07:18:18 zakim, this is 92794 07:18:18 bhill2, I see SEC_WASWG(TPACSES)3:30AM in the schedule but not yet started. Perhaps you mean "this will be 92794". 07:18:29 fuck you, zakim 07:18:37 zakim, this will be 92794 07:18:37 ok, bhill2; I see SEC_WASWG(TPACSES)3:30AM scheduled to start in 12 minutes 07:18:48 zakim, call St_Clair_2 07:18:48 ok, bhill2; the call is being made 07:19:51 zakim, call St_Clair_2 07:19:51 ok, bhill2; the call is being made 07:20:28 bhill2 has left #webappsec 07:20:35 bhill2 has joined #webappsec 07:23:22 zakim, call St_Clair_2 07:23:22 ok, bhill2; the call is being made 07:23:23 SEC_WASWG(TPACSES)3:30AM has now started 07:23:23 +Dialer 07:23:24 -Dialer 07:23:25 +St_Clair_2 07:32:27 Meeting: WebAppSec Face to Face, Day 2, TPAC, 2-Nov-2012 07:32:32 Chairs: bhill2, ekr 07:32:40 Agenda: http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0090.html 07:34:00 dveditz has joined #webappsec 07:34:57 suggested background reading for first agenda topic: http://lists.w3.org/Archives/Public/public-webappsec/2012Sep/0011.html 07:36:31 https://github.com/eoftedal/csp-testing 07:39:43 DanD has joined #webappsec 07:46:56 ware has joined #webappsec 07:48:27 mkwst has joined #webappsec 07:49:20 sburr has joined #webappsec 07:49:29 puhley has joined #webappsec 07:49:44 bhill2: when are implementers turning on un-prefixed header 07:50:04 dveditz: hope is to get it turned on for this release cycle, ~3 months to release 07:50:28 dveditz: be in beta channels earlier, and some fixed for spec compliance needed 07:51:06 ttanaka2 has joined #webappsec 07:53:27 bhill2: We just landed the unprefixed header in WebKit yesterday. I'd expect it to hit Chrome 25; so also ~12 weeks away. (I'll join the call in just a bit; just walked in the door) 07:54:14 We also expect some bugfixing to be necessary as it goes through dev/beta, but hopefully nothing major. 07:54:40 are you dialed-in, Mike? 07:54:45 Just about to be. 07:54:46 scribe: puhley 07:55:13 bradee-oh has joined #webappsec 07:55:45 bhill: Art discussing joint meeting with WebApp WG in Silicon Valley. 07:56:11 bhill: Not sure if there is enough work for a full 1-2 day workshop. 07:57:04 dveditz: Mozilla is still working on test cases for CSP. Currently, built-into the Firefox build process. 07:58:06 ACTION: bhill2 to propose testing day as part of joint HTML/WebApps/WebAppSec F2F in silicon valley to list 07:58:06 Created ACTION-91 - Propose testing day as part of joint HTML/WebApps/WebAppSec F2F in silicon valley to list [on Brad Hill - due 2012-11-09]. 07:59:06 +??P0 07:59:14 bhill: We need to identify where more test cases are needed beyond erlend's proposed cases. 08:00:35 mwest: We have layout tests. HTML files that are potentially usable in the W3C style. Most of the tests are currently doing console logging versus JS logging. 08:01:03 bhill: Might be able to write server-side code to work around the issue. 08:01:35 http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/security/contentSecurityPolicy/ are the current tests. 08:01:43 mwest: Some Perl scripts to verify report was generated. 08:02:25 mwest: They rely on the fact the entire render tree is dumped and need work to make them JS compatible. 08:02:46 mwest: Volunteers to be test coordinator. 08:04:13 mwest: May be able to attend Silicon Valley meet-up with HTML WebApp WG if we set one up with advanced notice. 08:05:33 mwest: Erland's test suite focuses on the core functionality around "-src" policies. No testing around properties like sandbox. 08:06:25 ekr has joined #webappsec 08:06:41 mwest: WebKit probably has some test cases on sandbox and report-uri. They don't have a really thorough test suite for ensuring sandbox works for all possible variants. 08:07:05 bhill: Perhaps we should ask Microsoft to see if they have test cases they can donate. 08:07:59 ACTION: jrossi to inquire about Microsoft test cases for sandbox directive to contribute to W3C 08:07:59 Sorry, couldn't find jrossi. You can review and register nicknames at . 08:09:30 bhill: Official go ahead from W3C to publish CSP 1.0 as candidate req on the 6th. 08:09:58 bhill: We want to get CSP 1.1 to first public working draft. 08:10:22 mwest: CSP 1.1 is ready for first public working draft. 08:10:22 https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html 08:10:52 mwest: New CSP 1.1 features are as follows: 08:11:19 mwest: First new item is meta implementation to allow CSPs in Meta tag. 08:11:32 mwest: Implemented in WebKit and roughly stable. 08:12:59 dveditz: sandbox is about that resource being used from somewhere else. 08:13:15 dveditz: ui-safety is more of an outgoing policy 08:13:46 dveditz: sandbox might difficult to support in a meta tag. 08:14:23 dveditz: need to know some things before renderring. 08:14:50 http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx 08:14:51 mwest: You wouldn't be able to block the entire load of the page but you could stop the process before something interesting happens. 08:15:07 tanvi has joined #webappsec 08:15:23 http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/dom/Document.cpp&exact_package=chromium&q=x-frame-options&type=cs&l=2956 <-- x-frame-options inside a document's meta tag. 08:15:29 bhill: X-Frame-Options is ignored in the meta tag 08:16:32 mwest: We should describe in the non-normative section of the spec where there will be variants in the behavior when the field is supplied in the meta tag. 08:16:52 mwest: Will bring the options for putting that in the spec to the mailing list. 08:17:09 ACTION: mkwest to propose changes to the list about making some directives optional to support in the META tag 08:17:09 Sorry, couldn't find mkwest. You can review and register nicknames at . 08:18:37 dveditz: Does the spec require meta tags to be in the head of the document? 08:19:13 mwest: It is listed as a to-do in the spec but it is their. 08:19:35 mwest: Policies are ignored once the document has reached a ready state. 08:20:03 tanvi: Does it need to be before head tags such as CSS which include JavaScript. 08:20:28 mwest: OK with making it a requirement that it needs to be the first entry in the head tag. 08:21:13 mwest - charset should go before/after the meta tag? 08:23:01 mwest: Google in process of trying to get some company properties to use CSP but it is a difficult transition. Need to support use case where meta tag can be used after a load event but before asynchronous interactions. 08:23:06 tanvi: probably after, since the charset could theoretically impact the way the policy is interpreted. 08:23:59 ISSUE: how to address dynamic application of CSP post page load / partial page load via META or script interface 08:23:59 Created ISSUE-30 - How to address dynamic application of CSP post page load / partial page load via META or script interface ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/30/edit . 08:24:00 mwest: Scripting interface is read-only but it has been proposed to allow JavaScript to modify the policy. 08:25:04 mwest: Next experimental feature is to allow paths in rules. 08:25:52 bhill: Is currently non-normative instead of experimental. 08:27:14 bhill: W3C is currently debating URI parsing. May need to cross-reference with their work. 08:28:16 dveditz: Does the spec explicitly require hierarchical schemes. 08:28:27 mwest: Not at the moment. Only specifies schemes: 08:29:01 dveditz: May need to address schemes with slashes. 08:29:23 mwest: Curent spec doesn't allow for that use case. 08:29:54 Current 1.1 spec references http://tools.ietf.org/html/rfc3986#section-3.1 which defines schemes as `ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )`. 08:32:40 ISSUE: what specification's definition of URL/URI are we using for path parsing in CSP 1.1? 08:32:41 Created ISSUE-31 - What specification's definition of URL/URI are we using for path parsing in CSP 1.1? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/31/edit . 08:33:34 ISSUE: do we specify that path-specificity applies only to hierarchical URI schemes? 08:33:34 Created ISSUE-32 - Do we specify that path-specificity applies only to hierarchical URI schemes? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/32/edit . 08:34:47 bhill: CSP spec should specific enough that it can be consistent across all browsers. 08:35:00 bhill: (with regards to URI parsing) 08:35:33 wei has joined #webappsec 08:35:58 mwest: Parsing a URI for CSP is already different than how normal URLs are parsed in general. 08:36:32 rfc 3986 defines paths as part of URLs that have a hier-part 08:37:00 Wu has joined #Webappsec 08:38:39 dveditz: if it starts with two slashes its hierarchical, and if it doesn't than it isn't. for csp we probably don't deal with exotic types, so could just reference rfc 3986. 08:39:18 dveditz: we have blob and other things that are standard but not hierarchical. what do we do if we want to block those or not block those. 1.0 spec doesn't really address them, they are just allowed 08:39:51 mwest: webkit taking position that they are the same as 'self' and allowed when 'self' is allowed. since only created and accessible within context of an origin 08:40:06 we should address it in the 1.1 spec, so consistent across implementors 08:40:34 ISSUE: need to address blob, data, filesystem URL types with greater specificity in CSP 1.1 spec 08:40:35 Created ISSUE-33 - Need to address blob, data, filesystem URL types with greater specificity in CSP 1.1 spec ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/33/edit . 08:40:52 mwest - file system api. sandboxed file system associated with an origin (like indexeddb). In webkit 08:41:13 ACTION: dveditz to propose spec text to resolve ISSUE-32 08:41:13 Created ACTION-92 - Propose spec text to resolve ISSUE-32 [on Daniel Veditz - due 2012-11-09]. 08:42:48 mwest: Currently not saying anything about queries but we could say that we are explicitly ignoring queries. 08:43:13 mwest: WebKit is throwing a warning that queries aren't accepted in source expressions and are being ignored. 08:43:25 mwest: Worth noting in the spec explicitly. 08:44:55 ACTION: mkwst to clarify CSP 1.1 spec text to make handling of query strings in source expressions explicit 08:44:55 Sorry, couldn't find mkwst. You can review and register nicknames at . 08:45:19 mwest2. :) 08:47:34 mwest: Next new feature in 1.1 is: script interfaces which allows read of the union of the content security policies in effect. 08:48:06 mwest: Some discussion about whether there should be write compatibilities. WebKit has read-only in Canary and Dev version of Chrome. 08:48:15 Wu has joined #Webappsec 08:49:32 mwest: No known use case for allowing the read of the report-uri 08:50:02 dbaron has joined #webappsec 08:50:56 bhill: If unique report-uris are created for each instance, then an XSS issue could be used to spam the report-uri to hide attacks. 08:51:32 mwest: Should assume that report-uri is public. That said, no known value in exposing to JavaScript. 08:52:06 bhill: Send email to the list to see if anyone is concerned with dropping it. 08:52:26 ACTION: mwest2 to query list if any use cases for reportURIs script interface 08:52:26 Created ACTION-93 - Query list if any use cases for reportURIs script interface [on Mike West - due 2012-11-09]. 08:54:15 puhley: Depends on whether per-session data in the report-uri to help refine log correlation on attacks. 08:55:05 dveditz: Would custom extension changes be reported in the report? 08:56:12 mwest: Yes. WebKit makes sure reports go to the URI that is associated with the specific policy that is being violated in the case of multiple policies. 08:57:28 mwest: Not sure if there is a good way to distinguish policies from the page and policy changes by extension. 08:59:00 mwest: Use case for script detection of policies is so that a page can determine whether eval is allowed. 08:59:53 Specifically, the request came from Angular, which has two implementations of templates: one without eval, and one with eval (which is more performant). They'd like to be able to hop between them. 09:00:57 dveditz: There are concerns about privacy implications regarding detecting the end-user's environment and extensions. 09:01:44 dveditz: Perhaps make it a request method rather than a read approach where you get the entire string. 09:02:18 mwest: It is currently request-orientated. 09:03:20 mwest: I am open to further discussion regarding how much information needs to provided to JavaScript. 09:04:33 mwest - drop uri from the spec right now. we can discuss whether adding it back is a good idea later. 09:04:48 ISSUE: discuss use cases / risks of script access to CSP information, solicit specific public comment on this feature with FPWD 09:04:49 Created ISSUE-34 - Discuss use cases / risks of script access to CSP information, solicit specific public comment on this feature with FPWD ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/34/edit . 09:04:50 mwest - rest we can leave in for the FPWD and solicit use cases 09:05:42 dveditz - one use it find out if anything in a user agent will block a load because of csp 09:06:02 dveditz - not because of adblock or anything else. just on csp blocking the load 09:06:52 s/one use it/one use case is to/ 09:07:06 ACTION: mwest2 to add specificity to CSP 1.1 draft that script access queries ONLY state of CSP, not general reachability of URLs by configured browser context 09:07:06 Created ACTION-94 - Add specificity to CSP 1.1 draft that script access queries ONLY state of CSP, not general reachability of URLs by configured browser context [on Mike West - due 2012-11-09]. 09:07:32 dveditz - at mozilla we probably wouldn't want to report what extension supplied csp's say. 09:07:47 tanvi - that could be tricky 09:08:16 mwest: Could allow for an http-only style policy for whether the policy is avialable to JavaScript 09:08:30 I have made the request to generate http://www.w3.org/2012/11/02-webappsec-minutes.html odinho_ 09:08:36 Present+ Odin_Hoerthe_Omdal 09:08:47 ISSUE: should we add an "httpOnly" like directive to CSP to indicate that the state of this policy is not available to the script APIs? 09:08:47 Created ISSUE-35 - Should we add an "httpOnly" like directive to CSP to indicate that the state of this policy is not available to the script APIs? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/35/edit . 09:11:46 dveditz: Jonas suggested that perhaps directives such as font-src should default to style-src instead of default-src when not specified. He will write an email to the list. 09:12:30 mwest: Next new directive is form-action which restricts the URIs can be used as the action of form-elements. Experimental version in Dev and Canary of Chrome but not well tested. 09:12:49 tanvi: What if you want to restrict to just HTTPS URI? 09:13:03 mwest: Should be able to specify similar to any other directive. 09:15:20 group agrees their isn't much value in restricting the form method with CSP. 09:15:27 s/their/there/ 09:18:09 Group agrees there isn't much value in restricting the mime-type 09:18:37 bhill: Is there value in restricting the scheme such as no mailto: in forms? 09:18:45 dveditz - should form-action fall back to default-src? maybe not. 09:19:22 in fact I'd say almost certainly not -- pages that work fine with CSP 1.0 will break in 1.1 09:19:33 if we say the new form-action falls back to default-src 09:19:59 ah yes, that is true 09:20:06 I was suggesting that the spec should be clear that form-action does NOT fall back 09:22:02 i/bhill2: when are implementers/Topic: CSP 1.0 09:22:04 ACTION: mwest2 to correct "font-src" typo in the form-action text of CSP 1.1 09:22:04 Created ACTION-95 - Correct "font-src" typo in the form-action text of CSP 1.1 [on Mike West - due 2012-11-09]. 09:22:30 ACTION: mwest2 to add note clarifying that form-action is not subject to default-src fallback 09:22:30 Created ACTION-96 - Add note clarifying that form-action is not subject to default-src fallback [on Mike West - due 2012-11-09]. 09:22:41 Group questions whether there is value to restrict the schemes due to the fact that there are specs for sites to self-register schemes. This may be an issue for 1.2 instead of 1.1 when more information on those specs is available. 09:23:35 Present odinho ekr bhill tanvi puhley DanD dveditz dbaron mkwst 09:24:15 bhill: Next 1.1 feature is that sandbox is now mandatory for compliance with 1.1 in a user agent. 09:24:41 Present+ ware bradee 09:26:07 mwest: Next 1.1 feature is script-nonce. Nonce is supplied by the server. Script is only allowed if the script has the nonce, unsafe-inline is allowed and/or script-src matches. 09:27:21 mwest: Allows whitelisting of inline scripts while still trying to protect against injected script when unsafe-inline is specified. 09:28:08 mwest: Assumes that the attacker can't predict the nonce. 09:28:33 i/mwest: CSP 1.1 is ready/Topic: CSP 1.1 09:28:43 tanvi: XSS in white-listed js code could bypass the mechanism. 09:29:23 I have made the request to generate http://www.w3.org/2012/11/02-webappsec-minutes.html odinho_ 09:30:13 ekr - maybe include an indicator that determines whether this applies to inline scripts or included scripts 09:30:21 or both 09:31:09 ACTION: ekr to make concrete suggestion to list on allowing script-nonce to apply selectively to inline vs src= scripts 09:31:09 Sorry, couldn't find ekr. You can review and register nicknames at . 09:31:35 ekr - coudl combine with script-hash. script-hash becomes script-mac where its keyed with the nonce 09:31:58 s/coudl/could 09:32:42 ISSUE: are we interested in considering script-hash as a CSP 1.1 directive? 09:32:43 Created ISSUE-36 - Are we interested in considering script-hash as a CSP 1.1 directive? ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/36/edit . 09:32:50 how solid is the assertion that the attacker can't figure out the hash. only as solid as the implementation. 09:33:39 Present+ odinho ekr bhill tanvi puhley DanD dveditz dbaron mkwst 09:33:49 mwest: Nonce randomness protection is determined by the server implementation. 09:36:29 mwest: Last 1.1. feature is plugin-types which limits the types of resources which can be embedded. There needs to be more discussion about how this will work in every browser due to IE ClassID mechanism vs the mime-type approach. 09:40:06 ACTION: jrossi to propose spec text for MSIE plugin implementation of plugin-types directive (e.g. with CLSID vs. MIME types) 09:40:06 Sorry, couldn't find jrossi. You can review and register nicknames at . 09:40:19 plugin-types - issue with mime types and classids. how should this be handled? question for microsoft. discussed an internal mapping from mime-type to classid, but this wouldn't work for all mime-types (ex: custom corporate plugin woudln't be in the generic mapping) 09:40:21 Present- Odin_Hoerthe_Omdal 09:40:30 s/woudln't/wouldn't 09:40:34 I have made the request to generate http://www.w3.org/2012/11/02-webappsec-minutes.html odinho_ 09:42:17 puhley: How would an iframe be handled whose src points directly to plugin content. 09:43:03 ISSUE: how to apply plugin-types in CSP 1.1 to iframes 09:43:03 Created ISSUE-37 - How to apply plugin-types in CSP 1.1 to iframes ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/37/edit . 09:45:54 mwest: May not be an issue due to same-origin policy enforcement on the content. 09:47:13 tanvi - without iframe, could end up having a vulnerable plugin type included. perhaps not worried about xss but dont want to include vulnerable plugins. 09:47:21 http://www.w3.org/Security/wiki/Content_Security_Policy 09:49:27 tanvi: May be worth discussing bringing back policy-uri in 1.1. Firefox has support for it. 09:51:22 mwest: OK with adding it as an experimental item for 1.1 09:51:45 dveditz: Spec should specify when policy-uri is appropriate and when it is not. 09:51:52 ACTION dveditz to propose spec language for policy-uri directive 09:51:53 Created ACTION-97 - Propose spec language for policy-uri directive [on Daniel Veditz - due 2012-11-09]. 09:53:13 tanvi: Should we look at script-hash? 09:53:54 bhill: Need a decent way to implement it. We haven't figured that out yet. 09:54:05 bhill2 - should we restrict to just the script? what about the headers? 09:55:45 tanvi: What about mixed-content restrictions? It could help websites prevent a bad user experience from accidental mixed-content warnings. 09:56:17 dveditz: Could partially fake it with the https restrictions. 09:57:00 ekr: Browsers are already partially solving this, as well. 09:57:13 tanvi: This is only for active content and not display content. 09:57:51 bhill: We can definitely discuss this further 09:58:02 ISSUE: discuss no-mixed-content further as a 1.1 experimental directive 09:58:02 Created ISSUE-38 - Discuss no-mixed-content further as a 1.1 experimental directive ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/38/edit . 09:58:31 bhill: What about JSONP-Src and JSONP-Sync? 09:59:41 tanvi - browser only block mixed active content. not mixed display content. we wouldn't be able to distinguish between the two with the directive (we would just turn all mixed content off) because the definition of mixed active content differs from browser to browser. 10:00:47 sorry, need to leave this room. 2 seeconds. 10:01:19 IE blocks mixed content iframes, Webkit does not. Mozilla will block mixed content iframes 10:01:21 -??P0 10:02:50 +??P2 10:03:06 zakim, ??P2 is mkwst 10:03:06 +mkwst; got it 10:07:00 ACTION: bhill2 to propose spec text for experimental jsonp-src jsonp-sink directives 10:07:00 Created ACTION-98 - Propose spec text for experimental jsonp-src jsonp-sink directives [on Brad Hill - due 2012-11-09]. 10:10:00 tanvi: What about no-user-js? No attacks seen to justify it. What have others seen? 10:10:34 bhill: Nothing seen from his end. 10:10:54 tanvi: What referrer tag that is implemented as Meta tag in WebKit? 10:11:23 mwest: Would be good to formalize it in either case and worth evaluating. 10:12:13 bhill - would be interesting from userCSP perspective, if a user wants to turn off or referrers for certain sites through CSP addons 10:12:51 ISSUE: discuss CSP relevant use cases for possibly including Meta Referrer as a CSP directive 10:12:51 Created ISSUE-39 - Discuss CSP relevant use cases for possibly including Meta Referrer as a CSP directive ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/39/edit . 10:14:21 -mkwst 10:18:19 ekr has joined #webappsec 10:23:35 gopal has joined #webappsec 10:24:58 +gopal 10:29:02 zakiim, who is here? 10:29:08 zakim, who is here? 10:29:08 On the phone I see St_Clair_2, gopal 10:29:09 On IRC I see gopal, ekr, wei, tanvi, ttanaka2, puhley, mkwst, ware, dveditz, bhill2, Zakim, trackbot, tpacbot, timeless, RRSAgent, odinho, odinho_, caribou, tobie 10:31:24 +??P3 10:34:18 dbaron has joined #webappsec 10:37:29 zakim, ??P3 is mkwst. 10:37:29 +mkwst; got it 10:37:31 Probably. 10:38:43 http://www.w3.org/2011/08/appsecwg-charter.html 10:39:42 bhill: Do we need to additional scope to our charter for CSP 1.1, etc? 10:41:24 bhill: We are chartered to produce something like policy-uri based on language within the scope Manageability section. 10:41:52 dveditz: May be covered by the fact that load balancers can manage policies. 10:42:41 DanD has joined #webappsec 10:43:20 bhill: Mashups should still be the same based on the 1.1 things under discussions. 10:44:48 bhill: We are on track to meet the success criteria of "two independent implementations" even if some minor details aren't exact. 10:45:11 tanvi: Happy with the current success criteria even if we aren't precisely there yet. 10:46:00 bhill: Can remove UMP from deliverables. 10:46:21 bhill: Secure cross-domain framing is the UI Safety Directives 10:46:36 bhill: Secure Cross-Domain Resource Sharing is CORS. 10:46:59 possibly specing out: 10:47:27 10:47:38 10:49:40 the later provides more performant secure page loads 10:49:56 bradee-oh has joined #webappsec 10:50:23 if the fingerprint fails in the we would request the https resource 10:50:35 bhill: Should we take this on as a change to the charter? 10:50:58 relevant to the script-hash discussion 10:52:00 di:location1;location2;hash 10:52:53 dveditz - would it actually get used? 10:53:39 bhill2 - performance and latency benefits would be so compelling, so likely to use it for that reason 10:54:16 maintains authentication but not privacy 10:54:41 which might be okay if you are going to the paypal home page 10:58:15 ekr - side channel problem for althref. 11:01:34 we have a number of WG members expressing an interest in proposing this as a new deliverable and scope item for the charter 11:03:37 dveditz - origin cookies, same domain cookies 11:06:34 bhill: Took stabs on updating timelines within the charter. 11:10:53 CSP 1.1 dates: FPWD - Nov 2012, LC - July 2012, CR - Sept 2013, PR - December 2013, Rec February 2014 11:14:04 Auth'd Mix Content: Mar 2013, LC - Aug 2013, CR - Oct 2013, PR - Dec 2013, Feb 2014 11:14:53 Change Device API Liaison to Web Crypto Liaison 11:16:29 http://www.w3.org/2012/webcrypto/track/issues/21 11:19:20 is there a different IRC channel and dial in number for Web Crypto WG 11:20:40 Potentially System Applications WG? 14:11:17 RRSAgent has joined #webappsec 14:11:17 logging to http://www.w3.org/2012/11/02-webappsec-irc 14:11:19 ekr has joined #webappsec 14:11:21 rrsagent make minutes 14:11:29 rrsagent, make minutes 14:11:29 I have made the request to generate http://www.w3.org/2012/11/02-webappsec-minutes.html bhill2 14:12:01 rrsagent, set logs public-visible 14:17:51 bhill2 has joined #webappsec 14:18:51 tlr has joined #webappsec 14:20:48 dveditz has joined #webappsec 14:23:35 tanvi has joined #webappsec 14:24:03 tanvi has joined #webappsec 14:43:19 bhill2 has joined #webappsec 15:33:37 ekr has joined #webappsec 16:01:34 ekr has joined #webappsec 16:09:18 tanvi has joined #webappsec 17:03:33 tlr has joined #webappsec 21:33:28 dveditz has joined #webappsec 21:57:21 ekr has joined #webappsec 23:06:42 tlr has joined #webappsec 23:46:50 mkwst has joined #webappsec