I am using DU meter to monitor web traffic. Since DU meter is normally not a network program, there is no ruleset in Network Policies. When I go to “about” and try to do an update, it is blocked as expected. When I select the “visit website”, Opera goes to the website with no problem. I am using avastwebsv. For the update, DU meter tries to go directly to its server on port 80 and is blocked. For the website access, it passes the http request through Opera and ashwebsv to display in Opera, and is not blocked. I tried the same thing with EditPad Lite, and also got to the website with no problem. So application---->Opera----->ashwebsv can set up a TCP connection, in spite of no network rules at all for application and a block all at the end of the application rules. DDE? OLE? ???
Do you have Opera open when these applications try to connect. If so close it first, then try. This has been a known issue since v2
When I close Opera, application opens it again. It is stopped only because I have chosen the dialog option on what I want Opera to do next. So DDE is a “Trojan Opportunity” since V2? 
Here’s the link to the thread regarding the same problem in v2:
These programs have never accessed Opera before, at least not in CFPs lifetime, and now they spawn Opera even if it is closed. Thread says not to worry, “HIPS will solve it in real time with v3”. So what to do about programs opening undetected TCP connections with unknown sites by using web browsers as proxies? Looks like no action on V2 thread, so where to go from here for V3? Or is this irrelevant because the leak tests don’t cover it?
There was a similar conversation about this recently. Started here:
Looks like we are counting heavily on D+ to make sure that application X never gets a chance. Hope everyone uses it wisely! So not a bug, just a feature. But we really don’t have a way to stop any known application from phoning home whenever they feel like it, and sending whatever data they wish. None of this generated any popups from D+.
You would need to set the properties for each of the applications (and any others who might be parents) to Ask instead of Allow, when launching an executable. This way you should get pop-ups even if the browser is open. Then, there is always Paranoid mode 
We just have to convince the users to answer popups for every application every time we execute it and all will be well. 
I should have said “no practical way”. But for things like editpad, for example, a check in D+ shows everything is still marked “ask”, but D+ doesn’t even blink-just messages saying D+ is learning, but no record of what it learned, And none of these home phoners/reporters is infected. Don’t know why D+ doesn’t change the access rights/protection settings in train with safe mode to reflect editpad is allowed? Pretty much all of the custom policies in D+ say that access rights are still “ask”, in spite of learning and actual behavior being different-there must be a stealth set we are not exposed to. Do your D+ policies reflect the permissions you have given the applications? Mine generally don’t, unless it is due to a popup instead of learning.
Is Editpad a safe application?
I don’t know; probably. But unless D+ tells me what the rules are for it, don’t know for sure. Does accentuate the problem, though, if a user can’t tell what is allowed for a learned application-editpad (and the others) are still marked all “ask”, but can invisibly use opera as an internet proxy. If Comodo tells me that it is safe to allow an application to do this without notice, and to not tell me which applications this is true for, I think we have different understandings of “safe”.
BTW, if I erase the editpad entry and switch to paranoid mode, D+ does the right thing, popups to execute Opera, changes keyboard to allow. But if I start in train with safe mode with editpad having been used, even paranoid mode doesn’t see it. The access rights tab doesn’t provide for allow of running an executable, yet the observed policy does, and paranoid uses this invisible policy. So unless you start in paranoid mode from the beginning, it is impossible to control this, and since you have no way of knowing which programs are allowed to run an executable, there is no way to monitor this behavior. So for the next upgrade (not just for this problem):
- Access rights need to reflect accurately the learned behavior of the processes
- “Run an executable” needs an allow column, since ask is not right for many of the programs, and we need to implement 1).
But if I start in train with safe mode with editpad having been used, even paranoid mode doesn't see it. The access rights tab doesn't provide for allow of running an executable, yet the observed policy does, and paranoid uses this invisible policy.
This is interesting. I wonder if something has changed as it used to be possible to switch from T wih S mode to paranoid mode and generate a pop-up, even if the app had been used.
I used T w S mode for a while, when I installed 276, but I soon switched back to Paranoid Mode. If what you say is correct, I might just delete all the ‘learned’ rules and start again.
Another interesting observation. Running editpad in paranoid mode seems to make it work ok in other modes; even when I switch back to “Train with safe mode” and erase the policy I get the proper popups. I wonder if anwering the popups actually changes the invisible rules??? DUMeter has never run in paranoid, and continues to exhibit the anomalies in train with safe mode. As do a few others-for example, WinRAR gave me a popup to allow execution in “train with safe mode”. Switched to paranoid, let me go the website without a whimper. D+ makes my head hurt! ???