Re: Add ability to specify the version of used CSP

Hi!
Thanks for reply.
В Пн, 20/03/2017 в 15:00 +0100, Mike West пишет:
> Sorry, I missed this thread. Thanks for the ping.
> In short, I think the ship has sailed on versioning. 

It is only 2 standard versions right now and significant next one. Also we are in the begging of CSP world wide
spreading. May be it is not so late to include versioning into the 3rd version?
> Whether or not it was a good decision, it's the decision we've run with until now, and it's not clear to me that it's
> worth a ton of investment at this point. Practically, developers already do user-agent sniffing to deal with
> differences in behavior between browsers, and I don't think versioning would actually change that (especially given
> browsers like Chrome and Firefox which are shipping pieces of CSP3, but don't yet support all of it).

In my opinion, user-agent sniffing is bad practice. It is better when protocol/technology provides versioning built-in
so developers don't need to write code like:
if ua.name == "Chrome" and ua.version > 46 ...

> We've established a pattern by which we introduce new bits and pieces that implicitly deprecate old bits and pieces. I
> agree that it's not always elegant, but it has the advantage that a policy always has the same meaning based on the
> features a browser supports. Moreover, it has the real advantage of not requiring us to support multiple incompatible
> versions of CSP in browsers at once. That's something I'd really like to avoid. 

On the another side it makes the policy more complex and harder to maintain for web resources. Furthermore it makes
possible to more safely brake backward compatibility in future versions of CSP.
> Personally, I'm not very interested in making fundamental changes to CSP at this point. I don't intend to write a
> CSP4, for instance. I'm more likely to be interested in stepping back from CSP, trying to learn what we can from the
> few years of experience we've gathered, and trying again with something more targeted. https://mikewest.github.io/artu
> r-yes/ is a strawman sketch we talked about at TPAC last year, and I'm sure we could come up with something similar
> for confinement.
> 
> All that said, it would be good to listen to developers about whether a versioning system would have helped them. If
> it would have been amazingly useful, then it's something we should think about for features we introduce in the
> future.
> 
> -mike
> 
> 
> On Mon, Mar 20, 2017 at 11:45 AM, Taras Ivashchenko <oxdef@yandex-team.ru> wrote:
> > Mike?
> > 
> > 
> > 
> > В Пт, 10/03/2017 в 12:26 +0300, Taras Ivashchenko пишет:
> > 
> > > +mkwst@google.com
> > 
> > >
> > 
> > > 9 years ago...and nice thread. I like the idea about some handshake between browser and server.
> > 
> > > The only thing that I'm worried about is additional logic on webserver site like "if we receive CSP version N from
> > the
> > 
> > > browser then send relevant header with policy". 
> > 
> > >
> > 
> > > Mike, what do you think about CSP built-in versioning?
> > 
> > >
> > 
> > > В Чт, 09/03/2017 в 07:43 -0700, Bil Corry пишет:
> > 
> > > > Back in 2008, I provided feedback on a newly proposed CSP specification.  My very first item addressed a
> > shortcoming
> > 
> > > > regarding CSP versioning.
> > 
> > > >
> > 
> > > > I suggested the client send a header with the version of CSP it supports (if any), and the server could then
> > respond
> > 
> > > > with the CSP header for that version (or make other security choices).
> > 
> > > >
> > 
> > > > I even called out that it would be better than having multiple CSP headers expressed by the server, e.g.
> > 
> > > >
> > 
> > > >         X-Content-Security-Policy: ...
> > 
> > > >         X-Content-Security-Policy2: ...
> > 
> > > >         X-Content-Security-Policy3: ...
> > 
> > > >         X-Content-Security-Policy4: ...
> > 
> > > >         X-Content-Security-Policy5: ...
> > 
> > > >
> > 
> > > > Instead, the spec omitted a versioning scheme, perhaps because some believed that there would never be a version
> > 2
> > 
> > > > of
> > 
> > > > CSP.
> > 
> > > >
> > 
> > > > The entire thread is here and makes for interesting reading, given what we know today:
> > 
> > > >
> > 
> > > > https://groups.google.com/forum/m/#!msg/mozilla.dev.security/slJarIvaMM0/discussion
> > 
> > > >
> > 
> > > >
> > 
> > > > - Bil
> > 
> > > >
> > 
> > > > On Mar 9, 2017, at 2:01 AM, Taras Ivashchenko <oxdef@yandex-team.ru> wrote:
> > 
> > > >
> > 
> > > > > Hello!
> > 
> > > > >
> > 
> > > > > It is awkward to maintain backward compatible CSP policy, e.g. keep in it unsafe-inline with nonce for CSPv1
> > or
> > 
> > > > > frame-
> > 
> > > > > src/child-src. It looks like in the future versions of CSP such problem will be more obvious. 
> > 
> > > > > In some cases in web application it is easer to have support of only the last one standard. 
> > 
> > > > > What do you think about adding ability to specify the version of used CSP? 
> > 
> > > > > It can be done in header name like:
> > 
> > > > >
> > 
> > > > > Content-Security-Policy-v3: ...
> > 
> > > > >
> > 
> > > > > If browser meets more the one CSP header it should use header with the latest support version.
> > 
> > > > >
> > 
> > > > > I had also reported the issue on GitHub but there is no activity in it during 8 days
> > 
> > > > > https://github.com/w3c/webappsec-csp/issues/189
> > 
> > > > >
> > 
> > > > > -- 
> > 
> > > > > Taras Ivashchenko
> > 
> > > > > Information Security Officer,
> > 
> > > > > Yandex
> > 
> > --
> > 
> > Taras Ivashchenko
> > 
> > Information Security Officer,
> > 
> > Yandex
-- 
Taras Ivashchenko
Information Security Officer,
Yandex