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

Not sure I understand. I think Freddy is saying that it's reasonable to
require people to add both the integrity attribute, the download attribute,
and the cross origin attribute. Basically, we don't need to implicitly make
integrity also mean the cross origin and download attribute.

I agree with him. Not tying things together is cleaner and more flexible. I
don't think the overhead for developers is that high.

On Fri, Sep 21, 2018, 12:26 PM Bertil Chapuis <bchapuis@gmail.com> wrote:

> On Thu, 20 Sep 2018 at 15:46, Frederik Braun <fbraun@mozilla.com> wrote:
> > 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.
>
> Fair point, I totally agree that this could be problematic. In this
> regard, the idea of introducing an exception for the anchor tags (that
> include both the cross-origin and the download attributes) is much
> clearer. However, if we don't introduce an exception for the
> same-origin constraint, I would go so far as to say that checking the
> integrity is useless, i.e., an attacker gaining access to the origin
> can change both the resource and its checksum. As the status quo is
> not ideal neither, do you have another alternative in mind?
>
> Bertil
>