webappsecirc

15:59 < mkwst> present+ mkwst
15:59  * mkwst might need to do that again if Zakim doesn't actually recognize the call?
15:59 < bhill2_> present+ bhill2
15:59 < bhill2_> Meeting: WebAppSec Teleconference, 23-Mar-2016
16:00 < bhill2_> Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/0073.html
16:00 < bhill2_> Chairs: bhill2, dveditz
16:00 < freddyb> present+ freddyb
16:00 -!- bhill2 [~bhill2@public.cloak] has quit [Ping timeout: 180 seconds]
16:00 -!- gmaone [~chatzilla@public.cloak] has joined #webappsec
16:01 -!- teddink [~teddink@public.cloak] has joined #webappsec
16:01 -!- mikeoneill [~mikeoneill@public.cloak] has joined #webappsec
16:06 < bhill2_> zakim, who is here?
16:06 < Zakim> Present: mkwst, bhill2, freddyb, francois, gmaone, teddink, dveditz, terri
16:06 < Zakim> On IRC I see mikeoneill, teddink, gmaone, bhill2_, freddyb, neilm, francois, ejcx_, yoav, Zakim, RRSAgent, Mek, terri, timeless, jochen__, schuki, mounir, MikeSmith, mkwst,
16:06 < Zakim> ... slightlyoff, dveditz, tobie, Josh_Soref, wseltzer, trackbot
16:06 < bhill2_> scribenick: bhill2
16:07 < bhill2_> TOPIC: Agenda Bashing
16:07  * francois can scribe after the first 5 minutes
16:07  * bhill2_ hears no agenda additions
16:07 < bhill2_> TOPIC: Minutes Approval
16:08 < bhill2_> https://www.w3.org/2011/webappsec/draft-minutes/2016-02-24-webappsec-minutes.html
16:08 < bhill2_> Any objections to unanimous consent to approve prior minutes?
16:08 < bhill2_> No objections, approved unanimously.
16:08 < bhill2_> TOPIC: May F2F
16:08 -!- devd [~devd@public.cloak] has joined #webappsec
16:09 < bhill2_> Thanks to Moz for volunteering space at Mountain View on May 16-17.
16:09 < bhill2_> http://doodle.com/poll/38uhygx3wtg3ax3f
16:09 -!- KingstonTime [~KingstonTime@public.cloak] has joined #webappsec
16:09 -!- tanvi [~Adium@public.cloak] has joined #webappsec
16:10 < bhill2_> Agenda bashing for F2F
16:10 < bhill2_> https://docs.google.com/document/d/1KQ_TWHBc1QBn4Xf2yJ7AYDQumuJioaGDfxbzwIJjxOI/edit
16:13 < bhill2_> mkwst: implementer interest is most important topic, and threat model discussion flows nicely into that
16:13 < bhill2_> ... what do various vendors actually care about and where should we be investing our effort
16:14 < bhill2_> dveditz: agreed on that, a few things not mentioned
16:14 < bhill2_> ... like CSP2.  Let's go through all specs and what next steps are, where are we in the process for each one.
16:14 < mkwst> bhill: Removing barriers is on the list. But doing inventory seems like it makes sense.
16:15 < mkwst> ... Very close on CSP2.
16:15 < mkwst> ... One or two features (`form-action`) that don't have two implementations.
16:15 < mkwst> ... Remove those features? Make them optional?
16:15 < mkwst> ... Want to get to REC.
16:15 < bhill2_> TOPIC: Finalizing Mixed Content to Proposed Recommendation
16:16 < bhill2_> https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/0067.html
16:16 -!- ckerschb_ [~sid407@public.cloak] has joined #webappsec
16:16 < bhill2_> Mike said on the list that if the context isn't secure, the content isn't mixed.
16:17 < bhill2_> tanvi: thought there was discussion that directive and UIR should work on insecure pages, too
16:17 < bhill2_> mkwst: UIR works on insecure pages and still tries to upgrade insecure requests
16:17 < tanvi> present+ tanvi
16:17 < bhill2_> ... but block all mixed exits early if not in a secure context because content isn't actually mixed
16:18 < bhill2_> tanvi: sounds fine, actually how our implementation works
16:18 < bhill2_> dveditz: if you are an insecure page and framed a secure page then you would have strict blocking for the secure frame, yes?
16:18 < bhill2_> mkwst: that is correct
16:18 < bhill2_> dveditz: should make sure we have a test case for that
16:18 < bhill2_> mkwst: I don't feel strongly about that behavior
16:19 < ckerschb_> present+ ckerschb
16:19 < bhill2_> ... fine to change to indicate that the directive only works in a secure context
16:19 < bhill2_> dveditz: I care that FF, Chrome and other browsers are consistent in cases like that
16:20 < bhill2_> mkwst: fairly certain that behavior is well-defined.  flag set on document that propagates down into iframes
16:20 < bhill2_> ... will test this
16:20 < bhill2_> TOPIC: sri source expressions
16:20 < mkwst> bhill: Will hold off on officially doing anything until tested. Sounds like it'll be quick.
16:21  * mkwst famous last words.
16:22 < bhill2_> neilm: idea is to add another directive to CSP to indicate that resources must have integrity tags
16:22 < bhill2_> seems to be pretty good consensus on this...
16:23 < bhill2_> 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
16:24 < bhill2_> dev: I prefer a new keyword expression for each individual -src directive rather than a new CSP directive
16:24 < bhill2_> ... for forwards/backwards compatibility reasons
16:24 < bhill2_> francois: I'm fine with either a global keyword or something in each -src directive
16:25 < bhill2_> ... I think that '*' is likely to cause problems in the future when browsers implement at a different pace
16:25 < bhill2_> neilm: would become a big problem if things were wildly all over the place
16:25 < bhill2_> ... don't know it will be that disjoint.  some of that already with things like nonces that some browsers don't understand
16:26 < bhill2_> 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
16:27 < bhill2_> dveditz: or require an integrity attribute on everything with a href and break even if we don't check it
16:27 < bhill2_> dev: so many tags...
16:27 < bhill2_> francios: still an issue if we invent a new type of subresource
16:27 < bhill2_> neilm: and pretty long
16:28 < freddyb> I suggest we don't support * but allow shorthands for sets of subresources by spec version, i.e. v1 = scripts & styles
16:29 < bhill2_> 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 *
16:30 < bhill2_> dev: I vote for not including a *
16:30 < bhill2_> francois: bring up the github discussion to the list
16:30 < bhill2_> neilm: will do it
16:30 < bhill2_> TOPIC: permissions delegation
16:31 < bhill2_> https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/0036.html
16:31 < bhill2_> https://lists.w3.org/Archives/Public/public-webappsec/2016Mar/0034.html
16:31 < bhill2_> https://noncombatant.github.io/permission-delegation-api/
16:32 < bhill2_> https://docs.google.com/document/d/1iaocsSuVrU11FFzZwy7EnJNOwxhAHMroWSOEERw5hO0/edit
16:32 < bhill2_> tanvi: I've commented on the proposal, but don't think that Raymes is here
16:32 < bhill2_> mkwst: neither Raymes or Chris is on the call...
16:32 < bhill2_> ... not sure how much value there is in discussion without either proposer
16:32 < mikeoneill> q
16:32 < bhill2_> ... I like it, think it's good and some tweaks proposed are interesting
16:33 < mikeoneill> +q
16:33  * Zakim sees mikeoneill on the speaker queue
16:33 < bhill2_> mikeoneill: I quite like it, also interested in the cookie control and embedded CSP thing from December
16:34 < bhill2_> ... seem to be addressing the same issue, would be good to discuss at the same time
16:34 < mkwst> bhill: Yes. Fits in with the conversation around threat models.
16:35 < mkwst> ... embedded widgets, ads. What control do we want to give to the embedder.
16:35 < mkwst> bhill: AOB?
16:35 < mkwst> ... Need to update CORS to point at Fetch.
16:35 < mkwst> ... Transition requests gone stale.
16:36 < mkwst> ... Need to talk with Web Platform WG to see what's going on with references to HTML.
16:36 < mkwst> ... WHATWG, etc.
16:36 < mkwst> ... mkwst is interested. Anyone else?
16:36 < mkwst> <crickets>
16:36 < mkwst> ... Will get that on the calendar.
16:36 < bhill2_> mkwst: issued an intent to ship same site attribute for cookies
16:37 < bhill2_> ... want to bring it to the attention of other browser vendors, please take a look
16:37 < bhill2_> ccowan: can you give us the elevator pitch?
16:38 < bhill2_> mkwst: if a cookie is marked as same-site, it will only be sent if the request is initiated by the same site
16:38 < bhill2_> ... example.com requesting something from example.com will send the cookie, evil.com requesting something from example.com won't have it
16:38  * mkwst Intent to Ship: https://groups.google.com/a/chromium.org/d/msg/blink-dev/csCtW3M3-wg/H5gEqBVNAwAJ
16:39  * mkwst Spec: https://tools.ietf.org/html/draft-west-first-party-cookies
16:39 < mkwst> bhill: How to feature-detect?
16:39 < mkwst> ... would love to use this if we know it'll be respected.
16:40 < mkwst> ... Want to know if the semantics will be forced or not.
16:40 < mkwst> dveditz: Looking at it as an opportunistic improvement.
16:40 < bhill2_> bhill2: would be good to know if the semantics are enforced without having to do UA string assessment
16:40 < mkwst> ... What would you do in a UA that doesn't support?
16:40 < mkwst> ... Works on browsers that don't support, but get more protection on browsers that do.
16:40 < bhill2_> dveditz: think of it as an opportunistic improvement
16:41 < mkwst> bhill: Some scenarios where you're trying to protect against CSRF'd login into some arbitrary account.
16:41 < mkwst> ... Might want to take other measures depending on the capability of UA.
16:41 < mkwst> dveditz: Would have to signal in the cookie itself
16:41 < mkwst> ... can't really decorate the cookie header without breaking soething.
16:41 < mkwst> ... could add a signaling header.
16:42 < mkwst> devd: Prefixes?
16:42 < bhill2_> dev: what about prefixes as a secondary mechanism?
16:42 < mkwst> mkwst: That would mean we'd need to signal support for prefixes.
16:43 < mkwst> bhill: DOM attribute would be enough for me.
16:43 < mkwst> ... `document.cookies.supportsSameSite`, etc.
16:43 < mkwst> ... Will think on it some more.