- From: Emily Stark <estark@google.com>
- Date: Wed, 15 Feb 2017 23:24:45 -0800
- To: Mike West <mike@mikewest.org>
- Cc: Daniel Veditz <dveditz@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Jochen Eisinger <eisinger@google.com>
- Message-ID: <CAPP_2SaUyf+R8ymdy0w+7t3LvXYve4di9X6JV-kmapmU25WNbA@mail.gmail.com>
On Wed, Feb 15, 2017 at 8:53 AM, Mike West <mike@mikewest.org> wrote: > On Wed, Feb 15, 2017 at 5:38 PM, Daniel Veditz <dveditz@mozilla.com> > wrote: > >> Here are a few highlights of recent WebAppSec activity you may have >> missed: >> > > Thanks for pulling this list together, Dan! > > Referrer Policy transitioned to CR on January 26; call for exclusions ends >> March 27. >> > > Yay, y'all! > > >> We received charter feedback that our milestones looked unrealistic, and >> resistance to adding Isolated Origins until we reduce the number of current >> specs we're juggling. >> > > Isolated Origins should indeed be considered an incubation thing. I > mentioned it in the context of the charter feedback mostly to ensure that > we agreed that the scope in the document would allow us to pull it in > (though I didn't make that at all clear...). > > >> New Referrer-Policy issue #94 requests an 'origin-when-downgrade' option. >> > > Jochen, Emily? How many words can we stick next to other words before > Brian's more granular v2 starts looking appealing? :) > > IMO, sure, why not, but it shouldn't block ->PR->REC at this point. > I commented on the bug, want to understand the use case a little more. I can't really think of why cross-origin https resources would depend on a full referrer but cross-origin http resources wouldn't. I'm not too thrilled about opening up new ways to send full referrers cross-origin since I wish people wouldn't do that. But if there's a compelling use case for it, then I guess sure why not. > > Credential Management issue #58 references a hidden Chrome bug about XSS >> attacks on passwords and suggests adding a non-normative section containing >> "additional security measures to be used in combination with CM API to >> provide the best protection against XSS attacks on passwords." No proposed >> text, presumably waiting until the Chrome bug is unhidden? >> > > If you've read section 3 of http://www.w2spconf.com/2012/ > papers/w2sp12-final11.pdf, you know all the interesting bits of that > Chrome bug. The "additional measures" boil down to "Don't have XSS. Also > use CSP. But really, try hard not to have XSS." :) > > >> Credential Management issue 56 wants to add a way to delete credentials >> when a login attempt fails so a site doesn't keep annoying the user with >> automatic but failed login attempts. >> > > In general, we've started working on the spec again to clean it up for CR > based on our implementation experience. Apple's public declaration of > interest > <https://lists.webkit.org/pipermail/webkit-dev/2017-January/028684.html> is > also a good reason to clean up some of the rough edges so that their > implementation might go a little more smoothly than ours did. Relatedly, > how's Mozilla feeling, Dan? :) > > >> Following up to Artur's discussion on the call last month about risks >> when using nonce with CSP, issue #177 proposes a warning about the risks of >> injected base-uri when using nonces. >> > > I have a few more patches in flight that I haven't finished yet. Maybe on > a plane tomorrow I'll get the nonce-hiding bits and pieces written up. > > -mike > > >
Received on Thursday, 16 February 2017 07:25:39 UTC