W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2011

[whatwg] a rel=attachment

From: Chris Bentzel <chris@bentzel.net>
Date: Wed, 20 Jul 2011 07:33:51 -0400
Message-ID: <CABCZv0p7E58LMYVzPOz0yb60Vf1-ZZgpDwNraO0yfTyFQjdv-g@mail.gmail.com>
Who should be trusted for filename if the one specified by <a> on the
referring page differs from the one specified by Content-Disposition
on the to-be-downloaded resource?

On Tue, Jul 19, 2011 at 1:42 PM, Alexey Proskuryakov <ap at webkit.org> wrote:
>
> 18.07.2011, ? 9:35, Glenn Maynard ???????(?):
>
>> > A different scenario which I don't think has been discussed in this thread is bypassing a hosting service security settings. Consider a highly reputable hosting that doesn't let you upload executable files (or maybe just scans those for malware if uploaded). With @download, one could bypass that, and make users download or even run an .EXE file by following an innocuous link to a well known domain. This kind of download could be same origin or cross origin.
>>
>> The service hosting the file--the target of the link--shouldn't convey trust. ?The page containing the download link is where trust should come from, not the link target.
>
>
> There are many views on what conveys trust. If we don't go to the extremes (like users who click on anything and agree to any confirmation dialogs without reading them), there is certainly a group of people who look where a link points to before clicking it.
>
> The fact that hosting implies a certain degree of trust is also built into client software. For example, if you download an executable file on Mac OS X, then the system warns you about it on first launch, and tells you where it was downloaded from, not where a link to the download was.
>
> Hosting services do have their policies on what can be hosted. As we discuss a way to subvert those policies, we shouldn't start with an assumption that it's inconsequential.
>
> - WBR, Alexey Proskuryakov
>
>
Received on Wednesday, 20 July 2011 04:33:51 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:34 UTC