4 ms·
> Not WebKit, WebCore. ^ I was literally pointing to the source code. WebKit consists of more than one project: JavaScriptCore, WebCore, WebKit, WebInspectorUI
by cookiengineer 5y ago
> Not WebKit, WebCore.
^ I was literally pointing to the source code. WebKit consists of more than one project: JavaScriptCore, WebCore, WebKit, WebInspectorUI.
WebKit is also not a Browser, it's a Browser-building framework (or sth like that...) which allows writing platform-specific adapters for all platforms. For example, macOS and iOS are using the Common Framework to do network requests, whereas on Windows it uses libcurl, whereas on GTK it uses libsoup. All things, including UI interaction and how they're integrated with the OS, are platform-specific adapters; which makes the InjectedBundle kind of a dirty hack.
My point being that WebKit uses WebCore as an embedded library, and that the problem is in WebCore's concept of the InjectedBundle; which WebKit is using to do calls to the specific GPU/Web/UI Process sandbox.
This is because WebKit runs in the UI Process, not the Web process. It was split up back when WebKit2 introduced this as its new architecture (not to confuse with WebKit 2.x, because that is WebKitLegacy).
- JimDabell 5y agoI think maybe you missed the point of the discussion? Somebody said that third-party iOS browsers were forced to use Safari. I said no, because they aren’t. They use WebKit. You then chimed in to correct me and say no, actually it’s WebCore. But you seem to be talking about something else. You seem to be talking about the most specific location of the vulnerability, not what third-party iOS browsers have to use. Third-party web browsers don’t use WebCore directly, they use WebKit like I said.