In the new API, downloads that don't pass the IAttachmentExecute::CheckPolicy call on Windows should be disallowed. Ideally, this check should not block the main thread or spin COM event loops.

I think we are trying to do the similar stuff as nsDownloadScanner::CheckPolicy(nsIURI *aSource, nsIURI *aTarget) http://mxr.mozilla.org/mozilla- central/source/toolkit/components/downloads/nsDownloadScanner.cpp#207 I am not familiar with c++. How do we access IAttachmentExecute::CheckPolicy using JS?

(In reply to Raymond Lee [:raymondlee] from comment #1) > I think we are trying to do the similar stuff as > nsDownloadScanner::CheckPolicy(nsIURI *aSource, nsIURI *aTarget) > http://mxr.mozilla.org/mozilla- > central/source/toolkit/components/downloads/nsDownloadScanner.cpp#207 > > I am not familiar with c++. How do we access IAttachmentExecute::CheckPolicy > using JS? Since that is a Windows-specific COM call, it's easier (if not required) to do this from C++ code. But, since the existing scanning code is tied to nsDownloadManager, this would need to be rewritten or ported in some way. However, we've been talking about replacing this limited and platform-specific scanning function with the Application Reputation check, that is cross-platform and doesn't block the main thread. In addition, antivirus software is able to scan downloaded files anyways, without the need for us to call them explicitly. Since the Application Reputation interface may be ready soon, I think we can put this feature on hold until we define how we want to proceed.

Now tracking release until we decide how to address this.

Hi Paolo, > Since the Application Reputation interface may be ready soon, I think we can > put this feature on hold until we define how we want to proceed. I'm working on the protocol parser now (bug 904607) which should be the last major work on this. There is some minor work (integrating with the new Downloads manager and telemetry) as well. Altogether I am hoping to land in about a month. Monica

For the alternate solution, see bug 909022 and this firefox-dev thread: https://mail.mozilla.org/pipermail/firefox-dev/2013-August/000848.html