W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

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

From: Chris Palmer <palmer@google.com>
Date: Wed, 5 Nov 2014 12:31:20 -0800
Message-ID: <CAOuvq21FVvZhrbhKLoXyTu1bv_tL5=vYfmrhD+G9ZCY_zKj-rw@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
Cc: Tanvi Vyas <tanvi@mozilla.com>, Frederik Braun <fbraun@mozilla.com>, Joel Weinberger <jww@chromium.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Pete Freitag <pete@foundeo.com>
On Tue, Nov 4, 2014 at 7:22 PM, Michal Zalewski <lcamtuf@coredump.cx> wrote:

>> Why expend effort on a guarantee so weak you don't want to surface it to
>> users?
>
> If it's extra work, I don't think it makes sense. But it doesn't
> really add complexity to permit HTTP origins, right?

Well, doing SRI at all is extra work. I tried to argue against SRI
from the beginning, because I knew it was going to come to this. And
indeed, here we are.

> I think the best argument in favor of allowing it is that it improves
> the security of the web. Today, people load scripts from CDNs, social
> networks, and ads services, and if the CDN / etc gets compromised,
> they will have a very bad time. SRI can fix that, that's a good thing.

SRI can't fix it so well that we can make any kind of promise to
users. I'm only interested in things that are good enough to surface
to users.

> Separately, we have this dream of promoting broader use of HTTPS (with
> opinions somewhere on a scale between "Amazon and Bing really need to
> start doing it" and "HTTP needs to die completely") that may or may
> not come to fruition.
>
> I'm unconvinced that we should take away SRI from HTTP sites to get
> there, though. Maybe...

Again, I don't see it as carrots and sticks. It's just, "Do we want
the web to be a cesspool of surveillance, spam, and malware? Or do we
want to achieve at least the bare minimum of safety before we give web
pages access to sensors on phones?" But that's sort of tangential to
the SRI discussion.
Received on Wednesday, 5 November 2014 20:31:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC