- From: Chris Palmer <palmer@google.com>
- Date: Wed, 5 Nov 2014 12:31:20 -0800
- 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