Whitelist Logic Bug?

[geoapps]

When SS&D was removing an ActiveX control this afternoon, I told it to always allow the removal of this particular control. To my surprise, later that day during a reinstall of the software, SS&D allowed the installation of the same control without asking me for permission. Looks like whitelisting the REMOVAL of an object means you've whitelisted ANY action WRT that object. Excuse me, but REMOVING something is not the same as INSTALLING it.

To restate what I saw this afternoon: if I whitelist the REMOVAL of an ActiveX control, it becomes whitelisted for ADDING it BACK. This is Not Good.

Whitelisting removal should NOT be construed as blanket whitelisting. It should only allow further REMOVAL of the particular object. IMHO, YMMV.

Or did I completely miss this...

[PepiMK]

Yes, the logic isn't really perfect It was kind of a compromise to not bring even more popups to the user.

TeaTimer 2.0 (current working name CoffeeLounge) takes a different approach; since it uses LASSHes (RunAlyzer classifications of entries), it has a huge list of decisions it can make on its own already. It also differs between additions, removals and changes, so user black/white lists are stored separate for each operation. Next to that, scan blacklist operations are reversed for removals (blocking new bad entries, but allowing removal of bad entries), white scan whitelist operations are applied only on addition/changes, but ignored on removal.