Most Internet research projects start in the browser. And standard browsers aren’t safe. They indiscriminately download web content and cache data on your local drive. It’s no wonder that security or compliance researchers need to wipe the machine clean after every investigation.

That process is cumbersome. Each time a new ticket is handled, the user will build a new VM, start a local sandbox, or sit in front of a vanilla machine that gets re-imaged regularly. Each of these actions disrupt the user’s workflow. They pay a performance penalty and an ease-of-use tax. From an IT perspective, it means supporting very specific hardware or dramatically increasing the baseline system resources to accommodate the local environment.

Perhaps worst of all, though, is that when you run a local VM or sandbox, you open your network and your device to potentially malicious code. In the words of one CIO: “no sandbox is perfect.” Any research that exposes local resources carries risk.

A layer of insulation between web content and local resources mitigates, if not eliminates, that risk. The need for this insulation layer stretches across a wide spectrum of users and scenarios.

On one end of the spectrum: a malware researcher who visits websites with the intention of interacting with, saving and analyzing malicious code. This could happen via the structure of the page itself or through a compromised host linked to the page, like within an advertising network. This type of investigation is very risky and requires a solution that:

  • Mis-directs the source IP: Sites can publish specific pages based on the requestor. Let’s say you’re an advertising company checking compliance of advertising assets. You wouldn’t want the content provider to know you’re from internal compliance, you’d want to look like any other web user.
  • Changes user-agent string: What if you want to see what sites look like on a mobile devices? You can’t get your sandbox running on an android phone or an ipad, so you’re stuck using the native browser on those platforms.
  • Save data without compromising the local file system: You may need to save page headers or even a binary payload for later analysis. But if you expose your local assets, you’ve let malware into your environment.
  • Integration with cloud-based services for persistent storage or further analysis: If you need data to persist or files you’ve saved to be shared across a pool of researchers, then you’ll probably need to connect to a cloud-storage solution or an S3 bucket somewhere.

On the other, less specialized, end of the spectrum is the simple need for a disposable browser that doesn’t reveal who you are and won’t track your usage. For example, if you’re in HR and are doing background checks or researching competitive products, you don’t want your browser to keep all the cookies, content, or history of your investigations.

While these may not be standard uses -- after all, the browser is ubiquitous -- it makes sense that users would want different browser configurations for different workflows, from everyday use to specialized needs.

That’s why we created Toolbox, a variant of Silo, our on-demand browser in the cloud. Instead of securing access to sensitive web apps as our standard configuration does, Toolbox gives users safe-but-free reign on the Internet, launching a fresh version of Firefox on demand. Users interact via a benign remote display protocol while all code executes in the secure sandbox on Authentic8 servers.

Toolbox comes from our IPs, and can even spoof a different device/browser configuration:


Toolbox gives you tools (like the ability to change user agent strings on the fly) to dig deeper in to web pages safely:


Programming tools to analyze web code:


And interfaces to connect with third party services for deeper content investigation:


Toolbox can also be integrated with existing ticket systems and support applications. You can be reviewing cases in your local browser and automatically open links inside of Toolbox through a simple re-format of the URL. For example, let’s say you want to open in Toolbox. In your support app, simply format the URL as A8:// and the page will automatically render within Toolbox. This lets you keep local record keeping and remote analysis integrated and seamless for users without jeopardizing your resources.

And when you quit… Poof, it’s gone. Just like Keyser Söze. Toolbox doesn’t let any web code hit your network or your device. That means there is no residue of any browsing data on your machine. And the virtual instance is purged, letting you start fresh on your next session.

We have been thrilled with the reception that Toolbox has received from incident response teams in leading organizations like La Poste, malware and fraud researchers at leading brands like Netflix, customer support investigations staff at security companies like SiteLock. Plus a long list of others. If you need a disposable browser that lets you dig deep in to the web without revealing your identity or risking exploit, Toolbox is there for you!