See also: IRC log
<scribe> Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2017Apr/0028.html
no new suggestions
dveditz notes that there is discussion on list of serializing of suborigins, but right people probably not on the call today, better left to list and github issue discussion for now
<jochen___> we still don't have two implementations of everything
<estark> Chrome doesn't have 3 of the policy values implemented
<jochen___> yes!
<jochen___> and estark :)
<jochen___> Firefox needs to implement the CSS bits
estark: still need to implement new policy values and firefox needs to do css things
approved, https://lists.w3.org/Archives/Public/public-webappsec/2017Mar/0042.html
please ask your AC rep to re-join
dveditz: no objections on list or call so time to complete this
deian: on implementation side,
hired someone to work on the implementation full time, would
like to bring him to work on the spec too, if possible
... Abdul, a masters student started hacking on the chrome
implementation a few weeks ago, want to talk to chrome team
about exposing behind a flag
... still refactoring after talking to Eduardo about his
isolation proposal, a bigger overhaul than I thought it would
be
... in original spec, top level pages could drop privileges
even if they couldn't be tainted
... now that's no longer possible so you can only do
interesting things in iframes, in long run this may be better
as covert channels are less in out of process iframes
... if someone can help me bikeshed it in the next few weeks
that would be nice
bhill2: to clarify on bikeshedding? actual discussion bikeshedding?
deian: yes, as in we are talking
with Eduardo, so we are looking for design review on use cases,
etc.
... would be nice to have a uniform way to interpose on
postMessage the way we have with Fetch, since this is needed
for suborigins as well
<jochen___> currently trying to refactor how suborigins hooks into postMessage: https://github.com/w3c/webappsec-suborigins/pull/67
<jochen___> comments welocme
deian: would also be nice to extend the secure contexts notion to be able to disable certain features / APIs in a confined iframe similar to as with http
<ArturJanc> for disabling certain APIs in COWL world maybe you can lean on the Feature Policy
deian: one thing we'd like to do
is not allow websockets, for example, since overhauling to work
with information flow seems like too much for now
... I should look at feature policy
bhill2: working on Chrome you say, still working on Firefox?
deian: yes, a little slower, there is a team on CMU working on it
<jochen___> \o/
bhill2: might be interesting to
find a way to have a more extended discussion with COWL,
Suborigins, Feature Policy teams about common mechanisms for
these different approaches
... let's propose that kind of meeting on the list to try to
illuminate the core platform features that these things have in
common
mkwst: this will be relatively
short, not much of an update
... on chrome, we are upstreaming tests to WPT
... we've also found one issue that Emily is working on, we are
not doing CSP reporting correctly, should be reporting before
but are reporting after
... patch in place that should land relatively soon, similar
with redirects
... I think we have interoperable implementations
... we should verify that, but from a spec POV we are good and
should move to PR once we have tests to back up that
devditz: does spec expect reporting to be synchronous?
mkwst: (summarized) we want CSP
to be useable for detecting links that are not upgraded, while
also supporting automatic upgrade
... so reporting and enforcement are separate steps
dveditz: I'm reasonably sure that in Firefox the reporting and blocking are bound up in the same code
mkwst: in a lot of our tests we
rely heavily on the DOM event so we don't have to go up to the
server, but that doesn't work so well in firefox
... it would be really good to get that event implemented so we
could more easily write reusable tests for WPT
dveditz: I keep trying to make
that a priority but it unfortunately isn't at the time
... anecdotally, we got reports of someone who can't login to
an old linksys router due to upgrade insecure requests, but
somehow chrome works fine
mkwst: we've had robust conversations recently with the WebAuthN WG to bring FIDO work into a web-facing API
<dveditz> in this particular case it didn't kill the gear, Firefox lost a user
mkwst: we're coming to the
conclusion that it would be good if WebAuthN was structured as
an extension of the CredMgr spec
... we've rewritten it in a way that doesn't change it for
developers but makes the extension mechanism more clear
... and more useful for the types of extensions that would be
useful for WebAuthN and other things people are thinking
about
... we've made some API changes
... user mediation is now an enum vs. a boolean
... previously allowed for potential of UI, but not required
mediation
... now you can do silent, potential UI but accepts silent, and
a require user mediation as policy states for that
... we also added an async constructor for all credential
types, new create method to navigator.credentials
... need this for WebAuthN because they can only be created in
an async fashion by talking to an external device
... also gives user agents an opportunity to interject and do
things like password generation while interacting with the
user, which requires an async mechanism
... navigator.credentials.create will return a promise
... Domenic is probably on call and manages password mgr
dominic: we've had some reports
of usability issues around use of Fetch
... some website expect a JSON object, others process passwords
before sending it along
... by not exposing the credentials this is broken, and hiding
the credential from the website doesn't provide that much extra
security in XSS scenarios
... e.g. by switching form fields. After discussing with our
security team, cred mgr API is a path forward to stronger
credentials and it is good to make this sacrifice against XSS
protection
... in order to move the web forward faster towards better
credential types by by not hindering adoption of cred mgr with
this restriction
JohnWilander: question about javascript access to credentials, could that be done by registering a function to apply without exposing it
<deian> cowl :)
<dveditz> :-)
<jochen___> the other problem was that ppl weren't able to change the server side
(can someone help the scribe with the proper spelling of the speaker's name, I was attempting to crib from irc nicks in the room and got it wrong)
mkwst: passwords are bad and we
want to get rid of them, better to help users use password
managers and better credentials than trying to protect use of
passwords from XSS
... as lcamtuf noted in postcards from a post-xss world, it's
totally possible to exfil data, fixing those seems for now more
costly than it was worth
JohnWilander: betting on
passwords going away doesn't seem like it will happen before I
retire
... especially with two-factor, there will still be a password
and then something else
mkwst: yes
... webauthn has the notion of authenticators that are first
factors in and of themselves
... you can imagine something more capable than a security key
today that could use biometrics or magic that can provide
identity in addition to device and user presence
... even if you don't buy that, I still think that the goal of
increasing the usability of password managers is a win
... they are defended against phishing in ways that are more
important that defending against content injection at
legitimate sites
<mkwst> JohnWilander: https://github.com/w3c/webappsec-credential-management/pull/76 <--
JohnWilander: can we discuss on the list this particular tradeoff? so it is recorded
mkwst: see that pull
request
... we have a model that works for the credentials we know
about today, but want to think about and get feedback so
extension points support things we may want in the future
... more eyes would be super helpful
<wseltzer> PR 384, Strawman of an integration between WebAuthn and Credential Management
mkwst: more eyes from WebAppSec on that PR would be awesome
<mkwst> bhill2: Edge 15 released.
<mkwst> ... CSP2. Nonces! frame-ancestors!
<jochen___> and unprefixed Web Auth (?) cf jakob rossi
<mkwst> ... Crispin Cowan left Microsoft. We should encourage MS to continue their engagement with this group.
<mkwst> plh: I can help with that. Happy to poke people.
fb.me/recovery
<mkwst> bhill2: Credential recovery mechanism launched recently.
<mkwst> ... https://fb.me/recovery
<mkwst> ... This seems like a more secure solution than other recovery mechanisms out on the market today.
<mkwst> ... Would love to work with other companies!
(spec is at: https://github.com/facebook/DelegatedRecoverySpecification)
mkwst: would like to resurface discussions about associated origins
<battre> https://developers.google.com/digital-asset-links/v1/getting-started
mkwst: both apple and google have
ways to do this for credential sharing
... would be interesting to figure out if there is appetite for
doing things like that more broadly
... is there a cowpath to be paved here?
... seems like there is some level of commonality
mike, there is also this from FIDO days: https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-appid-and-facets-ps-20141009.html
<battre> https://developer.apple.com/reference/security/shared_web_credentials
mkwst: also prior work in DBOUND,
so =JeffH would want to discuss
... though it seems like what apple and google have come up
with is pretty different
dveditz: possible interest at Moz, we keep building and disbanding password manager groups as priorities change
qa/
JohnWilander: I do think it's on
me to continue the thread I started
... should probably fork off the whole thread on shared
credentials
<jochen___> I'm here
dveditz: Suborigin has had active list discussions lately
mkwst: jochen has taken over for joel, seems like talking about it next month would be a good idea
<estark> I've been meaning to send around a rough spec for Isolate-Me (wicg.github.io/isolation/index.html), maybe if we put that on the agenda for next time it'll force me to actually send it out
bhill2: I think dev ususally has a conflict with this time, but maybe we can give him enough notice or give everyone else enough to shift this call an hour or a day if needed to get both him and jochen on the call
dveditz: clear site data?
<adrianba> we still have people from Microsoft who are members of this group - i'll figure out who is going to pick up the engagement from crispin
<dveditz> thanks, adrianba
<deian> thanks all
<mkwst> wseltzer: https://www.w3.org/2017/04/19-webappsec-minutes.html is throwing a 404. Does RRSAgent just take some time?