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.
'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 / is not possible to download in download managers (free download manager, internet download manager …)
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?
Tested on pages ftp:// web filter fail in both cases.
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”
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…