Security/Reviews/Firefox10/PanelDownload

From MozillaWiki
Jump to: navigation, search

Items to be reviewed: Panel Based Download Manager

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

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.