I'll Just Leave This Here Again...
Was posting a list of customization requests when the 2014 version first showed up, so I'll just leave it here again, though it's obvious that you're in a race to the bottom instead...
tl;dr version: A very customizable product that allows the end user to easily control and monitor its behavior in great detail while also significantly aiding said user in controlling and monitoring their computer as a whole. No "set and forget" unless the user specifically desires it, no unchangeable behavior, no default settings that will be used to determine behavior before the user has any chance to change them, no hiding of gathered information.
Full version, just copying the post I wrote then on my blog, with the mention that it's incomplete since I probably can't think of all the things they're removing or hiding away:
Of course, requesting complete and easy user control doesn’t imply removing automated settings and actions. The people who wouldn’t know what to do if asked and those who simply don’t want to bother with it will still be able to use default settings and all those features that make such software largely act on its own, without questions or even notifications, but let people who know what they want to happen on their computers easily customize and make choices, every single one of them if they want to. As a quick list, this would imply at least the following:
1. Allow the user to select which modules to install and allow settings to be made during installation, applying them on first launch, so any undesired functions will never be activated and the program won’t run in default mode at all if the user doesn’t want that to happen.
2. If any threats are found during the install scan, inform the user of them and either ask what action to take or, at the very least, allow the user to undo the actions taken automatically.
3. Have a clear “prompt” setting for pretty much anything and everything, make the resulting prompts informative, including exactly what was found, where, what the recommended action is and links to further information, if available, and obviously also make the answers highly customizable. I’ll detail this customization of prompts in the next section.
4. If the user desires some automated actions, allow such actions to be customized it great detail.
5. Let the user customize the alerts, individually. Have a list of all the possible events that may be noticed by the software, grouped for ease of access, and allow the user to select whether they want to be notified about each of them and, if so, how.
6. Offer as many details as possible about the system, running processes and their actions, making them easily accessible at all times, specifically in order to aid the user in monitoring and controlling what happens on their computer.
7. When web traffic scanning is active, allow the user to select whether a web page that is, in itself, safe but contains infected external elements should be blocked completely or the block should only apply to said external elements. Also, obviously allow the user to override any such block.
8. Whether or not automated URL scanning is available, what should definitely be available is a context menu option to “scan target”. Quite frankly, if web traffic scanning works as it should and blocks any on-line malware before being read by the browser, neither this option nor the automated one are necessary, but such an optional URL scanning method may have its uses and won’t unnecessarily waste any resources when not desired.
9. If automated URL scanning is available, allow the user to customize the list of sites on which this feature should be enabled, such customization options obviously including the document elements containing the links the user desires to have scanned. It would also be nice to have a setting for scanning short URLs, which the user should also be able to define, regardless of the site they appear on.
10. Allow the creation of generic firewall rules for all local connections. These rules should obviously also have customizable parameters, but would differ from regular firewall rules because they’d apply regardless of the application attempting the connection. Obviously, in case of such a generic rule for local connections, the antivirus software should determine whether the destination points back to the current computer, allowing but not requiring the user to select which addresses and connection methods count as local.
And I said I’ll detail the customization of prompts in the next section, because there are more details to give about this, so here’s what I wish would happen when “prompt” is the selected default action in a number of scenarios not covered by existing rules:
1. If on-access scanning detects a potential threat, it should temporarily block access to the file and ask the user what action to take. The prompt needs to be as informative as possible and allow the user to immediately determine, from the prompt itself, whether the chosen action is to be taken just then or a rule is to be created. Also, if the user chooses to create a rule, they should easily be able to set its scope as well, as in whether it’ll apply to the threat, to the file or even to the entire folder said file is in.
2. If on-demand scanning detects a potential threat, it should log it and ask the user what to do about it when the whole scan process is done. However, a clickable warning should also be displayed in the scan window, allowing any user that is at the computer during the scan process to decide what to do about each detected threat sooner. And, of course, what I said above about being able to easily decide whether to create rules and, if so, specify their scope applies here as well.
3. If behavioral scanning detects a potential threat, the same rules as for on-access scanning apply, with the additional requirement of informing the user of exactly what the program did to trigger the warning. If multiple behavioral analysis modules exist, it should obviously also be specified exactly which one of them is responsible for each prompt.
4. If the firewall detects a connection attempt, it should temporarily block it and ask the user what to do while offering every piece of available information about it, including both the IP address and the URL of the destination if at all possible and whether the program responsible is confirmed safe, as in scanned, signed, verified and whitelisted, or not. The prompt should allow the answer to be customized in detail immediately, as I’ll describe in the next section.
With the firewall being such an important component when it comes to both the protection and the control of always-connected computers, which are currently the large majority, antivirus software developers need to be particularly careful with the customization options offered for this module. As such, here’s what I think should happen when “prompt” is the selected default action when the current connection attempt is not covered by existing firewall rules:
1. Obviously, the first thing is to allow the user to choose whether the answer given should apply just to that connection attempt or a rule is to be created.
2. If the user wishes to create a rule, the prompt should also allow its scope to be defined. The basic levels I can think of right now are loose, applying to any and all future connections made by that program, typical, applying to all future connections made by that program when using the same protocol and, if applicable, being called by the same other program as the current attempt, strict, applying only for future connections with the exact same parameters as the current attempt, and custom.
3. If the user chooses to create a custom rule, the answer, as in whether to allow or block the connection, should just be applied to the current attempt, so it won’t be delayed even longer, and the advanced firewall rule window should be opened, with all the information for a strict rule, taken from the current attempt, filled in. The user must obviously be allowed to freely remove or modify any of the conditions and any further connection attempts made by the program in question should be delayed until the rule is created.
4. Also, for all custom firewall rules, multiple choices should be allowed for each condition, such as port, protocol, destination or program parameters, so the user won’t need to create several rules for the same program if, for example, a single one should apply to connections to several, but not all, possible hosts.