This object can be passed in along during the creation of your WKWebView object through a WKWebViewConfiguration object. The WKWebView API remedies this through the WKUserContentController object. This means you cannot directly expose new native features to websites. One unfortunate side effect of using a WKWebView versus your own rendering and JavaScript engine, is you can no longer make direct modifications to the underlying code. Rather than having Chromium suffer from subpar performance on the platform it’s better to just use a WKWebView like every other browser.

This capability would allow the implementation of an efficient JavaScript engine. This entitlement in particular is what would allow applications to map RWX memory. The reason for this is the code signing restrictions on the iOS platform and Apple’s unwillingness to allow developers to submit apps with the dynamic-codesigning entitlement enabled. In fact, most likely all third-party browsers on iOS use the built-in WKWebView API to add web support to their application. Unlike the desktop version of the Chromium browser, which uses V8 for its JavaScript engine and Blink for its rendering and WebAPI support, the iOS version of the Chromium does not. I will also talk about a UXSS bug that I found while exploring this area of the code. In the first part of this blog post series, I will be providing a quick introduction to the iOS Chromium browser and the potential attack surface of the JavaScript interprocess communication (IPC) provided by WKWebView.

Unfortunately, the answer is no they can. It’s just a wrapper around WebKit right? The developers cannot possibly add any bugs we need to worry about…right? Nobody on the team had experience looking for bugs in Chromium on iOS. When the security team first met with the engineers in charge of making iOS Edge a reality, we were unsure on what recommendations to make. This includes any changes to areas that have been prone to bugs in the past such as the addition of new Mojo interfaces.

As security engineers on the Microsoft Edge team, one of our responsibilities is reviewing code that could potentially impact the security of the browser. As part of Microsoft’s Edge’s move to using Chromium as the backbone of our browsers, we are updating all our browser product lines, including the iOS version.

Browsers not based on chromium