See also: IRC log
<bhill2> zakim aadd is jww
<bhill2> scribenick: dev
<bhill2> scribe: Devdatta Akhawe
<bhill2> RESOLVED by unanimous consent: minutes from TPAC are approved
<bhill2> bhill2 adding item: David Ross and Terri Oda to follow up on EPR
<bhill2> scribenick: bhill2
<dev> does david have a irc handle ?
dross: Spent some time going thru web app manifest
<mkwst___> dev: drx-goog
dross: we could use that
<mkwst___> or dross. :)
<dev> ok .. bhill2 is scribing .. sorry :)
dross: but would still need a
header to tell the browser that EPR is enabled for this
site
... currently this works by sending a synchronous request
... lots of pushback on that by browsers for perf reasons
... thinking about ways to work around that
... started discussion of that, just moved it to webappsec
list
... can discuss further there, possible to avoid any
synchronous requests
... idea there is basic level policy that comes with the
header
... mitigates xss in scenario where manifest is not yet
loaded
... overall manifest spec makes a lot of sense to hold EPR
manifest
... still requirement for a response header, whatever it is
called
terri: talked to folks at sysapps
about implementation of manifest
... one thing holding up implementation was knowing exactly
when and how it
... needs to be loaded so we should talk to them about that,
whether it should be
... sync for package apps
... similar proposal dead in water b/c of this, will probably
be pushback
devditz: earlier version of CSP
had synchronous fetch of policy-uri
... got booted for similar concerns
dev: for CSRF, reasonable to say it's only needed once you've visited site and have a cookie
drx-google: no way to do anything
in that case anyway, no info at all when first request is
sent
... not authN until actually interacting, should have manifest
by then
dev: we already have CSP...
... no story for CSRF, EPR can help there
terri: we do have Origin header
dev: is anyone implementing?
<inserted> scribenick: mkwst___
bhill2: Origin header is mandatory for CORS.
dveditz: CORS has different behavior when you do redirects, useful for CSRF.
<bhill2> dveditz: problem is that cors truncates on redirects, so not useful for other things
bhill2: regarding XSS. of that 20% which could be prevented by EPR, how much could be prevented by CSP?
dross: Lots of overlap
there.
... reflected XSS can be mitigated with CSP.
dveditz: how does EPR help for stored XSS?
<bhill2> dveditz: does EPR help for stored XSS?
dross: It does not.
dveditz: CSP can help with stored
XSS.
... CSRF mitigations are valuable, as we have XSS mitigations
with CSP.
bhill2: should give clear guidance to authors as to which (EPR or CSP) they should use and why, given overlap.
dross: Can determine what that
guidance should be.
... In packaged applications, if you want unsafe-eval, you
could do that and still use EPR to mitigate the threat.
... There's value in having another option.
<bhill2> dveditz: other thing is to consider how this works with priority of constituencies
<bhill2> ... have run into issues with CSP on that, EPR could be worse
<dveditz> http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
bhill2: <explains PoC>
http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
... How much of EPR should live in this group?
... joint deliverable with sysapps/webapps?
... would like to get away from the tradition of
monkeypatching.
terri: not entirely clear how the manifest spec is working.
bhill2: dross, can you introduce
your proposal to Marcos, et al?
... how would they feel about adding this to Manifest? which
venue would they prefer?
dross: sure.
bhill2: objecting generally to idea of a "none" referrer policy.
<dev> no
bhill2: does anyone else object to "none"?
dveditz: I have some
concerns
... but everywhere folks rely on referrer, they're already
unhappy.
bhill2: don't want to close it out here, if no one wants to represent that side, let's punt back to the list.
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0238.html
bhill2: <summarizing
thread>
... trending towards conclusion that defense in depth is a good
thing.
... punted the idea of applying hash source to out-of-line
content.
... investigate for CSP vNext?
dveditz: SRI spec uses ni:/// syntax, why couldn't we treat those as a scheme source expression?
<bhill2> dveditz: can we use ni:// url as a construct like we do blob: or data: ?
<bhill2> dev: question is do we need to to it right now?
dev: do we need to do it right now?
<bhill2> dev: what is size of the policy at that point... keep adding hashes too?
<bhill2> dveditz: have to whitelist CDN, so whitelist specific path, ...
<bhill2> .. or just put the hash in
<bhill2> ... it'd be long, and icky, but if you care that's what you could do
<bhill2> jww: there is currently a way to handle all these cases
<bhill2> ... we don't need to worry about it yet
bhill2: does the URL production for level 2 forbid NI?
<bhill2> mkwst: fairly certain ni:// scheme could be used in a source expression and that would work
mkwst: ni would work as a scheme source expression
<bhill2> bhill2: just a scheme source?
<bhill2> mkwst: triple slashes would cause problems, no authority section
<bhill2> ... only could whitelist all ni: as a scheme
bhill2: will create an issue to track the idea.
<bhill2> ISSUE can we produce a full ni:/// uri as a CSP source?
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0182.html
bhill2: there's a CfC. discussion
on the mailing list.
... any questions for folks who like to talk and not
type?
... note that last call means there's still room for
comments.
<dveditz> why does rfc 6920 introduce '///' for ni:?
<dveditz> it's not a hierarchical scheme
dveditz: it can be.
ni: //[authority]/[digest]
we're not using that.
but there's no reason we couldn't...
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0184.html
<dveditz> ah, didn't read far enough
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0176.html
<terri> 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.
<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0171.html
<dveditz> terri: can you send a summary of those use cases?
bhill2: will let us know what we
should focus on for next iteration.
... manifest. blob: data:. they want to whitelist a specific
data URI in CSP without whitelisting data as a scheme.
... perhaps we could use hash sources for data: or blob:
contents.
<inserted> scribenick: bhill2
dev: ties into how do we specify ni:/// etc... presumably their use case would be solved
bhill2: could be simpler....
dveditz: if there is hash in
policy, would have to hash all data: uris?
... potentially a perf hit for all script attributes
... would be useful, most obvious is with SRI integration
ISSUE explore how to identifiy specific data: uris, etc. more granular than scheme
dveditz: more worried about blob
from Mixed Content spec
from Mixed Content spec
http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0155.html
mkwst: would be unfortunate to
let this drop on the floor, interest from Chrome in blocking
access to private networks
... lot of things problematic about allowing that access
... more to consider than blanket restrictions than were in
MIX
... so not a problem to remove it from MIX
... but would be a problem to remove it without a plan to
resolve it.
terri: talking to folks about web
of things there is more of a need than people realize
... we can reopen perhaps?
bhill2: we can bring this to
attention of web of things interest group
... possibly get requirements or problem defintion from
them
http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0237.html
kevinHill: does window.open for about:blank inherit origins?
mkwst: this is a bypass and I'll need to look at chrome's impl to match what FF is doing