- From: Mike West <mkwst@google.com>
- Date: Mon, 6 Jul 2015 11:54:34 +0200
- To: Brian Smith <brian@briansmith.org>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Wendy Seltzer <wseltzer@w3.org>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>
- Message-ID: <CAKXHy=euZgg8kO-QozzBxr2wyN77oGBbN7YTe-K9uWCVDnRi3A@mail.gmail.com>
On Thu, Jul 2, 2015 at 7:26 PM, Brian Smith <brian@briansmith.org> wrote: > 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. > Since it probably wasn't clear from my response, I do agree with this broader point. In particular, I'd note that both Firefox and Chrome have pushed ahead with a somewhat late change to the meaning of `'self'` with regard to `blob:` in CSP2. When there is a real reason to make a change, we can and should ask developers to accept these behavioral changes. As you note below, `'unsafe-redirect'` was a bad mechanism that should have had more review before I put it into the spec. If it had real security impact, it would be worth impacting those 0.7% of page views (or 7%. Or 70%. On some reasonable timescale. :) ). 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. > We're going to have to go through CR again (I plan on sending out a CfC tomorrow), so editorial changes are totally reasonable to add! Last minute requests, anyone else? :) -mike
Received on Monday, 6 July 2015 09:55:22 UTC