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

Re: SRI: <a> vs integrity

From: Eduardo Robles Elvira <edulix@agoravoting.com>
Date: Mon, 28 Jul 2014 20:03:06 +0200
Message-ID: <CAHwZu3dr3=uPkjQsbCYM8vV-EGbp4MSJymA1Kcrae=ADc13tgQ@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, "public-webappsec@w3.org" <public-webappsec@w3.org>

On Mon, Jul 28, 2014 at 7:05 PM, Brad Hill <hillbrad@gmail.com> wrote:
> It just wasn't something we put in scope when we re-chartered to work
> on it. Not to be glib, but we decided to work on "Subresource
> Integrity", not "Navigation Integrity".
> For a variety of reasons, including the priority of constituencies
> (http://www.w3.org/TR/html-design-principles/) and the history and
> principles of the architecture of the Web, we tend to tread much more
> cautiously around anything that would restrict user's free navigation
> around or "damage the graph" of the web, even if sometimes that graph
> is constructed in insecure ways.
> It's one thing to allow an author to specify precisely what makes up
> their application, and silently (to the user) fail to load unexpected
> content.  It's quite another to introduce brittleness that requires
> user notification and intervention to the fundamental act of
> navigating a browser.  It wasn't clear there was even interest for
> that, or that we had an idea of how to do it well, without introducing
> a poor and desensitizing user experience.  We're experimenting around
> the edges of that with the new Mixed Content spec
> (http://www.w3.org/TR/mixed-content/) and that may lead to better
> agreed-upon ways to manage that problem.

I don't think that's accurate nor make much sense. When a user enters
in a page with a self-signed certificate, the user gets a really big
warning "this is insecure, get away!". Doesn't that restrict user free
navigation and "introduce brittleness that requires user notification
and intervention to the fundamental act of navigating a browser" too?

It's also related to the web application: you could link to the same
link from anywhere else without getting any warning if the hash is not
valid, because the hash is provided by the web page.

> Protecting download integrity is arguably a border-case here between
> what constitutes an application action and what constitutes a
> navigation, but we felt it was a very well-understood scenario and use
> case for which there would be many "customers".

I believe downloads are a very typical user interaction in the
world-wide web, and I think that if SRI introduces download integrity,
many websites that are security-concious will really use this feature
because it's very handy. How many times I have seen the warning
"download the link *and check the md5sum*", uncountable times! This
really is not border-case, and quite important, actually.

Received on Monday, 28 July 2014 18:04:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC