Re: CSP Versions in Violation Reports

I can see that great care has been put to make things backwards compatible
and additive as much as possible, and admittedly, some of this is a
hypothetical pain point in the future. An example in recent history could
be whether paths are or are not included in the reports. There's been some
changes in reporting behavior, and knowing that could help. Similarly, with
incompatible changes, such as workers being controlled by child-src rather
than script-src. Could there be other issues when supported hash algorithms
change? (old user-agent doesn't recognize a newer hash and reports
violation) I'm thinking in terms if correlating violation reports as
equivalent, trouble-shooting faster, and also eliminating false positives.

It could be that many situations can be covered by user-agent
vendor/version info, and knowing what it did and did not support. However,
I couldn't find any easy way of finding this info. (other than some very
coarse-level surveys of which browsers minimally support CSP 1.0 and up)



On Sun, Jan 18, 2015 at 11:47 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> Hey Boris
>
> Can you tell more on how version info would help make synthesizing
> reports on violations more accurate? Also, why can't you achieve this
> based on the violated directive in the report? For example, if UA
> supports a new foo-bar directive, you will have violation reports with
> foo-bar in the violated directive; otherwise you wont.
>
> cheers
> Dev
>
> On 18 January 2015 at 21:44, Boris Chen <boris@tcell.io> wrote:
> > Hello,
> >
> > I've been playing around with CSP reporting, and I was wondering if there
> > has been any discussion of including CSP version in the reports.
> >
> > User-agents will obviously be supporting different versions of CSP for a
> > given web application, and therefore, the reports will vary depending on
> the
> > user-agents. The version info would help reporting on the violation
> reports
> > more accurate. This won't help for current versions supported, but would
> be
> > helpful for the future..
> >
> > Any thoughts?
> >
> > Regards,
> > Boris Chen
> >
>