See also: IRC log
<dveditz> regrets bhill2
<dveditz> scribenick mkwst
<dveditz> https://www.w3.org/2016/07/13-webappsec-minutes.html
<dveditz> no objections, minutes approved
<mkwst> dveditz: Objections?
<mkwst> everyone: <crickets>
<mkwst> dveditz: Approved!
<dveditz> https://irccloud.mozilla.com/pastebin/ZsivtKfe
<mkwst> dveditz: TPAC is coming!
<mkwst> ... Our meeting is 22nd/23rd (Thursday and Friday)
<mkwst> ... Wed is a plenary day.
<mkwst> ... Hotels go quickly. If you're going, book fast.
<mkwst> ... MIX is republished as CR.
<mkwst> ... https://www.w3.org/TR/2016/CR-mixed-content-20160802/
<mkwst> ... Hope to PR soon.
<dveditz> https://lists.w3.org/Archives/Public/public-webappsec/2016Jul/0013.html
<mkwst> dveditz: No objections to moving three working drafts to NOTE.
<mkwst> ... CSP pinning, Entry Point Regulation, CSP Cookie Stuff
<dveditz> scribenick estark
<dveditz> https://lists.w3.org/Archives/Public/public-webappsec/2016Jul/0046.html
dveditz: origin-wide policy
manifest came up
... is that different from feature policy?
mkwst: different thing entirely,
"origin manifest" might be a better name
... 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
... manifest file on origins. response points to manifest.
browser synchronously downloads and applies to response before
rendering a page
... conceptually similar to policy URI mechanism in initial
drafts of CSP, which FF implemented and shipped
... more broad, applies not just to CSP, to anything and
everything delivered via HTTP headers
... enable changes to CORS, preflights on an origin-wide basis,
a couple other things
<mkwst> https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0351.html
mkwst: mark nottingham has a
draft for a similar concept in http wg
... informs many origin policy things; his draft is more
focused on header and delivery mechanism
... he's concerned with the manifest format, how it would
interact with middleboxes in addition to server/browser
... mark thinks his format would be better for
middleboxes
... and better for server implementors
... basic idea is the same, I need to sit down and figure out
with mark what the advantages of each are
estark: performance? is server push the be-all-end-all?
mkwst: server push is the only
thing that makes it viable. perf characteristics should be
similar to delivering a header
... we'll have to experiment a bit
... doc doesn't require server push. practically speaking, big
perf impact on initial request, probably wouldn't want to
recommend without server push
dveditz: presumably after initial receipt it would be cached
mkwst: manifest file is an HTTP
request like any other, it has cache headers served along with
it
... hopefully will simplify implementation
dveditz: hope that we only end up with one of those features
<dveditz> estark: are we talking about making this for secure contexts only?
<dveditz> mkwst: that's how it's currently specified, I think it would be bad otherwise
mkwst: currently specified that way, bad to specify it otherwise
<dveditz> https://github.com/w3c/webappsec-csp/issues/98
<dveditz> https://github.com/w3c/webappsec-csp/issues/65
dveditz: issues in CSP spec about
preventing nonce stealing
... whether it's practical to try to prevent, what the threat
model is
... anne filed #65, suggesting we don't expose nonce to the
page in the DOM
... artur filed #98 about dangling markup injection
mkwst: dangling markup in general
would be amazing to solve
... interesting for things like ???, but secondary
benefit
... small changes to parser which would neuter specific kinds
of injection
... artur concerned with script injection
... if you inject a script before a nonced script, nonce could
be applied to injected script rather than actual script
... if you have a src attribute and inline, reject the tag
during parsing
... solves very specific problem of scripts, but not injecting
a textarea along with a form
... would be great to have a more general solution
dveditz: another technique is if
you find an angle bracket inside an open tag, reject that
... ultimately becomes topic for HTML wg, not us
specifically
mkwst: solution will be in HTML, any ideas welcome
<dveditz> https://github.com/w3c/webappsec-secure-contexts/issues/42
dveditz: if you have an opener
referring to an insecure context, does that make your context
insecure?
... should we drop the opener, when can we drop the opener, is
the current secure context spec too strict
mkwst: jake raised in context of
service workers, which want to be able to control top-level
navigation
... they want to drop opener for service-worker controlled
top-level navigations
... 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
... 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
... will go to CR with current spec as written
... during CR period, figure out if there's something else we
should do
dveditz: does chrome team have telemetry on use of opener?
mkwst: nothing that's useful.
might have counter on window.open, but do not have counter on
use of opener from a new context
... 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.
dveditz: and whether it's a open from window.open or link with a target
mkwst: we don't have that, would be helpful
dveditz: neither does FF
... would really like to get rid of opener
mkwst: some valid use cases,
OAuth or OpenID
... 3rd party auth where it goes in a popup and you auth in the
popup, uses opener to pass info back to page
dveditz: definitely cases in past where opener was used from popups, not sure about pages opened from a link
mkwst: would be good to find
subsets we can disable
... maybe could make it explicit, not implicit, when you open a
link
... need data to figure that out
<dveditz> https://github.com/w3c/webappsec-secure-contexts/issues/43
dveditz: FF implementation accepts localhost as a secure context in at least one context
mkwst: we accept localhost on
stable as well, made this change relatively recently
... might be in beta, rolling through chrome's release train
right now
... as long as there are resolvers that will send localhost to
network for resolution, right thing is to treat localhost as
non-secure
... what we agreed in f2f
... would be great if we could do what people expect and treat
localhost as always loopback
dveditz: insecure for specific people in specific cases that page author woudl have no control of
mkwst: correct except that page
author on localhost is probably same person administrating
computer
... I'm concerned about only treating localhost as secure
depending on what it resolves to
... should avoid that confusion
... page would work or not work depending on net
configuration
... could add something like: if UA always resolves to
loopback, then they can treat it as a secure context
... not the way our implementation works in Chrome
... could change all the RFCs to MUST, or not, in which case
localhost should be non-secure
dveditz: but you said chrome in dev might be treating it as secure?
mkwst: no, in canary and dev and
maybe beta, we treat localhost as non-secure
... in stable it's secure, in canary it's nonsecure, in-between
who knows
dveditz: so shipping version treats localhost as secure?
mkwst: pretty sure, yes
dveditz: oh, so the issue is asking for it to go back to the way it was
mkwst: sympathetic to the idea, but only if we can change all the RFCs
estark: how does dns resolution in FF work? system resolver?
dveditz: yes, I believe so. our
own caching, but not our own resolver
... for making security decisions, we don't know the DNS
resolution at that point
... would be very hard for us to make the proposed change where
we treat it as secure if it resolves to loopback
... might end up making changes to make that easier, because of
protecting RFC1918 networks
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