Re: subresource integrity and browser extensions

As Yan noted in her email, I agree with this position. Given the
conversations around similar topics for CSP, I think it probably reflects
the conensus of the group, and I've added non-normative language to this
effect in
https://github.com/w3c/webappsec/commit/b85f0fad4a1d38f57f3bcc457c6f32ad703f3ee8
.

CCing Glenn explicitly, since Cox seems concerned about this sort of
language in general. If another formal objection is coming, I'd like to
know about it sooner rather than later. :)

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)


On Wed, Mar 26, 2014 at 12:57 PM, Mike West <mkwst@google.com> wrote:

> Forwarding this on from Yan Zhu.
>
> --
> Mike West <mkwst@google.com>
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>
>
> ---------- Forwarded message ----------
> From: Yan Zhu <yan@eff.org>
> Date: Tue, Mar 25, 2014 at 10:35 PM
> Subject: Fwd: subresource integrity and browser extensions
> To: Mike West <mkwst@google.com>
>
>
> Hi Mike,
>
> Somehow my emails to public-webappsec aren't going through even though
> I'm subscribed and getting emails :(. Feel free to forward or I can
> continue troubleshooting.
>
> -Yan
>
>
> -------- Original Message --------
> Subject: subresource integrity and browser extensions
> Date: Tue, 25 Mar 2014 13:27:10 -0700
> From: Yan Zhu <yan@eff.org>
> To: public-webappsec@w3.org <public-webappsec@w3.org>
>
> Hi all,
>
> Mike West seemed to suggest on EFF's crypto-ops mailing list thread
> about SRI [1] that the spec should address how SRI interacts with
> browser extensions. I thought I would cross-post my input as the
> maintainer of HTTPS Everywhere (https://eff.org/https-everywhere).
>
> [1] https://lists.eff.org/mailman/listinfo/crypto-ops. Archives are
> visible to list members only.
>
>
> Mike West wrote:
> > This proposal _would_, however, make it difficult for extensions to
> > redirect one request to another resource. That's something we should
> > address in the spec; extensions should be capable of bypassing these
> checks.
>
> This is the HTTPS Everywhere problem. It's possible that a resource will
> fail SRI checks when it's rewritten (correctly!) by our extension to its
> HTTPS version. This rewrite definitely happens before SRI gets a chance
> to work because it occurs inside a web request listener.
>
> Here are two examples of things we've seen in the real world:
> 1. The title of http://site.com is "Welcome to our site!" whereas the
> title of https://secure.site.com is "Welcome to our secure site!" The
> SSL version gets blocked when it's inside an iframe with a SRI hash for
> the non-SSL version.
> 2. The SSL version of a resource has all of its own subresource URL
> schemes changed from "http://" to "https://", because the developer has
> some server-side script that detects whether the resource is served over
> SSL and changes the URLs accordingly (perhaps for mixed content reasons).
>
> In general, there's no guarantee that a site is serving the exact same
> resource over HTTP and HTTPS; part of the job of HTTPS Everywhere
> contributors is to check and make sure that any differences are innocuous.
>
> The reasonable solution is to allow extensions to bypass SRI, though
> this may cause website operators and extension repository maintainers to
> complain that extensions shouldn't have the power to *disable* security
> features unless the user installed them for that purpose or had to check
> a box giving them permission to. Nonetheless, I think specifying that
> extensions can bypass SRI in the spec is a good idea if there are no
> objections.
>
> I'm not too concerned either way; we've survived more annoying breakages
> in the past.
>
> Hope this is useful,
> Yan
>
>
>
>
>
>