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

We can get into that if needed; but I don't think that changes Freddy's
point---we shouldn't merge two different concepts together in one directive.

On Wed, 26 Sep 2018 at 10:16, Bertil Chapuis <bchapuis@gmail.com> wrote:

> On Tue, 25 Sep 2018 at 18:49, Devdatta Akhawe <dev.akhawe@gmail.com>
> wrote:
> >
> > I haven't dug in heavily but I am imagining:
> >
> > 1. Allow download attribute on cross origin resources if cross-origin
> attribute exists
> > 2. Allow integrity work as expected when download attribute exists (so
> just works on same origin and needs cross-origin attr on x-origin resources)
>
> Thanks for your inputs. If I understand correctly it would mean that
> the integrity attribute would be used as follows (on a page at
> https://www.website.com):
>
> <a href="https://www.website.com/file.exe" integrity="hash" download>
>
> or (if the file has a different origin):
>
> <a href="https://www.another-website.com/file.exe"
> crossorigin="anonymous" integrity="hash" download>
>
> Today, the first option brings little as the considered threat arises
> mostly in cross-origin contexts (website + CDN) and the second option
> is in conflict with the same-origin requirement of the download
> attribute.
>
> The fact that the specs of the download and integrity elements are
> interdependent complexifies the problem. Just to be sure we are on the
> same page, could anyone recall what were the security reasons for
> restricting the download attribute to same origins?
>
> > On Tue, 25 Sep 2018 at 07:39, Eric Lawrence <Eric.Lawrence@microsoft.com>
> wrote:
> >>
> >> Is the proposal here to respect the Download attribute on a
> cross-origin resource only when cross-origin is set or integrity is
> provided and matches?
> >>
> >>
> >>
> >> (If not, we reintroduce the same security problems that resulted in the
> Download attribute being restricted to Same-Origin to begin with.)
> >>
> >>
> >>
> >> From: Devdatta Akhawe <dev.akhawe@gmail.com>
> >> Sent: Friday, September 21, 2018 7:17 PM
> >> To: Bertil Chapuis <bchapuis@gmail.com>
> >> Cc: Frederik Braun <fbraun@mozilla.com>; public-webappsec@w3.org;
> Kévin Huguenin <kevin.huguenin@unil.ch>; Igor Bilogrevic <
> ibilogrevic@google.com>; Mike West <mkwst@google.com>
> >> Subject: 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
>