16:01:53 <RRSAgent> RRSAgent has joined #webappsec
16:01:53 <RRSAgent> logging to http://www.w3.org/2016/08/10-webappsec-irc
16:01:55 <francois> present+ francois
16:02:04 <Zakim> Zakim has joined #webappsec
16:02:20 <dveditz> present+ dveditz
16:02:22 <francois> present+ francois
16:02:24 <dveditz> Zakim, who is here
16:02:24 <Zakim> dveditz, you need to end that query with '?'
16:02:28 <dveditz> Zakim, who is here?
16:02:28 <Zakim> Present: dveditz, francois
16:02:30 <Zakim> On IRC I see RRSAgent, estark, francois, ArturJanc, dydz, bblfish, gszathmari, dveditz, schuki, adrianba, tobie, mkwst, Josh_Soref, slightlyoff, Jb, MattN, terri, Mek_, jyasskin,
16:02:30 <Zakim> ... timeless, jochen___, jww, mounir, wseltzer_off, trackbot
16:02:37 <dveditz> present+ estark
16:02:46 <mkwst> present+ mkwst
16:02:51 <ckerschb_> ckerschb_ has joined #webappsec
16:03:07 <dveditz> regrets bhill2
16:03:12 <puhley> puhley has joined #webappsec
16:04:01 <gmaone> gmaone has joined #webappsec
16:04:17 <terri> present+ terri
16:04:38 <ckerschb_> present+ ckerschb_
16:04:55 <dveditz> agenda: https://lists.w3.org/Archives/Public/public-webappsec/2016Aug/0004.html
16:05:02 <teddink> teddink has joined #webappsec
16:05:09 <bhill2> bhill2 has joined #webappsec
16:05:15 <teddink> present+ teddink
16:06:15 <dveditz> TOPIC: Agenda bashing
16:06:15 <gmaone> present+ gmaone
16:07:07 <dveditz> Zakim, who is here?
16:07:07 <Zakim> Present: dveditz, francois, estark, mkwst, terri, ckerschb_, teddink, gmaone
16:07:10 <Zakim> On IRC I see bhill2, teddink, gmaone, puhley, ckerschb_, Zakim, RRSAgent, estark, francois, ArturJanc, dydz, bblfish, gszathmari, dveditz, schuki, adrianba, tobie, mkwst,
16:07:10 <Zakim> ... Josh_Soref, slightlyoff, Jb, MattN, terri, Mek_, jyasskin, timeless, jochen___, jww, mounir, wseltzer_off, trackbot
16:07:43 <dveditz> scribenick mkwst
16:08:17 <dveditz> TOPIC: Minutes approval
16:08:29 <dveditz> https://www.w3.org/2016/07/13-webappsec-minutes.html
16:08:55 <dveditz> no objections, minutes approved
16:08:56 <mkwst> dveditz: Objections?
16:09:05 <mkwst> everyone: <crickets>
16:09:09 <mkwst> dveditz: Approved!
16:09:16 <mkwst> TOPIC: News
16:09:21 <dveditz> https://irccloud.mozilla.com/pastebin/ZsivtKfe
16:09:41 <mkwst> dveditz: TPAC is coming!
16:09:54 <mkwst> ... Our meeting is 22nd/23rd (Thursday and Friday)
16:10:03 <mkwst> ... Wed is a plenary day.
16:10:24 <mkwst> ... Hotels go quickly. If you're going, book fast.
16:10:43 <mkwst> ... MIX is republished as CR.
16:10:52 <mkwst> ... https://www.w3.org/TR/2016/CR-mixed-content-20160802/
16:11:11 <mkwst> ... Hope to PR soon.
16:11:26 <dveditz> TOPIC: Call for Consensus: Stop work and transition 3 WD to Notes
16:11:26 <dveditz> https://lists.w3.org/Archives/Public/public-webappsec/2016Jul/0013.html
16:12:07 <mkwst> dveditz: No objections to moving three working drafts to NOTE.
16:12:28 <mkwst> ... CSP pinning, Entry Point Regulation, CSP Cookie Stuff
16:12:47 <dveditz> scribenick estark
16:12:59 <dveditz> TOPIC: Origin-wide policy manifest
16:12:59 <dveditz> https://lists.w3.org/Archives/Public/public-webappsec/2016Jul/0046.html
16:13:09 <estark> dveditz: origin-wide policy manifest came up
16:13:14 <estark> ... is that different from feature policy?
16:13:27 <estark> mkwst: different thing entirely, "origin manifest" might be a better name
16:14:06 <estark> ... feature policy is a specific policy delivered w/ a resource, applies to that resource. origin-wide policy mechanism applies to every page on an origin without 3-4k of a policy mechanism on every response
16:14:38 <estark> ... manifest file on origins. response points to manifest. browser synchronously downloads and applies to response before rendering a page
16:14:56 <estark> ... conceptually similar to policy URI mechanism in initial drafts of CSP, which FF implemented and shipped
16:15:11 <estark> ... more broad, applies not just to CSP, to anything and everything delivered via HTTP headers
16:15:22 <estark> ... enable changes to CORS, preflights on an origin-wide basis, a couple other things
16:16:07 <mkwst> https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0351.html
16:16:17 <estark> mkwst: mark nottingham has a draft for a similar concept in http wg
16:16:34 <estark> ... informs many origin policy things; his draft is more focused on header and delivery mechanism
16:16:53 <estark> ... he's concerned with the manifest format, how it would interact with middleboxes in addition to server/browser
16:16:59 <estark> ... mark thinks his format would be better for middleboxes
16:17:08 <estark> ... and better for server implementors
16:17:35 <estark> ... basic idea is the same, I need to sit down and figure out with mark what the advantages of each are
16:18:15 <estark> estark: performance? is server push the be-all-end-all?
16:18:29 <estark> mkwst: server push is the only thing that makes it viable. perf characteristics should be similar to delivering a header
16:18:39 <estark> ... we'll have to experiment a bit
16:19:00 <estark> ... doc doesn't require server push. practically speaking, big perf impact on initial request, probably wouldn't want to recommend without server push
16:19:14 <estark> dveditz: presumably after initial receipt it would be cached
16:19:40 <estark> mkwst: manifest file is an HTTP request like any other, it has cache headers served along with it
16:19:49 <estark> ... hopefully will simplify implementation
16:20:10 <estark> dveditz: hope that we only end up with one of those features
16:20:39 <dveditz> estark: are we talking about making this for secure contexts only?
16:20:41 <bblfish> bblfish has joined #webappsec
16:20:53 <dveditz> mkwst: that's how it's currently specified, I think it would be bad otherwise
16:20:54 <estark> mkwst: currently specified that way, bad to specify it otherwise
16:21:21 <dveditz> TOPIC: [CSP] Prevent nonce stealing
16:21:21 <dveditz> https://github.com/w3c/webappsec-csp/issues/98
16:21:21 <dveditz> https://github.com/w3c/webappsec-csp/issues/65
16:21:33 <estark> dveditz: issues in CSP spec about preventing nonce stealing
16:21:53 <estark> ... whether it's practical to try to prevent, what the threat model is
16:22:19 <estark> ... anne filed #65, suggesting we don't expose nonce to the page in the DOM
16:22:49 <estark> ... artur filed #98 about dangling markup injection
16:23:05 <estark> mkwst: dangling markup in general would be amazing to solve
16:23:41 <estark> ... interesting for things like ???, but secondary benefit
16:24:04 <estark> ... small changes to parser which would neuter specific kinds of injection
16:24:11 <estark> ... artur concerned with script injection
16:24:28 <estark> ... if you inject a script before a nonced script, nonce could be applied to injected script rather than actual script
16:24:42 <estark> ... if you have a src attribute and inline, reject the tag during parsing
16:24:59 <estark> ... solves very specific problem of scripts, but not injecting a textarea along with a form
16:25:06 <estark> ... would be great to have a more general solution
16:26:16 <estark> dveditz: another technique is if you find an angle bracket inside an open tag, reject that
16:26:40 <estark> dveditz: ultimately becomes topic for HTML wg, not us specifically
16:26:52 <estark> mkwst: solution will be in HTML, any ideas welcome
16:27:03 <dveditz> TOPIC: .opener and secure contexts
16:27:03 <dveditz> https://github.com/w3c/webappsec-secure-contexts/issues/42
16:27:35 <estark> dveditz: if you have an opener referring to an insecure context, does that make your context insecure?
16:27:49 <estark> ... should we drop the opener, when can we drop the opener, is the current secure context spec too strict
16:28:17 <estark> mkwst: jake raised in context of service workers, which want to be able to control top-level navigation
16:28:32 <estark> ... they want to drop opener for service-worker controlled top-level navigations
16:29:04 <estark> ... marked as at-risk, would be nice if we could get rid of it, if security of new context did not depend on the way it was opened
16:29:25 <estark> ... in status quo, this is what we should be doing, and SW folks are okay with currently described mechanism, given the work-around on their end
16:29:33 <estark> ... will go to CR with current spec as written
16:29:48 <estark> ... during CR period, figure out if there's something else we should do
16:30:03 <estark> dveditz: does chrome team have telemetry on use of opener?
16:30:16 <estark> mkwst: nothing that's useful. might have counter on window.open, but do not have counter on use of opener from a new context
16:30:37 <estark> ... would be useful to add such telemetry, e.g. whether opener is being used same- or cross-origin, after top-level navigation or initial page, etc.
16:30:49 <estark> dveditz: and whether it's a open from window.open or link with a target
16:31:05 <estark> mkwst: we don't have that, would be helpful
16:31:08 <estark> dveditz: neither does FF
16:31:12 <estark> ... would really like to get rid of opener
16:31:34 <estark> mkwst: some valid use cases, OAuth or OpenID
16:31:47 <estark> ... 3rd party auth where it goes in a popup and you auth in the popup, uses opener to pass info back to page
16:32:03 <estark> dveditz: definitely cases in past where opener was used from popups, not sure about pages opened from a link
16:32:20 <estark> mkwst: would be good to find subsets we can disable
16:32:30 <estark> ... maybe could make it explicit, not implicit, when you open a link
16:32:33 <estark> ... need data to figure that out
16:32:44 <dveditz> TOPIC: is "localhost" a secure context?
16:32:44 <dveditz> https://github.com/w3c/webappsec-secure-contexts/issues/43
16:33:41 <estark> dveditz: FF implementation accepts localhost as a secure context in at least one context
16:33:53 <puhley> puhley has joined #webappsec
16:34:08 <estark> mkwst: we accept localhost on stable as well, made this change relatively recently
16:34:18 <estark> ... might be in beta, rolling through chrome's release train right now
16:34:36 <estark> ... as long as there are resolvers that will send localhost to network for resolution, right thing is to treat localhost as non-secure
16:34:42 <estark> ... what we agreed in f2f
16:35:02 <estark> ... would be great if we could do what people expect and treat localhost as always loopback
16:35:17 <estark> dveditz: insecure for specific people in specific cases that page author woudl have no control of
16:35:29 <estark> mkwst: correct except that page author on localhost is probably same person administrating computer
16:35:44 <estark> ... I'm concerned about only treating localhost as secure depending on what it resolves to
16:35:55 <estark> ... should avoid that confusion
16:36:01 <estark> ... page would work or not work depending on net configuration
16:36:15 <estark> ... could add something like: if UA always resolves to loopback, then they can treat it as a secure context
16:36:25 <estark> ... not the way our implementation works in Chrome
16:36:37 <estark> ... could change all the RFCs to MUST, or not, in which case localhost should be non-secure
16:36:59 <estark> dveditz: but you said chrome in dev might be treating it as secure?
16:37:18 <estark> mkwst: no, in canary and dev and maybe beta, we treat localhost as non-secure
16:37:48 <estark> mkwst: in stable it's secure, in canary it's nonsecure, in-between who knows
16:37:54 <estark> dveditz: so shipping version treats localhost as secure?
16:37:59 <estark> mkwst: pretty sure, yes
16:38:17 <estark> dveditz: oh, so the issue is asking for it to go back to the way it was
16:38:33 <estark> mkwst: sympathetic to the idea, but only if we can change all the RFCs
16:38:51 <estark> estark: how does dns resolution in FF work? system resolver?
16:38:59 <estark> dveditz: yes, I believe so. our own caching, but not our own resolver
16:39:17 <estark> ... for making security decisions, we don't know the DNS resolution at that point
16:39:27 <estark> ... would be very hard for us to make the proposed change where we treat it as secure if it resolves to loopback
16:39:42 <gmaone> gmaone has joined #webappsec
16:39:54 <estark> ... might end up making changes to make that easier, because of protecting RFC1918 networks
16:40:10 <gmaone> present+ gmaone
16:40:59 <estark> estark: a bit of a mess in chrome; uses system resolver on some platforms, always resolves to loopback on other platforms but that causes problems for certain use cases
16:41:38 <bblfish> bblfish has joined #webappsec
16:42:06 <ckerschb_> ckerschb_ has left #webappsec
16:42:34 <dveditz> rrsagent, make minutes
16:42:34 <RRSAgent> I have made the request to generate http://www.w3.org/2016/08/10-webappsec-minutes.html dveditz
16:43:05 <dveditz> zakim, list attendees
16:43:05 <Zakim> As of this point the attendees have been dveditz, francois, estark, mkwst, terri, ckerschb_, teddink, gmaone
16:43:11 <dveditz> rrsagent, make minutes
16:43:11 <RRSAgent> I have made the request to generate http://www.w3.org/2016/08/10-webappsec-minutes.html dveditz
16:43:20 <dveditz> rrsagent, set logs world
17:28:56 <yoav> yoav has joined #webappsec
18:10:18 <bblfish> bblfish has joined #webappsec
18:50:11 <Zakim> Zakim has left #webappsec
21:03:29 <bhill2> bhill2 has joined #webappsec
21:50:38 <bhill2> bhill2 has joined #webappsec
21:54:04 <bhill2> bhill2 has joined #webappsec
22:33:41 <bhill2_> bhill2_ has joined #webappsec
23:01:41 <dydz> dydz has joined #webappsec
23:07:04 <yoav> yoav has joined #webappsec