See also: IRC log
<tanvi> i will be 10 minutes late today
<terri> I have overlapping meetings and will be irc-only for at least the beginning of this one
<dveditz> scribenick:francois
<dveditz> scribenick: francois
<francois_> I don't know the magic zakim commands though, so you'll have to do that bit :)
<dveditz> scribenick: francois_
<JeffH> +
<JeffH> heh
dveditz: a few topics haven't
made it to the schedule yet because i wasn't sure they were
ready to be dicussed here
... for example, the security ui thread and the meta tag to
lock away code (which nobody on this group seems to have
interest in), also the long discussion on the topic of client
certs (doesn't feel like it belongs to our group)
https://www.w3.org/2011/webappsec/draft-minutes/2016-02-10-webappsec-minutes.html
<dveditz> https://www.w3.org/2011/webappsec/draft-minutes/2016-02-10-webappsec-minutes.html
<teddink> No objeciton
dveditz: minutes are approved unanymously
dveditz: poll results: first half
of May won
... proposal is May 16-17 at Mozilla Mountain View
<dveditz> Tentatively May 16-17 at Mozilla in Mountain View, California
<dveditz> Who does that work for, who does it not?
https://www.mozilla.org/en-US/contact/spaces/mountain-view/
<estark> I think I can make it
<JeffH> i think i can make it
<KingstonTime> I'm not sure as I don't know what my status will be and what Mozilla is doing etc :D
dveditz: We will need a hand count at some point so that we can order lunch for people.
<teddink> I am working with folks at Microsoft to decide who should attend, I would expect at least 1 attendee.
<JeffH> just verified that week is clear on my calendar
<tanvi> i will be there
dveditz: this is the same week as Google IO, but IO is at the end of the week
<terri> I will make a travel request, not sure if I will be able to get a flight or not yet
dveditz: mkwst work with mark
nottingham to set up this registry at the IETF. it currently
has CSP 2 directives. doesn't have strict mixed content
blocking or referrer policy directive, or upgrade insecure
request
... this will enable CSP3 to be more of a framework and let
other specs easily declare extra directives
dveditz: mkwst took a stab at the
credential management API to come up with a more limited spec
that we're more likely to agree on and implement
... we'll need to coordinate with the web auth group to find
out whether or not they can build on this
... the mozilla folks working on web auth aren't in this
group
<dveditz> mailing list message: https://lists.w3.org/Archives/Public/public-webappsec/2016Feb/0046.html
mkwst: the current api does three
things: let websites integrate with the password manager
... 2- hook into account creation / registration
... 3- framework for other groups to build stuff on top
of
... of those things, chrome has implemented the first 2. based
on their data, the first use case makes a lot of sense. it
makes the password manager work better
... the sign up case (#2) was much harder
... in chrome we have not found a good way to make that work
well
... e.g. if you logged using a password you don't save, the
browser might prompt you to use facebook login next time
... the plan for chrome is to ship #1 in Chrome 50 or 51
... feedback is welcome on this plan
... we'll keep the ability for websites to tell the browser
that a user logged in using facebook connect, but we're taking
out the part where we synthesize credentials on the user's
behalf
dveditz: is an updated spec coming to the proper channels?
mkwst: i'm waiting on some bikeshed work to happen and make that automatic
dveditz: there is a concern that our specs look stale from the w3c point of view, despite the github ones looking fine
mkwst: there is a large gap between github and w3c at the moment, my hope is that it will change soon
tanvi: mozilla hasn't currently prioritized that spec yet
<JeffH> mike's plan for cred mgmt sounds fine by me
<dveditz> https://lists.w3.org/Archives/Public/public-webappsec/2016Feb/0048.html
dveditz: mkwst's proposal comes from Google's experience trying to implement CSP
mkwst: it seems like a valuable
thing that would enable the google infra team to put CSP on
more Google properties.
... dev was raising some issues asking whether or not the
polyfill would be enough
... that requires nonces though and on some Google properties
they would be using hashes because the pages are totally
static
... it looks pretty sane from my point of view (and google's).
i have an action item to draft a spec change for this
dveditz: it's a weaker form of csp, but it's still better than not using CSP at all
mkwst: the current practice of
whitelisting origins is, for google, not as strong as we though
it was. there are a lot of endpoints on ajax.google.com for
example that enable JS injections (e.g. through old angular
JS)
... the infra sec team is of the opinion that every large
origin will run into this problem
... unless you whitelist individual files, you're going to have
a bad day. and whitelisting individual files has proven too
brittle to be deployed in practice
(see the thread on the list for the details of the proposal)
mkwst: we audit the scripts we know we're including on the webpages. we're ok with those scripts doign whatever they need to do (including loading more scripts that they need)
dveditz: are nonces allowed on script-src that's an actual script-src rather than inline scripts?
mkwst: yes
dveditz: interesting proposal adressing real-life pain that a large implementer is facing
dveditz: reminder that a lot is
happening on our github repos
... there was a good "issue" thread on cowl, one about null on
the referrer policy
... there was a good discussion clarifying things about
suborigins. it was probably the most active topic / spec since
the last meeting
... interesting CSP discussion. apparently in Firefox, script
hashes only apply to script tags, not onclick handlers
... it could be dangerous to allow these because attackers
could copy these handlers and make them fire in other places on
the page
... the alternative is to programmatically add the event
handler from within the script
... if the mailing list seems quiet, that's because half of the
conversation is happening on github
<teddink> Thanks!
<KingstonTime> Thanks all!
<JeffH> thx!
<dveditz> hm, well _that_ didn't work right.
<dveditz> wseltzer: wondering why Zakim thinks only jeffH was here
<dveditz> earlier there was a much larger "present" list
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found ScribeNick: francois Found ScribeNick: francois WARNING: No scribe lines found matching ScribeNick pattern: <francois> ... Found ScribeNick: francois_ Inferring Scribes: francois, francois_ Scribes: francois, francois_ ScribeNicks: francois, francois_ Default Present: JeffH WARNING: Replacing previous Present list. (Old list: KingstonTime, MikeSmith, bhill2, ckerschb, dveditz, estark, francois, francois_, gmaone, kmckinley, mkwst, tanvi, teddink, terri, timeless) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ JeffH Present: JeffH dveditz francois KingstonTime mkwst gmaone estark teddink Regrets: wseltzer bhill2 WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 24 Feb 2016 Guessing minutes URL: http://www.w3.org/2016/02/24-webappsec-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]