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
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:
- The possibility of running untrusted code (e.g., a nefarious site exploits a browser vulnerability to execute harmful code on your machine)
- 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:
- Don’t allow remote connections at all; plugin-created webviews could only load local assets (HTML, JS, etc.) that were bundled with the plugin
- Disable JavaScript entirely
- Require plugins to provide a whitelist of URLs that are deemed safe to send & receive data from
- Disable JavaScript loaded from external (or non-whitelisted) domains
- 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
I can’t even believe that users would even question this? My answer is the same as Steve Jobs… “A lot of times people don’t know what you want till we give it to them”.
This is X-Plane…
Nice explanation in plain English.
BTW – I have a hexa-core CPU, so I don’t care what additional functionality you implement as long as it runs on one of the other 5 cores that X-Plane does not know/care that I have 😛
Obligatory: https://www.youtube.com/watch?v=MNhubpzhs-Q
😀
Good morning guys, the more I think about this, the more I think plugin authors actually need two different ways of using CEF in X-Plane.
First, if you aren’t doing anything complicated-perhaps you just need a basic web browser, and the ability to change the URL, there should be a shared solution for that. Maybe this should be a shared community plugin, or maybe it should be an XPLM API maintained by Laminar, I don’t know. Either way, it shouldn’t expose the CEF API directly, as once people depend on that, you can’t upgrade CEF. The exposed API necessarily needs to be stable across CEF versions so that CEF can be updated without updating every plugin using this API.
Second: if you need to run a modified copy of CEF, or use more of the API, then you should be running your own instance of CEF in another process. This is necessary to prevent conflicting with another plugin using CEF. Your plugin will need to start, stop, and communicate with an external process running CEF. You’ll need a way to communicate with this external process with some form of IPC in order to transfer rendered pages, navigation commands, etc between your plugin in the X-plane process and the CEF process. Most importantly, because your copy of CEF is in another process, it doesn’t conflict with any other instances of CEF running in X-Plane.
Any reason why this wouldn’t work? I think this provides a solution for everybody to use CEF in the ways they need it while resolving conflicting version problems.
I’m not remotely qualified to make judgements on the subject. But in the previous post about you wrote:
“CEF absolutely doesn’t support multiple initialization calls in the lifetime of an app—you can’t initialize it, shut it down, then reinitialize it.”
For an open platform, this seems like a terrible limitation. That alone would make me consider other options first.
See the section “Objection: Don’t use CEF . . .”. 😛
Remember when on your last stream you claimed that a new ATC system was almost done and just needed some things to finish up? Then you did one question and answer here for us just to shut us up. Now you are working on CFE and it has been months without anyone talking about AI/ATC. Pathetic honestly.
For years the xplane community has been talking about an improved AI/ATC system. if fsx can get it right more than 10 years ago why cant you. But better go develop CFE for no one who wants to use it.
That Ben guy really knows his priorities.
Uh… you’re confused. We never said a new ATC system was almost done. (You can check the tapes!) We said we had ATC bug fixes on the way, and that we wanted to hear from people on what they would like to see in a future ATC overhaul. But, to quote from the request for feedback post:
We have to prioritize everything we want to do, and an ATC system rewrite is a major undertaking… it’s going to require a lot of schedule time.
How can you claim that nobody uses it if there already are plugins that do exactly that? Additionally I know of at least one person (me) who thinks that having a web browser in game … excuse me – “in simulator” … is a _very_ useful feature to have (especially for VR).
As stated by Tyler right now the problem is that only one plugin can use it and every other plugin that tries to do the same will break it. Since there already are plugins that do this solving this problem isn’t purely an academical but a very real matter. Considering that they already have CEF integrated into X-Plane at this very moment it seems like defining and implementing a proper plugin interface for plugin developers to use won’t take away several month of work and manpower.
When they finally tackle ATC I bet people that don’t use ATC will complain why time on this is wasted. Why not work on seasons instead or improve the weather system or what not. Just because you are not interested in a particular feature doesn’t mean no one else is.
The only problem I see is with updates. Ideally the embedded browser could be updated independently of X-Plane.
While I certainly don’t think there’s any reason to be rude about your dev path, I also think it’s a little unfair of Tyler to make the comments above.
In a long video when you were all together, it might have been as long ago as last summer, there had clearly been long discussions between you all and the solution on ATC was going to be two approaches.
Accepting that you can’t ‘promise’ anything, it was clearly indicated at the time that the target was to get it done soon & I think for 11.10. It was ‘on the tapes’!
I’m certainly sad that it hasn’t yet been addressed, and seems to have slipped down the priority table, as it is an area of what is an amazing sim that is clearly broke!!!
Keep up the good work but I hope you can address it soon!
Citation needed. At the time of that recording, 11.11 was already final (the recording was made in January 2018, and 11.11 went final December 22, 2017), and every time we talked about 11.20, it was always in the context of “this will be the VR release.”
Ahhh! I understand now. What you’re talking about was Austin’s support for untowered operations. I’m not sure what the state of that is right now, but we discovered a handful of show-stopping issues that required the entire project to be put on the back burner. Austin was… a few orders of magnitude too optimistic in suggesting it would be “no problem” to get it into 11.10.
So, just for completeness…. you were sitting next to Austin!
In the live Developer Q/A in July 17 – 43mins in – Austin said that you should be able to get the 2 part solution done for 11.10, although he hoped he hadn’t promised something he couldn’t deliver (not those words! )
That list of applications doesn’t inspire confidence what with most of them being bloated memory hogs, in addition none of those are games, seeing as performance demands in VR are already very high every bit of performance we can squeeze out counts. As for the security implications I’m fine with it as long as the user has control over what CEF can and can’t do.
Hehe. In an attempt to not belabor the point, I actually left off from that list the fact that both Unity and Unreal (the two most widely used game engines) support CEF out of the box.
So, no, it is factually inaccurate to say that games don’t use webviews.
I think the problem is the idea that CEF is merely a browser in the sim. It can be, but I’ve seen it used in other sims and projects where it’s used as a mechanism to expose native code to javascript. The browser side of things occasionally gets left to doing some UI related stuff or nothing at all.
I get people are concerned about the security of it, but this is where as a user you manage the risk, you may feel comfortable reading the news, watching videos or using web based flight planning, just don’t do your banking in any CEF based application. If you think the scope of CEF is limited to a fancy EFB on payware aircraft, that’s a very narrow snapshot of the potential, look further.
The possibilities for devs with even read/write on datarefs exposed through a javascript API is huge. Think about the requirements for people extending X-Plane right now, they need a background in cross-platform dev (C/C++, other compatible binary) or Lua most commonly, not a problem for some people. If you just add the people with web development skills to that group, you’re in a good place.
The positive thing here is the scope of what CEF exposes to JS is under control of LR, they can limit you to a single dataref or go, “you know what, that UI was so 2017 let’s use CEF for everything”. I’m confident LR wont cripple the implementation to the point we will never see a return on investment from the overhead, that’s a good place to be.
Thank you Tyler for the clarification. I understand what you are looking for.
Also I’m glad that you are fully aware of the security risk which is not a question of personal interest or taste but a real problem that no one should ever underestimate!
What ever will be your counter measure against the the persistent threat of malicious online activity – a “master switch” for the user to enable or disable online connectivity of CEF should be implemented.
If there is online traffic caused by CEF, the user
a) should be aware of it and
b) needs to be the final authority to approve or disapprove it.
The default setup of such a “master switch” should be “off”.
3rd party devs then need to be encouraged to explain why they use CEF and why it is required to switch it to on or what feature will be hampered or non-functional if the switch is turned to “off”.
I do not know if “off” could also disable already implemented CEF versions used by other developers. I wish it was possible.
Also it should be tested if security software is reliably compatible to X-Plane’s CEF implementation. I know that this will be very very difficult because there is a bunch of different security software available – for Windows, Mac and Linux! You should consider that security software also could flag X-Plane itself as malware when using CEF:
==========================
>>One worry is that if too many instances of CEF are being used for malicious purposes, it might lead to the framework being blacklisted by endpoint security products. “Given the large number of companies currently using libcef for legitimate purposes I think it’s unlikely that we’ll end up on any anti-virus black lists,” Greenblatt said. “Companies are also encouraged to sign all of their binaries, including CEF binaries, before distribution.”<<
==========================
source: https://www.darkreading.com/risk-management/malware-developers-hijack-chromium-framework/d/d-id/1109259
"I think it's unlikely that we'll end up on any anti-virus black lists […]" – this is an opinion and some degree of hope but no guarantee!
Chromium requires patches – just like any other browser, embedded as a frame work or stand alone. Also Steam is updating and patching there portal software. But X-Plane cannot update/patch it for add-on compatibility reasons – this makes me a little nervous.
Again: I got your point but opening "Pandora's Box" also is a question of responsibility. I assume that it will be the user who'll have to take all risks but if so, the user really – as a minumum – requires active control about if/how CEF talks to the (dirty) internet.
If VR users then like to benefit from CEF – even for browsing cat videos – why not? But it needs to happen by user's intention and not because of any unknown activity "under the hood".
You may think now that I am suffering from paranoia, but security risks are growing dramatically. I understand that CEF is already being used by some add-ons – but this is no excuse to accept additional security issues being implemented by X-Plane.
Regards,
Marc
My two concerns with this are simple, CEF needs to be ” everyone in the pool” or ” no one in the pool” If having a CEF on one add on prevents others from being able to use it, it’s not a good thing and needs to be sorted out first. Putting end users in that position, is not a good thing.
The second is the monster in the closet, security. Admittedly a LARGE percentage of it needs to be on the user, but at the same time LR and by extension, plug in makers are going to have to seriously consider this. I think a kill switch is a must, an default off switch ( indepenant of the first) is a must. and from add on makers, explanations of WHY it needs to be on, are a must ” just because” is not going to fly anymore after the FSL incident. As long as those are hammered out prior to release I think its fine.
Now obligatory where is my __________ barb (seasons!)
Since you mentioned the Flight Sim Labs debacle, it’s worth noting that CEF running in an app is 100% separate from any installation of Chromium or Chrome on your PC. That means no access to shared passwords, cookies, history, etc.
Tyler said: Since you mentioned the Flight Sim Labs debacle, it’s worth noting that CEF running in an app is 100% separate from any installation of Chromium or Chrome on your PC. That means no access to shared passwords, cookies, history, etc.
My question: since google does Nothing out of the goodness of their heart, what access Do they have?
FYI: I use none of the applications on your list
Chromium itself is 100% open source… if there were some nefarious Google back door, it’s out there in the open waiting to be found.
I agree Google’s behavior is problematic at times, but implying that they’ve embedded malware in an open source project is totally unsubstantiated. Even a company wanted to be evil, that’s not the way to do it… it’s just too easy to get caught!
It doesn’t have to be what most consider malware. Does it ever talk to google for/about anything?
Not that I’m aware of.