W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2018

Re: Extending Subresource integrity to more elements (<a>, <img>, etc.)

From: Bertil Chapuis <bchapuis@gmail.com>
Date: Wed, 19 Sep 2018 14:55:02 +0200
Message-ID: <CAPb0bti4LG3MnYrZWSkZrkMi945p+nwjv4cSRDO5ENfP2onvsw@mail.gmail.com>
To: dev.akhawe@gmail.com
Cc: public-webappsec@w3.org, Kévin Huguenin <kevin.huguenin@unil.ch>, Igor Bilogrevic <ibilogrevic@google.com>, Mike West <mkwst@google.com>
Hello Dev,

> There is a lot of history here
> https://github.com/w3c/webappsec-subresource-integrity/issues/68
> The spec work is a bit tricky too given that you need to define the cross origin tag for anchor etc. But if @annevk is helping, I am confident most spec issues can be resolved.

Thanks for the pointer, we noticed this issue but still had a couple
of questions regarding the ongoing discussion.

In our understanding, the download attribute currently informs the
browser to download the resource pointed by a link, even if the
Content-Disposition header of the HTTP response is not set. As
suggested by @annevk, as this attribute only works for same-origin
URLs, an exception for anchor tags that include both the cross-origin
and the download attributes could be introduced. As these attributes
are not mandatory, wouldn't it be more appropriate to simply trigger a
download if the integrity tag is present (regardless of the MIME type,
Content-Disposition or download attribute)?

Note that from a security perspective, the integrity attribute is less
needed in the same-origin context.

As hinted by @mikewest, CORS is required to prevent the exposition of
the content of the resource via hashes. However, if anchor tags
containing integrity attributes systematically trigger downloads in a
fire-and-forget fashion, would such exposition of the content occur?

Best regards,

Received on Wednesday, 19 September 2018 12:55:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:04 UTC