See also: IRC log
<bhill2_> none requested
<inserted> scribenick: mkwst
bhill2_: Normally we'd approve
minutes.
... But the automated minute uploader is down. I'll fix that up
sometime soon.
bhill2_: CSP2 is a proposed rec! Yay!
wseltzer: Reminder to remind your
AC reps to support CSP2 -> REC.
... AC review, showing of support is helpful.
bhill2_: Implementation of CSP:
Embedded Enforcement.
... `CSP-Allow-Origin`
<bhill2_> mkwst: allows an embedder to enforce a policy on an embedee
<bhill2_> ... suggest a policy for framed content, browser will only load if content agrees
<bhill2_> ... content agrees by a header listing what policy it agrees to, or if the enforced policy is subsumed by that policy
<bhill2_> ... right now we only do the CSP-Allow-Origin piece and are working on the other piece
bhill2_: Two requests for
review.
... IndexedDB. Screen Orientation.
... Still working on a process for responding to these kinds of
requests.
... Folks are encouraged to take a look at these documents and
provide feedback.
deian: To what extent can we
chime in here?
... For instance, IndexedDB says it doesn't handle PII, but
some developers do store interesting data in these
databases.
bhill2_: Everyone should feel
encouraged and empowered to chime in.
... We're all responsible for the security of the
platform.
... We're charted to advise.
... "Wide" review is intended to be wide.
... So say things if you think things should be said.
dveditz: Where do the reviews
go?
... "File comments as GitHub issues." Got it.
wseltzer: Right, folks are generally moving to GitHub. Will tag issues as "security".
bhill2_: Group by group. Each call for review will generally specify how comments should be submitted.
bhill2_: Charter expires at the
end of the year. Talked about this a bit a TPAC.
... Scope is pretty broad, covers the things we're thinking
about.
... Anti-clickjacking might end up in Intersection
Observer.
... Perhaps we should make room to give it a home?
... Discussion at TPAC.
... ArturJanc suggested that we specifically mention XSS and
CSRF.
... And carve out room for SafeNode, etc.
... And deal with large problems like timing attacks and side
channels.
wseltzer: A topic I'd like to bring to the group:
<bhill2_> wseltzer: we've been dealing with the question of normative references to Fetch for a while
wseltzer: Normative references to Fetch, etc.
<bhill2_> (will let you continue, mike, thanks)
wseltzer: Should that be in the
charter more explicitly?
... Fetch in WHATWG poses something of a challenge to the
platform because there's a split among implementers and
developers about whether they're able to use it.
... IPR policy, royalty free commitments, process around
recommendations.
... Important to some implementers.
... If we're not all looking at the same algorithms, that can
cause security issues.
... Small details around hooks matter.
... Working to offer work modes that work with WHATWG.
... Still trying to do that.
... Looking to find a mode that works with WHATWG's existing
development mode.
... Snapshot and bring levels of the spec through the REC
process.
... Patent commitments attach at the time we hit REC.
... Living standards are great for lots of things. We also need
snapshots.
... They're the pieces to which we can say folks have made
patent commitments.
bhill2_: It would be great if we
could come to agreement.
... Not sure we have anything approaching consent from the
relevant authors.
... Wouldn't be unhappy to open up the possibility of bringing
that into our scope.
... But probably best to bring into email, as it would be a
substantial extension of our scope, so folks will need to bring
it to their counsel.
dveditz: CORS?
bhill2_: We included CORS by
saying we were looking at cross-origin mashups and
cooperation.
... Fetch is bigger.
wseltzer: Taking that up would give us a clearer way to point people to active CORS development.
bhill2_: That was a concern I
heard at TPAC.
... W3C version forks SEO, etc.
... Would be good to address those concerns.
wseltzer: Taking search engine
traffic wouldn't be our goal.
... We can recommend a stable version, but recommend to
implementers that they file bugs against the development
version.
bhill2_: Objections to ArturJanc's suggestions?
[crickets]
<teddink> No objections
bhill2_: Ok. We'll prepare an updated charter, and submit it to the group for review.
bhill2_: (We == dveditz and
bhill2_)
... john_wilander_ you wanted to raise this?
john_wilander_: Right. This was
discussed back in July.
... mkwst said Chrome could capture data on usage of
`window.name`.
mkwst: I didn't do this. Sorry. :(
john_wilander_: We've started
looking into this.
... Ran into test failures from W3C.
... Mostly around iframes that navigate cross-origin.
... Could be starting from unique going to non-unique.
... Embedder has named the frame, addresses the frame through
its name.
... More concerned about top-origin navigation.
dveditz: Addressing frames through their name is one of the primary purposes of `window.name`, right?
john_wilander_: We started
clearing `window.name` upon cross-origin navigation.
... Breaks some tests.
dveditz: Frames and popups, sites
do that.
... At least they did 10 years ago.
john_wilander_: Were also thinking about restricting length or characters in the string. Currently DOMString.
<deian> I think it's still the case. Some folks working on FF (bholley and bz) looked at removing window.name. They may have some metricts from looking at this
john_wilander_: Initially, this
was called out as part of the evercookie; if `window.name` is
never set, it persists.
... Persistent tracker, etc.
... Also called out as payload mechanism for XSS attacks.
... Can dump JS into `window.name`, and then use it in the
loaded page.
... Acts like an environment variable that can make it easier
to bypass XSS protections.
dveditz: So if we made it read-only, `window.open()`, etc, that would help the first case, but not the second. And it may or may not break things.
john_wilander_: Yup.
mkwst: I don't think this is a bad idea, FWIW. I didn't add metrics because I didn't think about it when I was in front of a computer, not because I think it's bad.
john_wilander_: We might ship it into Safari's tech preview to get feedback.
<bhill2_> (mike, I'll take over scribing from this topic forward, thanks)
mkwst: I'm interested in hearing what y'all hear. :)
<inserted> scribenick: bhill2_
john_wilander: brought up at
MtnView F2F, currently on a csp thread
... currently 4 safelisted request headers, of those only
Content-Type has any restrictions on it
... that means a CORS requestor can add accept, accept-language
and content-language with any characters in it
... reported when shellshock was a thing, to cross-origin send
requests to servers with shellshock payload in it
... RFC7231 implies that the content should be restricted, but
not what browsers implement
... we would like to enforce that
bhill2: any thoughts from other implementers?
mkwst: think the idea is
generally reasonable, need to skim the thread for Jonas'
concern
... seems he has issues with cors preflights generally
... notion of restricting values sent for a simple cors
preflight is probably in line with the idea of a cors
preflight
... limiting that data to protect unaware servers seems like a
good thing to do, period
dveditz: sicking is concerned that networking team weigh in
mkwst: can we put on agenda for
next call to make sure we follow up?
... get an opinion from Chrome side, Dan organize an opinion
from Mozilla
<teddink> I will make sure that someone on our networking side is looped in - they should have an opinion.
dveditz: looks like Yoshino has an opinion, not sure Sicking is reachable
john_wilander: started by looking
at mixed content with local servers
... that want to do privileged things, mostly on desktop
... companion apps set up a local websocket server so extension
can talk to local server, store things in crypto keychain,
etc.
... dropbox has brought up that they would like to have some
restrictions on this
... we treat it as mixed content, so an https page cannot talk
to a local websocket but an http page can
... we would like to say that loopback address is actually
secure and flip this
dveditz: we've already agreed to first point to treat 127.0.0.1 as secure, and we are leaning towards localhost being localhost
mkwst: not only in secure
contexts and mixed content and is in candidate rec that should
move to PR at some point
... chrome has already shipped behavior that 127.0.0.1 is
accessible from secure contexts
crispin: can someone recap what happened in last call's discussion
<mkwst> https://www.chromestatus.com/metrics/feature/timeline/popularity/1652 https://www.chromestatus.com/metrics/feature/timeline/popularity/1653
<dveditz> https://www.w3.org/2016/10/19-webappsec-minutes.html
mkwst: there are some metrics but
only for dev channel at this point, will be more useful when
they hit beta and stable
... ratio of secure to non-secure is about 1:1 on dev
channel
<dveditz> Crispin: see link above (10/19) for last minutes
crispin: we had unexpected surprises when we tried this in Edge
mkwst: I expect it will be AV
crispin: we also hit cloud
storage, DRM and CDNs
... so expect there are existing use cases that will be broken
by this
john_wilander: are you saying a page served from http is making connections to localhost?
crispin: two years ago Edge made
an attempt to do this, just blocked it
... a fair number of important partner organizations said we
broke them
... they were using real local servers that they wanted to talk
to
john_wilander: we have at least two password managers
mkwst: suggests a few
things
... 1. treat workers as scripts, not as child contexts
... 2. move worker-src to sit on top of script-src
<mkwst> https://www.chromestatus.com/metrics/feature/timeline/popularity/258
mkwst: think this is reasonable,
anne asked for it a while ago
... other question is whether various types of workers should
have their own policy
... or should inherit the policy of the page that creates
it
... Brian's suggestion is that dedicated workers are scripts
and should have the same policy
<mkwst> https://twitter.com/mikewest/status/798464142206087168
<deian> +1 in favor of these changes
mkwst: people have no idea what
we are doing so there is opportunity to change it
... to me making a shared/service worker dependent on the
context of the page that created it seems strange
<deian> I'm with you on it being strange. Though the suggestions for normal workers sounds good to me
<mkwst> bhill2_: Yeah, I think we went with this direction because it would be strange for shared/service worker behavior to be dependent upon the page that opened them.
mkwst: would be good if folks interested hop onto that github thread
https://github.com/w3c/webappsec-referrer-policy/pull/77
bhill2: <rambling summary of thread>
mkwst: think jochen wants to do
minimal amount of work, not clear what that is
... if we could get a commitment from Firefox as to what they
would ship, that would help
... emily wants to do minimum amount of work to call Referrer
Policy done, move to CR and be done
... I think this makes sense, if we can come to a compromise
that would be great
... fits well with what referrer policy should do, is a good
idea regardless of Firefox shipping
bhill2: is pairwise compare OK?
mkwst: prefer that
<terri> +1 to moving it up one week for dec
<wseltzer> [Dec 14]