<mkwst> https://lists.w3.org/Archives/Public/public-webappsec/2018Jun/0004.html

Minutes approval

<mkwst> https://www.w3.org/2018/05/16-webappsec-minutes.html

<dveditz> mkwst: any objection to approving those minutes from the last meeting?

<dveditz> ... hearing none we'll run with them

<dveditz> scribenick: dveditz

mkwst: news items -- looks like safari 12 will have some interesting things in it
... <list of items linked from agenda>. John?

wilander: we'll also have same-site cookies

mkwst: nice to see Edge and surprisingly IE will also now support same-site cookies

<mkwst> https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-06

mkwst: the HTTP group is defining structured headers, and since we define more headers than anyone else it's worth us taking a look at this proposal
... they want a format that can have a single parser, perhaps a binary format rather than an ascii format
... written primarily by mnot and ?? and they'd appreciate feedback from us and others interested in http headers
... Other specs that want to define a header will specify a structure and then defer the serialization to this specification
... Limitations: reporting headers use JSON and to some extent nesting. Structured headers don't support that (discussions ongoing). Things like that would be good to look into

Spec Backlog

mkwst: next steps in nearly done specs
... I pulled out 4 candidates that seemed worth talking about

<wseltzer> https://www.w3.org/TR/mixed-content/

mkwst: according to WPT we have agreement between chrome and firefox on mixed content, less agreement with edge and safari

<wseltzer> https://www.w3.org/TR/secure-contexts/

mkwst: we meet the two implementations there. we seem to have two implementations that match secure contexts (though some disagreement about nested contexts)
... credential management -- we talked about splitting the spec in TPAC, and we have agreement on parts. Hung up on nitty spec details to finish up but not a content disagreement.
... jeffh were you still working on that? is it still moving?

jeffh: been busy but we're trying to get webauthn to agreement this summer and I'll get it moving

mkwst: if there's a dependency on it from webauthn we need to get it done first, but otherwise I'm not ....

wseltzer: normally dependencies should only be on specs that are at the same level of the process or higher.
... it's possible the director could agree to the stability of the feature even if the spec structure itself is expected to change

johnwilander: should mixed-content be labelled "level 1"?

mkwst: I've heard rumblings about "living specs"

wseltzer: we've been investigating what it would take to adopt a "living spec" approach in W3. It has implications on IP and it could be a while before that became an official work mode

mkwst: in that case john's suggestion is on point and we should call it "level 1"
... do we need to pull it back from CR to change the name?

wseltzer: not to just change the name

<wseltzer> https://www.w3.org/TR/upgrade-insecure-requests/

mkwst: the last one is UIR. there's a couple failing tests in chrome but we have good interop between browsers

<estark> (I'm not sure which uir tests are failing in Chrome but at least some of them should be newly passing in canary as of last week)

<wseltzer> PROPOSED: Advance Mixed Content, Secure Contexts, Upgrade Insecure Requests, and split Credential Management

mkwst: I'm going to send mail to the list asking to advance MIX and SECURE from CR to REC, Cred Man to CR, and UIR to CR

Cross-origin data leakage

mkwst: there are a couple proposals here I want to make sure people are paying attention to
... * Cross-Origin-Resource-Policy is the name for the thing that used to be "From-Origin"

<mkwst> https://github.com/web-platform-tests/wpt/tree/master/fetch/cross-origin-resource-policy

mkwst: and Annevk has an update to the fetch spec on this and making WPT tests
... good idea to look at the algorithm anne wrote as well as the Safari 12 implementation to verify it does what it says and solves the problems we think it solves

johnwilander: it's in beta 2, the first public beta I think released yesterday
... CORP was still called from-origin in beta 1
... another thing that comes up is the "Same Site" concept. I think we should adopt this in as many of these headers as possible
... same-site is based on the host, ignoring port, and special rules for the scheme.
... we'd like to add this to x-frame-option and csp frame-ancestors

mkwst: we always have to worry about backwards compat in CSP. could be a small thing to add and worth our time especiall for frame ancestors
... for XFO I'm think it's a no-op in chrome, that sameorigin actually is treated as same-site
... we made recent changes to make sameorigin walk the ancestor tree, and I think we now have different behavior from Firefox.
... might have loosened sameorigin to same-site in that case
... if this is easier for developers could be worth making the change. I worry that XFO has wide adoption (double-digits) and sites might be written assuming the original behavior. but consistent behavior across headers is good

johnwilander: would like sites to be able to say "last checked for spec compliance in 2012" so we know what behaviors to use

mkwst: we had that with doctype and quirks mode -- not sure that's the best model

ArturJanc: I believe what mike said about XFO being samesite doesn't sound right to me -- pretty sure sameorigin is sameorigin
... otherwise this would cause problems on sites depending on the stricter behavior
... I like the samesite definition for CORP. I worry about the backwards compat implications for developers
... deployment might get tricky

mkwst: just looked at the code and I was wrong. sameorigin is origin, not site

dveditz: can't you get same-site behavior in CSP using the wildcard feature?

mkwst: yes, this would be syntactic sugar

johnwilander: there are differences in wildcard in certs and in CSP. also does the scheme behavior match samesite behavior?

ArturJanc: doesn't csp already do something similar if there's no scheme?

mkwst: csp does the opposite -- if you're an HTTP document then schemeless also matches https resources, to make it easier for sites to upgrade to secure behavior.
... next is "* Cross-Origin-Window-Policy"

<mkwst> https://github.com/whatwg/html/issues/3740

mkwst: conversation in github and implementation in safari beta

johnwilander: this is about window.open() -- the opened site doesn't know who opened it, but that possibly-evil site has a handle to it.
... with this header you could say cross-origin-window-policy; deny -- so such sites lose their reference to you
... discussion brought up various other ways to navigate that should honor this headers
... and then it's useful for sites to be able to postMessage() so there's a lax form that allows that

mkwst: does the goal include frames wishing to divorce themselves from their parents?

johnwilander: this was discussed but I can't remember how it got implemented

mkwst: the anti-malvertising team has been interested in having sites served on the same origin to not be able to talk to themselves
... imagine two doubleclick frames on a page. one can walk up the frame tree and down into the other, where it's now same-origin
... we had an old proposal for this that required changing document.domain -- if you set it to null we'd always fail the same-origin check without doing additional work. IIRC people weren't happy with that approach

<mkwst> https://github.com/whatwg/html/issues/2757

johnwilander: checking the scenario -- in doubleclick you're in control of what headers you can send, but not what scripts are running?

<mkwst> https://github.com/whatwg/html/issues/2757#issuecomment-308539157

mkwst: yes, we might serve an essentially blank origin container and then run an ad in it, and ads can do interesting things
... see the github comment.

<jeffh> https://github.com/whatwg/html/issues/3740

mkwst: please look over the COWP proposal. it's interesting and would definitely benefit from feedback

<mkwst> https://mikewest.github.io/sec-metadata/

mkwst: next * Sec-Metadata
... bad name because everything is metadata, but the notion is we send a little info to the server about how the request was made so the server can make some decisions about whether to send the response or not
... one of the threats we talked about was when an attacker can see your traffic (coffee shop wifi?)
... we have an implementation in canary behind a flag that people can play with
... would love feedback from potential users (developers) and also browser vendors
...

<scribe> scribenick: mkwst

dveditz: TPAC is in October! 22nd - 26th!

<wseltzer> https://www.w3.org/2018/10/TPAC/

dveditz: We're currently scheduled for one day.
... Tuesday.
... In the past, we've been scheduled for two days, usually used a day and a half.
... will be a little tighter this year.
... (Tuesday the 23rd)

<ArturJanc> some comments about how Sec-Metadata compares to the other cross-origin restrictions from the TAG review: https://github.com/w3ctag/design-reviews/issues/280#issuecomment-397265773

dveditz: We should plan out what we'd like to get done.

wilander: If two days, we could have a full day on anti-Spectre work.
... Lots of work going on, CORP, COWP, etc.
... Gave a talk at WWDC: https://developer.apple.com/videos/play/wwdc2018/207
... Pushing on these kinds of countermeasures.
... These are complicated.

weiler: There's some flexibility to get a little more time.

<jeffh> which day is webauthn on?

weiler: WebAppSec and WebAuthn have one day each.
... Wanted to avoid conflict.
... Still some slack in the schedule.
... will need to fight with WebAuthn.

wilander: Anti-Spectre is a little different.
... To a large part about defending the same-origin policy in the browser engine.

<dveditz> jeffh: monday 10/22, for one day

wilander: Affects infrastructure of the web.
... Developers might need to opt-in to avoid breakage.

<jeffh> dveditz: thx

mkwst: That does sound like an important topic! We should talk about it regardless of how much time we end up with at TPAC.

dveditz: What's the best way to collect topics?
... Google Doc?
... Email on the list?

mkwst: Email to the list sounds like the right place to start.

dveditz: GitHub issues maybe?
... Canonical place that's updated.

mkwst: SGTM.

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Am I the only one unable to join with WebEx (Android app)?//
Succeeded: s/@wseltzer thanks, will keep trying then :(//
Present: ArturJanc ckerschb__ dveditz estark gmaone jeffh johnwilander jyasskin mkwst pranjal terri weiler wseltzer
Found ScribeNick: dveditz
Found ScribeNick: mkwst
Inferring Scribes: dveditz, mkwst
Scribes: dveditz, mkwst
ScribeNicks: dveditz, mkwst
Found Date: 20 Jun 2018
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)