- From: Brad Hill <hillbrad@gmail.com>
- Date: Mon, 28 Jul 2014 10:05:31 -0700
- 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". -Brad 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