Esper Deep Cuts: The Birth of the Unbreakable Browser

At Esper, we specialize in building a platform and offering management tools for dedicated device solutions. But in this complex environment, our customers run into complex issues that require “above and beyond” expertise to get to the root causes and ultimately solve the problems in a commercially viable way. As an infrastructure provider for dedicated and fully managed solutions on both Android and iOS, we go much deeper than typical MDM vendors. 

This is the third blog in our Deep Cuts series of posts that provide case studies of actual situations we’ve encountered and solved for our customers. Names have been removed to protect the innocent (and, in some cases, the not-so-innocent).

Deep Cut #3: The Creation of a Hardened Browser Meeting a Tough Use Case - Titanium!

Esper was working with a customer that provides an end-to-end solution underpinned by learning journeys combined with media content consumption and communications in a highly secure environment. A solution lynchpin was delivery of content and experiences via a web browser in a multi-user situation with a potentially shared device.

The standard Android GMS build was inappropriate for their use case as deployments in the secure environment required an Android OS build that was locked down well beyond what they could do on a standard GMS device — even one managed by Esper. The customer was able to achieve that using Esper Foundation for Android running as a generic system image (GSI).

Driven by their browser-centric solution, of course the browser was absolutely key. On AOSP, Google provides Chromium which is the core library on which sophisticated browsers can be built. But it in itself is not a browser and was still missing capabilities the customer required.

Additionally, AOSP provides Webview, which is an Android system component built on Chromium to make it easy for other Android apps to render web content in situ without having to go to an external browser. Sounds pretty good for the use case! However, it was clear from the start to our customer that Webview’s capabilities were even more lacking than what was exposed by Chromium, which makes sense as by definition Webview delivers a small subset of Chromium capabilities for a very scoped use case.

Beyond just capabilities, keeping the browser implementation secure was extremely important to this customer. Browser technology is one of the most frequently patched software systems out there. Using Chromium as an example, a new stable version comes out about every month. But looking at release 127, before a month after release there were 4 updates to 127 delivered for Chromium. While Chrome does their best to take care of this on Android GMS via Google Play, the Chromium updater service was insufficient for the customer.

Chrome might seem like a viable option, but its consumer-focused nature makes it incredibly challenging  to keep in a locked-down state. A maintained managed configuration is required for Chrome to specify which websites to block or allow. “Do Not Track” and “Network Isolation” features are not the default for Chrome, requiring a feature flag to be set. Ensuring that all keyboard shortcuts are hidden and disabled on Chrome can be troublesome. “DisableLongPressMenu” is an atomic feature on Chrome set by managed configuration, and this customer wanted fidelity to be able to selectively make this available for their use case. Silent permissions for selected audio and video capture were deprecated on Chrome for Android — a capability our customer really needed. Finally, it is possible that tab persistence in Chrome could result in a situation where a different user encountered the open tabs from the previous user, which was unacceptable for this customer.

What is a customer to do? Work with Esper and see if we could come up with something together.

Requirements Gathering and Prioritization

The customer did their leg work and scanned the set of available Browser options.  Ultimately, they were unable to find one that sufficiently met their needs. So we sat down with them through a set of virtual sessions and defined their key requirements:

• Implement service to send all website usage history (including attempts to access blocked sites) to Esper’s reporting service, which was then ingested by the customer.
• Disable fetching of popular sites, autofill by default, saving passwords to the Cloud, and Cloud printing.
• Remove lite mode (previously known as data saver), disabling prefetch, and removing the capability to subscribe to RSS feeds.
• Disable the uploading of logs to preserve user privacy.
• Disable key exchange features.
• Have a means to update the browser at scale with full control, independent of the Chromium updater service (e.g. remove it).
• Remove the default first run promo and Google account sign in.
• Disable the media router communication capability, WebRTC address and log policies, intranet detection, Google time tracker, and disable media pre-provisioning.
• Properly enable media capabilities like DRM and WebRTC, including an optimization of the AV1 codec for Web RTC.
• Force “Do Not Track” to be always on.
• Use JSON with wildcards to specify allowed and blocked websites enabling a code-driven approach, but block all traffic if any aspect of the JSON code block is incorrectly implemented.
• Modify the new tab page to remove remote suggestions and the display of metrics.
• Cosmetic and branding — extensive branding changes needed to be made across the browser implementation including the logo, package icon, package name, and new tab page tiles. This required a lot of heavy code modification  to accomplish. 

The above is an incomplete list, but just enough to give you the flavor. The overall browser experience needed to be optimized for a 10” tablet form factor running a minimum of Android 10. All classical navigation means expected in a browser needed to be supported.

Furthermore, the customer needed the browser codebase to track and then address any critical vulnerabilities patched in Chromium. These changes would then be built and delivered as updates to the deployed devices, with a corresponding update service accomplished using Esper’s existing Foundation OTA service supplemented by our app management system for complete control by the customer. In other words, they wanted to make sure the browser was always up to date and secure from known vulnerabilities.

Building the Browser

Ultimately, this led to the creation of what we proudly call the Esper Titanium browser!

A big part of this was the block-and-tackle of taking the Chromium code base and doing the work needed to meet the very particular requirements from this customer. This was accomplished across multiple sprints, with interim drops to the customer for validation and feedback.

But there was also the infrastructure and ongoing processes components — this was not a one-and-done build. The browser needs to be maintained against the ongoing updates delivered via the Chromium project, but done in a way that meets the deployment and overhead constraints the customer faces with their customers. Nuance needed to be built for optimal update windows,  as oftentimes these devices were deployed in poor Internet environments.

Luckily, we already had a similar infrastructure and set of processes in place — building updates for Esper Foundation for Android by tracking the Android CVEs and then distributing them via our OTA infrastructure for Foundation. This means it’s also an avenue to update Titanium since we included it in ROM. Since Titanium is an Android app, we brought Esper’s precise app management infrastructure into the solution. This gave the customer the flexibility to rely on system updates to be the primary means to maintain Titanium since they could perform everything in one operation and reduce the tax on the oftentimes constrained Internet infrastructure their customers use. It also gave them the flexibility to update Titanium as a standalone when the situation called for it.

It took some work to complete this adaptation specific to Titanium. We worked with the customer to get this done and stay on track with Chromium updates to pick up appropriate patches to then drop into the Titanium build. This allows us to quickly build updates for delivery and installation to the devices in the field.

As with the delivery of any complex piece of software, we had some hiccups. But we were able to effectively work with the customer to quickly resolve issues that cropped up in the field and enabled them to stage their rollout and switchover to their customer base.

Since then, we’ve been in a rhythm with the customer to work with them on new features and capabilities needed in Titanium, and negotiating with them to get them added in a way that works for both companies.

Where We Are Today

With Titanium, Esper offers a Chromium-based browser design with security and remote management built-in - it meets the needs of a dedicated device fleet operator. Titanium is available for license to any of our Esper customers. Which also means that today more than just this customer is using Titanium.

Titanium’s features include:

• WebRTC optimizations
• Configurable main menu (can be hidden or shown)
• Configurable long press main menu on websites (can be hidden or shown)
• Configurable URL Bar (can be hidden or shown)
• AV1 Codec Support
• Media processing enhancements for ARM devices
• Network Isolation Security Feature
• Explicit provisionable browser (doesn't work until someone provisions it using managed config)
• Telemetry Support (including delivering full browsing history and whether it was allowed or not)
• Cleanup after browsing session
• Non-persistable tabs on restart
• Removed UI elements that reference external websites
• Default homepage and new tab page is blank to remove any company branding
• Restricted text select menu.
• And more…

Since it is an Android app, it can be installed and maintained using Esper’s sophisticated app management infrastructure. For Foundation customers, the additional option is there to be able to include updating Titanium as part of the regular system update cycle. Choices can be good!

Titanium is included in our Architect device management SKU and is available a la carte for customers who are using our Bridge SKU.

Conclusion

The needs for companies deploying dedicated devices in highly secure environments go beyond what you typically see in an Android GMS with Chrome-based deployment. While there are third-party browsers available, none of them met the bar for this particular customer.

So Esper stepped up and created Titanium, giving this customer (and others) the best of both worlds. A Chromium-based browser benefiting from the security coverage provided by the Chromium community combined with the features and capabilities needed for this type of deployment.

Titanium is also available to you for your dedicated device use case. If you are interested in finding out more, please contact Esper.