W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2015

Re: CSP2: Drop 'unsafe-redirect'.

From: Brian Smith <brian@briansmith.org>
Date: Thu, 2 Jul 2015 12:26:51 -0500
Message-ID: <CAFewVt7P326GVVppcL9SM=1jyk6Q7SFHcnCSMiyr2p3e6FBHPA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Wendy Seltzer <wseltzer@w3.org>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>
On Thu, Jul 2, 2015 at 3:25 AM, Mike West <mkwst@google.com> wrote:

> On Wed, Jul 1, 2015 at 8:24 PM, Brian Smith <brian@briansmith.org> wrote:
>
>>
>>
> When Firefox implemented mixed content blocking, Mozilla treated
>> Mozilla-owned sites specially: We assumed that our coworkers would make the
>> necessary changes before we shipped, after we helped them understand what
>> was necessary, and so we didn't consider breaking any Mozilla site a risk
>> for shipping. That strategy worked very well for us (IIRC).
>>
>
> Point taken. That said, if I could wave a magic wand to make changes to
> some subset of Google sites, this isn't what I'd focus my effort on. :)
>

My overall point is that this kind of compatibility issue is very
short-term pain that is easily addressed. We should be careful to dismiss
things that are useful in the long-term because of these short-term issues.
And the breaking of any website or product of a webappsec member (at least)
due to it using a feature before a specification reaches Recommendation
status shouldn't be considered to be problematic; instead it should be
expected, especially when the breaking behavior is *already actually in the
spec* but just not implemented. Everybody should expect to have to make
changes on short notice at least until a spec reaches Recommendation
status. If that doesn't work for them, then they should wait until the spec
reaches Recommendation status to use the features. W3C can't have an
effective spec development process otherwise.


> For clarity,
> https://github.com/w3c/webappsec/commit/7456cb77e504fa70991b3cc54c852e62ebc7a2cc
> is the change I've made to the ED, and that I'd like to make to the CR
> before moving forward.
>

Great, thanks for correcting my misunderstanding.

In the last hunk of your patch, you removed the text about redirects being
something to watch out for. I think that is OK because the surprising (to
some) behavior of redirects in CSP is called out in section 4.2.2.3
already. If it is not too late, I recommend also recommending in section
4.2.2.3 that the server pay attention of the CSP request header to avoid
the attack.

FWIW, I support making this change to remove unsafe-redirect because the
mechanism doesn't seem good, not because of the compatibility issue that
was raised.

Cheers,
Brian
Received on Thursday, 2 July 2015 17:27:19 UTC

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