Security/Reviews/Firefox10/PanelDownload

Items to be reviewed: Panel Based Download Manager

• https://wiki.mozilla.org/User:P.A./Panel-based_Download_Manager
• Mostly landed on UX branch (builds)
• http://limi.net/articles/safari-downloads/

Agenda:

Introduce Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

• to move dowloads into a panel that drops down from the awesome-bar area

1. Replacing download window with a panel

    Will support dragging.

2. Replacing download history UI 3. Not showing the open-or-save dialog in most cases. Instead, 4. Open the default handler if it's on a small whitelist of “fairly safe document formats”: PDFs, images, videos, DMGs.

    But also keep it in the download folder. Clutter, but prevents dataloss.

5. Zips and exes always save 6. Other things still ask 7. What will we do for Content-disposition:attachment?

Out of scope

• Better+safer UI for downloading executables - https://bugzilla.mozilla.org/show_bug.cgi?id=249951. For now, we'll just save and show the panel. (And we'll keep the warning if you decide to open-from-Firefox.)
• Application reputation for downloading executables - https://bugzilla.mozilla.org/show_bug.cgi?id=662819
• Better+safer UI for downloading archives such as zips - https://bugzilla.mozilla.org/show_bug.cgi?id=175008. For now, we'll just save and show the panel.
• Making sure your PDF viewer and video player are up-to-date.

What solutions/approaches were considered other than the proposed solution?

• Chrome-style (in the status bar)

Why was this solution chosen?

• need to make file-download experience better for users
• parity with other browswers

Any security threats already considered in the design and why?

Threat Brainstorming

• Jesse: we shouldn't distinguish based on whether the link goes directly to the download.
  • Users can't guess the MIME type based on the URL of the link.
  • Cross-site links (e.g. in emails) can go straight to downloads.
  • Lots of legitimate downloads go through redirects.
  • Download links are slow, so the analogy with popups fails.
  • If the concern is DoS, there should be better ways to
• DoS: fill disk with stuff if it goes directly to some download folder that is not cleaned up
  • with content-encoding or tranfer-encoding compression, this doesn't necessarily require lots of bandwidth
  • This attack is probably possible even with the old download UI. It's just a DoS. Meh.
• Does the download URL get run through the safebrowsing list (for known exploit URLs)?
  • does whatever we currently do (out of scope for this review)
• Can users tell Firefox "don't open PDFs automatically" if they are paranoid or archivers?
  • Yes, in Prefs
• Can Mozilla tell Firefox "don't open PDFs automatically" in an Adobe Reader firedrill situation? Or even for a particular helper app? (Kill switch.)
  • No
  • Maybe instead of adding kill switches to Firefox, we'll rely on legneato's crazy plan.
• Can we ensure that Firefox will never open an external PDF reader automatically if the user has a PDF plugin? (Even if the site uses content-disposition: attachment)
  • that is true today -- we never consider external handlers if there's an internal one (which includes plugins)
  • ok, not sure in the C-D:attachment case
  • When pdf.js lands, inline will be the default, even for content-disposition: attachment!

Conclusions / Action Items

• Limi will share the proposed lists (always show in browser even if content-disposition attachment, always open, always save) with the secteam.