[SRI] Updates to the spec and outstanding issues

Hi everyone

As we progress to SRI last call, I wanted to update everyone on a few
changes to the spec and current status/open-issues. I would love to get
feedback; but to help the discussion, please kick off a new thread for
individual issues in this email instead of responding directly on this
thread (or just respond on Github if you prefer).

Changes in the last few weeks
<https://github.com/w3c/webappsec/commits/master/specs/subresourceintegrity/spec.markdown>
the
tl;dr version is:

   1. We now use the CSP format for specifying hashes (base64, not
   base64uri)
   2. SRI doesn't officially require HTTPS, but the spec now notes the
   security issues with not using HTTPS as well as the spec will only use SSL
   in the examples etc. This is tricky and we definitely want to explain this
   correctly, an issue which is currently open
   <https://github.com/w3c/webappsec/issues/116>
   3. Unsupported/unknown hashes no longer break: this allows applications
   to support the latest and greatest hash functions without having to worry
   about some old browser breaking. This was previously discussed on the list
   and agreed upon and this change just made that more clear.
   4. Since we only support scripts and styles, the hello world example in
   the spec changed to use a script instead of text/plain.
   5. The require-for-all directive was removed. It really should be
   require-for-all per resource type; otherwise, app authors write
   require-for-all and tomorrow a UA adds support for images in SRI and
   everything breaks. We will look at something like require-for-all in v2.
   6. Explicitly removed caching as a goal of the SRIv1 spec, since the
   spec doesn't do this nor does any implementation.

Open issues/PRs <https://github.com/w3c/webappsec/milestones/SRI-v1-LC>

   1. There <https://github.com/w3c/webappsec/issues/189> is no example
   example  violation report in the spec.
   2. Currently <https://github.com/w3c/webappsec/issues/207>, a resource
   is eligible for SRI if it is same-origin, or allowed via CORS, or is
   "publicly-cacheable". That last part is a bit confusing and unclear and
   Anne doesn't agree that it is secure. I also think it is confusing and
   unclear and the spec should just stick
   <https://github.com/w3c/webappsec/pull/190> to CORS. What do others
   think?
   3. The SRI <https://github.com/w3c/webappsec/issues/211> spec currently
   doesn't enforce the mime-type and should say something like "insist on this
   mime type, even after sniffing". Unfortunately, content-type sniffing
   (afaik) isn't really spec'ed so it is not clear how to put that in the
   spec.
   4. SRI <https://github.com/w3c/webappsec/issues/210> currently doesn't
   support objects for v1. Should this be in V1 under the broader "integrity
   for code" banner? No implementation supports this right now, but I know it
   will definitely improve the guarantees a web application can provide.
   5. The spec <https://github.com/w3c/webappsec/issues/149> doesn't really
   help an application developer figure out how to fall back to safer (say,
   non-cdn) resource when the SRI checks fail.

As usual, all the spec editors would look forward to feedback.

cheers
#team-sri ;)