- Create a Parent Sandbox Sandbox-Parent and install a Web Browser inside it.
Once the installation is finalized, in most cases the Parent Sandbox container should be made READ ONLY (but don't force it). - Create child sandbox Sandbox-Child1 with Sandbox-Parent as its parent.
When reading files, registry, etc... it goes like this: Sandbox-Child1 -> Sandbox-Parent -> Real OS. - Run the Web Browser from Sandbox-Child1, do some tests like trying out a Browser Extension.
Now I've finished testing, I reset sandbox to clean state by using [Delete Contents] command on Sandbox-Child1. - After that Sandbox-Child1 should contain nothing, but I can still run the Web Browser from it.
As all the program files, registry entries, etc... of the Web Browser are stored inside Sandbox-Parent thus not affected by deleting the content of the child sandbox Sandbox-Child1. - Best part is, I can create multiple child sandboxes of one parent sandbox.
(a browser for using online banking, another one for working, yet another one for entertainment with tons of extensions, etc...)
Why not just install the Web Browser directly and create different sandboxes to run it with?
"Trust No Program" is the slogan of sandboxie, and that's why I don't install programs outside sandbox. Besides that, even if I fully trust the program I'm using, installing the program directly to OS has limitations. For example, it's hard to keep different versions of some program to co-exist, installing them to separate sandbox solves this problem. If I accidentally upgraded the program outside sandbox, it could break all the sandboxes.