See also: IRC log
<trackbot> Date: 23 March 2016
<scribe> scribenick: bhill2
<scribe> Meeting: WebAppSec Teleconference, 23-Mar-2016
<mikeoneill> Hi Im Mike O'Neill in webex
<mikeoneill> via webex I meant
wseltzer: can we chat about some document statuses later?
transition request for CORS to edited REC is stale as of Sep 9 (!) and SRI to Proposed REC from Jan 22...
<wseltzer> bhill2, yes, and about fetch dependencies.
yes, great
Agenda is here: https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/0073.html
<scribe> scribenick: bhill2
https://www.w3.org/2011/webappsec/draft-minutes/2016-02-24-webappsec-minutes.html
Any objections to unanimous consent to approve prior minutes?
No objections, approved unanimously.
Thanks to Moz for volunteering space at Mountain View on May 16-17.
http://doodle.com/poll/38uhygx3wtg3ax3f
Agenda bashing for F2F
https://docs.google.com/document/d/1KQ_TWHBc1QBn4Xf2yJ7AYDQumuJioaGDfxbzwIJjxOI/edit
mkwst: implementer interest is most important topic, and threat model discussion flows nicely into that
... what do various vendors actually care about and where should we be investing our effort
dveditz: agreed on that, a few things not mentioned
... like CSP2. Let's go through all specs and what next steps are, where are we in the process for each one.
<mkwst> bhill: Removing barriers is on the list. But doing inventory seems like it makes sense.
<mkwst> ... Very close on CSP2.
<mkwst> ... One or two features (`form-action`) that don't have two implementations.
<mkwst> ... Remove those features? Make them optional?
<mkwst> ... Want to get to REC.
https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/0067.html
Mike said on the list that if the context isn't secure, the content isn't mixed.
tanvi: thought there was discussion that directive and UIR should work on insecure pages, too
mkwst: UIR works on insecure pages and still tries to upgrade insecure requests
... but block all mixed exits early if not in a secure context because content isn't actually mixed
tanvi: sounds fine, actually how our implementation works
dveditz: if you are an insecure page and framed a secure page then you would have strict blocking for the secure frame, yes?
mkwst: that is correct
dveditz: should make sure we have a test case for that
mkwst: I don't feel strongly about that behavior
... fine to change to indicate that the directive only works in a secure context
dveditz: I care that FF, Chrome and other browsers are consistent in cases like that
mkwst: fairly certain that behavior is well-defined. flag set on document that propagates down into iframes
... will test this
<mkwst> bhill: Will hold off on officially doing anything until tested. Sounds like it'll be quick.
neilm: idea is to add another directive to CSP to indicate that resources must have integrity tags
seems to be pretty good consensus on this...
neilm: there is some contention on whether we want a directive to require on all resources, e.g. * as an equivalent to default-src: none
dev: I prefer a new keyword expression for each individual -src directive rather than a new CSP directive
... for forwards/backwards compatibility reasons
francois: I'm fine with either a global keyword or something in each -src directive
... I think that '*' is likely to cause problems in the future when browsers implement at a different pace
neilm: would become a big problem if things were wildly all over the place
... don't know it will be that disjoint. some of that already with things like nonces that some browsers don't understand
francois: I fear that lots of devs will use * because it is shorter, and it only applies to styles, scripts, site will break in the future as new tags are supported
dveditz: or require an integrity attribute on everything with a href and break even if we don't check it
dev: so many tags...
francios: still an issue if we invent a new type of subresource
neilm: and pretty long
<freddyb> I suggest we don't support * but allow shorthands for sets of subresources by spec version, i.e. v1 = scripts & styles
bhill2: I would lean towards not giving developers a footgun, we had to scramble at Facebook to fix when data: and blob: were no longer implicitly part of *
dev: I vote for not including a *
francois: bring up the github discussion to the list
neilm: will do it
https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/0036.html
https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/0034.html
https://noncombatant.github.io/permission-delegation-api/
https://docs.google.com/document/d/1iaocsSuVrU11FFzZwy7EnJNOwxhAHMroWSOEERw5hO0/edit
tanvi: I've commented on the proposal, but don't think that Raymes is here
mkwst: neither Raymes or Chris is on the call...
... not sure how much value there is in discussion without either proposer
<mikeoneill> q
mkwst: I like it, think it's good and some tweaks proposed are interesting
<mikeoneill> +q
mikeoneill: I quite like it, also interested in the cookie control and embedded CSP thing from December
... seem to be addressing the same issue, would be good to discuss at the same time
<mkwst> bhill: Yes. Fits in with the conversation around threat models.
<mkwst> ... embedded widgets, ads. What control do we want to give to the embedder.
<mkwst> bhill: AOB?
<mkwst> ... Need to update CORS to point at Fetch.
<mkwst> ... Transition requests gone stale.
<mkwst> ... Need to talk with Web Platform WG to see what's going on with references to HTML.
<mkwst> ... WHATWG, etc.
<mkwst> ... mkwst is interested. Anyone else?
<mkwst> <crickets>
<mkwst> ... Will get that on the calendar.
mkwst: issued an intent to ship same site attribute for cookies
... want to bring it to the attention of other browser vendors, please take a look
ccowan: can you give us the elevator pitch?
mkwst: if a cookie is marked as same-site, it will only be sent if the request is initiated by the same site
... example.com requesting something from example.com will send the cookie, evil.com requesting something from example.com won't have it
<mkwst> bhill: How to feature-detect?
<mkwst> ... would love to use this if we know it'll be respected.
<mkwst> ... Want to know if the semantics will be forced or not.
<mkwst> dveditz: Looking at it as an opportunistic improvement.
bhill2: would be good to know if the semantics are enforced without having to do UA string assessment
<mkwst> ... What would you do in a UA that doesn't support?
<mkwst> ... Works on browsers that don't support, but get more protection on browsers that do.
dveditz: think of it as an opportunistic improvement
<mkwst> bhill: Some scenarios where you're trying to protect against CSRF'd login into some arbitrary account.
<mkwst> ... Might want to take other measures depending on the capability of UA.
<mkwst> dveditz: Would have to signal in the cookie itself
<mkwst> ... can't really decorate the cookie header without breaking soething.
<mkwst> ... could add a signaling header.
<mkwst> devd: Prefixes?
dev: what about prefixes as a secondary mechanism?
<mkwst> mkwst: That would mean we'd need to signal support for prefixes.
<mkwst> bhill: DOM attribute would be enough for me.
<mkwst> ... `document.cookies.supportsSameSite`, etc.
<mkwst> ... Will think on it some more.