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

Re: SRI: Behavior when a developer fails to specify CORS

From: Joel Weinberger <jww@chromium.org>
Date: Fri, 12 Jun 2015 03:21:28 +0000
Message-ID: <CAHQV2KmpnUu7T6HWJrdG=JnPSzba5vqFNSTs6GjGgL47UKvfOg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Jun 10, 2015 at 11:46 PM Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Jun 11, 2015 at 7:39 AM, Joel Weinberger <jww@chromium.org> wrote:
> > FWIW, the status quo is (1). At least a majority of the editors lean
> towards
> > (1) as well since we can adjust in the future in a forwards compatible
> way,
> > but we want to check in with the community to see what we're missing
> here.
> > Again, you can check out the GitHub issue for all the juicy details of
> our
> > back-and-forth.
>
> Given the compatibility argument, (1) would be safest there too.
> Otherwise e.g. painting
>
>   <img integrity=...>
>
> on a <canvas> and then exporting it would fail in older user agents
> while it would work in newer user agents that get that integrity
> implies crossorigin. (You can think of similar examples with <script>
> and remote debugging or <link rel=stylesheet> and CSSOM.)
>
Wouldn't these examples be compatible in all the cases, since the integrity
attribute is not defined for any of these elements (and I'm sure we
wouldn't turn on crossorigin=anonymous in the presence of integrity except
in cases where the elements where integrity is defined)? Perhaps I'm
misunderstanding the point.

>
>
> --
> https://annevankesteren.nl/
>
Received on Friday, 12 June 2015 03:22:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:13 UTC