WebAppSec WG -- 20 Apr 2016

<bhill2> Meeting; WebAppSec Teleconference, 20-Apr-2016

Agenda Bashing

<bhill2> none

bhill2: first topic is agenda bashing. anything to add?
... nothing to add

Minutes Approval

<bhill2> https://www.w3.org/2016/03/23-webappsec-minutes.html

bhill2: next topic is minutes approval

May F2F is coming...

bhill2: any objection to unanimous approval? ...... none, approved
... May f2f is coming

<wseltzer> Doodle Sign up: http://doodle.com/poll/38uhygx3wtg3ax3f

<mkwst> dveditz: Please sign up via the Doodle so we can plan for lunch.

<mkwst> ... Rooms for ~20 people. 16 signed up.

<mkwst> ... If more sign up, we can get a bigger room.

<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)

<mkwst> ... If not, we might be crowded.

<mkwst> bhill2: TAG members might be interested. Will inform them that they should sign up as soon as possible,

<mkwst> dveditz: Sure. We'd love to have them. We just need to know in advance so we can have room for them.

<mkwst> bhill2: Don't wait to book a hotel. Google I/O is the same week (Thanks Emily!).

References to Fetch, etc.

bhill2: next topic, references to Fetch
... we have a number of specs close to done or even just waiting
... with a persistent issue about how to do references to documents that are not w3 docs. particularly WHATWG documents
... fetch is the main one, but also parts of HTML and others
... Mike, Wendy and myself met with Web Platform WG about how to construct stable references
... made progress with DOM and HTML, but Fetch is a stickier issue
... also had some small corrections to CORS that said to reference the WHATWG Fetch spec, and that was rejected

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

<wseltzer> https://www.w3.org/2013/09/normative-references

wseltzer: 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
... One of the elements is the stability of the reference
... another question is "is there another stable reference for the pointer, will the 'living specification' change and make the reference invalid?"
... the directory also pointed out that in some cases there are references /from/ fetch to our own specs
... 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
... thanks to your effort to get things moving, Brad.

<bhill2> https://docs.google.com/document/d/1AtxTDw-g9BSRW9n9kGTTqNkDTGcVfSKPAOjVGkPFu2k/edit?usp=sharing

bhill2: I feel like this persistence issue has been something we've been locking horns over for 3 or 4 years now
... I linked to document that could help separate the concerns about CORS itself from the persistence issue

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

bhill2: even that is a non-trivial amount of work, many hours of editorial/formating work.
... anyone want to take that on and create a w3 snapshot?

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
... to see if that is enough to help us move forward with the director

<wseltzer> ACTION: wseltzer to examine Fetch refs for stability [recorded in http://www.w3.org/2016/04/20-webappsec-minutes.html#action01]

<trackbot> Created ACTION-216 - Examine fetch refs for stability [on Wendy Seltzer - due 2016-04-27].

bhill2: it's not doing anyone any help to pretend the Fetch spec doesnt' exist

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.
... some changes will be straightforward, and some are based on frameworks and concepts the w3 version just doesn't have.
... the WG claimed they had imported things up to @@ but when I checked that was not entirely true, some things were missing or incomplete

wseltzer: thanks very much mike for going through and doing that. heard from Philippe that was happening and useful
... we're trying to be responsive to that.. please do keep pushing on us to get that right
... we'll be keeping a closer eye on it

mkwst: 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.
... there are some conceptual differences between the two and making the same hooks to each might have different effects
... Some of the concepts are new, some are simply described in a new way. "Realms" for instance, has come from ES6
... In certain places the specs were more different than I expected them to be

mkwst: I don't want to be the one doing that review, I'm suggesting that the W3 have someone do that

CSP Level 2 - Welcome Safari Technical Preview!

<dydz> Hello from Cupertino, CA

scribe note: speaker was mkwst starting with "in this group I would simply note..."

<jww> welcome, Safari!

<wseltzer> Welcome!

<mkwst> yay!

<bhill2> http://w3c.github.io/webappsec/implementation_reports/CSP2_implementation_report.html

dydz: [Apple has joined the working group]

bhill2: the link I just posted is a CSP implementation report for the latest browsers
... includes the most recent Firefox would has made recent improvements, and Safari
... we're missing some tests for font-src, report-only, and the script/event handling
... would like help improving the tests to get to 100% coverage of the spec

mkwst: took a look at two of them, and one needs to be rebased but otherwise they look good

default-src definition in CSP2

bhill2: skipping ahead, to "last things for CSP2"

<bhill2> https://github.com/w3c/webappsec/issues/514#issuecomment-211587068

bhill2: from an issue submitted by April King, pointing out in how we define the default-src directive
... 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.

mkwst: I do think it's worth correcting in CSP2. It's just a correction, a large typo if you will.
... 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
... we're so far into this that having to wait a little longer to get the spec approved wouldn't hurt

'unsafe-dynamic'

<bhill2> https://github.com/w3c/webappsec-csp/issues/70#event-631031432

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

mkwst: unsafe-dynamic is something I've proposed that some google properties are playing around with
... 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
... the extensive whitelisting can actually introduce security holes because it tends to be too lose to accommodate
... Chrome 5? is going to release with an implementation and we'll see how this works
... haven't heard much from others

bhill2: taking off my chair hat, from a Facebook perspective I'm interested in this feature and think it will help.
... do you have any thoughts about redirects, such as google switching to country-specific ones?

mkwst: with nonces we already allow that. are you asking outside the context of nonces?

bhill2: if this new behavior only applies to nonces then my concern may have already been taken care of

mkwst: I also have the idea to combine CSP and SRI. currently we only allow hashes to work for inline scripts
... will file a bug and we can alk about it there

<teddink> Microsoft is also interested, just a matter of prioritization of work.

bhill2: any other implementors?

Block all non-SRI resources

dveditz: Mozilla is watching, but working on a lot of other requirements first so just watching for now

<bhill2> https://github.com/w3c/webappsec-csp/pull/64#issuecomment-211482914

<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Apr/0001.html

bhill2: suggested by dveditz that we punt on '*' for now since we only have two directives covered, and will avoid future breakage.
... any responses?

mkwst: seems reasonable to me. gave neil some feedback on the patch, waiting for him to clean it up

Providing safer referrer policy states

<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Apr/0004.html

bhill2: proving safer referrer policy states. anyone on the call want to present it?

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
... currently in the spec if you want to truncate the referrer to origin there's no way to do that without leaking it insecurely
... we proposed adding some additional states that preserves this

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
... a more flexible syntax in a future version (that could also cover these new states)

bhill2: I also had the concern about changing current behavior making the new states the default
... This is an incredibly useful feature for people who want to send referrers without having to go through unnecessary redirects
... 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

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

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

estark: are there developers who have asked for these states? I don't know if that should be a requirement, but I am curious.

dveditz: only individuals, no large sites

estark: do you have any thoughts, francois, about the future where we make the whole thing more flexible?

francois: personally I'd prefer to see the first version to include these simple additions rather than having to wait for version 2

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.

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
... but maybe leaks sensitive subdomains?

wseltzer: maybe we should ask the privacy IG for a review since we're talking about control of what information is sent

Further granularity of unsafe-inline styles

<bhill2> https://github.com/w3c/webappsec-csp/issues/45

bhill2: two minutes left to discuss, probably don't have time to deal with it. but raising it
... would be good to get more feedback from developers and implementors on that issue
... should we cancel the next call, and just batch things up for the F2F?

<teddink> sounds good

bhill2: let's tentatively cancel, but will bring it up on the list
... thanks everyone

<bhill2> rrasagent, make minutes

- DRAFT -

>WebAppSec WG

20 Apr 2016

Attendees

Contents