Using Right-Click To Download File Bypasses WebFilter Rules [M896]

1. Attached.

2. comodo internet security 7.0.312140.4101

3. Windows 7 service pack 1 (64)

4. comodo - proactive security
antivirus - active
Defense + active - safe mode
active firewall - custom mode

5. N / A

6. KeyScrambler

a) set up the web filter to ask before downloading files.
b) if I right-click “save as …”, the download will happen without any warning from the web filter.

8. Download files happened without the web filter warn.

9. The web filter alert you or block the attempt to download when I click “Save As …”

A video which, in part, shows this can be seen here:

Thank you very much for your report in standard format, with all information supplied. The care you have taken is much appreciated by Comodo, and will increase the likelihood that this bug can be fixed.

Developers may or may not communicate with you in the forum or by PM/IM, depending on time availability and need. Because you have supplied complete information they may be able to replicate and fix the bug without doing so.

Many thanks again.

As this was not fixed during the Beta testing period I will move this bug report to the main Bug Reporting Board.

Please check and see if this is fixed with the newest version (7.0.313494.4115)? Please let us know whether it is fixed or you are still experiencing the problem.

Thank you.

PM sent.

No filters started in https:// or ftp:// results nor prevents downloads.

So do you mean that this is not fixed for CIS version 7.0.313494.4115?

liosant has informed me that this is not fixed for CIS version 7.0.315459.4132. I have therefore updated the tracker.

Is not fixed!

an opinion: web filter CIS 7 does not seem to recognize the format as web pages are displayed.

Thanks for checking this. I have updated the tracker.

Okay, the devs have not been able to replicate this. Could you please provide clear, numbered steps (complete with sample URL’s) which the devs can follow to replicate this.

Also, can you attach screenshots of your rules.


've Posted the first video reporting some earlier versions of the program these errors;
I have created a thread explaining a bit like the error happens and a guess on https:// … connections;
Anyway here is the screens (see attached):

The error occurs only on pages started by ftp:// and https:// addresses
In the specific case of addresses beginning with HTTPS :confused: / is not possible to download in download managers (free download manager, internet download manager …)

[attachment deleted by admin]

In that case would you agree that this bug report seems to be a combination of that reported here:
Web Filter does not react on HTTPS Sites [M840]
and here:
Web Addresses With ftp:// Are Allowed Regardless Of WebFilter Rule [M895]?


PM sent.

For sites starting in HTTPS :confused: / web filter failed when we downloaded by the browser files with extensions configured to be blocked, examples: * exe *, * rar, * js *, etc…

On the other hand if you have a download manager, example: free download manager, internet download manager. If you try to download from this type of program the web filter will be able to block.

Note: In the third attachment as the web filter only works when we try to download something for download managers

[attachment deleted by admin]

So am I correct in interpreting this that there is a problem with HTTPS sites, where you are able to bypass the Webfilter Rules through the browser. However, if you use a download manager it is not bypassed?

If so, have you only noticed this behavior on HTTPS sites? If not, what other types of sites have you seen this same behavior?


  1. Only HTTPS :confused: / sites.

  2. Tested on pages ftp:// web filter fail in both cases.

  3. On sites starting at http:// and https:// web filter does not filter ads with terms set to be blocked only if ads belong to the domain of the page itself.
    Both pages have in common the same structure when we click “inspect elements”

[attachment deleted by admin]

From what you are describing it sounds like you have investigated deeper the issue reported here.

Do you agree that this issue is a subdomain of the larger issue with HTTPS sites?


By terms do you mean words in ad titles? It only filters URLs not ad titles.

Also maybe it will not filter images/ads embedded in a certain site, if served by another (eg a content delivery network - CDN). I’m not sure whether it is blocking the request or response… If so to block those you’d need to block the CDN Url, but that will have side effects. If this is true there’s a valid, but different, ‘debatable’ (hybrid wish/bug) there maybe…

Okay, this has been marked as a duplicate of the issue reported here in the tracker. I will therefore move this bug report to Resolved, as there is already a bug report created for this issue.

Please let me know if you have any questions.

Thank you.