In this topic, we'd like to invite the Community to share what you know about some of the lesser-known features.
What do you know that others might not be aware of?
I'll get us started. :)
Did you know...
WSA has a sandbox?
In all three versions of WSA, (Antivirus, Internet Security Plus, and Complete), there is an option available to open up any program on your computer in a sandbox, in order to limit those programs' ability to modify the computer until you are satisfied they are safe. This feature is often overlooked because it's not critical. Some users never use it at all because they don't understand what it does. For advanced users however, it can be pretty handy.
So why run something in a sandbox?
First, let's explain why you don't necessarily need to. If WSA ever "misses" a threat, it can still revert all of the changes that threat made to the system just as soon as it realizes the program is, in fact, a threat. Whenever an unknown program that the cloud isn't sure about yet is introduced into a system, WSA is monitoring it. During the course of that monitoring, it's journaling all of the activities of that program. If the program is ultimately marked as "good" in the cloud database, WSA stops journaling it and clears its log of that program's data since it won't be needing to ever look at it again. On the other hand, if it's marked as "bad," WSA will quarantine the threat and use that journaled data to roll back all of the changes the threat has made since its introduction to the computer - in effect, putting things back the way they were before the threat ever showed up. That is detailed more in this video:
That said, why sandbox something manually? Primarily, it's for manual analysis and intervention. Secondarily, (and this is not an intended function), you could purposely alter program behaviors in some situations.
1. Manual Intervention and Analysis
When you first open up the SafeStart Sandbox, you'll see the following screen:
And when you scroll down a bit, you also get these options:
(the checks are defaults)
Taking a look at these options, we see we have a tremendous amount of control over what the program we are about to run can be made able or unable to do, as we see fit. We can even run a program with command-line switches if desired. Some of the options are more or less self-explanatory. Some of the others are solidly on the advanced side of the spectrum.
The default options serve as a generally good baseline for tests you may be wanting to conduct on an executable file, though you could certainly find reasons to adjust the settings. For instance, if the second option, "Allow access to the Internet," is unchecked, you'll find out very quickly whether or not that program requires Internet access to function.
If "watch events originating from this process" is checked, you'll be presented with a handy screen like this while you run the program being evaluated:
(The details tab provides additional information.)
You may notice this looks very similar to the screen you get when you double-click a process in "Control Active Processes," elsewhere in WSA. It's essentially the same information, except we're running the app out of a sandbox. When a persistent event is logged, it will appear in this box.
All of the various options allow or deny specific permissions to the program being run. These can be used to determine how much access a program needs in order to run successfully without failing. Most of the options are ones a piece of malware might try to exploit if provided that level of access, but they are also commonly used by many legitimate apps. That is why this is an advanced feature. You cannot expect any and every app to run with only some or none of these settings checked. However, when you're running an app you're uncertain of and want to find out more about what permissions it needs, various combinations of settings in the sandbox can give you that information.
It's important to note that WSA automatically sandboxes unknown apps already. This feature allows you to take manual control of the sandboxing instead. You can sandbox programs WSA may already have flagged as good files as well.
2. Purposely Altering Program Behavior
Occasionally you might not want to let a certain program online. Maybe you don't want it auto-updating or doing a license check. You can block the ability to get online temporarily when running it in a sandbox, which may serve that purpose effectively if the program does not other wise need to be online. Of course you can also do this with a firewall on a more permanent basis, so this is definitely a less common secondary use and isn't really what it's intended for.
Those are the two main reasons I've used this feature in the past.
So, that's one lesser-known feature covered. I'm sure the Community has others. Please share your uncommon knowledge here! 🙂
