Bringing a new category of product to market requires equal parts clarity and comfort with ambiguity. We've been focused on building a service that, based on our read of the market, puts admins back in control of the web. We've had the clarity of our internal vision, but now as we speak to the market, we get to experience a bit of the ambiguity. We're learning a lot about how companies are struggling to manage the web using the overwhelming array of point solutions currently available, and as we learn more about their challenges, we're learning about more specific use cases for Authentic8. What they need isn't always clear, and it takes digging and tweaking to get to it.
We describe Authentic8 as a way for admins to get back in control of the web. We're learning that control means different things to different customers. Our cloud-based browser lets admins manage security, access, and user actions in the web session. Authentic8 users browse the personal and business web pretty much as normal. But all the code execution, session state management and browser actions occur in the Authentic8 sandbox in the cloud. This approach takes most of the "can't secure the web" gaps head on. But as rich as it is, the full suite of functionality might be too much for some customers. They might need less, rather than more.
Keeping both admins and users happy
Let me explain. Our development has been governed by the belief that for Authentic8 to be successful, we need to be minimally disruptive to both admins and users. If we were to make one constituent happy but not the other, we'd fail. So we've spent a lot of time looking at how users actually use the browser and have invested in making Authentic8 look and feel as native as possible. If we can give users a no-compromise experience while at the same time giving admins greater control over the end-to-end web environment, we'll succeed.
This approach has been validated by a lot of our beta accounts. Our ability to provide a secure web environment has freed admins from having to configure a bunch of software at each end point. Admins define policies in the cloud, provision users, and give users single sign-on access to their web apps.
Users benefit, too. They don't need to remember complicated passwords, they aren't locked down to a single, work-provisioned computer, and they can access from any network anywhere. And when they come back to Authentic8, they can pick up where they left off. We're trying to not ask anybody to make a sacrifice.
But to many admins, control needs to go beyond securing the machine and enforcing policy. Many see the co-mingling of work and personal data as a business risk, and they want the tools to separate the two.
Site Specific Browsers
In the old days (of just a few years ago), IT owned the entire computer stack. They'd provision a computer, configure with user credentials, install a virtual private network (VPN) client, and install the necessary apps. When users needed to do work, they'd connect back to the work network via the VPN, open their apps, and get busy. Obviously, today’s world is profoundly different. Computers aren't necessarily provisioned by IT, and securing the all endpoints is impossible. Apps are now hosted by 3rd parties, and users access the data directly, outside of any controls. And secure HTTP, while not universal, has pushed the VPN aside.
Combine this new way of working with the questionable tactics of popular websites -- persistent cookies, cross-site requests, behavior tracking, browser caching -- and it is understandable that companies want to separate church from state. But as long as the browser is the general purpose app to access business and personal web content, separation is impossible.
In talking this through with customers, we've come up with a way to make this happen. What if -- instead of trying to manage bottoms up, where the user's machine and behavior are the focus -- policy is enforced tops down, from the business app perspective?
Just a couple of years back, there was a nascent product category called Site Specific Browsers (SSB). An SSB was a browser container that was designed to interact with a single website - no additional tabs, menus, or configuration options. These SSBs were designed to make a website look like a dedicated app. The use case focused on information services like stock and weather sites and early social sites. The idea was good, but as the browser became the de facto app that users were always in, the app-view mode made less sense. Also (and perhaps more important to the demise of this category) there was the complete omission of any sandboxing or policy management capabilities. If users were willing to use a focused browser for particular content, why not layer in the controls necessary to secure the environment?
Less is more
While customers today aren't asking for an SSB by name, their description of the use cases is right in line. Admins want the ability to put their content -- either their in-house app or select web apps -- in front of their users in the most controlled manner possible. They want to be able to restrict how users interact with the app data, and they want to be sure that there is no cross-contamination of any sort, whether local malware or exposure to cross-site scripting attacks. And when the session ends, they want to be sure that there is no data left on the client that shouldn't be there - downloaded files, cookies, browser history, local cache, etc.
Some admins aren't looking for a way to wrap security around all web behavior of their users. Instead, they want to provision web apps selectively to their users and insulate business-oriented web use from from anything else the user does.
Given what we've built with Authentic8 to date, our path to deliver our version of the site specific browser is pretty short. We'll be streamlining some of our provisioning and policy tools and rolling it out to customers shortly; and in the process, we'll be delivering more by allowing less. If this sounds compelling, chime in below.