852596 - Block downloads that don't pass the IAttachmentExecute::CheckPolicy call on Windows

Status: RESOLVED WONTFIX

(Toolkit :: Downloads API, defect)

Description

[:Paolo Amadini]

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.

Comment 1

[Raymond Lee [:raymondlee]]

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?

Comment 2

[:Paolo Amadini]

(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.

Comment 3

[:Paolo Amadini]

Now tracking release until we decide how to address this.

Comment 4

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

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

Comment 5

[:Paolo Amadini]

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