W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2013

Re: [whatwg] Priority between <a download> and content-disposition

From: Glenn Maynard <glenn@zewt.org>
Date: Tue, 19 Mar 2013 20:05:13 -0500
Message-ID: <CABirCh-deKhBpfPU8AsEnh5uOnw==8k8MNhbMBcQwuf_jWU5zQ@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
Cc: WHAT Working Group <whatwg@whatwg.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, Jonas Sicking <jonas@sicking.cc>
On Tue, Mar 19, 2013 at 1:15 AM, Michal Zalewski <lcamtuf@coredump.cx>wrote:

> > This is about how the Web works, not browser UIs.  If I click a link on
> > www.computerviruses.com, and it prompts me to save a file to disk, I
> make my
> > decision of what to do with the file based on the context of the link I
> > clicked.
>
> In my experience, the web is a lot more complicated than that. There
> are many interesting corner cases here, including but not limited to
> downloads initiated by other documents / windows (say,
> http://lcamtuf.coredump.cx/fldl/).
>

I don't think the solution to that issue is to put the hosting URL in a big
font in the download dialog.  People won't read it; if they do, they won't
know how to interpret it (amazonaws.com probably looks "safe" to many
casual users), and some browser UIs don't even have a download popup
(Chrome).

My intuition for this case is that the download UI should be tab-modal to
the page that started the download.  For example, flash the tab that
started the download, and only prompt to download as an interface internal
to that tab.  In Chrome, for example, this might show up like the "download
this dangerous file?" prompt, but only be seen on the tab that started the
download.

This is a tricky case, but I don't think this feature makes it any worse,
since I don't think showing the hosting URL is a solution.  More generally,
given how hard it is to even get people to check for a TLS lock icon, I
don't think expecting users to evaluate URLs is reasonable.

With content sniffing, we have learned the hard way that
> second-guessing the intent of the owner of a server in terms of the
> way the content should be interpreted by the browser will almost
> always bite back. I think we're making the same mistake here (and in
> several other areas, too).
>

Content sniffing is something else entirely: it's software automatically
ignoring what the server says and doing something else.  This is an
explicit override by authors, not second-guessing.

-- 
Glenn Maynard
Received on Wednesday, 20 March 2013 01:05:39 GMT

This archive was generated by hypermail 2.3.1 : Wednesday, 20 March 2013 01:05:39 GMT