Revisit anchor element download attribute for cross-origin links

[WebWeWantBot]

---

title: Revisit anchor element download attribute for cross-origin links
date: 2023-06-22T22:19:19.331Z
submitter: Brad Isbell
number: 6494c8e7b2763a007a11a7f3
tags: [ ]
discussion: https://github.com/WebWeWant/webwewant.fyi/discussions/
status: [ discussing || in-progress || complete ]
related:

• title:
  url:
  type: [ article || explainer || draft || spec || note || discussion ]

---

Today, the download attribute for anchor elements can be used to specify that the linked resource should be downloaded (rather than opened in a browser view), and can also specify a filename. For example, suppose my website at https://puppy-vlog.example.com/ wants to provide a download link for the latest episode.

<a href="puppy.webm" download="My Puppy.webm">
  Download my puppy's latest vlog!
</a>

Now, suppose my site becomes popular and I want to use common CDNs to serve my downloads:

<a href="https://cdn.example.com/puppy-vlog/assets/2acaf36f-b8b6-4222-bc7a-7c4e4052f881" download="My Puppy.webm">
  Download my puppy's latest vlog!
</a>

This doesn't work.

The reason is that over a decade ago, it was decided this was a potential security risk. The argument, as I understand it, is that we did not want users making a cross-origin download while not realizing they were doing that. We did not want them to be tricked into then re-uploading that file to the place they downloaded it from. You can read some of this discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=676619

While I appreciate the concern for the security of this edge case, I think in practice we have more security issues, as well as wasted resources. With no way for the client to specify a download, the server must do it by way of Content-Disposition header. This has lead to many insecure implementations of proxying resources. (A common example can be seen on Stack Overflow: https://stackoverflow.com/a/29773570/362536)

Furthermore, we are now in a time where many web applications are simple static websites without any dynamic server infrastructure. Without a server to proxy and add the header, these applications can't do much about their situation. At best they can fetch the resource as a Blob, but this is slow, memory intensive, and inappropriate for files of any significant size.

A solution...

Let's follow existing CORS restrictions. Certainly if an origin is willing to opt-in to allow another origin to fetch its resources directly, there cannot be any additional risk from allowing users to download cross-origin.

---

If posted, this will appear at https://webwewant.fyi/wants/6494c8e7b2763a007a11a7f3/