15:56:44 <RRSAgent> RRSAgent has joined #webappsec
15:56:44 <RRSAgent> logging to http://www.w3.org/2016/04/20-webappsec-irc
15:57:53 <freddyb> freddyb has joined #webappsec
15:58:10 <bhill2> present+ bhill2
15:58:20 <bhill2> bhill2 has changed the topic to: https://lists.w3.org/Archives/Public/public-webappsec/2016Apr/0027.html
15:59:13 <teddink> present +teddink
15:59:19 <jeff> jeff has joined #webappsec
16:00:10 <freddyb> present+ freddyb
16:00:17 <mkwst> present+ mkwst
16:00:39 <gmaone> present+ gmaone
16:01:08 <jeff> present+ jeff
16:01:39 <dveditz> present+ dveditz
16:01:45 <francois> francois has joined #webappsec
16:02:17 <bhill2> present+ John Wilander
16:02:29 <estark> estark has joined #webappsec
16:02:30 <francois> present+ francois
16:02:57 <estark> present+ estark
16:03:32 <wseltzer> present+ wseltzer
16:04:16 <dydz> dydz has joined #webappsec
16:04:38 <bhill2> Meeting; WebAppSec Teleconference, 20-Apr-2016
16:04:44 <bhill2> Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2016Apr/0027.html
16:05:09 <bhill2> TOPIC: Agenda Bashing
16:05:10 <bhill2> none
16:05:10 <dveditz> bhill2: first topic is agenda bashing. anything to add?
16:05:17 <dveditz> ... nothing to add
16:05:19 <bhill2> TOPIC: Minutes Approval
16:05:23 <bhill2> https://www.w3.org/2016/03/23-webappsec-minutes.html
16:05:31 <dveditz> ... next topic is minutes approval
16:05:41 <bhill2> TOPIC: May F2F is coming...
16:05:48 <dveditz> ... any objection to unanimous approval?  ...... none, approved
16:06:01 <dveditz> ... May f2f is coming
16:06:10 <wseltzer> Doodle Sign up: http://doodle.com/poll/38uhygx3wtg3ax3f
16:06:26 <mkwst> dveditz: Please sign up via the Doodle so we can plan for lunch.
16:06:34 <mkwst> ... Rooms for ~20 people. 16 signed up.
16:06:44 <mkwst> ... If more sign up, we can get a bigger room.
16:06:49 <estark> have we already talked about the fact that it's the same week as Google I/O? (so people should book hotel rooms, etc. ASAP)
16:06:54 <mkwst> ... If not, we might be crowded.
16:07:21 <mkwst> bhill2: TAG members might be interested. Will inform them that they should sign up as soon as possible,
16:07:51 <mkwst> dveditz: Sure. We'd love to have them. We just need to know in advance so we can have room for them.
16:08:09 <mkwst> bhill2: Don't wait to book a hotel. Google I/O is the same week (Thanks Emily!).
16:08:25 <bhill2> TOPIC: References to Fetch, etc.
16:08:30 <dveditz> bhill2: next topic, references to Fetch
16:08:45 <dveditz> ... we have a number of specs close to done or even just waiting
16:08:50 <wseltzer> q+
16:09:10 <dveditz> ... with a persistent issue about how to do references to documents that are not w3 docs. particularly WHATWG documents
16:09:28 <dveditz> ... fetch is the main one, but also parts of HTML and others
16:10:07 <dveditz> ... Mike, Wendy and myself met with @@ about how to construct stable references
16:10:09 <weiler> weiler has joined #webappsec
16:10:23 <dveditz> ... made progress with DOM and HTML, but Fetch is a stickier issue
16:10:32 <mkwst> s/@@/Web Platform WG/
16:10:51 <dveditz> ... also had some small corrections to CORS that said to reference the WHATWG Fetch spec, and that was rejected
16:11:35 <dveditz> wseltzer: I've been having some conversations with the director since then. Thank you for the document you wrote that helped pinpoint the technical questions the director has raised
16:11:54 <wseltzer> https://www.w3.org/2013/09/normative-references
16:12:12 <dveditz> ... a thread of discussion is "is CORS/Fetch serving the web platform" and the other main one is what is the appropriate normative reference policy
16:12:39 <dveditz> ... One of the elements in the stability of the reference
16:12:49 <dveditz> s/in the/is the/
16:13:42 <dveditz> ... another question is "is there another stable reference for the pointer, will the 'living specification' change and make the reference invalid?"
16:14:55 <dveditz> ... the directory also pointed out that in some cases there are references /from/ fetch to our own specs
16:15:30 <dveditz> ... If we can address the 'persistence and stability of the reference' problem then we're on a reasonable track to get these things moving again
16:15:44 <dveditz> ... thanks to your effort to get things moving, Brad.
16:16:04 <bhill2> https://docs.google.com/document/d/1AtxTDw-g9BSRW9n9kGTTqNkDTGcVfSKPAOjVGkPFu2k/edit?usp=sharing
16:16:09 <dveditz> bhill2: I feel like this persistence issue has been something we've been locking horns over for 3 or 4 years now
16:16:52 <dveditz> ... I linked to document that could help separate the concerns about CORS itself from the persistence issue
16:17:32 <dveditz> wseltzer: would it be a workable model to snapshot the Fetch spec as a normative reference. Not in the way HTML has done but in the more lightweight way the Encoding one was done
16:17:55 <dveditz> bhill2: even that is a non-trivial amount of work, many hours of editorial/formating work.
16:18:12 <wseltzer> q+
16:18:21 <dveditz> ... anyone want to take that on and create a w3 snapshot?
16:18:55 <dveditz> wseltzer: the action I volunteer to take is to examine each of the references closely to see if we have sufficient stability of the features, even if the overall document is changing
16:19:18 <dveditz> ... to see if that is enough to help us move forward with the director
16:19:28 <wseltzer> action: wseltzer to examine Fetch refs for stability
16:19:28 <trackbot> Created ACTION-216 - Examine fetch refs for stability [on Wendy Seltzer - due 2016-04-27].
16:19:56 <dveditz> bhill2: it's not doing anyone any help to pretend the Fetch spec doesnt' exist
16:20:01 <jww> jww has joined #webappsec
16:20:44 <dveditz> mkwst: I went through the CSP spec last week and went through and filed bugs against the W3 HTML spec where it's incompatible with what CSP and the web are actually doing.
16:21:09 <dveditz> ... some changes will be straightforward, and some are based on frameworks and concepts the w3 version just doesn't have.
16:21:38 <wseltzer> q+
16:21:42 <dveditz> ... the WG claimed they had imported things up to @@ but when I checked that was not entirely true, some things were missing or incomplete
16:21:47 <terri> present+ terri
16:22:08 <dveditz> wseltzer: thanks very much mike for going through and doing that. heard from Philippe that was happening and useful
16:22:39 <dveditz> ... we're trying to be responsive to that.. please do keep pushing on us to get that right
16:22:51 <dveditz> ... we'll be keeping a closer eye on it
16:23:37 <dveditz> ... in this group I would simply note that it's going to be difficult to review the patches the HTML group adds to make sure they're the same as the equivalent in the WHATWG version.
16:24:06 <dveditz> ... there are some conceptual differences between the two and making the same hooks to each might have different effects
16:24:35 <dveditz> ... Some of the concepts are new, some are simply described in a new way. "Realms" for instance, has come from ES6
16:24:58 <dveditz> ... In certain places the specs were more different than I expected them to be
16:26:03 <dveditz> mkwst: I don't want to be the one doing that review, I'm suggesting that the W3 have someone do that
16:26:19 <bhill2> TOPIC: CSP Level 2 - Welcome Safari Technical Preview!
16:26:34 <dydz> Hello from Cupertino, CA
16:27:00 <dveditz> scribe note: speaker was mkwst starting with "in this group I would simply note..."
16:27:02 <jww> welcome, Safari!
16:27:41 <wseltzer> Welcome!
16:27:44 <mkwst> yay!
16:27:46 <bhill2> http://w3c.github.io/webappsec/implementation_reports/CSP2_implementation_report.html
16:27:54 <dveditz> dydz: [Apple has joined the working group]
16:28:29 <dveditz> bhill2: the link I just posted is a CSP implementation report for the latest browsers
16:28:58 <dveditz> ... includes the most recent Firefox would has made recent improvements, and Safari
16:29:20 <dveditz> ... we're missing some tests for font-src, report-only, and the script/event handling
16:29:43 <dveditz> ... would like help improving the tests to get to 100% coverage of the spec
16:30:03 <dveditz> mkwst: took a look at two of them, and one needs to be rebased but otherwise they look good
16:30:17 <bhill2> TOPIC: default-src definition in CSP2
16:30:20 <dveditz> bhill2: skipping ahead, to "last things for CSP2"
16:30:25 <bhill2> https://github.com/w3c/webappsec/issues/514#issuecomment-211587068
16:30:42 <dveditz> ... from an issue submitted by April King, pointing out in how we define the default-src directive
16:32:04 <dveditz> ... april is of the opinion that our implementations are correct and match CSP3, and that it's the CSP2 spec that was incorrect or unclear.
16:32:46 <dveditz> mkwst: I do think it's worth correcting in CSP2. It's just a correction, a large typo if you will.
16:33:22 <dveditz> ... I don't think there is any actual normative impact if we change this. This is the second time this question has come up so it'd be worth correcting
16:33:51 <dveditz> ... we're so far into this that having to wait a little longer to get the spec approved wouldn't hurt
16:34:00 <bhill2> TOPIC: 'unsafe-dynamic'
16:34:04 <bhill2> https://github.com/w3c/webappsec-csp/issues/70#event-631031432
16:34:17 <dveditz> bhill2: I'll write some tests. if we have 3 conforming implementations then it should be easy to show this is a non-normative change
16:34:44 <dveditz> mkwst: unsafe-dynamic is something I've proposed that some google properties are playing around with
16:35:25 <dveditz> ... if you include a script and that script loads more scripts you have to whitelist all of them. fragile, hard to work with, too much coordination with downstream libraries
16:36:05 <dveditz> ... the extensive whitelisting can actually introduce security holes because it tends to be too lose to accommodate
16:36:34 <dveditz> ... Chrome 5? is going to release with an implementation and we'll see how this works
16:36:41 <dveditz> ... haven't heard much from others
16:37:04 <dveditz> bhill2: taking off my chair hat, from a Facebook perspective I'm interested in this feature and think it will help.
16:38:34 <dveditz> ... do you have any thoughts about redirects, such as google switching to country-specific ones?
16:38:53 <dveditz> mkwst: with nonces we already allow that. are you asking outside the context of nonces?
16:39:33 <dveditz> bhill2: if this new behavior only applies to nonces then my concern may have already been taken care of
16:40:11 <dveditz> mkwst: I also have the idea to combine CSP and SRI. currently we only allow hashes to work for inline scripts
16:41:57 <dveditz> mkwst: will file a bug and we can alk about it there
16:42:14 <teddink> Microsoft is also interested, just a matter of prioritization of work.
16:42:30 <dveditz> bhill2: any other implementors?
16:42:49 <bhill2> TOPIC: Block all non-SRI resources
16:42:50 <dveditz> dveditz: Mozilla is watching, but working on a lot of other requirements first so just watching for now
16:43:00 <bhill2> https://github.com/w3c/webappsec-csp/pull/64#issuecomment-211482914
16:43:10 <bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Apr/0001.html
16:44:08 <dveditz> bhill2: suggested by dveditz that we punt on '*' for now since we only have two directives covered, and will avoid future breakage.
16:44:13 <dveditz> ... any responses?
16:44:36 <dveditz> mkwst: seems reasonable to me. gave neil some feedback on the patch, waiting for him to clean it up
16:45:07 <bhill2> TOPIC: Providing safer referrer policy states
16:45:13 <bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Apr/0004.html
16:45:39 <dveditz> bhill2: proving safer referrer policy states. anyone on the call want to present it?
16:47:22 <dveditz> francois: current referrer policy is focused on unbreaking people moving to https, but there have been cases such as healthcare.gov where private data was leaked in referrers so it would be nice to add stricter states as well
16:47:58 <dveditz> ... currently in the spec if you want to truncate the referrer to origin there's no way to do that without leaking it insecurely
16:48:22 <dveditz> ... we proposed adding some additional states that preserves this
16:49:08 <dveditz> estark: are there develoeprs actually asking for these states? We've also proposed a more flexible syntax for the future maybe we should wrap up what we have and then move to
16:49:24 <dveditz> ... a more flexible syntax in a future version (that could also cover these new states)
16:49:41 <dveditz> bhill2: I also had the concern about changing current behavior making the new states the default
16:50:30 <dveditz> ... This is an incredibly useful feature for people who want to send referrers without having to go through unnecessary redirects
16:51:11 <dveditz> ... Saves Facebook a lot not having to redirect through a http: site, also our security posture improves because we don't need to support those http insecure end=points
16:51:40 <dveditz> estark: I'm also not enthusiastic about changing the defaults, but the meat of the proposal was the new states and doesn't require changing the default names
16:52:23 <dveditz> francois: that's correct, the name change is separate. would have been nice if we had started that way, but i take your point given the existing implementations
16:52:55 <dveditz> estark: are there developers who have asked for these states? I don't know if that should be a requirement, but I am curious.
16:53:15 <dveditz> dveditz: only individuals, no large sites
16:53:45 <dveditz> estark: do you have any thoughts, francois, about the future where we make the whole thing more flexible?
16:54:12 <dveditz> francois: personally I'd prefer to see the first version to include these simple additions rather than having to wait for version 2
16:55:06 <dveditz> estark: I need to look at what the implementation in Chrome would require. tempting to say it should be easy, but needs to be checked that it's not a major undertaking.
16:55:42 <wseltzer> q+
16:56:05 <dveditz> bhill2: seems like a 'nice to have', not all that pressing. Truncating to the origin is unlikely to leak sensitive information which mostly addresses the original reason for the https->http truncation
16:56:06 <bhill2> ack wseltzer
16:56:15 <dveditz> ... but maybe leaks sensitive subdomains?
16:56:45 <dveditz> wseltzer: maybe we should ask the privacy IG for a review since we're talking about control of what information is sent
16:58:23 <bhill2> TOPIC: Further granularity of unsafe-inline styles
16:58:30 <bhill2> https://github.com/w3c/webappsec-csp/issues/45
16:58:40 <dveditz> bhill2: two minutes left to discuss, probably don't have time to deal with it. but raising it
16:58:57 <dveditz> ... would be good to get more feedback from developers and implementors on that issue
16:59:36 <dveditz> ... should we cancel the next call, and just batch things up for the F2F?
16:59:47 <teddink> sounds good
16:59:53 <dveditz> ... let's tentatively cancel, but will bring it up on the list
17:00:00 <dveditz> ... thanks everyone
17:00:18 <bhill2> zakim, list attendees
17:00:18 <Zakim> As of this point the attendees have been bhill2, freddyb, mkwst, gmaone, jeff, dveditz, John, Wilander, francois, estark, wseltzer, terri
17:00:28 <bhill2> rrasagent, make minutes
17:00:34 <bhill2> rrsagent, make minutes
17:00:34 <RRSAgent> I have made the request to generate http://www.w3.org/2016/04/20-webappsec-minutes.html bhill2
17:00:40 <bhill2> rrsagent, set logs world
17:01:29 <weiler> weiler has left #webappsec
17:02:37 <bhill2> bhill2 has joined #webappsec
17:59:44 <jeff_> jeff_ has joined #webappsec
18:40:21 <yoav> yoav has joined #webappsec
18:52:48 <jeff_> jeff_ has joined #webappsec
19:26:15 <Zakim> Zakim has left #webappsec
20:41:43 <yoav> yoav has joined #webappsec