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

Re: SRI: <a> vs integrity

From: Brad Hill <hillbrad@gmail.com>
Date: Mon, 28 Jul 2014 10:05:31 -0700
Message-ID: <CAEeYn8gJQzw+mb9y1Wb1i0SVTLy_GFd51uB8zi+dqYtRN_ZyDg@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
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.

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".


On Sun, Jul 27, 2014 at 9:57 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> Hi there,
> can somebody please explain why the spec rules out use of @integrity on <a>
> unless @download is set? (a pointer would be sufficient).
> Best regards, Julian
Received on Monday, 28 July 2014 17:06:01 UTC

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