#827 assigned defect

Put file download links ('?save=true') in WUI directory listings

Reported by: davidsarah Owned by: davidsarah
Priority: major Milestone: soon
Component: code-frontend-web Version: 1.5.0
Keywords: security usability capleak docs download easy Cc: freddyb
Launchpad Bug:

Description (last modified by daira)

Typical behaviour of web browsers for a retrieved over HTTP[S], is to decide based on its inferred MIME type whether to display it, pass it to some plugin/helper app, or treat it as a download (either pass it to a download manager or prompt the user to save it locally). The inferred MIME type is arrived at by rules that no-one understands; the HTTP spec says that the HTTP Content-Type takes precedence, but browsers deliberately violate that in some cases, and the result can even vary nondeterministically depending on network delays.

Sometimes it's useful to override this behaviour and force the browser to treat the file as a download, regardless of its inferred MIME type. This can be done using the Content-Disposition HTTP header, e.g. "Content-Disposition: attachment; filename=suggested_name".

(Well, not actually force, but strongly hint. I think all the common browsers now implement this; IE has had some bugs http://support.microsoft.com/kb/279667 but I think they are all pre-IE6.)

Content-Disposition is specified in:

(The "very serious security considerations" mentioned in http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.5 are scaremongering. A server can't do anything with Content-Disposition: attachment that can't also be done via the MIME type.)

To close this ticket,

  • add an optional parameter to the webapi that will force a download.
  • modify Tahoe directory listings to include 'download' and 'view' links.

Note that if the most prominant link for a non-directory file was the download link, that would allow the WUI to be used from a browser (with some care on the part of users) without necessarily being vulnerable to the same-origin attacks described in #615. Users would only be vulnerable to these attacks if they click the view link, or if they view the downloaded local files in a browser that treats all file URLs as same-origin (or has some other related bug such as http://www.mozilla.org/security/announce/2009/mfsa2009-30.html ).

Change History (21)

comment:1 Changed at 2009-11-01T06:37:41Z by davidsarah

  • Summary changed from Support forcing download using "Content-Disposition: attachment" in WUItre to Support forcing download using "Content-Disposition: attachment" in WUI

comment:2 Changed at 2009-11-01T06:38:28Z by davidsarah

  • Component changed from unknown to code-frontend-web

comment:3 Changed at 2010-01-22T21:08:50Z by davidsarah

  • Summary changed from Support forcing download using "Content-Disposition: attachment" in WUI to Put file download links ('?save=true') in WUI directory listings

The facility to download using Content-Disposition: attachment already exists, using the save=true parameter. It is even documented in source:docs/frontends/webapi.txt . I was confused partly by seeing the undocumented @@named feature used by the file info page, which downloads the file as text/plain (treated by browsers as "guess the type").

However, there isn't any way to access the file download URI from the WUI other than by manually adding the save=true parameter, which makes this feature undiscoverable except by reading technical docs.

comment:4 Changed at 2010-02-01T19:50:39Z by davidsarah

  • Milestone changed from undecided to 1.7.0

comment:5 Changed at 2010-02-27T18:18:30Z by zooko

  • Keywords easy added

comment:6 Changed at 2010-03-12T04:10:59Z by davidsarah

  • Owner changed from nobody to davidsarah
  • Status changed from new to assigned

comment:7 Changed at 2010-03-25T20:23:51Z by davidsarah

  • Keywords capleak download added

comment:8 follow-up: Changed at 2010-05-02T13:49:48Z by davidsarah

If #1029 were implemented, it would make sense for child entries that are directories to have a 'download as archive' link.

comment:9 Changed at 2010-05-17T02:19:40Z by davidsarah

  • Milestone changed from 1.7.0 to 1.8.0

comment:10 Changed at 2010-08-08T05:32:34Z by davidsarah

  • Milestone changed from 1.8.0 to soon

comment:11 Changed at 2012-08-27T18:12:56Z by davidsarah

  • Cc freddyb added
  • Keywords docs added
  • Milestone changed from soon to 1.11.0

comment:12 in reply to: ↑ 8 Changed at 2012-08-27T18:16:56Z by davidsarah

Replying to davidsarah:

If #1029 were implemented, it would make sense for child entries that are directories to have a 'download as archive' link.

The scope of this ticket for 1.11 is just to add the download link for files, probably as an icon next to the filename.

comment:13 Changed at 2012-08-27T18:40:11Z by zooko

See also #277 where I wish for an alternate design for the WUI where every link in LAFS has a page in the WUI. That page would be the place where a Save-As and a Display would go, perhaps.

comment:14 Changed at 2012-08-27T18:44:39Z by zooko

Brian suggested a good idea: a separate port for "pure bytes, unmolested by the LAFS layer -- what you put in is what you get at" and for "content, such as should be displayed in a web browser". Fetching a resource (e.g. with a file cap) from the latter port might result in content that wrapped in a Secure Ecmascript prefix, for example, which attempts to nullify the ability of Javascript within the content to do bad things once it is displayed in a browser.

I propose that we have separate ports for at least these uses:

  1. Pure no-JS-required WUI/WAPI
  2. Pure bytes data port -- you should never ever point a web browser at this port! Use the web content port instead.
  3. Content for display--the content might be manipulated, such as by prepending a Secure Ecmascript prelude, or other attempts to confine the content when your browser runs it.
  4. New shiny JS-powered WUI/WAPI

comment:15 Changed at 2012-08-27T19:01:28Z by davidsarah

Please stay on topic for this ticket! A separate ticket should be filed for the multiple-port idea, or use #615 for general discussion of WUI same-origin and sandboxing issues.

Comment that should really be on #1797, except that it's addressing comment:14 :

  • Note that HTML5 sandbox does not in any way require JS. Nor does it stop single-page JS webapps served from Tahoe from working, if allow-scripts is set in the sandbox tag. Multi-page JS webapps can also work if they do not rely on same-origin information sharing, although we might need to handle .css and .js filetypes differently because the browser will be expecting them to be served raw, not framed.

comment:16 Changed at 2012-08-27T19:09:12Z by davidsarah

Multiple ports ticket filed as #1798.

comment:17 Changed at 2013-08-13T23:00:06Z by daira

  • Description modified (diff)
  • Milestone changed from 1.11.0 to 1.12.0

comment:18 Changed at 2016-03-22T05:02:25Z by warner

  • Milestone changed from 1.12.0 to 1.13.0

Milestone renamed

comment:19 Changed at 2016-06-28T18:17:14Z by warner

  • Milestone changed from 1.13.0 to 1.14.0

renaming milestone

comment:20 Changed at 2020-06-30T14:45:13Z by exarkun

  • Milestone changed from 1.14.0 to 1.15.0

Moving open issues out of closed milestones.

comment:21 Changed at 2021-03-30T18:40:19Z by meejah

  • Milestone changed from 1.15.0 to soon

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.