W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2015

Re: CfC: Subresource Integrity (SRI) to Last Call?

From: Austin William Wright <aaa@bzfx.net>
Date: Thu, 23 Apr 2015 14:51:07 -0700
Message-ID: <CANkuk-Xzj7epw-0YiT-jdg6ZyRzay=-3YLDUvNyeh8VGYbcAWA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Joel Weinberger <jww@chromium.org>, Devdatta Akhawe <dev.akhawe@gmail.com>, Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Thu, Apr 23, 2015 at 9:51 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Apr 22, 2015 at 3:48 PM, Joel Weinberger <jww@chromium.org> wrote:
> > FWIW, it would not be difficult for Chrome to switch back to the ni:///
> > syntax, so I don't think we should make that a blocker on using it.
> As per
> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0200.html
> and other emails I wrote on the subject I'm opposed to switching back.
> URLs add a layer of abstraction to the processing model that is not
> warranted and for which there is no precedent. The precedent worth
> following here is CSP and HTML's existing approach to syntax within
> attributes.

That's because this isn't a URL, it's a URI (at least not without an
authority component). As such, it's completely opaque to Web browsers.

While `integrity` isn't limited to HTML, there's plenty of precedent for
using URIs outside use as network identifiers in HTML, namely the `rel` and
`xmlns` attributes, and the `profile` media type property.

Also the rel="profile" link relation type in RFC 6906 [1]:

      Notes: Profile URIs are primarily intended to be used as
      identifiers, and thus clients SHOULD NOT indiscriminately access
      profile URIs.

In any event, Web browsers shouldn't need to care, the syntax is arbitrary
to them.



[1] https://www.ietf.org/rfc/rfc6906.txt
Received on Thursday, 23 April 2015 21:51:35 UTC

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