W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2017

Re: Summary of recent conversations for WebAppSec

From: Emily Stark <estark@google.com>
Date: Wed, 15 Feb 2017 23:24:45 -0800
Message-ID: <CAPP_2SaUyf+R8ymdy0w+7t3LvXYve4di9X6JV-kmapmU25WNbA@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:22 UTC