[whatwg] "Content-Disposition" property for <a> tags

[Dennis Joachimsthaler]

  Am 02.06.2011, 21:58 Uhr, schrieb Glenn Maynard <glenn at zewt.org>:

> On Thu, Jun 2, 2011 at 3:32 PM, Michal Zalewski <lcamtuf at coredump.cx>  
> wrote:
>>> I don't think the issue raised was about getting people to save files,
>>> though.  If you can get someone to click a link, you can already point
>>> them at something that sets the HTTP C-D header.
>>
>> The origin of a download is one of the best / most important
>> indicators people have right now (which, by itself, is a bit of a
>> shame). I just think it would be a substantial regression to make it
>> possible for microsoft.com or google.com to unwittingly serve .exe /
>> .jar / .zip / .rar files based on third-party markup.
>>
>> Firefox and MSIE display the origin fairly prominently, IIRC; Chrome
>> displays it in some views. But deficiencies of current UIs are
>> probably a separate problem.
>
> Firefox displays it in a small, unimportant-looking piece of text
> inside a busy dialog; I never even consciously noticed it until I
> looked for it.  For me, Chrome doesn't say anything; when I click an
> .EXE it saves it to disk without asking (maybe I changed a preference
> somewhere--that seems like an unlikely default).
>
> When I download a file, I decide whether to trust "dangerous" file
> types based on who's telling me to download it--that is, based on the
> site linking the file, not the site hosting it.  I'd strongly suspect
> that more people look at who's linking the file (eg. where they were
> when they clicked the link), and that very few people examine the
> "from:" text in the save-as dialog.
>
> Either way, again this is something that can be dealt with in UI, for
> example by displaying the source URL as the source of the download
> rather than or in addition to the domain hosting the file when this
> attribute is used.  It's a weak argument against this feature.
>

Also it doesn't matter since the content-disposition can be changed in
http headers anyway. So almost every case can be applied to this too.

If somebody wants to do evil things on your computer, he'd just use the
http header. We might only make it easier for them. Less programming skills
needed.

Security is a) the browser displaying security-relevant info the user
and b) the user USING the security relevant info. The user still has to
decide if he wants to open the file. Also, the browsers could do primitive
guesswork. Example: txt file content-dispositioned as .pl, .php, etc.
Browser can give a warning based on this.

If it's a php file content-dispositioned as a exe, txt, etc file, it would
not raise a warning, since php files from the server are usually  
server-sided
scripts.

By the way, another point that we have to discuss:

Which tag should a browser favor. The one in HTTP or the other one in
HTML?