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

For what it's worth, for all the attention that HTTPS is getting of
recent (for good reasons), I suspect that an opportunistic compromise
of a JS-hosting CDN is a more endemic and pervasive risk to most users
than the possibility of active MITM on unencrypted wifi or so.

While I'm strongly in support of pushing high-profile sites over to
HTTPS (*koff* Amazon *koff*)... unless we're completely writing HTTP
off, it's probably reasonable to allow the "bad CDN" problem to be
addressed by SRI independently of deploying HTTPS everywhere.

/mz

On Tue, Nov 4, 2014 at 2:41 PM, 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.
>
> Most users aren't going to understand SRI at all and it's not a user facing
> feature, so we aren't giving them any new or misleading security guarantees.
> There may be other new features that we want to restrict to HTTPS as a stick
> to get developers to migrate to secure origins, but features like SRI that
> can only help protect users shouldn't be put in that bucket.
>
>
> On 11/3/14 4:28 PM, Chris Palmer wrote:
>>
>> On Mon, Nov 3, 2014 at 4:02 PM, Joel Weinberger <jww@chromium.org> wrote:
>>
>>>> Although it would be desirable for every site to use HTTPS,
>>>> I don't think that SRI is the right way of promoting this.
>>>
>>> This isn't a matter of promoting HTTPS; it's a matter of suggesting to
>>> users
>>> and developers that they're getting a security property that they're
>>> simply
>>> not getting.
>>
>> Exactly.
>>
>> I'm increasingly concerned about this idea, popping up in several
>> contexts now, that there can be any security at all without at least
>> strong server authentication, data integrity, and data
>> confidentiality. Like, we need those as the baseline minimum, so that
>> we can *begin* to think about the next problems, like metadata
>> confidentiality.
>>
>> Putzing around in the margins like this (Better Than Nothingism) is
>> not going to help users.
>>
>
>

Received on Tuesday, 4 November 2014 23:08:30 UTC