Re: [CSP] "sri" source expression to enforce SRI

That approach seems sensible to me, assuming the syntax can be made to work.

On Wed, Mar 16, 2016 at 2:30 PM, Neil Matatall <oreoshake@github.com> wrote:

> Another option to support the asset type granularity would be to make
> a `require-sri` source expression that can be added to script-src,
> style-src, img-src, media-src, and unicorn-src.
>
> On Wed, Mar 16, 2016 at 7:18 AM, Neil Matatall <oreoshake@github.com>
> wrote:
> > What can we do to get this moving? No matter the form, I don't think
> > there's any disagreement about whether or not this is valuable. We're
> > starting to see a proliferation of SRI attributes included in example
> > snippets for 3rd party assets. It's my gut instinct* that SRI has the
> > possibility of eclipsing CSP in terms of adoption, but that's a
> > different topic. It sounds like CSP bloat and SRI changes are the
> > biggest hurdles. Something that may alleviate both concerns:
> >
> >   block-non-sri-resources: stylesheets, scripts(, images, videos,
> unicorns)
> >
> > I would still love to see this as a part of CSP, especially if we're
> > talking about adding something related to noopener
> > https://twitter.com/mikewest/status/710025892970504193. Maybe this
> > separate header value can also work as a directive, just remove [:,]
> >
> > * I'll take bets
> >
> > On Tue, Feb 16, 2016 at 5:44 AM, Patrick Toomey
> > <patrick.toomey@github.com> wrote:
> >> On Wed, Feb 10, 2016 at 7:47 AM Frederik Braun <fbraun@mozilla.com>
> wrote:
> >>>
> >>> On 09.02.2016 19:35, Craig Francis wrote:
> >>> > I'm forgetting the discussion a bit, but CSP already gives us:
> >>> >
> >>> > block-all-mixed-content
> >>> > upgrade-insecure-requests
> >>> >
> >>> > Maybe we could keep it as just one directive:
> >>> >
> >>> > block-non-sri-resources
> >>> >
> >>> > Or am I missing the more advanced cases like saying SRI is required
> for
> >>> > all JavaScript files, but not on CSS (doubt that is useful, as you
> might
> >>> > as well do both)... or maybe in the future SRI could be added to
> images,
> >>> > video, etc?
> >>>
> >>> We'd need to think about compatibility assuming SRI will expand to
> other
> >>> tags.
> >>>
> >>> I would be surprised if nobody wanted a report-mode and a block-mode
> and
> >>> a way to specify which subresources/elements should be subject to the
> >>> policy. (The list of elements could be abbreviated with a short-hand
> >>> form, e.g., "sri-v1" meaning scripts & styles.)
> >>>
> >>> I guess this level of complexity (and Mark Nottingham's comment about
> >>> HPACK and entropy) warrants its own header?
> >>>
> >>
> >> I'm curious where the line should be drawn between extending CSP and
> adding
> >> a new header? Not having been involved with CSP from day one, maybe
> this has
> >> already been discussed. But, I feel like CSP is a natural place to
> >> centralize on browser based security policies (like x-frame-options
> >> migrating to frame-ancestors). Adding a new header for each and every
> new
> >> good idea for browser security doesn't seem to scale. As has been
> mentioned
> >> in this thread prior, it feels like we are starting to bump up against
> >> practical size consideration issues. Whether the CSP header itself
> grows too
> >> large or we end up adding 50 headers to each HTTP response, there is an
> >> issue of bloat. It would be a shame to place some artificial cap on good
> >> ideas based on concerns for adding too many new headers and/or
> stretching
> >> the size of the CSP header. I personally feel like moving toward a
> >> centralized policy/manifest/resource sounds like the best way to handle
> >> this, but I think most of that discussion is best had over in the
> "header
> >> size and policy delivery" thread. I just wanted to bring it up here
> since I
> >> think the "where do we put it" discussion should be deferred until
> later,
> >> since it seems like this is a general concern for almost anything new
> that
> >> is proposed.
>
>