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

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 22:40:57 UTC