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

On 19.09.2018 14:55, Bertil Chapuis wrote:
> 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?

Implicitly conflating attributes for some elements, but not for others
is too surprising, imho.
I do agree, that the use case for integrity on same-origin is certainly
smaller.
But if the `integrity` attribute secretly implied a cors-anonymous
request, you'd effectively disallow same-origin downloads that require
authentication cookies to work with integrity. And disallowing that
completely is also odd.

Received on Thursday, 20 September 2018 13:46:39 UTC