On 5/8/13 12:37 PM, Gordon P. Hemsley wrote:
I understand now the motivation for this, but I would think that it
would remove a lot of the usefulness of the @download attribute

You're right, but we haven't found another mitigation for our security concerns.

If you have the same origin, you probably already have access to (a) name
the file appropriately in the first place, or (b) set the
Content-Disposition header to send the appropriate filename. No?

For files, not for things like data: and blob:, which were the primary motivation for @download.

That said, there are lots of cases in which someone can upload files but not pick the filename on the server or control the headers...

I'm not so sure about that, but I'll leave it to someone else to
argue. (If you determine a file to be a PNG, then you suggest a .png
extension, regardless of whether there might be an embedded
executable; if you don't support the file format, then how do you know
that it isn't supposed to be an executable in the first place? —and
what is it doing on the Web?)

I assume that last question is a joke, yes?  ;)

-Boris

Reply via email to