SRI: Behavior when a developer fails to specify CORS

Hi folks. We're working on finalizing a few last spec issues in SRI. Most
of them are relatively minor, but we have one which is an important API
related question: what should the behavior be when a developer fails to
specify that a resource should be fetched CORS enabled and also specifies
an integrity attribute?

A large amount of discussion can be seen on
https://github.com/w3c/webappsec/issues/317, if you care to go back and
read the history. The summary is that SRI requires cross origin requests to
be CORS enabled because otherwise it would provide an oracle for
potentially sensitive content. Thus, for practical purposes, a developer
needs to provide a crossorigin attribute for a cross origin resource load
if an integrity attribute is specified.

There are effectively three behavior options, which I'll list below with
some pros and cons for each (the other editors should feel free to chime in
and correct my errors and omissions):

1. Fail open. If the developer fails to specify a crossorigin attribute on
a cross origin resource load, user agents would still allow the resource to
load, but would not check the integrity and would warn the developer on the
console.

This has a few advantages. It would allow us to be backwards compatible if
we ever ever found a path to dropping the CORS requirement for SRI. It
would also match the behavior of several other failure modes, such as if a
developer misspells a hash algorithm name.

The downside is that developers might not check the console and thus might
think they're getting an integrity check when they're really not. And given
that we (the editors) think is extremely unlikely that we would ever be
able to drop the CORS requirement, it is questionable how much of a cost
this really is.

It should also be noted that if we went with this path, it would be forward
compatible with moving to either option (2) or (3) in the future, if we
went with this behavior and decided that it was insufficient and needed to
be more clear to developers.

2. Fail closed. If the developer fails to specify a crossorigin attribute
on a cross origin resource load and an integrity attribute is present, user
agents would block the resource from loading.

This has the advantage of making it much more likely for a developer to be
able to tell if they forgot to add the crossorigin attribute.

The disadvantage is that it mostly closes the door on dropping the CORS
requirement in the future, as if developers started adding resource loads
without a crossorigin attribute, old user agents would be incompatible.

3. Automatically add a crossorigin=anonymous attribute. If the developer
fails to specify a crossorigin attribute on a cross origin resource load
and an integrity attribute is present, the user agent would automatically
add crossorigin=anonymous to the resource load.

This has the advantage that if the developer fails to add the crossorigin
attribute, the fetch would still succeed as long as the server supplied the
CORS headers.

The disadvantage is that it might be confusing to developers to have extra
attributes silently added to their resource requests that they might not
expect, especially when if we instead failed closed, they'd immediately
just get a helpful console error telling them what to do. Additionally,
like (2), it precludes a dropping of the CORS requirement.

FWIW, the status quo is (1). At least a majority of the editors lean
towards (1) as well since we can adjust in the future in a forwards
compatible way, but we want to check in with the community to see what
we're missing here. Again, you can check out the GitHub issue for all the
juicy details of our back-and-forth.

This question is blocking shipping SRI for Chrome, so it would be great to
work this out as soon as possible. Thanks for your input!
--Joel