662819 - (downloadprotection) [meta] Download Protection: protect against malware, potentially unwanted software and uncommon downloads

Status: REOPENED

(Toolkit :: Safe Browsing, enhancement, P3)

Description

[Jesse Ruderman]

IE9 warns if you download software that is not commonly downloaded.

* http://blogs.msdn.com/b/ie/archive/2011/03/22/smartscreen-174-application-reputation-building-reputation.aspx

* http://blogs.msdn.com/b/ie/archive/2011/05/17/smartscreen-174-application-reputation-in-ie9.aspx

* Key quote: "When it comes to program downloads, other browsers today either warn on every file or don’t warn at all. Neither of these approaches helps the user make a better decision."

This seems like the only sane solution to the problem of socially engineering attacks that entice users to download and run malicious native software.

Microsoft's system allows reputation to accrue to the download's hash and code-signing certificate.  We might also want reputation to accrue to the page URL and download URL, especially if they use https and/or link fingerprints (bug 292481).

Designing the feature to have minimal impact on user privacy may be tricky. Resisting sybil attacks on the reputation system may also be tricky.  Microsoft's posts do not address these issues.

It might be sensible to partner with Microsoft, Google, Soluto, or an anti-virus vendor on this feature.

Comment 1

[Christopher Blizzard (:blizzard)]

Similar feature for Chrome?

http://www.computerworld.com/s/article/9217427/Google_adds_download_defense_to_Chrome_patches_15_bugs

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Is malware uncommonly downloaded?  I'd expect that malware that propagates through, say, Facebook, gets downloaded much more often than developer tools that I download.

Comment 3

[chris hofmann]

also related to Bug 646602 - Installing add-ons from AMO should not invoke the security prompt.

we actually have quite a bit of meta data for addons that we host to help users make an informed decisions about what they are installing.  work would be needed to unlock this data from amo and integrate it into the installation process of amo hosted addons.

then there is another project that would be needed to gather similar kinds of meta data for non-amo hosted software.

Comment 4

[Jesse Ruderman]

Kyle, this is intended to help with malware that constantly moves and changes. If any single piece of malware is frequently downloaded, other strategies come into play.

Comment 5

[Gian-Carlo Pascutto [:gcp]]

Aside from the privacy implications of such a feature (which may or may not be something we can engineer around), there is the question if we are able to deploy infrastructure that is effectively receiving and processing everything our 450M+ users download or visit.

Comment 6

[Gian-Carlo Pascutto [:gcp]]

FWIW, one idea that came up at some point during the all-hands is that this perhaps only needs to activate 1) on a page where there is a login/password dialog (need to recognize the common and alternate forms, and perhaps some misspellings, in many languages, which sounds doable) 2) when the user downloads something. So the infrastructure load may not be that big, and the privacy issues are reduced to only those 2 type of pages.

Comment 7

[chris hofmann]

getting beat up on not having something like this on the site set up at 

http://yourbrowsermatters.org/  and in the press at 

www.zdnet.com/blog/bott/microsoft-calls-out-firefox-and-chrome-for-security-weaknesses/4070

Comment 8

[Gian-Carlo Pascutto [:gcp]]

Jesse Rederman pointed out in response to my comment 4 that it is not possible to detect login/password prompts reliably. The reasons why are explained in bug 353922, which talks about something similar.

Comment 9

[Sid Stamm [:geekboy or :sstamm]]

Status: Google has a service for this, we are waiting on an API doc so we know how to interact with it and can finish weighing pros/cons of deploying their app-rep stuff as an extension to safebrowsing.  Taking the bug for now as I'm working with them to get the API.

Comment 12

[[:mmc] Monica Chew (no longer reading bugmail)]

While we're waiting for the "official" API, looks like the call in Chromium is here:

http://code.google.com/p/chromium/source/search?q=clientdownloadrequest&origq=clientdownloadrequest&btnG=Search+Trunk

We need to stuff at least one of sha256/sha1/md5sum hashes, the final url along with any redirects, optionally the filetype and other flags into a request, then process the verdict in response.

The download manager in firefox seems to be here:

http://mxr.mozilla.org/mozilla-central/source/toolkit/components/downloads/nsDownloadManager.cpp

I don't see offhand how to follow the chain of redirects, but from reading the protocol buffer we probably only need the target url. Sure would be nice to have an officially supported API, though :)

If anyone on this bug knows how to track redirects, hints welcome.

Monica

Comment 13

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Without knowing anything about what you're trying to do, you can receive redirect notifications via asyncOnChannelRedirect on an nsIChannelEventSink.

Comment 14

[[:mmc] Monica Chew (no longer reading bugmail)]

I think the idea is that if there's a redirect chain that leads to a downloaded executable, having the chain is useful in classifying whether or not the binary is malicious. I'll poke around more in the Chromium source to see if that's what actually happens.

Comment 15

[[:mmc] Monica Chew (no longer reading bugmail)]

Looks like Chromium does set the redirect chain:

http://code.google.com/searchframe#OAMlx_jo-ck/src/chrome/browser/safe_browsing/download_protection_service.cc&exact_package=chromium&q=clientdownloadrequest%20set_url&type=cs&l=659

    ClientDownloadRequest request;
    request.set_url(info_.download_url_chain.back().spec());
    request.mutable_digests()->set_sha256(info_.sha256_hash);
    request.set_length(info_.total_bytes);
    for (size_t i = 0; i < info_.download_url_chain.size(); ++i) {
      ClientDownloadRequest::Resource* resource = request.add_resources();
      resource->set_url(info_.download_url_chain[i].spec());
      if (i == info_.download_url_chain.size() - 1) {
        // The last URL in the chain is the download URL.
        resource->set_type(ClientDownloadRequest::DOWNLOAD_URL);
        resource->set_referrer(info_.referrer_url.spec());
        if (!info_.remote_address.empty()) {
          resource->set_remote_ip(info_.remote_address);
        }
      } else {
        resource->set_type(ClientDownloadRequest::DOWNLOAD_REDIRECT);
      }
      // TODO(noelutz): fill out the remote IP addresses.
    }
    request.set_user_initiated(info_.user_initiated);
    request.set_file_basename(info_.target_file.BaseName().AsUTF8Unsafe());
    request.set_download_type(type_);
    request.mutable_signature()->CopyFrom(signature_info_);

Comment 16

[Jesse Ruderman]

Tracking the entire redirect chain scares me a little, because some URL in the chain might (1) contain private data and/or (2) not realize the final destination is an executable.  Hopefully it's all encrypted before being sent to Google, at least?

Comment 17

[[:mmc] Monica Chew (no longer reading bugmail)]

The URL can always contain private data, for sure, whether it's on the redirect chain or the final URL. Chrome sends requests over SSL, so we should be able to as well (http://code.google.com/searchframe#OAMlx_jo-ck/src/chrome/browser/safe_browsing/download_protection_service.cc&exact_package=chromium&q=clientdownloadrequest&type=cs&l=50)

I'm not sure whether the redirect chain improves classification for that particular request, or whether it's used to improve classification for later requests, or whether it's something as yet unused on the server side. I'll ask.

Comment 18

[[:mmc] Monica Chew (no longer reading bugmail)]

Attachment: Changes to download manager to query application reputation.

- firefox.js: added prefs for turning on application reputation check, and URL for service
- downloads.js: add event handlers in case of bad application reputation
- nsDownloadManager.cpp: The bulk of the changes are in here. Change state machine to check application reputation after the download has finished
- nsDownloadManager.idl: Adds 2 new states, DOWNLOAD_REP_SCANNING and DOWNLOAD_BAD_REP
- csd.pb.{cc,h}: These are autogenerated files by the protocol compiler from Chrome's implementation of application reputation (http://git.chromium.org/gitweb/?p=chromium/chromium.git;a=blob_plain;f=chrome/common/safe_browsing/csd.proto)
- test_app_rep.js: Fakes a malware verdict and checks that DOWNLOAD_BAD_REP state is reached

Comment 19

[[:mmc] Monica Chew (no longer reading bugmail)]

Attachment: screencap

Comment 20

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 698939 [details] [diff] [review]
Changes to download manager to query application reputation.

We need to avoid doing main-thread I/O to calculate the hash from the file on disk. I think that means a slightly more complicated setup than your existing NS_NewLocalFileInputStream/UpdateFromStream setup, though I'm not sure exactly what the best solution is.

Comment 21

[:Gavin Sharp [email: [e-mail]]]

Paolo or Marco may have suggestions for ways to address comment 20.

Comment 22

[[:mmc] Monica Chew (no longer reading bugmail)]

This patch is kind of working, in the sense that malware verdicts are computed successfully and reach the "in progress" download UI. However, it borrows the UI from the windows AV scan, and that UI seems to be broken. In the "show all downloads" dialog, it seems that a download that gets a bad verdict (through application reputation or windows scan) stays stuck in "Starting..."

See http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/chrome/mozapps/downloads/downloads.dtd, where there are strings for "Starting" and "Scanning" but no strings like "Blocked: may contain a virus or malware" like there is in http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/chrome/mozapps/downloads/downloads.properties

Blockers:
- Fix "show all downloads UI"
- Make sure save file and app handlers abort on DOWNLOAD_BAD_REP
- Get API key from Google
- Implement exponential backoff if the service 503s

Comment 23

[[:mmc] Monica Chew (no longer reading bugmail)]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #20)
> Comment on attachment 698939 [details] [diff] [review]
> Changes to download manager to query application reputation.
> 
> We need to avoid doing main-thread I/O to calculate the hash from the file
> on disk. I think that means a slightly more complicated setup than your
> existing NS_NewLocalFileInputStream/UpdateFromStream setup, though I'm not
> sure exactly what the best solution is.

How about computing the hash wherever the transfer is taking place since the transfer has to read the bytes anyway, and saving the results in nsIDownload?

Comment 24

[:Gavin Sharp [email: [e-mail]]]

That's a good idea!

Comment 25

[(no longer active)]

(In reply to comment #20)
> Comment on attachment 698939 [details] [diff] [review]
>   --> https://bugzilla.mozilla.org/attachment.cgi?id=698939
> Changes to download manager to query application reputation.
> 
> We need to avoid doing main-thread I/O to calculate the hash from the file on
> disk. I think that means a slightly more complicated setup than your existing
> NS_NewLocalFileInputStream/UpdateFromStream setup, though I'm not sure exactly
> what the best solution is.

Could we use NS_AsyncCopy or something?

Comment 26

[:Paolo Amadini]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #20)
> We need to avoid doing main-thread I/O to calculate the hash from the file
> on disk. I think that means a slightly more complicated setup than your
> existing NS_NewLocalFileInputStream/UpdateFromStream setup, though I'm not
> sure exactly what the best solution is.

Uh, avoiding main-thread I/O is absolutely a requirement, though I'm afraid that
saying it's "slightly more complicated" is definitely euphemistic... I've learned
from bug 789932 that our network components were designed with main-thread I/O
in mind.

So, be prepared for a bit of work here. I'll try to summarize briefly, to avoid
writing too much, feel free to ask if something is unclear.

Option 1 is computing the hash after the download finished, by reading the data
from disk. To load the file on a background thread, you need to create the input
stream and then call nsIStreamTransportService::createInputTransport. But, since
nsICryptoHash::updateFromStream is _not_ able to leverage nsIAsyncInputStream,
you must create an nsIInputStreamPump and pass your own implementation of
nsIStreamListener to it, that calls UpdateFromStream inside OnDataAvailable.

Option 1-B is doing the same thing, but moving your current synchronous code to
your own background thread (so, including the hash computation).

Option 2 is computing the hash while the file is being saved. The issue here is
that nsIDownload does not generally execute the download; it only receives
progress updates and can call into an nsICancelable to abort the original
save operation. If a canceled download is resumed, then nsIDownload contains
some code to perform the download, but it is used only in that case.

This means that, to implement option 2, you would need to implement the hash
computation in several different components that save files. In addition, if
a download is paused and resumed, you would need to persist the mathematical
parameters that were used to compute the hash up to that point, then resume
computation starting with these saved parameters. I'm not sure if this "resume"
feature is supported by our existing hashing components - otherwise, you
would need to read the entire file again on resume, effectively going back
to implementing option 1.

In both cases, keep in mind that some downloads can involve multiple files
(like saving a complete web page), and hash computation might not make sense
in that case (that is, it shouldn't take place at all).

Obviously, option 1 increases the total download time, while option 2 doesn't,
but implementing option 2 is definitely more "challenging" than option 1
(euphemism intended).

I'll mention here, for completeness, that we are working on a new JavaScript
API for downloads in bug 825588, substantially unifying the code paths used
by downloads. At that point, we'll be able to feed a single BackgroundFileSaver
component per download, and extend it to leverage its existing background
thread for hash computation as well. We'll also be able to leverage JSON
serialization to persist the partial hash parameters if needed.

Comment 27

[[:mmc] Monica Chew (no longer reading bugmail)]

Hi Paolo,

Many thanks for your thorough consideration. It sounds like option 1A is the easiest to implement correctly, but for large files the delay may be intolerable. I can't find any recent data on malware size other than this: http://nakedsecurity.sophos.com/2010/07/27/large-piece-malware/

So it seems that malware sizes probably don't overlap substantially with common large downloads, and we may be able to skip the check if the download is, say, over 10M. Additionally, Google probably has similar issues when computing hashes and may truncate the hash to the first X MB anyway, I will ask.

If it turns that we can't skip malware checks on large files, then for option 2, one incremental approach might be to add optional in-progress hashing to the most common codepath (nsIInputStream?) and fix the cancel-resume case later, which probably also affects only large downloads.

It also seems that we should skip the multi-part case -- I notice in chromium code that this check is only supposed to trigger on a handful of executable extensions, anyway.

Monica

Comment 28

[:Paolo Amadini]

(In reply to Monica Chew from comment #27)
> So it seems that malware sizes probably don't overlap substantially with
> common large downloads, and we may be able to skip the check if the download
> is, say, over 10M. Additionally, Google probably has similar issues when
> computing hashes and may truncate the hash to the first X MB anyway, I will
> ask.

Looks like a good idea.

> If it turns that we can't skip malware checks on large files, then for
> option 2, one incremental approach might be to add optional in-progress
> hashing to the most common codepath (nsIInputStream?) and fix the
> cancel-resume case later, which probably also affects only large downloads.

There are at least two common code paths, "Save Link As" and single-click
downloads, that should be handled. And yes, not checking on pause and resume
may be a compromise we make initially.

Comment 29

[Devdatta Akhawe [:devd]]

The other side is, "how common are large downloads". I would guess that large downloads are extremely uncommon (basically non-existent) on mobile devices; and increasingly uncommon on desktops. And on desktops, I think the delay won't be that bad: users are already used to this for AVs and Windows Spynet etc.

That said, if Google only uses the first 10MB in their data then that is obviously the way to go. I wonder if we can also ask the Google folks about how common are the large downloads (based on the pings they receive).

Comment 30

[[:mmc] Monica Chew (no longer reading bugmail)]

Chromium source seems to indicate that the hash is based on the full file, from files in http://code.google.com/p/chromium/source/search?q=secure_hash_+file%3Asrc%2Fcontent%2Fbrowser%2Fdownload&origq=secure_hash_+file%3Asrc%2Fcontent%2Fbrowser%2Fdownload&btnG=Search+Trunk.

As to large download frequency, I guess they are pretty uncommon with the exception of torrents -- and we should probably shoot for delays that aren't suckier than on Windows :)

I think I can pass the hash in nsExternalHelperAppService, which has pointers nsITransfer (which I think maps to nsDownloadProxy) and nsIBackgroundFileSaver, which has access to the bytes as they are being read. nsExternalHelperAppService can either notify nsDownloadProxy of the hash when the file is done, or perhaps nsIBackgroundFileSaver can add the hash to nsIFile, if hashes are more generally useful.

Comment 31

[Gian-Carlo Pascutto [:gcp]]

Hashing only the first part of the file would allow the obvious workaround of putting malware in the last part, or making it 10Mb+epsilon bytes in size. So it's no surprise this isn't done.

Large (10M+) downloads: ISO images, graphics card drivers, software (executable and source distributions), ...

On a typical desktop system you're going to be saved for many of these because they will still be in the OS cache. However, for very large downloads, it's going to suck a lot.

Comment 32

[[:mmc] Monica Chew (no longer reading bugmail)]

Attachment: still borked

I need some xpcom help. BackgroundFileSaver is now computing the hash, but I'm having trouble passing it back to nsDownload. I created a new interface, nsIDownloadInfo, and am trying to pass that back to nsITransfer via nsExternalHelperAppService. However, the call to nsITransfer->OnTransferComplete seems to be disappearing into the ether.

I thought that nsDownload and nsDownloadProxy were the only concrete implementations of nsITransfer, but obviously neither of them are getting nsIDownloadInfo.

Any clues? Also, is the existing hash computation (teeing the input stream in BackgroundFileSaver and passing one to the hasher) acceptable?

Comment 33

[:Paolo Amadini]

Comment on attachment 700164 [details] [diff] [review]
still borked

Review of attachment 700164 [details] [diff] [review]:
-----------------------------------------------------------------

Handling the hashing in BackgroundFileSaver is indeed the most efficient and reusable way. I just want to reiterate that this currently applies to single-click downloads only. We'll need a follow-up to use BackgroundFileSaver at least in the "Save Link As" code path also, which is a Good Thing in any case. Summary of what we're supporting with this patch:
- Follow link: YES
- Auto-start by webpage: YES
- Save Link As: NO
- Pause then resume: NO
- Close browser then reopen: NO

I took a quick look at the code. I don't see at first glance why the function isn't called, but I've not investigated in detail since we need some changes to the approach in any case. My considerations:
- I suggest filing a different bug for the BackgroundFileSaver part.
- We must have unit tests for it (added to the existing xpcshell tests).
- We must support both BackgroundFileSaverStreamListener and
  BackgroundFileSaverOutputStream.
- More detailed notes follow!

::: netwerk/base/public/nsIBackgroundFileSaver.idl
@@ +129,5 @@
> +/**
> + * Interface for keeping track of file metadata on download
> + */
> +[scriptable, uuid(0e4867ee-5aab-11e2-a9df-33c86088709b)]
> +interface nsIDownloadInfo : nsISupports

BackgroundFileSaver is independent from nsIDownload and nsITransfer, and should be kept such. So, we don't need a new interface here.

Also, hash computation should be optional (and possibly, allowing to select the hash type as well).

I'm inclined to just have a new attribute "hasher" of type nsICryptoHash in BackgroundFileSaver, null by default, that must be populated by the consumers before calling setTarget. This will allow us to also support quick resuming in the future, if we extend nsICryptoHash to support initialization data.

To read the hash, we may put a readonly attribute "hash" in nsIBackgroundFileSaver, or just let consumers read the result from nsICryptoHash directly, after onSaveComplete is called.

::: netwerk/base/src/BackgroundFileSaver.cpp
@@ +777,5 @@
> +  rv = hashOutput->Close();
> +
> +  // Update the hash from hashInput
> +  rv = mHasher->UpdateFromStream(hashInput, UINT32_MAX);
> +  NS_ENSURE_SUCCESS(rv, rv);

We should move the hash computation to the background thread, operating on the data available from mPipeInputStream (or written to the file's nsIOutputStream). In addition to leveraging multi-core processors for computations, this way we support both BackgroundFileSaverStreamListener and BackgroundFileSaverOutputStream.

I'm not sure if we can avoid creating a second pipe - but for sure we must not create a new pipe every time OnDataAvailable is called. I'm not an expert in the networking components, different combinations of nsIInputStreamTee/nsIInputStreamPump/nsIStreamListenerTee/nsIPipe can be tried. But in the end, I think the most memory-efficient way is to proxy the file's nsIOutputStream through our own nsIOutputStream implementation, similarly to what "nsCheckSummedOutputStream.cpp" does.

::: uriloader/base/nsIWebProgressListener2.idl
@@ +71,5 @@
> +
> +  /**
> +   * When the transfer is complete, passes metadata about the download.
> +   */
> +  void onTransferComplete(in nsIDownloadInfo aDownloadInfo);

nsIWebProgressListener2 is a widely used interface and I wouldn't extend it for this specific use. I'd be fine with adding a specific method on nsITransfer to communicate the hash; nsITransfer is only implemented in the Download Manager (though it's proxied sometimes).

::: uriloader/exthandler/nsIExternalHelperAppService.idl
@@ +115,5 @@
>     * information on the current helper app launcher download.
>     * This reference will be released when the download is finished (after the
>     * listener receives the STATE_STOP notification).
>     */
> +  void setWebProgressListener(in nsITransfer aWebProgressListener);

You don't need to change the type here, you can QueryInterface to nsITransfer in the function if needed. By the way, you don't seem to be doing anything different with aWebProgressListener?

Comment 34

[[:mmc] Monica Chew (no longer reading bugmail)]

Getting closer -- the cleanest way to compute the hash seems to be to add hashing to nsLocalFileOutputStream (or rather, nsFileStreamBase), which BackgroundFileSaver uses in the async copy. This requires no extra pipes or streams, doesn't change blocking/nonblocking semantics, and would automatically support BackgroundFileSaver/StreamListener/OutputStream.

Except that nsICryptoHash is not threadsafe, but according to bsmith nsICryptoHash should only be called from js anyway, I need Digest from ScopedNSSTypes.h

Note that that's not an idl so the Digest/DigestContext are going to have to live in nsFileStreams. But at the moment I am blocked on a compile error that I can't clobber away:

4:10.94 In file included from ../../../dist/include/ScopedNSSTypes.h:16:0,
 4:10.94                  from /home/mchew/mozilla-central/netwerk/base/src/nsFileStreams.cpp:6:
 4:10.94 ../../../dist/system_wrappers/cert.h:3:23: fatal error: cert.h: No such file or directory

Next week is a work week, so I might not have time to work on this until the week after.

Comment 35

[[:mmc] Monica Chew (no longer reading bugmail)]

Status:
- broke this bug up because probably not everyone cc'ed is interested in code reviews
- BackgroundFileSaver is nearly hash enabled (bug 829832)

To be done:
1) Make nsExtAppHandlerService pass hashes from BackgroundFileSaver to DownloadManager, and DownloadManager actually query the reputation service (bug 837199)
2) Get API key from Google so they can turn us off in case of emergency
3) Write metrics, so we know how useful this feature is (bug 837202)
4) Make all downlaod paths go through BackgroundFileSsaver (bug 837195, bug 837194)

Comment 36

[:Gavin Sharp [email: [e-mail]]]

You may be interested in bug 835890 as well.

Comment 37

[Jesse Ruderman]

More from Google:

http://www.csoonline.com/article/731494/camp-for-chrome-catches-99-of-malware-google-says

https://www.cs.jhu.edu/~moheeb/aburajab-ndss-13.pdf

Comment 38

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Since application reputation would be transmitting information about URLs and file contents that would sometimes be protected by TLS (e.g. https://example.org/example.exe), it should be protected by HTTPS. So, I think that bug 783047 should also be a prerequisite for enabling application reputation, unless application reputation is somehow already using HTTPS independently of fixing bug 783047. (In which case, please just remove the bug dependency.)

Comment 39

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

mmc said that the application reputation endpoint is already HTTPS so bug 783047 isn't a prerequisite.

Comment 40

[[:mmc] Monica Chew (no longer reading bugmail)]

This is waiting on bug 895476 and bug 887044 to be minimally useful (i.e., turned on in Nightly).

Comment 41

[Benjamin Kerensa [:bkerensa]]

Tracking for now so Relman can keep an eye on this.

Comment 42

[Lukas Blakk [:lsblakk] use ?needinfo]

We do not typically track the tracking bugs, when the feature is landed and enabled in m-c we can track it if we are intending to uplift to channels.  This bug, and associated work, looks like it is spread out around a bunch of smaller bugs where none of them look like major features we should be monitoring or noting for a specific version. If there are any specific bugs that counter this perception, please nominate them.

Comment 43

[Sylvestre Ledru [:Sylvestre]]

Added to the 31 release notes with the wording: "New Block malware from downloaded files (learn more)"

learn more points to https://wiki.mozilla.org/Security/Features/Application_Reputation_Design_Doc

Comment 44

[:Gavin Sharp [email: [e-mail]]]

Is there a good reason not to mark this FIXED?

Comment 46

[Terrell Kelley]

(In reply to :Gavin Sharp [email: [e-mail]] from comment #44)
> Is there a good reason not to mark this FIXED?

The strings are still being discussed in bug 1053890, even though the bug is marked as fixed. (No, I'm not the only one discussing it.) And there's the issue of users who, due to the current lack of a per-file override, may have disabled the entire anti-malware or safebrowsing features, despite only wanting to bypass it in a specific instance. We may want to consider resetting those preferences (with a release note explaining why).

Comment 47

[Gian-Carlo Pascutto [:gcp]]

(In reply to Terrell Kelley from comment #46)
> (In reply to :Gavin Sharp [email: [e-mail]] from comment #44)
> > Is there a good reason not to mark this FIXED?
> 
> The strings are still being discussed in bug 1053890,

Further bikeshedding around the exact strings is a trivial issue compared to the actual override not being implemented yet.

The problem is that without an override, we're uncomfortable enabling the remote lookups, which were envisioned as part of this feature and are needed for it's full effectiveness. So I think we can leave this open until that part is completed.

> We may want to consider resetting those preferences (with a release note explaining why).

They have a privacy impact so I think that's a tough sell. Bug 1057848 modified the preferences to add specific ones for the new feature.

Comment 48

[heaven-seven]

It would be great if this feature is implemented as a plug-in which everybody can add to FF in case they need it.

Comment 49

[Gian-Carlo Pascutto [:gcp]]

This feature was implemented quite a while ago, the problem was/is that being able to "unblock" blocked files turned out to be impossible without rewriting large parts of Firefox' download UI. See for example bug 1068656.

Comment 50

[heaven-seven]

I wonder why it's implementation was started without the ability to "unblock" blocked files! I wonder twice why it is not optional, but silently enabled by default!

BTW, there must be sources of download manager in the repo without this "feature". Guess, rollback is much more easy than rewriting those large parts.

Comment 51

[Gian-Carlo Pascutto [:gcp]]

Implementations of new things tend to start from nothing, the feature is optional, togglable via preferences, and generally speaking every feature which is considered a net benefit is enabled by default in Firefox. Most parts of it (the ones who could give most false positives) are disabled until the unblock UI can be finished.

Comment 52

[François Marier [:francois]]

There is a complete UI for this in 48 and we are blocking all verdict types.