<wseltzer> mkwst: reviewing agenda

<scribe> scribe: dveditz

specs that are almost done

<wseltzer> scribenick: dveditz

Referrer Policy

mkwst: I apologize in advance I didn't get web platform tests running on Edge so I only have data for other browsers
...: RP went to PR in Jan 2017. waiting for implementation of a couple of things
... 6 open issues
... "should ping-from be controlled by RP?"

<wseltzer> https://github.com/w3c/webappsec-referrer-policy/issues/

jochen___: the author put the ping-from on the attribute, if he didn't want the referrer he could also put a referrerpolicy attribute on the element

estark: I agree, RP should control referrers, not things that are not referrers.

mkwst closes the issue
...: #74 editorial/typo --- assign to jochen___
... #82 also editorial, not even sure this is in the document anymore

estark: there's an interesting question here... if you're going from a valid TLS state to a broken one, would we want to strip referrers? Chrome isn't interested in doing that
...: if we don't implement that we may want to just look for the scheme of the origin being https and leave it at that.

mkwst: if no browser has implemented this we should leave it and if we need to add it in v2 we can do that
...: #96 RP attribute missing on script tags -- should fix, everyone assumes it's there
... #108 SVG doesn't say how it loads resources, so no hooks for RP to say how its resources are loaded
... #109 RP of child CSS

jochen___: there's a WPT for that

mkwst: WPT test results. Chrome passing all. Firefox passing a lot but two bugs killed a bunch of tests
...: Safari failing about half, but some are test failures (plus a couple of webkit bugs). would be great if apple folks could point me at folks who could help fix the canvas issues
... I'm hopeful when Firefox fixes their bugs we'll have two interoperable implementations and can proceed

wseltzer: have we gotten "wide review"?

mkwst: ...

<bhill2> the webex link in the agenda is only for the regular concall, so I can't join ("not started")

<bhill2> maybe at the next break, before CredMan, someone could see if an ad-hoc one can be started?

wseltzer:

jochen___: ... concerned that feedback at rec time could derail things. Feedback should have come on FPWD

@@: https://www.w3.org/2011/webappsec/webex.html -- TPAC

bhill2: https://www.w3.org/2011/webappsec/webex.html --- TPAC section at bottom

<bhill2> OIC. thx

sangwhan: TAG actually recommends having explainers at early stage for review, to get meaningful feedback

mkwst: I think we're doing a better job on newer specs. E.g. blink requires as part of the "intent to ship" process to send an explainer to the TAG
...: formally we'll send mail out, get no response, and say we got wide review. Two implementations is a better demonstration of wide review

<wseltzer> ACTION: mkwst and dveditz to send call for wide review for Referrer Policy

<trackbot> Created ACTION-218 - And dveditz to send call for wide review for referrer policy [on Mike West - due 2017-11-13].
...: we should be ready (dan and I) to send out for wide review and a transition request

secure contexts

mkwst: CR in Sept 2016
...: two issues, data: edgecases.
... may not be an issue now that Mozilla treats data as an opaque origin in all cases
... next issue is "secure stylesheets" -- will have to cache state when CSS is parsed

<wseltzer> https://github.com/w3c/webappsec-secure-contexts
...: writing tests will be difficult because there aren't any css features restricted to secure contexts yet
... chrome failing some tests (3 bugs) -- missing nested workers, SharedWorker connection, and Worker's document's ancestors
... firefox passes most, single bug "opener" doesn't influence secureness anymore
... safari basically missing the things Chrome is
... should have interoperability very soon

<wseltzer> ACTION: mkwst and dveditz to send call for wide review for Secure Contexts

<trackbot> Created ACTION-219 - And dveditz to send call for wide review for secure contexts [on Mike West - due 2017-11-13].

upgrade-insecure-requests

mkwst: FIrefox has a great implementation, passing everything
...: open issue, need to upstream some language to HTML

<wseltzer> https://github.com/w3c/webappsec-upgrade-insecure-requests/issues
...: issue about Vary header, I'll work on that.
... safari and chrome have an issue with redirects, otherwise fine
... does edge support this?

angelo: we do not

johnwilander: is the order of UIR and HSTS specified, especially with redirects?

mkwst: yes, well specified

johnwilander: will be hard for us to do redirects and upgrades

mixed-content

...: CR in March 2015, republished Aug 2016
... one open issue. Media is optionally blockable (will be shown) but Tracks are blockable. got a complaint this harms accessibility
... seems reasonable. Do we stop blocking Track, or do we get more aggressive and solve the accessibility problem by also blocking the Media?
... from my POV I'd like to make things stricter rather than loser in general. Given the usage I don't really care -- not used much.
... mixed-content text track is practically indistinguishable from zero, but in theory it's inconsistent

dveditz: the inconsistency is sort of fingernails-on-chalkboard, but I don't really care because it's not used much
...: Fx fails 6 tests because link rel=prefetch considered blockable. but in fact I prefer Firefox's behavior.

<scribe> ACTION: dveditz to file issue on the spec to match Firefox behavior

<trackbot> Created ACTION-220 - File issue on the spec to match firefox behavior [on Daniel Veditz - due 2017-11-13].
...: safari fails a few more tests, some for unrelated things (like error events being fired in particular ways)
... also no support for prefetch and also and

mkwst: the stated goal of the spec is to eventually block all mixed content
...: images are "less dangerous" and "widely used" so they're getting a pass at the moment

danbates: I don't see a lot of value in treating them as blockable other than "can we get away with it"

johnwilander: I think the media stack in mobile is different enough that it might be worth splitting these out. I hope we behave the same on desktop and mobile but we need to check.

danbates: I'd like to hear what edge does

mkwst: me too

credential management

mkwst: specifically want to talk about integration with web authn so we're not blocking them going forward
...: sent a couple questions to public-webappsec

<wseltzer> https://lists.w3.org/Archives/Public/public-webappsec/2017Oct/0016.html
...: AFAIK chrome is the only browser that has implemented the in-browser password management
... doesn't look like password and federated credentials will be able to go to PR and then Rec any time soon because of lack of other implementations
... one option would be to split the spec. Tried it once and got feedback that it made things too complicated (which I agree with), but from a process perspective it could be helpful to split
... wendy, what happens if web authn tries to go to PR referencing our spec that's not implemented

wseltzer: they'd be asked about the stability of the specs they are referencing. Normally expected that a spec entering PR should reference specs in PR, and going to Rec referencing Recs. But not absolute if stability can be shown

mkwst: so the argument would be that web authn is depending on "stable parts" of the spec, as shown by multiple implementations?
...: do folks here have a preference 1) push to CR as is and wait for implementations, or 2) split the spec and push the infrastructure parts to PR

danbates: we've been slow to have a discussion on whether passwords are a useful spec. the usecases don't seem useful to implement. spec says a replacement for browser heuristics, but from our POV the browser heuristics work pretty well and wouldn't give sites an incentive to change what they're doing.
...: is the issue distaste for the browser heuristics?

battre: there are types of login such as XHR in the background where getting the password values programmatically would help

mkwst: for example, NY Times pops up a login form that wasn't there, submits (via XHR) in background and never updates the page, makes it hard for Chrome to know whether the login was successful or not

danbates: if the user types something different in the form, then they want to update the password. I don't see the problem

jochen___: chrome currently asks if you want to update your password (normal form). If user updates their password and doesn't update the password store, and login happens in the background, they don't see the error or know how to update their password.

<tanvi> why did the javascript access restriction go away? I missed that

danbates: I've not heard of any bug reports of complaints about the current behavior. If there are any it can probably be addressed by a new autocomplete attribute or page hint. not a whole new API
...: the bigger issue is the page knowing the password -- that would be a bigger win to sell to web sites. You could XSS that page but that's OK because there's nothing to intercept.

mkwst: you should be looking at what the web authn group is doing then -- they're trying to solve that problem

<battre> the comments about chrome's current password manager behavior were from battre, not me
...: in a slightly different way, but that could be the place for that.

<jochen___> tanvi: did mkwst's talk about web site author's feedback on the CM API answer your question?

mkwst: the current form of the spec was shaped by feedback from web developers that the old version was too complicated, but that they liked the features they got

<tanvi> jochen___: only slightly
...: and it's a stepping stone to using the same API in a similar way to get to a more secure behavior

<tanvi> jochen___: you had to come up with a new system that made it impossible to restrict javascript access?

jeffh_: passwords are not going away immediately, some people can use federated credentials, and some sites are adding authenticators like Google

mkwst: if a site can ask a user for both a password and a security key, the browser can help walk the user through that because the browser knows what the user has used before. NFC key? USB token? the browser knows
...: the code for the site can be common in those scenarios

johnwilander: for web authn we definitely see the value! back to the question, splitting or not....

<jochen___> tanvi: well, the feedback was that folks couldn't change their server side endpoints to consume the opaque passwords
...: what you're hearing from dan is that the password part is not that interesting because heuristics work and exposing the password doesn't offer the site any additional security. the part supporting Web Authn is important

<jochen___> tanvi: giving script access to the passwords made it possible for them to use the spec

<tanvi> jochen___: i see

<tanvi> that is unfortunate

angelo: the federated case is interesting. I can see a case for it, but is anyone pushing to use it?

<jochen___> yeah, that's why I proposed that we could make it some per-origin configuration

jeffh_: using the API users would get a consistent behavior across sites

tanvi: mozilla is in favor of splitting. we have active work on implementing web authn and the parts that requires, but having trouble getting interest in implementing the other parts. Seems like it could be a UX win, but with other priorities not compelling enough yet

<tanvi> well more than that… I don't think the UX win is good enough. I think we need to do more here to make this compelling

mkwst: concrete actions are -- split the spec, we have good idea what the infrastructure is. Look at the password/federated part and see how we can drive interest in that (or if we can) separately

angelo: can we do the split in a short amount of time?

mkwst: we already had it split once, shouldn't take that much time

<tanvi> Along with the UX wins, we need some more security wins

<wseltzer> [break, return in 36 mins]

mkwst: let's take a break now, come back at 11:00 for CSP3

<mkwst> mkwst: Welcome back! ArturJanc is going to talk about CSP @ Google for an hour before lunch.

<mkwst> aaj: [slides]

11: 06 ...: over the last year we've spent time using CSP3 features and can give feedback on what's useful and what's not

CSP 3 part 1

ArturJanc: last year we talked about why we wanted to use nonces instead of whitelists
...: over the last year we've spent time using CSP3 features and can give feedback on what's useful and what's not
... nonce-based policies require: 1) remove inline event handlers and javascript urls. 2) create a random value and add nonce attribute on script tags. 3) send a CSP with strict-dynamic and the nonce (and unsafe-eval for old browsers). 4) roll out in report-only mode to check for broken stuff
..: side note my team runs the web vulnerability reward program and we pay a million (?) a year. 60% of the web vulnerabilities are XSS
...: CSP adoption at google -- gmail, google accounts, google docs/wallet/photos/contacts etc
... high value UIs -- account management applications, cloud admin interfaces, etc
... nonce-based adoption -- over 70 distinct services, enabled for ~50% of HTML responses, req'd for new appls and enabled by default in popular frameworks
... elsewhere -- uber, pinterest, optimizely, atlassian
... CSP wishlist for browser vendors
... strict-dynamic, report-sample, CSP violation events
... report-sample can help distinguish between noise (extensions?) and attacks (snippets of injected script?)
... all of these are in the spec so I don't think they're controversial, but they would really help my life to implement them
... still give rewards even if blocked by CSP because not in all browsers, treat as "defense in depth"
... attacks on nonce-based CSP we've seen or reported elsewhere
... 1) if you have injection, might have exfiltration of values from DOM using scriptless features (