The Enterprise Browser Blog

No items found.

No results found

Guest Blog: Island Redefines Security Delivering the Enterprise Browser

Guest Blog: Island Redefines Security Delivering the Enterprise Browser

July 27, 2022
Alon Weinberg
Read Article

Several years ago, Island Co-founders Michael Fey and Dan Amiga had an epiphany.

What if enterprise organizations had complete control over the browser environment? They knew the traditional web browser was the most widely deployed application by enterprise organizations; yet the browser wasn’t built for the enterprise, it was built for the consumer market.

This commonly used software application is incapable of offering the high-level security, visibility and privacy enterprise users needed.

If it could be modified for the enterprise, they knew it could change everything. With this belief, the founders began developing an enterprise browser that would simplify the security stack, give the enterprise complete policy control and deliver a more efficient, safer and productive browsing environment.

In February 2022, their vision became reality when the enterprise browser emerged from stealth mode to take control of the last mile – from the network to the end device - and redefine the end-user experience.

With the Island Enterprise Browser launch, enterprise organizations no longer need Secure Sockets Layers (SSL) or costly virtual desktop infrastructure (VDI) for data loss prevention.

While the thought of contractors accessing Software-as-a-Service (SaaS) applications from home once made CISOs think twice, with Island’s Enterprise Browser they can now greenlight personal email, collaborative platforms and Bring Your Own Devices (BYOD) while quickly ramping up contractors as needed.

Perfect Timing for the First Enterprise Browser

After nearly two years of product development, the Island browser emerged at a time when most major browsers were standardizing to the Chromium open-source project. Leveraging the open-source project, Island’s co-founders seized an opportunity to create a custom browsing experience for enterprise organizations without having to build their own rendering engine. Building on Chromium also meant creating an entirely familiar experience for end users, reducing friction in deployments.

“We could stand on the shoulders of those giants and make sure all of our energy went into making the browser the best enterprise resource possible by upgrading the security posture, improving integrations, giving them complete policy control and providing infinite last mile control,” said Michael Fey, co-founder and CEO, Island.

At the same time, enterprise organizations were shifting to a remote workplace where contractors, call center staff, and BYOD workers needed access to internal web and SaaS applications like Salesforce and Workday.

Island’s enterprise browser allows these organizations to seal the SaaS environment, secure last-mile control and achieve total data loss prevention (DLP). By simplifying the security stack and working with, not against, existing systems, the browser is able to support web filtering, web isolation and Zero Trust network access with a cost-effective solution.

“When call centers move remote, they find themselves going to a SaaS application over a virtual infrastructure to a backhaul location to get out to the SaaS application,” says Fey. “We bring common sense to that architecture and let those users go directly to the SaaS application while still providing the security controls.”

A pricey venture requiring a massive number of engineers, Island’s browser also carried the good fortune of launching within a favorable fundraising environment, with Insight Partners, Stripes and Sequoia Capital providing more than $200 million in capital to bring the founders’ vision to light.

Protecting the SaaS Environment with Built-in – not Bolt-on – Security

Unlike bolt-on security tools, Island’s enterprise browser provides deep control at the operating system level with security that’s built by design.

While not a replacement but more of an augmentation to the enterprise customer’s existing approach, the enterprise browser circumvents massive change management, allowing enterprises to quickly ramp up call centers and contractors on personal devices.

Users can decide what the browser does and doesn’t do – like cut, copy, paste; take a screenshot; tag traffic; redact data; and change what information flows under enterprise control and governance.

Although Island’s enterprise browser provides remote browser isolation, web filtering and mobile device management (MDM), the browser most often works alongside existing systems to simplify the architecture, reduce expense and provide total endpoint protection.

“This allows us to connect to any of those designs and complete that last mile that’s been missing. So often in the Zero Trust architecture, people would get to the last mile and realize the data on the endpoint was still a massive point of risk, so they went with a heavy, overburdened architecture like a desktop as a service. The enterprise browser allows us to rethink the last mile and ensure it collaborates with all the platforms,” says Fey.

How Island Built its A-Team

Island has built an impressive roster of leadership and engineering talent with a “nexus of experience” approach beginning with Fey, the former president of Symantec, and Amiga, the founder of Fireglass, an RBI solution that works with Chromium browsers.

“In the world of cybersecurity, where the bulk of people spend their entire careers selling and building something that is just the next generation of something else – the next endpoint, the next gateway, the new firewall – this was an opportunity for those people to take all that skill and expertise and do something fundamentally new and different. We’ve excited people’s imaginations,” says Fey.

The co-founders also learned early on that they would need to remove the friction of adoption if they were going to realize the ultimate vision of delivering the first enterprise browser.

“I think too often people fall in love with their big vision and don’t fully appreciate the challenges they will encounter on the path between the vision and the reality,” says Fey. “You have to address the journey from day one because your investors are going to go to those places and ask you the hard questions, and the difference between an investment they’re excited about and one they just think is interesting is having great answers and proof points to solve those problems.”

Fey advises other startup founders to first identify the obstacles that may be standing in the way of their go-to-market plan. “What is uncharacteristically difficult about your plan? Whether it’s adoption, the business model or the tech, make sure your early days of investment are about tackling that,” he says.

As Island drives toward more integrations, Fey expects the company to expand beyond cybersecurity by helping IT better understand performance and the end user process with greater visibility.

Island’s founders believe every enterprise organization will be running on an enterprise browser one day. “That level of control at the last mile is essential to delivering things like Zero Trust, secure edge and BYOD,” says Fey.

If the vision holds true, the enterprise browser will soon become a core part of the IT toolset as users seek a safer, more secure and productive end solution.

The True Power of AWS Tags: How to Use ABAC at Scale

The True Power of AWS Tags: How to Use ABAC at Scale

July 27, 2022
Itamar Bareket
Read Article

One of the biggest challenges nearly all engineering organizations face is scaling up without slowing down productivity or compromising on security standards. One area where we at Island encountered this challenge is in controlling access and permissions to AWS without compromising on speed and developer autonomy.

While AWS IAM is packed with features, including support for ABAC (attribute-based access-control), It is often very hard to control who can tag what at scale. In this blog post, we’ll dive into the deep waters of AWS IAM, face its problems and learn how to leverage IAM policies to make ABAC scalable.

This journey walks through parts of a talk I gave at fwd:cloudsec 2022 called "The Power of AWS Tags". I encourage you to watch it here

A journey for developer autonomy

You might be familiar with RBAC (role-based access-control), where access is granted for specific roles on specific resources, which typically requires an administrator to handle permission requests from R&D teams and adjust their roles accordingly. In many organizations - this is a slow process.

On the other hand, if permissions are managed with ABAC (attribute-based access-control), it is easier for the administrator to create rules to match resources by the attributes set on both resource and actor. That way permissions would be granted dynamically, lowering the number of requests from R&D teams and giving teams more autonomy and control over the resources they own.

For example, here is a rule an admin may configure: “users of team: infra can read data from DynamoDB tables tagged with owner: infra.”

This IAM policy would look like this:

Where it gets more complex

What if a bad actor from the infra team had access to modify the tags of his own user or role, or even modify the tags of other DynamoDB tables? Privilege escalation is pretty easy.

In order to mitigate this, we’ll need to protect our owner tag. Let’s write statement like this:

Now, imagine you manage 30 of those tags. Adding a protection statement for each kind of tag sounds pretty cumbersome, and with IAM policies contain as many as 6144 characters, it’s probably a good idea to propose a solution that will allow scaling ABAC with more ease. 

Reaching separation of concerns

Looking at the previous policy we came up with, it is easy to distinguish each statement as its own role:

  • The first statement is responsible for the access-control logic itself - these kinds of data plane statements are to be distributed so it can be attached to different users, roles or groups or the whole organization, according to the business needs.
  • The second statement is responsible for the tagging integrity, the control plane, and we want it to be as generic and centralized. This policy will be attached as an SCP to all accounts in the organization.

Modeling privileged tags

Think of a UNIX filesystem. If I’m granted permissions to my home directory at `/home/itamar` I can write anything under that path, since this is my grant area.

Translating this into IAM, we’ll assign each user/role with a grant path of their own that will define their tagging grant area: if a role’s grant path points to “ctl/v1/admin” then users assuming this role can tag anything under that path, like “ctl/v1/admin/owner” (but not “ctl/v1/bagels”).

Setting the grant path

In our UNIX filesystem we’d have a special file, in which every entry will be a username and its grant area, and no one would have write access to it (unless they’re using sudo). Like this:

Yet in IAM, we don’t have the equivalent of a centralized file, so each principal will hold its own grant path in a tag key (which itself, is a control tag under a meta subtree) that no one can create, delete or modify (unless they use “sudo”, we’ll get to that..). In that case, the tag value will be a pointer to the grant area.

Introducing Control Tags

Control Tags are a privileged set of tags. Any tag that starts with `ctl/` is a Control Tag.

Let’s see the IAM statements behind this control plane:

Let’s break this down:

  • We do not allow principals that don’t have grant path configured to tag any control tag.
  • We do not allow principals to tag outside of their grant area, or other allowed set of tags, such as “environment”, or “info/*”

Revisiting our first example

It’s THAT simple

This way, only admins can designate principals with team affiliation and only team members can designate resource affiliation with the team.

Recipe: How to Use Control Tags

  1. Define the meta grant_path tag key, and set grant paths for your principals.
  2. Attach the Control Plane as an SCP to your AWS account.
  3. Define data-plane policies and attach them to your roles/accounts/resources.

NOTE: NEVER SET THE GRANT_PATH TAG TREE TO ANY OF THE PRINCIPALS.

Managing grant paths for users

Say you want to introduce a new team to this scheme, change paths or add a broader grant area for some users.

There are two main options to manage grant paths for your users:

  • Using 2PA, 2PA is a concept we created to implement the two-person rule in the cloud. Learn more about it in our fwd:cloudsec lecture!
  • Temporarily exempt yourself from the Control Plane SCP. Just add another Condition to assert your user/role can tag under the meta grant path.

To sum up, Control Tags are a great way to manage tagging permissions and enable some developer autonomy in your organization. Check out my entire presentation to learn more tricks Control Tags have up their sleeves

The Last Mile of Zero Trust

The Last Mile of Zero Trust

July 20, 2022
Tad Johnson
Read Article

“Zero Trust” is everywhere in the cybersecurity world. While it’s fair to say that the term is a bit over-used by over-zealous marketers, the security paradigm it describes is real. Broad categories of security exploits can be significantly reduced – if not eliminated – by implementing a zero trust security model that continuously validates user identity, device posture, and resource access. One area that’s often overlooked in zero trust implementations is the last mile: extending the principle of least privilege all the way to end-users of information systems.

What is the last mile of zero trust?

To understand the last mile of zero trust, let’s first review the first mile. A user wants to access a protected resource, such as a customer record stored in their SaaS CRM platform. The user’s identity is verified against the enterprise identity provider (IdP), the security posture of her laptop is validated to conform with enterprise standards, and her access privileges for the CRM platform are verified. Once this level of trust is established, a secure connection is established between her laptop and the CRM platform and the customer record is displayed. In an ideal scenario, everything just mentioned happens in milliseconds and is transparent to the user.

At this point in our scenario, a customer record is displayed on screen. Now let’s consider the last mile: what can the user do with that data?

  • Is she allowed to print the page, creating a new physical copy that is more or less untraceable?
  • Is she allowed to take a screenshot of the window, creating a digital copy that’s disconnected from the CRM platform?
  • Is she allowed to copy notes from the most recent customer support case and paste it in an email? What if she tries to paste those notes in her personal email account?
  • Is she allowed to view the customer’s credit card number that was attached in a note regarding a recent billing inquiry?
  • When she joins a Zoom meeting and shares her desktop, will that customer record be displayed to everyone in the meeting?

This deeper level of granularity in data protection is critically important – but it’s left largely unaddressed by legacy ZTNA vendors. The principle of least privilege is a foundational tenant of zero trust: a user should be given only those privileges necessary to complete their job. Returning to the example above, her job requires access to customer records from the SaaS CRM platform; her job does not require her to make new copies (printed or digital), move customer data to a personal email, or share customer records to a Zoom meeting. Most of the time, she doesn’t need to view credit card data, but there are some exceptions when she needs that information to resolve a customer issue.

An ideal last-mile security policy would look like this:

  • When she is viewing customer records, the function to print or take screenshots is disabled (and she sees a clear message explaining why if she attempts that function).
  • If credit card numbers are stored in case notes, they are redacted from view. The InfoSec team set an optional rule to allow a user to toggle visibility (and when toggled, that action is logged).
  • When copying data from a customer record, she can paste it within the CRM platform, or within trusted enterprise apps, but she is not allowed to paste that data to a personal email or untrusted apps.
  • If she joins a Zoom meeting and shares her desktop, the window with customer records is hidden, but other non-sensitive windows can be shared.
  • All the controls above are granularly enforced to apply only to sensitive content like customer records, so she remains fully productive at work.
  • Every interaction with the CRM platform is logged to a centralized analytics platform to support fast incident response and investigation.

This vision for embracing zero trust principles for end-to-end security of modern web apps and data inspired the development of Island, The Enterprise Browser. It’s the browser that’s designed for the enterprise that makes work fluid, frictionless, and fundamentally secure. Instead of layering security tools on top of a consumer-focused browser, Island applies security controls within the browser itself. It’s the perfect on-ramp for putting zero trust principles into practice, both at the network layer and at the last mile. Because it’s built around Chromium technology, users enjoy the fast, familiar experience they expect. It’s work as it was meant to be, where security is native to all users, applications, and the data between them.

Zero Trust in Practice

Zero Trust in Practice

July 20, 2022
Tad Johnson
Read Article

The zero trust security model builds on decades of hard-learned lessons. The era of a secure network perimeter is long past, so we should never implicitly trust a connection based on its network location alone. With the ubiquity of federated identity providers, we can positively identify the identity behind every request. We can evaluate the posture of the device a request originates from to protect to further protect against stolen credentials being misused. And with modern networking technologies, we can start from zero and build up these layers of trust before allowing the network connection, then continuously re-evaluate trust with every request.

As a security philosophy, zero trust offers a path to resolving many categories of vulnerabilities. Credential theft is much less effective when we require multiple factors for authentication and evaluate the device posture before granting access. Internet-based attacks can’t succeed if there is no routable path between a private app and the outside network. Even if malware is already resident on a device, lateral movement to infect other devices is made exponentially more difficult.

Making it Real

Bringing zero trust out of the realm of theory and putting it into practice means investing in security tools. An identity provider, some network infrastructure, and typically some combination of endpoint agents. Curiously, there’s one application at the center of almost every zero trust workflow that’s been ignored by most security vendors: the web browser.

When an enterprise invests in security tooling to put zero trust in practice, it doesn’t make sense to leave a basic consumer-oriented web browser at the center. Island built The Enterprise Browser to change that.

The Enterprise Browser is the on-ramp for a practical zero trust security implementation. It integrates with identity providers for user authentication and identification of all web activity. It continuously evaluates device security posture, without requiring any additional agents. It can make secure connections to private apps and resources over any network, while keeping those private apps completely dark to unauthorized access. It can apply last-mile controls to protect data from inappropriate use or accidental leakage – something that is virtually impossible for a legacy network-based security tool to achieve. And all web activity within the browser can be logged and shared with a SIEM or analytics platform to gain unmatched visibility and inform security governance and incident response.

And because all of this is built around a Chromium-based web browser, the end-user experience is frictionless and familiar. There are no extra agents to deploy, no training to teach users how to connect. Simply by introducing a new web browser, you can take a practical step at leveling up your security practice and embracing the zero trust paradigm.

The Human Element

A collaborative partnership with end-users is key to any successful security strategy.

At baseline, any new security tool or technique shouldn’t burden users or disrupt their general productivity. Thankfully, modern security practices are generally transparent to users or follow familiar patterns that become second nature. Clear communication with users in the form of status indicators, notifications, or error messages (with instructions on what to do next) goes a long way in ensuring lasting success.

The Enterprise Browser offers a unique approach to end-user engagement. The browser itself is tuned to be fast and a tailored enterprise app chooser makes every app and resource immediately available. There are no added burdens for end-user adoption, and no extra steps that could hinder user productivity. User messaging can be customized to match corporate brand voice, and users get clear and immediate feedback when they encounter a security policy. It’s tempting to overlook user experience or take it for granted when designing a security strategy. The Enterprise Browser makes it easy for end-users to adopt it as their default browser, and it gives Security teams the tools they need to clearly communicate their security policies.

Changing One Thing  

The concepts and technologies that form a zero trust security model are not a secret, nor are they proprietary to any one security vendor. Today’s challenge is largely one of optimization and operations – how do we implement a security strategy that decreases risk without disrupting end-users or business operations?

This challenge is what motivated creating The Enterprise Browser. It’s a unique approach, where the web browser itself plays an active role in the security strategy. Sometimes changing one thing changes everything.

Three Pitfalls of BYOD and One New Answer

Three Pitfalls of BYOD and One New Answer

June 27, 2022
Tad Johnson
Read Article

There are still many advantages to centralized purchasing and provisioning, both financial and operational. On the other hand, every business needs the ability to extend access to a personal device in some cases: employee onboarding, business continuity, or contract workers, for example. Some employees want the option and convenience of accessing business apps using their home computer. Balancing the competing concerns of information security, IT operations, and user privacy is no small task—as is evident from the mixed results of BYOD in practice.

BYOD initiatives often stumble when they hit one or more of these three pitfalls: 

  1. Un-Managed Devices
    The most common barrier to any BYOD program is the very real concern of unmanaged devices connecting to critical applications housing sensitive data. Putting sensitive data on devices where you have no visibility or management is a huge risk. The natural solution is to install an endpoint management agent, which solves one problem but creates another.

  2. User Rejection
    Ask the average user to install an endpoint management agent on their personal device and you’ll be met with some (well deserved) skepticism. What data can the agent see? Are my personal email, documents, and photos visible? Is all my personal web browsing being logged? Concerns over user privacy are real and users shouldn’t have to trade their privacy for BYOD flexibility. Instead, we can deploy a virtualized desktop and manage that layer. Problems #1 and #2 are solved, but at what cost?

  3. IT Operational Cost
    Desktop Virtualization seems appealing for allowing users to leverage their own devices, because it answers some of the security questions without intruding on user privacy. But that technology comes with a steep price tag, both in licensing cost and operations staff to manage it. For remote users on less-than-ideal networks, the user experience of DaaS can be painful. Now you’re adding extra help desk calls on top of an already costly solution. What if we could get all the benefits of a managed, secure, and isolated platform without the high costs of VDI or DaaS? 

Now we can solve all three with Island, The Enterprise Browser. 

First, the Enterprise Browser eliminates the need for a system-level endpoint agent on a personal device. By enforcing security and management policies in the browser itself, all critical web apps and data are secure. Last-mile controls keep data in the browser, stopping data leakage and keeping business and personal data separate. Users keep their personal privacy and you get the security controls you need. No endpoint management agent required. 

Next, the Enterprise Browser eliminates the need for DaaS or legacy VDI. On top of the security controls mentioned above, the Enterprise Browser protects against web-based browser exploits, phishing scams, man-in-the-middle attacks, malware, and more. Instead of adding multiple security agents, or virtualizing the desktop and all its apps, The Enterprise Browser addresses the root cause of web vulnerabilities: the web browser itself. You get more granular control and visibility than with VDI or DaaS, without the cost and complexity. 

Last, the Enterprise Browser is already familiar to users. It’s based on Chromium, the same as Chrome, Edge, and other modern web browsers. The user interface is the same and every web app functions exactly as expected. And unlike DaaS, it’s running locally on their computer, so performance is excellent. 

The Island Enterprise Browser is a unique approach that resolves several common problems that hold back BYOD. To learn more about how Island can deliver a better BYOD experience, contact us. 

BYOD / BYOPC User Privacy vs. UEM Security Visibility DaaS/VDI alternative
Why it’s time to rethink your VDI or DaaS

Why it’s time to rethink your VDI or DaaS

June 27, 2022
Tad Johnson
Read Article

Cut out cost and complexity and dramatically improve user experience by replacing your VDI or DaaS strategy with an Enterprise Browser

The promise of desktop virtualization is hard to argue: your employees can work from (just about) any device, anywhere in the world while you keep your sensitive apps and data secure and centrally managed. VDI was a decent solution at a time when most organizations managed their own data centers, Windows apps were the norm, and working with rich content (such as video) wasn’t a requirement. Today, most apps are delivered through a web browser and hosted by SaaS providers. Users often connect from home networks outside the reach of enterprise controls. A growing remote workforce pushed many organizations to rethink how they secure and monitor access to critical apps. As an established technology, VDI or DaaS was a natural choice at the time. 

But as your help desk tickets will confirm, virtualization in any form comes with a huge burden on both operations staff and the end-users they support. Performance issues, network congestion, and complex provisioning weigh against the benefits of virtualization. Add to that the high costs of hosting, licensing, and operating a robust VDI or DaaS environment and the costs start to outweigh the benefits.

There’s a modern alternative to DaaS that you should consider: The Enterprise Browser. 

The Enterprise Browser takes a new approach to securing critical apps and data. Instead of adding layers of virtualization–disrupting the user’s experience and adding cost and complexity–security and access controls are built-in to the browser. Users authenticate with their corporate credentials, last-mile controls stop data leakage, browser hardening protects against malware, and full activity logs are sent to your SIEM. This approach gives InfoSec teams a level of control and visibility that goes way beyond VDI or DaaS, and end-users enjoy unrivaled performance.

Provisioning a new user with The Enterprise Browser is much simpler for IT Operations teams: install the browser. That’s it. End-users can even download and install it themselves on devices IT doesn’t own or manage. And it’s available for Windows, macOS, and Linux so everyone gets to enjoy full native-app performance. Once deployed, IT’s job is done: no performance tuning, resource monitoring, or cost modeling required. 

The end-users who are working with SaaS apps every day see a noticeable improvement. The Enterprise Browser is built on Chromium, so web performance is as good as it gets. Since there’s no virtualization overhead, there’s no lag or visual artifacts. Users get their work done, in a browser they’re already familiar with. 

The Enterprise Browser won’t replace all virtualization: if you’re connecting to systems for high-end CPU or GPU workflows, VDI is the right play. But if your primary goal is to secure access to web apps and data, across a remote or distributed workforce, The Enterprise Browser is a far better choice. Get a demo

VDI / DaaS cost and complexity Security controls End-user performance
Supporting Legacy Web Apps in the Modern Era

Supporting Legacy Web Apps in the Modern Era

June 22, 2022
Tad Johnson
Read Article

2022 marks the end of the Internet Explorer era, with Microsoft ending all support for IE11. While it’s no surprise that modern browsers like Chrome, Edge, and Safari have replaced the legacy Internet Explorer, there are still many organizations who rely on legacy web apps developed years ago and seldom updated. These legacy tools are often critical to some business process and difficult to replace (hence why they’re still in use today). 

1. Add Multi-Factor Authentication (MFA)

Many legacy web apps were built before MFA was a common practice. Refactoring the login and authentication flow to support MFA is a daunting task for old, brittle code. So, while it’s a universal best practice to use a second factor during authentication, it may be impractical if not impossible.

The Enterprise Browser can change that: the browser integrates with your enterprise Identity Provider so every user is identified and authenticated with as many factors as you like. You can go further and require a one-time code on when a user navigates to a web app–giving you the security benefits of multi-factor authentication without touching the legacy source code.

2. Access shared credentials without disclosing passwords

Another challenge for legacy apps is managing shared credentials. In an ideal world, every user would use their own credentials to authenticate; in practice it’s not uncommon for legacy systems to rely on a shared administrator account. When common credentials are shared among several users, you lose visibility and control over user access. And revoking credentials for a user when they leave the organization can be inconvenient (or worse, left undone).

The Enterprise Brower can help: you can store shared credentials securely and make them available to specific users or groups. When the user reaches a login page, the browser will offer to auto-fill the credentials. Unlike using a shared password manager, the actual password is never disclosed to the user. Since every user is identified within the browser, you get an accurate record of every user and every login event where shared credentials are used. Password rotation is much easier, with a single place to update in the Island management console. And revoking credentials is as simple as removing that user from the access list in your IdP.

3. Support Internet Explorer 11 compatibility

As published by Microsoft:

The Internet Explorer (IE) 11 desktop application ended support for Windows 10 semi-annual channel on June 15, 2022. Customers are encouraged to move to Microsoft Edge with IE mode. IE mode enables backward compatibility and will be supported through at least 2029.

In global web browser market share, Edge holds about 4% behind Safari (20%) and Chrome (63%). Rolling out Edge with IE mode is a sizable effort for a rather limited benefit. It doesn’t answer either of the issues addressed above, so MFA and shared credential challenges remain unsolved.

The Enterprise Browser is a better choice: it’s built on the same Chromium browser engine as Edge or Chrome, so it looks and feels familiar. It offers IE11 compatibility mode so you can run legacy web apps in a separate tab, and it can solve the other legacy web app challenges listed above. Of course it doesn’t stop there–The Enterprise Browser is built for the modern workplace with security and user productivity in mind.

enterprise browser, IE replacement
Chromium Internals 101

Chromium Internals 101

June 7, 2022
Peleg Wainberg
Read Article

What is Chromium?

As described in the Chromium project's official site:

Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web

Technically, Chromium is the name of the project, and is not referred to in the code. The product itself is Chrome, not to be confused with Google’s browser named Google Chrome.

Over the years, the Chromium project became more than just a browser. It’s a powerful web platform that can be used in many ways to build different products (Electron, Chromecast, etc). It even became an integral part of an OS (Chromium OS).

Chromium is one of the largest codebases in the world, and it runs almost everywhere. It is developed mostly in C++, but already includes some Rust, TypeScript and more.

Basic concepts / Terminology

Before we begin, let’s set some common terms which anyone interested in Chromium must know.

  1. Rendering Engine - The component responsible to parse and transform HTML to what we see as web pages. It takes the tags and implements their behavior.
    1. Blink - The rendering engine used in Chromium. It was forked from Apple’s WebKit in 2013.
    2. Renderer - Usually refers to a process running the rendering engine.
  2. V8 - The JavaScript engine used in Chromium.
    1. Chrome API - JS events and functions that the browser exposes. Some APIs are exposed globally across the browser, some are limited to specific components (e.g. to extensions only).
  3. Mojo - Chromium’s IPC (Inter Process Communication) system. Used for communication between the different processes and components of the browser.
  4. Sandboxing - The concept of isolating and limiting a component. Usually implemented by restricting process privileges via operating system features. Implemented differently per operating system.
  5. Extensions - Software plugins for the web browser. Built mostly with web technologies such as HTML, CSS, JavaScript, etc. They allow adding capabilities to the web platform by third parties.
    1. In Chromium, extensions run in their own process.
    2. There are other types of plugins supported, we will cover some of them later on.

Process model

One of the most commonly known facts about Chromium based browsers is that they have lots of processes. But why are they all needed?

First of all, for security reasons. If we run all of our code in the same process, exploiting one part can lead to code execution all over the browser. It’s harder to isolate threads, so the browser leverages operating system’s features and isolates processes. In Chromium, a renderer doesn’t run in the main browser’s process. Different sites will run in different renderers who have different processes. Also, different types of processes have different privileges. Some processes are sandboxed. This makes exploiting the browser much harder, as in most cases you will have to chain multiple vulnerabilities in order to gain control of the whole browser

This separation is also good for the user’s experience. As more “services” or logical components are moved out of the browser process, it is more likely to recover from errors and crashes - it might be possible to just relaunch the service seamlessly. To be as fast as it can, it uses more operating system resources.

Process Types

So what kind of processes do we have? Here are some notable examples

  1. The browser process - The main broker of the engine. It is not sandboxed, provides capabilities via its interfaces and acts as a broker between different processes
  2. Frame/Tab processes - The renderer of the tab itself. In Chromium, a different renderer instance is created per frame (tab, iframe, etc), usually in its own process
  3. Utility/Service processes - Provide specific capabilities as a service. The network service is an example of such process, and it's responsible for, as you can guess, network operations
  4. Extension Processes - each extension runs in its own process

And of course there are more.

You can view your own browser’s processes by opening the browser’s task manager:

In this example, we can see a browser with 2 tabs. It has a browser process, some utility processes, a tab process for each tab and an extension process.

So we’ve got different logics in different processes, and some of them are tightly restricted. But how do they work together? If tabs are sandboxed and cannot access most of the operating system’s features, how can we listen to music or download files? It all starts with a bit of mojo.

Mojo

Mojo is a platform-agnostic collection of runtime libraries, providing inter process communication primitives, a messaging format and a binding system. To make it simple, it allows components (within the same process or not) to communicate with each other over predefined messages, in different languages.

Mojo is the successor of a legacy IPC system, which barely exists as most code was migrated. Nowadays, the different components of Chromium communicate with each other almost only using Mojo. That way, when we upload a file, the renderer process asks the browser for the file’s contents - and the renderer doesn’t need to actually access the filesystem.

Mojo is relatively similar to other IPC systems, but is unique for its ability to pass object handles - such as file descriptors and file handles. It also allows validations that the browser uses for security (e.g. it doesn’t allow passing file path objects if the receiver might not have permissions to it now or later on).

Mojo's top level design, taken from the official documentation

Blocking/Non blocking threads

In order to maintain a fluid user experience, the browser doesn’t allow blocking/synchronous operations to run everywhere. It would be a shame if the entire UI would freeze while the browser tries to write a file, or a single tab waits for server response.

Any blocking task that runs in the browser must be marked as such, and it would usually run in a dedicated thread. Blocking APIs always validate that they run in a context that allows blocking.

In the browser process itself there are different UI and IO threads.

Extensions and applications

Chromium provides interfaces which allow third parties to extend the browser and provide non-generic features to the browser. Extensions are the most known interface, but others exist as well.

Extensions and apps should be downloaded from the official store, but can practically be downloaded and installed from anywhere else.

Chromium provides APIs for such components, making them more powerful and versatile. You can read more about it here. They are developed in JavaScript (or any other language that can be transpiled to JavaScript).

An extension is defined via a manifest file. In this file it declares the permissions it requires, its scripts and in which tabs to inject them, what resources it needs, some metadata and more. An extension is limited in regard to what it can and cannot access, and it must ask for specific API permissions in the manifest (e.g. - storage, bookmarks, …).

Extensions can run two types of scripts - background and content. Background scripts run in the extension’s process, have access to the chrome API and in general have more capabilities. Content scripts are injected into the requested tabs and can access them. Background and content scripts can communicate with each other and work together.

Web platform or a browser?

While for the end user Chrome is the entire product, the project is actually built as a framework and a specific implementation of it.

The framework, often referred to as the web platform or the web engine is the multi-process sandboxed browser platform itself. It includes the rendering engine, interfaces for all supported features, most of the services and components of the browser and more. Think about it as a browser library.

Chrome is the product itself, the browser built atop the web platform - the UI, implementations of platform interfaces, browser specific logics and so on. It uses the framework’s library, implements some of its interface and “makes it an app”.

While the two were separated for code health reasons, it also allowed new opportunities such as creating other products on the platform - such as Electron, Chromecast and others.

in the code, all of Chrome’s code is under src/chrome, while the platform’s code is under src/content.

Summary

Great, you’re ready to dive deep into Chromium’s internals! We’ve learned what Chromium is, covered some basic concepts and set a common ground. In future blogs, we will move on to explore various features and areas in the project. Stay tuned!

Resources

  1. Chromium's official site
  2. Chromium's official documentation
  3. Chrome University

5 Myths of the Enterprise Browser

5 Myths of the Enterprise Browser

June 7, 2022
Tad Johnson
Read Article

Click here for an infographic of this article

The Enterprise Browser is just another flavor of remote browser isolation (RBI)

False. 

The Enterprise Browser achieves the same outcomes as RBI — protecting malicious code execution, phishing attempts, and dangerous file downloads — but does so from within the browser itself. This means no added latency for the user and much less complexity  for the organization. And unlike RBI that only isolates a fraction of web activity, The Enterprise Browser by definition protects all web activity.

Takeaway: Island, The Enterprise Browser, keeps all web-based work fundamentally secure—without the cost and complexity of a full RBI implementation. 

The Enterprise Browser is just another web security tool 

False.

While the Enterprise Browser delivers end-to-end security for web applications and their data, it’s so much more than that. By operating inside the browser presentation layer, it provides granular, “last-mile” controls such as screen capture, copy/paste, and download/upload control, or sensitive data redaction. But it doesn’t stop there: it also enhances any web app with robotic process automation (RPA), such as adding MFA to legacy web apps or placing additional approval steps for mission-critical workflows. And all data flows directly into your SIEM for detailed visibility and forensic analysis.  

Takeaway: Island takes an entirely different approach to security that goes beyond the network or content layer to inspect and modify web apps at rendering time, opening a range of possibilities far beyond other security tools. 

The Enterprise Browser requires a managed device for policy enforcement  

False. 

The Enterprise Browser secures access to web apps and content on any device, managed or not. It knows the posture of the device it’s running on and enforces policies accordingly. For example, the Enterprise Browser can redirect file downloads from an unmanaged device to in-browser secure storage to prevent data leakage. Many organizations are using the Enterprise Browser in place of more complex VDI or DaaS implementations to give contractors or BYOD users secure web access. Whether it’s running on an unmanaged or managed device, the full power of the Enterprise Browser remains intact.  

Takeaway: Island secures access to web apps & content, regardless where it’s installed, with a deployment mode that’s far less complex than VDI or DaaS. 

The Enterprise Browser is a locked-down secure browser

False.

While the Enterprise Browser provides secure-by-design access to web apps, it’s built with the same familiar browsing experience that users already know and love. Policies are context-aware, so the security controls that keep sensitive data secure and enterprise apps protected are only applied where they’re needed. Unlike single-purpose secure browser products, the Enterprise Browser is often used as the default browser for all web access. 

Takeaway: Island pairs enterprise security & management policies with a granular enforcement engine so the important apps and data are always protected without sacrificing browser speed or user experience.

Existing browsers already have enterprise features

False. 

The enterprise features offered by popular consumer-oriented browsers like Google Chrome and Microsoft Edge are significantly limited and only skin deep by nature. For example, the controls offered are only applicable at the device level, which means policies are by definition applied to all web apps, leaving no room for granular policy enforcement. And most essential enterprise features are missing entirely, such as device posture assessment for tailoring policy management, or inserting browser-based RPA to enhance web app functionality.

Takeaway: Existing browsers offer few, limited, and surface-level enterprise features that were not designed to address the wide-ranging needs of the enterprise. The Enterprise Browser, however, offers comprehensive control, visibility, and governance over all browser behavior, delivering a level of security that was previously unimaginable.

Conclusion

It may seem easy at first glance to confuse the Enterprise Browser with some familiar solutions we’ve seen over the years. But dig deeper, explore what the Enterprise Browser has to offer, and the truth comes out - changing this one thing really does change everything. 

Extensions in Chromium and where to find them

Extensions in Chromium and where to find them

May 24, 2022
Michael Maltsev
Read Article

Chromium extensions provide a way of customizing the web-browsing experience by adding extra functionality to the browser. The straightforward way of loading an extension in Chromium is by installing it via a supported extension store. But that’s not the only way. An extension can also be loaded from a folder on the computer, via the registry, or via admin policies. Some extensions, called component extensions, are an integral part of the browser which happen to be implemented as extensions.

For each loaded extension, Chromium keeps track of its source location type, which affects the way the extension is treated. For example, component extensions are not displayed on the extensions page (chrome://extensions) and have some extra privileges.

In this post, we’ll take a closer look at where inside Chromium extensions are found, and why their location matters.

The ManifestLocation enum

The ManifestLocation enum is defined in the manifest.mojom file in the Chromium source code, and at the time of writing, it has 10 valid values. The enum is preceded by a short explanation comment:

Historically, where an extension was loaded from, and whether an extension's files were inside or outside of the profile's directory. In modern usage, a Location can be thought of as the installation source: whether an extension was explicitly installed by the user (through the UI), or implicitly installed by other means. For example, enterprise policy, being part of Chrome per se (but implemented as an extension), or installed as a side effect of installing third party software.

Here are the 10 values and comments from the source code which provide a short explanation:

The location rank

The values in the ManifestLocation enum are ordered chronologically, with each newly added value added to the end of the list. I found it more convenient to order the values by their rank. The GetLocationRank function, implemented in manifest.cc, assigns a rank to each ManifestLocation value in order to be able to decide which extension to load if there’s an extension of the same id in different locations. The rank has a good correlation with the privileges that are given to the extensions from the corresponding location.

Here are the ranks along with short comments which can be found in the source code:

In addition to the rank values, the ranking function divides the 10 ManifestLocation values to 5 groups, which helps get some extra intuition about the values and the way the browser treats them.

Listing installed extensions

Before we begin looking at the different extension types, let’s tackle another basic question - how do we list all of the installed extensions and their location values? There’s the extensions page (chrome://extensions), but as we mentioned, not all extensions are displayed on it, and it also doesn’t show the location values.

One way to see all enabled extensions, including component extensions, is to navigate to chrome://system and look at the extensions row. Another way to see component extensions is to run Chromium with the --show-component-extension-options command line switch which will show them on the familiar extensions page (chrome://extensions). But those two methods still don’t give us enough information. Specifically, we still can’t see the location value of each extension.

To get full visibility, we can look directly at the information in the user profile folder. The “Secure Preferences” file contains the information we need. For Chrome on Windows, the file for the default profile is located in the following folder:

%localappdata%\Google\Chrome\User Data\Default

The file is a JSON file containing, among other details, the list of installed extensions for the profile which can be found under extensions.settings. For each extension, the key of the entry is the extension ID, and one of the properties is “location”. The location value is a number corresponding to the ManifestLocation enum defined in the manifest.mojom file.

For example, Google Chrome comes bundled with a component extension called Google Hangouts, and we can see the following entry for it in the Secure Preferences file:

{
  "extensions": {
    "settings": {
      // …
      "nkeimhogjdpnpccoofpliimaahmaaome": {
        // …
        "location": 5,
        // …
        "path": "C:\\Program Files\\Google\\Chrome\\Application\\97.0.4692.71\\resources\\hangout_services",
        // …
      },
      // …
    }
  }
}

This tells us that the location value of Google Hangouts is kComponent. The path parameter is also interesting - we can see that the extension is loaded from the readonly installation folder of Chrome, not from the profile folder.

After installing vanilla Google Chrome (version 97.0.4692.71) on Windows 10, here’s what I got under my profile:

Note that 4 extensions are visible on the extensions page, but in fact 14 extensions are installed.

Extension types

The post wouldn’t be complete without mentioning extension types. Chromium defines another enum called Type, defined in manifest.h, which contains the following values at the time of writing:

  • TYPE_UNKNOWN
  • TYPE_EXTENSION
  • TYPE_THEME
  • TYPE_USER_SCRIPT
  • TYPE_HOSTED_APP
  • TYPE_LEGACY_PACKAGED_APP
  • TYPE_PLATFORM_APP
  • TYPE_SHARED_MODULE
  • TYPE_LOGIN_SCREEN_EXTENSION
  • TYPE_CHROMEOS_SYSTEM_EXTENSION

The logic that determines the extension type is implemented in the GetTypeFromManifestValue function in manifest.cc. That’s the reason why, for example, the Slides extension was visible on the extensions page for me, but the YouTube extension wasn’t - the former is of type TYPE_EXTENSION, while the latter is of type TYPE_HOSTED_APP (and is visible on chrome://apps).

In this post, we’ll be focusing on extensions of type TYPE_EXTENSION.

kComponent

As a reminder, here’s what the comment in the ManifestLocation enum says about kComponent:

An integral component of Chrome itself, which happens to be implemented as an extension. We don't show these in the management UI.

Component extensions are registered to be loaded by the AddDefaultComponentExtensions function in component_loader.cc, and loaded by ​​the AddComponentExtension function in extension_service.cc. The list of component extensions is predefined in the code, and can’t be changed without changing the code and recompiling the browser. The extensions themselves are loaded from the browser installation folder, not from the profile folder, and don’t change unless the browser changes, e.g. on a browser update. That means that component extensions don’t update independently like regular extensions do.

As an example, here’s the commit that adds the Google Network Speech component extension.

It can be useful as a reference for adding your own component extension to Chromium.

Regarding special treatment of the browser for component extensions, you can find several such code snippets in the source code by looking for “kComponent” and “IsComponentLocation” around the code. Here are a couple of examples:

Note: Confusingly, in addition to component extensions, Chromium has something completely unrelated called components. Components are listed in chrome://components, and are bundles of files, usually dynamic libraries or data files, which are updated separately from the browser itself. To add to the confusion, components are distributed in .crx files, but they have nothing to do with extensions.

kExternal*

Before proceeding to kExternalComponent, there are details that are common to all kExternal* values. Extensions for all 6 kExternal* values (kExternalComponent, kExternalPolicy, kExternalPolicyDownload, kExternalRegistry, kExternalPref, kExternalPrefDownload) are loaded by loaders which are specialization classes of the ExternalLoader class. Those loaders are used by instances of ExternalProviderImpl that pass the loaded extensions to an installation service. The extensions are eventually loaded by the CheckForExternalUpdates function in extension_service.cc.

Each external provider can provide extensions in two ways: Extensions originating from .crx files, and extensions originating from update URLs. The external provider is initialized with a location type for each of the two ways, which the installed extension will end up being marked with.

Here is the rough list of extension loader specializations and their location values. ChromeOS-specific and other OS-specific cases are not included.


It’s interesting to note that kExternalPolicy is not present in the table. It’s only being used in ChromeOS.

kExternalComponent

The comment from the ManifestLocation enum:

Similar to kComponent in that it's considered an internal implementation detail of chrome, but installed from an update URL like the *kDownload ones.

External component extensions are registered in the StartLoading function in external_component_loader.cc. The registration sets the extension IDs and the extension store URL to be used for installing the extensions.

Like with component extensions, the browser has special treatment for external component extensions. You can find relevant snippets in the source code by looking for “kExternalComponent” and “IsComponentLocation”.

kExternalPolicy

The comment from the ManifestLocation enum:

A crx file from an external directory (via admin policies), cached locally and installed from the cache.

As was already mentioned, the kExternalPolicy location is only used in ChromeOS.

kExternalPolicyDownload

The comment from the ManifestLocation enum:

A crx file from an external directory (via admin policies), installed from an update URL.

kExternalPolicyDownload extensions are registered in the StartLoading function in external_policy_loader.cc. Two instances of ExternalPolicyLoader are created, one for forced extensions (that can’t be disabled) and one for recommended extensions.

Like with other location types, the browser has special treatment for policy extensions. You can find relevant snippets in the source code by looking for “kExternalPolicyDownload” and “IsPolicyLocation”.

kCommandLine

The comment from the ManifestLocation enum:

--load-extension.

Extensions that are loaded by using the --load-extension command line switch are marked with the kCommandLine location. They are loaded by ​​the LoadExtensionsFromCommandLineFlag function in extension_service.cc, which delegates the loading to UnpackedInstaller which loads the extensions from their target folders.

The browser has special treatment for extensions which are loaded unpacked. You can find relevant snippets in the source code by looking for “IsUnpackedLocation”. There are also a few places with special treatment specifically for “kCommandLine”.

kUnpacked

The comment from the ManifestLocation enum:

From loading an unpacked extension from the extensions settings page.

Extensions that are manually loaded from a folder for development are marked with the kUnpacked location. They are loaded by ​​the FileSelected function in developer_private_api.cc, which delegates the loading to UnpackedInstaller which loads the extensions from their target folders. They are also reloaded by ​​the LoadExtensionForReload function in extension_service.cc on browser launch.

The browser has special treatment for extensions which are loaded unpacked. You can find relevant snippets in the source code by looking for “IsUnpackedLocation”.

kExternalRegistry

The comment from the ManifestLocation enum:

A crx file from an external directory (via eg the registry on Windows).

kExternalRegistry is a Windows-specific location for extensions that were loaded from a local .crx file via the registry as specified here: Pre-installed Extensions (Pre-installing via the Registry). The extensions are registered in the StartLoading function in external_registry_loader_win.cc.

Note: Extensions that were loaded from a URL (and not a .crx file) via the registry as specified here: Alternative extension distribution options (Using the Windows registry) are registered with the kExternalPrefDownload location, not kExternalRegistry.

kExternalPref

The comment from the ManifestLocation enum:

A crx file from an external directory (via prefs).

kExternalPref is a location for extensions that were loaded from a local .crx file via the browser preferences as specified here: Alternative extension distribution options (Using a preferences file). The extensions are registered in the StartLoading function in external_pref_loader.cc. Two instances of ExternalPrefLoader are created, one for the system-wide preferences and one for the per-user preferences. kExternalPref is not used on Windows (except for ExtensionMigrator which is a specific migration case).

Note: Extensions that were loaded from a URL (and not a .crx file) via the browser preferences as specified here: Alternative extension distribution options (Using a preferences file) are registered with the kExternalPrefDownload location, not kExternalRegistry.

kExternalPrefDownload

The comment from the ManifestLocation enum:

A crx file from an external directory (via prefs), installed from an update URL.

kExternalPrefDownload is a location for extensions which were loaded from an update URL via the registry (Windows) or via the browser preferences (non-Window). See kExternalRegistry and kExternalPref for more information.

kInternal

The comment from the ManifestLocation enum:

A crx file from the internal Extensions directory. This includes extensions explicitly installed by the user. It also includes installed-by-default extensions that are not part of Chrome itself (and thus not a kComponent), but are part of a larger system (such as Chrome OS).

Except for a couple of specific cases, kInternal extensions are the common, regular extensions that are installed by the user from the extension store.

Summary

In this post, we went over the extension locations that Chromium defines and uses. We looked at when and where they’re used, and how they affect the way the browser treats the extensions.

How software teams avoid death by hypergrowth

How software teams avoid death by hypergrowth

May 20, 2022
Alon Biran
Read Article

We were building a really big product, and we knew we needed to do it right from the start and keep it right at scale, no matter how many engineers we onboard. 

We knew the code itself was less important, as it would change frequently, but building a mechanism that would allow us to move fast while continuously onboarding people was critical. And because of that, we decided to invest in building the right infrastructure.

Here are the five main areas we focused on to successfully launch Island.

Create consistency by systemizing the development of new services

We wanted the code to look similar across the system, so we made a skeleton of how a microservice looks, how an extension “service” looks, and made sure they were similar to each other. This made diving into any code and things like code reviews much simpler. It also enabled us to get into someone else’s code very quickly, easily, and confidently, since all of the code looked similar. Naturally, we didn’t want to create a big boilerplate for each service, so we wrapped it in generators and Jenkins jobs to create the code as easily as deploying it. Today, populating a new service takes less than a day and is mostly automated. Engineers focus on the business logic rather than how to install dependencies, or how the code structure should look.

And of course, in the specific cases where you’d want to go out of the template, it would be obvious to understand a discussion is needed around it

Ensure the highest standard of quality with ongoing tests, coverage, automation, & CR

We then understood that, while we wanted to move fast and release features in rapid phases, our releases had to be of the highest quality and remain that way. Maintaining this high-quality standard was extremely important because the browser is such a crucial tool for everyone – bugs could negatively impact our customer’s productivity – and because of that we kept progressing without letting ourselves get “stuck in the mud” with a lot of regression bugs.

First, we had a rule: No code goes unreviewed. Every piece of code must be reviewed by at least one person from the team. Every feature, every bug, every configuration file, even every typo fix. In specific cases we even added code owners to make sure only the code they approve makes it into the product.

Second, we added CI in the form of github actions to enforce specific style, coverage of tests, build and quality of the code (no warnings etc.), and while coverage does not always point to quality, it at least forced the engineers to think about what they wanted to test and how.

Here’s a nice graph on how our coverage looked after we started enforcing it. When we started back in Jan ‘21 we were at around 80%, eventually making it to 97%.

In addition, we invested heavily in automation from the beginning. This gave us the ability to test features E2E and and keep ourselves accountable for its stability and consistency, while always improving our ability to understand and debug issues on a given PR.

Here is an example of our Grafana presenting the automation success rate:

Another good example is our per-test fail ratio & build time, for monitoring which tests are giving value, which are not, and of course which are slowing us down:

Make gradual deployment easy with feature flags

Deploy, deploy, deploy. Since we use our own browser on a daily basis, we wanted to make sure engineers are comfortably deploying multiple versions a day while maintaining a high level of quality. Instead of canary or blue-green deployments style, we wanted to make sure our deployment strategy fits the Island company strategy – lots of engineers moving at a very fast pace. We chose a strategy to keep deploying and keep testing in production while having granular control on how each feature behaved. For that, we chose to use feature flags. Each development, each feature can be controlled by a feature flag (not only boolean, but every variation of a parameter) and each feature is gradually deployed among customers as well. 

First we deploy features to our own browsers, then we deploy them to our demo segment and sales engineering. Afterwards we deploy them to specific customers (beta customers, early stage adopters) and finally to all customers. This strategy allowed us to control the quality of releases while getting continuous feedback from both internal and external users and our internal tools and metrics. In addition, it allowed our product managers to have granular control over the product and its deployment, and to decide how and when they wanted to present it to the customer instead of having to depend on engineering. Of course, we’ve added granular control flags in both unit-tests and E2E automation in order to ensure the system is working in all kinds of variations.

I suggest this strategy to any early stage startup wanting to move fast while maintaining high quality.

Invest in onboarding as much as your code

As we planned on continuously onboarding engineers, we made sure everything was well documented so a clear plan was presented to each engineer as they joined. Of course, like most companies, we assigned each new engineer a ‘buddy’ to guide them along the onboarding process. Our initial goal with onboarding was to have an engineer fully ramped up with all of our tech and be ready to insert code into the product by the time onboarding was finished. The engineer received a clear checklist of what needed to be done and what exercises were to be completed. There would be planned checkpoints between each technology, that included a sync with his/her assigned buddy where they’d show what they worked on. In addition, the engineer would add a module that improved the life of the day-to-day work of the developers, followed by a “kudos” shared with the whole company from his/her buddy to celebrate what the new team member achieved in such a short time. 

What’s important to understand is that onboarding is not a static, one-time, “check the box” creation. It’s an ongoing process.

Every new employee joining the Island team improves and fixes the onboarding flow as we go, in case something is wrong or no longer relevant. In addition, we do a retrospective with the engineer and his/her buddy, and see what other items we need to add to the onboarding. For example, our onboarding originally focused only on technology. But over time, we added architecture sessions, product functionality overview, automation and other areas.

Create visibility into your production environment via monitoring & alerting

Finally, you can’t keep the flow without visibility and alerting. We added logs everywhere and set up alerts to dedicated slack channels on every error. We assigned a “developer on duty” to continuously investigate bugs and improve our monitoring infrastructure. We added dashboards to ensure quality as well as user experience, which measured latency of calls, time of browser events as well as error rate and uptime of production cloud services, all alerting into Jira.

Summary

It’s important to make a conscious effort to recognize when your organization is in scale mode. Every tiny decision is important, even the small stuff like how you organize a specific file in the development environment file system or taking the time for a regular retro with new employees. 

Find a way to create an environment where quality is top priority but does not cause fear of deploying and merging. Enable the tools your engineers need to deploy their code comfortably while putting strict methods in place for having granular control over what is deployed and when, as well as ensuring overall quality. In addition, engaging product leadership to understand those decisions will create a healthy work environment while enabling the speed and velocity you need for early stage start-ups aiming to grow fast.

Solving Critical SaaS Vulnerability with an Enterprise Browser

Solving Critical SaaS Vulnerability with an Enterprise Browser

April 26, 2022
Jason Trunk
Read Article

SaaS and corporate web apps present challenges to the enterprise many have not considered. The process of signing up and migrating critical business operations to the cloud is fast, easy and can add remarkable value, but comes with a tradeoff that’s not always obvious. These apps can increase an organization’s vulnerability to cybersecurity risk. Due to the nature of the web and traditional web clients (browsers), there is simply not an adequate level of data protection or governance.

Given the massive adoption of SaaS and web apps, this presents an urgent problem. Organizations are operating with thousands of apps, sanctioned and unsanctioned, and often have thousands of employees across myriad departments with their own needs. The need to create constant exceptions to give workers what they require creates massive complexity, along with equally massive risk.

In other words, the present situation is a colossal headache for IT departments.

Here’s the good news: we’ve solved this problem by creating an innovative new product category: the world’s first Enterprise Browser.

A Simple, Elegant Solution for Data Protection and Governance

The web browser is now an integral part of the business technology landscape. Yet they were never meant to be enterprise tools. Conventional browsers may work beautifully, but they are a consumer product at core.

Pressing a consumer-grade tool into enterprise service comes with a slew of security complications. You can’t see how users interact with data within a browser. They can print screens, copy and paste data, take screen snapshots–a full range of potentially compromising actions for which organizations had minimal visibility.

There have been attempts to address this problem by bolting on tools such as web gateways and Cloud Access Security Brokers (CASBs). These approaches have always failed because these tools are cumbersome and do not offer fine-grained control, creating an ongoing governance mess.

These failures led us to pose a fundamental question: what if we approached this problem of control and governance directly in the browser?

Marrying Enterprise-Grade Security with Consumer-Grade Usability and Performance


Role-Based Access Controls (RBAC) associated with some apps provide a level of control, but they can’t do the one thing that enables effective governance: assert control over the right app, at the right time, for the right user.

An Enterprise Browser can do this by checking device posture during user logins to ensure trusted devices are being used to access critical SaaS apps. An Enterprise Browser allows you to create policies to block things like screen printing, cut & paste into non-approved destinations, or sharing information over web conferencing.

Additionally, you can use an Enterprise Browser to redact sensitive data types within applications via browser-based Robotic Process Automation (RPA) or enable deep audit logging to see every action a user has taken. An Enterprise Browser can also encrypt cookies to protect app sessions from intrusion, scan for malware, or create policies governing data storage and enhance privacy.

This gives you everything you need to make data protection and governance headaches a thing of the past.

While SaaS and Web apps have seen extraordinary adoption and delivered numerous benefits, cyber-risk and unstructured governance have hitched along for the ride. Creation of the enterprise browser is the breakthrough that IT departments urgently need to solve this long standing problem.

For a more in depth article on protecting critical SaaS and web apps using an enterprise browser, click here.

 Navigating the Challenges of Contractor and Third-Party Access

Navigating the Challenges of Contractor and Third-Party Access

April 11, 2022
Bradon Rogers
Read Article

It’s been impossible to miss the recent cybersecurity incidents involving contractors and third-party access to organizational resources. While these headlines are hardly new, their impact is now exponentially more serious given the major shift to hybrid work, paired with mixed cloud and on-premises hybrid architectures.

Contractors and third parties often serve as the functional backbone of many operations. In some cases, they are individuals performing a specific function. In others, it’s a third-party organization performing an entire function like logistics management or HR. To ensure at least a basic level of security, organizations typically ask them to legally attest to their understanding of their responsibilities toward protecting the critical resources they are given access to. This may also involve rigorous inspection of the contractor’s controls and resources. But given the urgency of many contractors’ work, these inspections are often treated  as a mere “checkbox.” Regardless of the need for speed or not, it’s a given that onboarding contractors and third parties is slow, expensive and cumbersome. Here’s why.

Third parties need to be granted access to an organization’s critical systems just to do their jobs, which organizations typically do using one of these two approaches;. 

  1. They allow third parties to use their own devices 
  2. They ship a company-owned device that the contractor or third party must use to access these systems and fulfill their duties

Both approaches involve different complexities and levels of risk that cause unnecessary pain on both sides. Let’s take a closer look:

Unmanaged Contractor and Third-Party Devices

As uncovered in recent news stories, third parties very often use their own devices. The advantages of this approach are fairly obvious. Allowing these resources to use personal devices saves time, reduces onboarding costs and allows the third-party’s resources to operate in a familiar environment, which significantly speeds up productivity.

But this approach has its downsides as well. It requires giving individuals account credentials to the systems (VPNs, Virtual Desktops, and actual applications) they need to perform their roles. Onboarding this kind of access is complex, costly, and requires ongoing attention to manage provisioning and revoking access and credentials. 

Managed Devices for Contractors or Third-Party Access

On the other hand, many organizations opt to ship a company-owned, managed and pre-configured device to the contractor or third party. The upfront cost and effort involved in buying, building, and shipping these devices at scale is immense.  Not to mention the timing - it can take a month or longer to get a single contractor up and running. It also creates a steep learning curve on the third-party’s side to integrate new devices and systems into their workflow. While ultimately this may be the less risky approach, the significant tradeoffs feel unacceptable to both the organization and the third party.

The Ongoing Effort

In both of the above scenarios, provisioning alone is a serious organizational challenge. And yet, it’s only the beginning. Ongoing governance is also necessary to ensure contractor and third-party access is limited to only the sources and systems necessary to perform the responsibilities they were hired to carry out. This requires uncomfortable architectural choices to be made to balance the often opposing forces of efficiency and risk. On a practical level, these considerations include whether to use VPN backhaul, cloud forward/reverse proxy implementations, virtual desktops, CASB, DLP, Web Gateways, or ZTNA technologies to govern third-parties safely. Unfortunately, these decisions cause complexity and costs to explode, leaving the organization vulnerable to the contractor or third-party risk.  This was made quite evident in recent headlines where the level of complexity for offshore third-party access was undoubtedly one of the core issues.

The Enterprise Browser: An Ideal Way to  Onboard and Oversee Contractors

We’ve always been forced to choose between security and complexity or speed and efficiency. This is what we challenged ourselves with. A way to ensure security while enabling work. Maximum efficiency, minimum risk. And out of this challenge came the industry’s first browser built for the enterprise. Imagine, instead of all the organizational challenges, all the workers’ frustrations, all the costs and complexities, contractors or third parties just logged into a browser that had all the resources they needed waiting for them. This is what the Enterprise Browser can do for work. 

Let’s start with provisioning. For third-party organizations or contractors using their own devices, you provide a download link for the Island installer. Once the browser is installed (it takes less than a minute), you give them credentials and access privileges aligned with their role, and in seconds they begin working. The applications they need are immediately made available with no complex configurations or additional software required. And for organizations choosing to provide their own managed devices to contractors or third parties, simply include the Island Enterprise Browser in your device build, and the process is exactly the same as above.

Once the user is working on the Island Enterprise Browser, your organization’s applications and associated data are fundamentally protected. Island’s unique last mile controls allow you to easily create policies to govern application and data access. And further, it allows you to control who has privileges to add new users, who is authorized to change or copy data, and whether or not a user can download, screenshot or save content.  

You also get extraordinary visibility in a way that simply wasn’t possible before; deep forensic audit logging to keep a close watch on what these resources are doing as they do their jobs. You can even output these activities in real-time to data aggregation environments such as SIEM to monitor user behaviors and actions to quickly discover unwanted activities. Island sheds light on a unique dimension of user-based data by keeping tabs on the contractor or third-party’s actions within the browser window. 

As seen in recent news stories, the inability to govern contractor or third-party usage of key application areas was  what allowed attackers to manipulate backend application areas that very well could have been out of the scope of the third-party’s work in the first place. Last-mile control and deep logging could have been the difference between identifying and preventing any sort of compromise and hunting down and remediating the problem once the damage is done. 

And while it’s essential to govern the actual contractors or third parties as they engage in critical application areas, it is equally necessary to ensure that they are protected from outsiders who might leverage them as a vulnerable attack vector in the organization. Island ensures that the browser is safeguarding the entire journey on all sides, at all times. Island delivers several key capabilities to ensure that attackers are thwarted in their attempts to use the contractor or third party as a vector of compromise.  These capabilities include:

  • Man-in-the-Middle Protection
  • Anti-tampering Protection
  • Browser Isolation
  • Malware InspectionDocument Isolation and Disarmament
  • Malicious and Unknown Site Categorization

These built-in capabilities ensure that the organization’s applications and the contractor or third party are always protected from attack as they perform their work.

The Bottom Line. 

Third-party contractors and resources are pervasive and the practice is growing exponentially as the gig economy and the need for hyper specialized project work expands. Companies are purposefully building this practice into their business models, making these services very often mission critical to operations. But recent compromises using this vulnerable channel threaten to either reduce the practice entirely or forcefully add more cost, complexity and inefficiency into the process.  

It is time to consider a whole new way to approach contractors and third-party access.  We need to be able to get people to work quickly, and allow the organizations and people on both sides of the equation to be confident that both the applications, data and users are protected. With Island’s Enterprise Browser at the core of these use-cases, you can safely and quickly get people to work, create a great user experience and be confident your data and applications are protected. 

Frost & Sullivan Thinks an Enterprise Browser is Critical for SaaS

Frost & Sullivan Thinks an Enterprise Browser is Critical for SaaS

March 29, 2022
Bradon Rogers
Read Article

When was the last time you thought about your web browser?

The truth is that today's browsers are so powerful, refined and simple-to-use that we essentially take them for granted. Most people use the browser for personal/consumer use and the same exact thing to access their work environment.

A new report from leading analyst firm Frost & Sullivan highlights the challenges of using a consumer browser for business and points out the features and functions a true enterprise browser must offer.  You can download it here.  

I think the report sums it up best with this statement: 

“An enterprise browser with a different approach, which delivers functions with the enterprise in mind, is needed. With the proper control, the browser is able to solve serious problems more easily. Its position is a very unique intersection of users, critical web applications, the underlying data, and the threat landscape.”

Here’s a quick summary of the report.  

Consumer-Grade Technology Can't Provide Enterprise-Grade Security

Consumer-centric design hasn't stopped web browsers from playing a critical role in the business technology ecosystem. Yet it has created a very significant (and often underappreciated) problem: Conventional browsers don't have the visibility, control and manageability required for corporate SaaS and web-based applications.

In other words, reliance on conventional browsers means the assumption of significant and sustained cyber-risk.

Fortunately, there is good news: A new category of browser now exists -- one that pairs the speed and flexibility of a consumer browser with the security of an enterprise-grade product.

Meet the Enterprise Browser.

Why CISO's Need a New Browser Approach

Today, the browser has become the new office. Employees spend much of their workday accessing data and applications through browsers. This greatly accelerated during the COVID-19 pandemic, which sparked an explosion of telecommuting activity.

Massive adoption of work-from-home and bring-your-own-device scenarios, however, means that IT departments now have even less visibility into user behavior and how people and data are interacting.

For CISOs, the security concerns that come with vastly expanded work-from-home opportunities simply add another layer of stress and pressure.

Other key issues include:

  • Addressing growing complexity (which is often exacerbated by deployed security solutions)
  • Dealing with a shortage of skilled staff
  • Navigating evolving regulations, privacy and compliance mandates

That's a tall order. Fortunately, it's now possible, for the first time, to address these challenges at the browser level.

A New Breed of Browser

A browser rests at the intersection of organizational users, critical applications and underlying data. They are deeply embedded in almost all organizational activity.

Yet enterprises have not been able to exert flexible control over what happens when employees use these browsers. Consumer-grade browsers simply do not offer tools to implement security policies. As a result, they leak data. They are vulnerable to screen grabs or printouts, downloads, copying and pasting into personal apps or even smartphone snaps.

Enterprises understand this and have historically attempted to mitigate these risks with multiple security and management tools. Plus, they are forced to do things like banning the use of personal email accounts or other applications. Yet these measures are not truly effective, and they alienate employees.

Enter the Enterprise Browser -- an innovative new product category.

An Enterprise Browser mitigates cyber-risk by assessing the posture of the device on which it is installed. It then dictates the appropriate policy depending on the device type of the logged-in user. This means organizations can manage access regardless of device, user or location.

In essence, an Enterprise Browser gives CISOs infinite control over how users and information interact.

Fine-grained controls aren't the only benefit offered by an enterprise browser. They can also audit user behavior, giving enterprises visibility if unauthorized screen grabs or data copying occurs. This level of visibility into browser-level user and data interaction has never existed before. And what’s more, is that organizations can enforce the use of an Enterprise Browser for certain applications, while allowing standard consumer browsing for personal use or access to non-risky applications or destinations. And for the final kicker, since it is based on the open source Chromium browser, the basis of the majority of browsers in use today, the Enterprise Browser delivers the same experience to users, lowering resistance to adoption significantly.

Bottom Line

Conventional browsers are powerfully elegant pieces of software. Yet they are poorly suited for the integral role they are being asked to play within the business technology ecosystem.

Introducing enterprise-grade security at the browser level with an Enterprise Browser is one of the most impactful things CISOs can do today to simplify their entire security architecture and mitigate some of the most urgent cyber-risks they face.

Get the Frost & Sullivan report by clicking here.  

Enterprise Strategy Group highlights Island Enterprise Browser

Enterprise Strategy Group highlights Island Enterprise Browser

February 1, 2022
Bradon Rogers
Read Article

As organizations turn towards SaaS cloud-based applications to help them grow, there is an increasing need for access control and sensitive data control measures to be taken. However, internal security teams have many different complications to work through in order to maintain compliance and protect sensitive data across enterprise-level organizations.

Third-party SaaS applications are increasingly important for businesses, as they help manage key operations, improve employee collaboration, and help new initiatives start quickly. While these applications provide many benefits to organizations, they also make security management difficult as there are limitations to access controls for internal IT, risk, and security teams.

Adding even more complication to the problem is the increased reliance on non-corporate-owned devices and personal devices. This goes hand-in-hand with the growing hybrid workforce, making it even more difficult to maintain compliance and security standards across an organization. New strategies are needed in order to address these problems.

The Challenges of IT, Security, and Compliance Teams

There’s no question that third-party SaaS applications help businesses grow, compete with competition more effectively, and cover gaps within the workforce. However, they do add challenges to IT, security, and compliance or risk teams' ability to:

  • Implement fine-grained user-access privileges
  • Prevent sensitive data leakage from personal and non-corporate devices
  • Audit access and user functions and sensitive data access
  • Leverage network security controls and strong encryption protocols

IT, security, and risk teams struggle to manage the staggering amount of third-party SaaS and internal web applications that organizations are adding to their workplace. SaaS applications are often designed for the most common use cases, making specific access and compliance controls difficult to manage and security hard to maintain across departments and at-home or hybrid employee offices.

Identifying the Need for an Enterprise Browser

Most organizations use consumer browsers like Chrome or Edge to engage with SaaS and web-based applications. However, these browsers were not built with governance in mind and offer no controls over what a user can do inside an application, including printing, taking screenshots, or downloading content.

Clearly, a new approach is needed in order to provide security to modern businesses with cloud-based SaaS applications, hybrid work environments, and non-corporate devices. ESG has identified a new, disruptive approach to securing and managing user and data access—an enterprise browser.

What is the Island Enterprise Browser?

Island is a security-enabled and compliance-focused web browser. It uses the same capabilities and user experience that you would find in Chrome or Edge, but ensures that organizations have control over how users interact with information and provides core security controls for IT, risk, compliance, and security teams.

Island enterprise browser provides:

  • Sensitive data protection
  • Safe browsing
  • Device posture assessment
  • Forensics and audit capabilities
  • Multi-tenancy control
  • Centralized management
  • Browser-based robotic process automation

To learn more about the need for an enterprise browser and the capabilities that are provided by Island, read the whitepaper from ESG and discover the bigger truth about modern security and governance in enterprise-level organizations. Click here to see the report.


Why “The Last Mile” is the Most Critical Terrain in Cybersecurity

Why “The Last Mile” is the Most Critical Terrain in Cybersecurity

February 1, 2022
Brian Kenyon
Read Article

Cloud growth continues to be nothing short of astonishing: Gartner estimates 95% of new digital workloads will be deployed on cloud-native platforms by 2025, up from just 30% in 2021.

Yet this race to adopt cloud technology has left security teams with an extremely challenging mandate: They need to keep critical assets safe in a world where remote work, BYOD and virtual desktop use are all exploding.

Fortunately, they have no shortage of options. Security concepts such as Zero Trust, and the usual range of data loss prevention, identity management and cloud access security tools, provide a framework for risk management.

However, one urgent risk remains underappreciated: No matter how many security tools you wield, you’re still deeply vulnerable if you continue to use conventional web browsers.

Why the Consumer-Focused Web Browser Creates Massive Enterprise Risk

Web browsers have become an essential cog in the wheel of business technology. Many of the productivity applications and SaaS platforms that organizations use today are highly dependent on browsers.

The truth, however, is that they are not truly intended to be used as such. Because they were designed for advertising, tracking and search optimization, they offer minimal control over “the last mile” – the space where users interact with data and applications within the browser.

This means that a user can compromise security through printouts, screen grabs, copying-and-pasting text or even taking a photograph of the screen – and an organization may never realize it because conventional browsers also offer no visibility into how users have acted in the past.

That absence of control is a huge problem – one that organizations have often attempted to address by placing severe restrictions on how workers can use applications or devices. Unfortunately, this is not only ineffective, but it also constrains how businesses operate, and alienates workers.

Fortunately, there is a simple change you can make to avoid this risk: Start managing “the last mile” via an enterprise browser.

Last Mile Control and the Enterprise Browser

Consumer-grade browsers gush data because they don’t allow you to implement security policies. An enterprise-grade browser solves this long standing problem by offering a centralized management console for policy enforcement to govern activities such as downloading, saving, cutting-and-pasting or screen grabs within critical apps.

This gives organizations the ability to give workers much more latitude in terms of how they interact with applications and data.

That’s not the only benefit:

  • An enterprise browser extends the practice of role-based access to provide a governance layer in areas that have always been inaccessible.
  • This means it closes a cyber-risk blind spot, vastly strengthening your security posture.
  • An enterprise browser is highly scalable and delivers exceptional ROI.
  • It also significantly reduces resource use.

Ultimately, by merging the speed and seamless UX of a consumer-grade browser with last mile controls, the enterprise browser represents an urgently needed innovation – and one of the most exciting new product categories in years.

Read a more in depth editorial brief on this topic by Brian Kenyon, Chief Strategy Officer at Island, by clicking the title: Enterprise Browser Management – The Last Mile Challenge.

The next chapter of enterprise work. Introducing The Enterprise Browser.

The next chapter of enterprise work. Introducing The Enterprise Browser.

February 1, 2022
Mike Fey
Dan Amiga
Read Article

We began our journey in enterprise security with a single goal in mind: to build a truly secure-by-design environment. Where work could thrive because security is naturally woven into the enterprise.

So we teamed up with some amazing people. Built anti-malware, DLP, proxies, CASB, firewalls, and many other enterprise security products that became industry standards. Even invented brand new technologies like browser isolation that carved a new path towards a safer enterprise. We were fortunate to build products that truly mattered.

But as the enterprise evolved in ways we couldn’t even imagine, the industry’s approach to securing it stayed more or less the same. An upgrade here. A plus-one there. These improvements were effective. But that’s exactly it - they were merely improvements - on an ecosystem designed years ago for a very different world.

Today, the most precious parts of most organizations live in the cloud. Our employees work in offices, coffee shops, living rooms, and beach chairs. And they use whatever device they want. Let’s face it - even the best versions of yesterday’s security tools weren’t meant to handle the size and scale of today’s modern enterprise. And as long as we were playing by the old rules, that vision of a secure-by-design work environment couldn’t become reality.

The teams we were privileged to lead solved some of the biggest challenges in our industry. Yet, the narrative hadn't changed. And it was becoming painfully obvious why. The one place where basically all our work takes place - where our users, apps, and all underlying data meet - that place was still fundamentally not in our control.

The browser.

The browser is the one application enterprises use more than any other on planet earth. By far. And yet, ironically, the browser isn’t even an enterprise application. It was built for consumers and advertisers. Optimized for content distribution and consumption. Organizations and employees? They were never part of the picture.  

But we knew this already, and we chose the consumer browser for work anyway. Its value to the enterprise was so immense that we ignored the fact that it was built for consumers. We embraced it for its amazing speed, rendering power, universal compatibility, and near flawless user experience. And we learned to live with the tradeoffs - the lack of control, visibility, governance, or privacy - the core elements of a safe work environment.

We accepted this as reality.

A reality where the centerpiece of our workplace wasn’t designed for work. Which meant the one place nearly all our critical data lived was the very place we couldn’t protect or even see.
And this reality forced us to treat our browser like a caged animal - surrounding with an endless stack of heavy, expensive, and inefficient tools just to keep it from working against us.

It’s not the browser’s fault. It just wasn’t designed for the enterprise.

Well, what if it was?

It was such a simple question. One that deep down we’ve all wanted to ask. What if there was a browser specifically designed for the enterprise? A browser that put the organization in complete control over how its users, apps, and data interact? A browser that let the enterprise in instead of shutting it out? A browser that integrated into your infrastructure instead of fighting against it?

And suddenly it hit us - That was it. The goal we’ve been working towards our entire careers, right before our eyes.

The ideal enterprise workplace. Security, visibility, and governance built right into the work experience, without getting in the way of work itself.

That vision of secure by design - finally realized.

Why hadn’t it been done before?

It seemed almost too obvious. Why hadn’t someone built this yet?

Three stars needed to align for the enterprise browser to seem like a viable idea.

  1. The SaaS revolution. As work migrated to SaaS, work categorically shifted away from desktop services and towards the web-first experience. Critical apps were now available anywhere all the time, making the browser the center of enterprise work.
  2. The Chromium effect. When the Chromium open source browser project was introduced - all major browsers suddenly became standardized. All fueled by the same technology, all providing the same powerful, yet enjoyable user experience. Which made it possible to build the core needs of the enterprise into the browser, while retaining the consumer-grade experience users have come to expect.
  3. The rise of the endpoint. With widespread adoption of the remote workforce, the shift to SaaS and cloud services, and the explosion of network encryption, the endpoint suddenly became the best place to anchor our security operation. This new work reality not only brought about a greater need to secure the endpoint, but it created a major opportunity to leverage the endpoint to secure our critical data right where it was being accessed and used.

All the pieces were finally in place. The only thing left was to build it. So we did.

And we call it Island. The Enterprise Browser.

The Enterprise Browser fully integrates the browser into the organization, providing complete control and visibility over everywhere work happens. All while delivering the same smooth, powerful, nearly flawless experience users have come to expect. It’s work as it should be -  fluid, yet fundamentally secure.

And with it, the possibilities are endless. SaaS and internal web apps truly live anywhere without leaking data everywhere. Contractors and BYOD workers work freely while organizations keep the data they access fully secure. Consumer or risky apps can be safely introduced into the enterprise without compromising security posture. Users are naturally protected from the inherent dangers of the web. And this is all just the beginning.

For years we had one goal - to design the place where work naturally belongs.

Island is that place.

Welcome to the next chapter of enterprise work.

Press Release: First Enterprise Browser Improves Enterprise Security

Press Release: First Enterprise Browser Improves Enterprise Security

February 1, 2022
Read Article

Backed by Insight Partners, Sequoia Capital, Cyberstarts and Stripes, Island delivers a familiar Chromium-based browser experience with built-in critical security control and governance for corporate applications and data

DALLAS and TEL AVIV – Feb. 1, 2022 – Today Island unveiled a new category of enterprise software that revolutionizes security control, visibility and governance with the introduction of the world’s first Enterprise Browser. After almost two years of product development, the company emerged today from stealth mode to introduce the Enterprise Browser, eliminating the massive gaps between current consumer-focused browsers and the increasingly complex IT and security requirements of enterprises worldwide. With core needs of the enterprise naturally embedded within the browser itself, Island is the first browser to provide end-users with the same Chromium-based experience they expect, while giving the enterprise much needed functionality to vastly improve corporate security and employee productivity.

Headquartered in Dallas with research and development in Tel Aviv, Island is led by co-founder and CEO Mike Fey, previously president and COO at Symantec and GM and CTO of McAfee; and co-founder and CTO Dan Amiga, inventor of web isolation technology and previously founder and CTO of Fireglass. Island emerges from stealth with a complete senior management and technical team bringing decades of experience in enterprise security from both successfully established cybersecurity firms and start-ups, as well as deep domain expertise in Chromium research and development.

To date, the company has secured almost $100 million in financing from leading early-stage investors including Insight Partners, Sequoia Capital, Cyberstarts and Stripes and has hired over 100 employees.

“For decades, organizations have globally utilized consumer browsers in the corporate computing environment,” said Mike Fey, co-founder and CEO, Island “These organizations require strong control and governance, which consumer browsers were never built to deliver. Island uniquely provides manageability, control, security and enhanced productivity features from within the browser itself, while users enjoy a familiar browsing experience. We envision the Enterprise Browser fundamentally improving not just security, but enterprise work itself.”

“SaaS has fundamentally changed how IT teams are providing value added services to their companies and the industry is ripe for a new way of thinking about how we secure that value,” said Bob Schuetter, CISO at Ashland Global Holdings, Inc. “A browser built for the enterprise can fundamentally change the industry, empowering us to reimagine how we approach our use cases with tremendous power yet elegant simplicity.”

Product Features, Capabilities and Use Cases

The Enterprise Browser enables organizations to deeply govern how users interact with all SaaS and internal web applications. Through the use of the Island Enterprise Browser, security teams can fully control last-mile actions from advanced security demands to more basic data exfiltration protections such as copy, paste, download, upload, screenshots and other activities that might expose critical data. This opens up unprecedented opportunities across a growing number of enterprise use cases, including securing critical SaaS and internal web applications from data leakage, safe access for contractors and BYOD workers, and full governance over privileged user accounts. It can also reduce VDI dependency while also supporting built-in safe browsing, web filtering, web isolation, exploit prevention, smart network routing, and Zero Trust access.

“The browser is the office where today’s hybrid workforce lives,” said Dan Amiga, co-founder and CTO, Island, “We have engineered the Enterprise Browser to be the platform for the future of their work. It begins by redefining how an organization secures its work but will positively impact endless needs across information technology.”

“It’s rare that you see a security technology with the potential to reimagine the industry the way Island’s Enterprise Browser does,” said Jeff Horing, Insight Partners co-founder and managing director. “Island has all the attributes we look for in a successful venture – an experienced management team, a brilliant idea and a large market disruption capability.”

Market Demand Intensifying

Island released and deployed its GA product beginning in September 2021 to some of the world’s most recognizable brands across a range of industries, including several in the Fortune 500.

“When we first saw Island’s design, we immediately recognized the revolutionary impact it could have on securing the workplace,” said Doug Leone, Sequoia global managing partner. “By delivering on the long-standing goal of security by design, we see it as a disruptive solution within the security industry.”

“Our focus at Cyberstarts is to invest in important ideas and people that will change the cybersecurity industry,” said Gili Raanan, Cyberstarts founder and Sequoia general partner. “Island’s Enterprise Browser has the potential to positively impact every part of the space.”

About Island

Island, the Enterprise Browser is the ideal enterprise workplace, where work flows freely while remaining fundamentally secure. With the core needs of the enterprise naturally embedded in the browser itself, Island gives organizations complete control, visibility, and governance over the last mile, while delivering the same smooth Chromium-based browser experience users expect. Led by experienced leaders of the enterprise security and browser technology space and backed by leading venture funds -- Insight Partners, Sequoia Capital, Cyberstarts and Stripes -- Island is redefining the future of work for some of the largest, most respected enterprises in the world. Island is based in Dallas with research and development in Tel Aviv, and can be reached at info@island.io or (866) 832 7114.

For more information contact:

Hannah Carroll/Tim Hurley
Matter Communications for Island
island@matternow.com

The use cases

Fully govern how contractors interact with your data by setting highly specific policies around which apps and data they access and what they can do with them.