Blog

Let’s Talk About CEF (Some More)

The CEF post generated a lot of controversy, and rather than replying directly in the comments (and doing a bunch of copy & paste), I thought I’d collect my responses to the major objections here.

Objection: Nobody wants to browse the web in X-Plane!

Yes and no. I agree that, unless you’re in VR, a full-fledged web browser is totally useless. Nobody wants to be browsing cat pictures while flying. But CEF is really not designed to power a traditional web browser.

Consider this list of a bunch of other applications that nobody wants a web browser in:

• Spotify
• Adobe Acrobat
• Evernote
• The Steam client
• The Atom text editor
• The GitHub desktop client
• WhatsApp

What do all those applications have in common? They’re built on CEF, or the closely related Electron project.

My point is this: the primary use case for CEF is not to build a full-fledged browser—it’s to support things like HTML5 user interfaces, which massively lower the bar for creating nice, easy-to-use plugins. It could also support things like displaying PDF charts or other electronic flight bag features—things that are theoretically possible without a webview, but which have such a high barrier to entry that nobody wants to tackle them.

We are always looking for ways to both

• get more people involved in creating X-Plane add-ons, and
• give existing plugin developers better tools so that they can create things they couldn’t have before.

Doing so makes the X-Plane community stronger, and supports the creation of add-ons that might otherwise not have existed.

Objection: This is a waste of time. What you should be working on is [some other feature].

As I mentioned previously, CEF is being used in X-Plane right now to enable in-app upgrades. This is obviously the most boring non-feature we could ever ship, and I understand why power users (people who might have bought X-Plane 11 on day 1!) are irritated.

The reality is: some features we ship for end-users*, and some we ship to “pay the bills.” Paying the bills is boring, but important: having X-Plane be financially successful ensures that we can continue improving the sim (ahem, in ways that end users actually care about!) for decades to come. In this particular case, we have reason to believe the current purchasing process is convoluted enough that it’s losing us sales. In-app upgrades will increase sales by some (small) percentage, so even though it’s not a direct improvement to the sim for existing users, it’s funding future development.

One more thing worth mentioning on the topic of “I wish you’d do x instead” is that we have a handful of full-time developers now, with people specializing in very different areas, so we tend to have a lot of features in progress at any one time. It’s certainly not the case that, say, Sidney stopped working on improving performance while I was off integrating CEF. 🙂

Objection: I don’t want X-Plane plugins using webviews!

The reason we’re having this discussion is that plugin developers are already using CEF—and they’re doing so in ways that are incompatible with other developers’ implementations.

It’s certainly an option for us to bury our heads in the sand and ignore this—we could force users to choose between, say, installing a Flight Factor plane and installing a fancy new web-based plugin (or using future X-Plane core features). Ultimately, though, this hurts both the end users who would have otherwise chosen “all of the above,” and it hurts the add-on makers who lose sales because users were forced to choose.

We can’t stop add-on makers from using webviews, but we can make sure that doing so doesn’t lead to a compatibility nightmare for end users.

Objection: CEF represents a massive security hole!

This is absolutely a concern for us. Webviews in X-Plane present two major attack surfaces:

1. The possibility of running untrusted code (e.g., a nefarious site exploits a browser vulnerability to execute harmful code on your machine)
2. The possibility of sending data somewhere you didn’t want it to go (e.g., a nefarious site masquerades as your bank’s web site, and sends your login info to bad guys)

We’re still in the “exploration” phase here, trying to understand plugin developers’ needs, but there are a lot of ways we could mitigate these threats. A few possibilities, listed from most extreme to least:

1. Don’t allow remote connections at all; plugin-created webviews could only load local assets (HTML, JS, etc.) that were bundled with the plugin
2. Disable JavaScript entirely
3. Require plugins to provide a whitelist of URLs that are deemed safe to send & receive data from
4. Disable JavaScript loaded from external (or non-whitelisted) domains
5. Allow user preferences to control the above policies (or even disable webviews entirely)

Objection: CEF will slow the sim down. This is bloatware!

That’s for measurement to decide! In our tests, having CEF displaying static pages while flying didn’t slow down the sim by any amount we could measure. And since CEF doesn’t run on the main X-Plane thread, the OS can schedule CPU-intensive things like page loads around X-Plane’s work. There is definitely some memory overhead involved (a few hundred megabytes), but considering the existing footprint of X-Plane, it’s not a crazy amount.

And, like everything in X-Plane, if you want to tune it to get the last drop of performance, you’d be free to avoid using features & add-ons that depend on webviews.

Objection: Don’t use CEF—You should use WebKit, Gecko, Servo, etc. instead.

I did a lot of research and test implementations (on Windows, I went so far as to use Trident, the underlying engine to Internet Explorer!), and the only webview framework I found that meets X-Plane’s requirements was CEF.

* Aside: What does 11.20 include for end-users? A few highlights from the release notes:

• VR support
• New Sydney, Australia landmarks
• A new Aerolite 103 model
• An overhauled Columbia 400
• 1,315 airports with new 3-D scenery