Re: [SRI] may only be used in documents in secure origins

Tanvi Vyas <tanvi@mozilla.com> wrote:

> SRI on an non-secure origin does not protect the user from an active
> network attacker that is MITM'ing their connections and changing their
> content.  But SRI on a non-secure origin does protect the user who is not
> subject to an active attack and who is trying to source javascript from a
> third party that has been compromised.  For me, that's a good enough reason
> to allow SRI on non-secure origins.
>

SRI is already allowed on non-secure origins; no browser is going to show
an error page when a non-secure HTML document uses SRI. The issue, as I
understand it, is whether a browser MUST NOT, SHOULD NOT, SHOULD, or MUST
enforce SRI for for non-secure documents and/or non-secure subresources.

In order to avoid breaking the web, the default has to be MUST NOT, because
SRI on non-secure origins has clear, well-known compatibility concerns due
to middleboxes tampering with content. Before the working group could
consider saying that SRI SHOULD or MUST be enforced for non-secure
documents and/or non-secure subresources, somebody needs to demonstrate
that doing so won't break the web.

For example, a browser like Firefox could implement SRI and then use its
telemetry mechanism to determine how often enforcing SRI would break a
page. Then, it could deploy a release version that enforces SRI for
non-secure documents and/or non-secure subresources and see what kinds of
breakage bug reports it gets. From there, the working group could consider
the issue of whether the specification should be changed to say that SRI
SHOULD or MUST be enforced for non-secure things, perhaps with additional
language concerning the Content-Transform header and other necessary evils
that seem likely to be necessary.

But, unless/until somebody actually does that experiment, for "don't break
the web" reasons alone, it makes sense to say that SRI MUST NOT be enforced
only for non-HTTPS documents or non-HTTPS subresources.

Note also that SRI 1.0 could get published with the "MUST NOT" language and
then SRI 2.0 could change that, if such experiments are not done before SRI
1.0 is finalized.

Anyway, please don't interpret this email as an endorsement of SRI for
non-secure origins. It's just a suggestion for a productive way to move the
conversation towards a conclusion for SRI 1.0. I suspect that if anybody
does the experiments I suggest, SRI for non-secure origins will be shown to
be unworkable.

Cheers,
Brian