3 ms·

> Not Safari, WebKit. Not WebKit, WebCore. WebCore's API client is broken and leaked IndexedDB transactions into the ObjectStore of the WebInspectorUI. This w

> Not Safari, WebKit. Not WebKit, WebCore. WebCore's API client is broken and leaked IndexedDB transactions into the ObjectStore of the WebInspectorUI. This was kind of bound to happen, as WebCore's InjectedBundle [0] for cross-process communication exposes all kinds of APIs for debugging, which are all dependent on the JavaScriptCore VM's memory/heap and callstack. Things like HitTestResult in order to be able to select an element in the DOM via the WebInspectorUI, for example. InspectorInstrumentations are littered all over the codebase, in the UI Process, Web Process and GPU process. WebGL and Media Codecs could probably result in a similar persistent state across the sandboxes if abused correctly. Source: Forked WebKit into RetroKit, trying to get rid of everything security-relevant that a locally embedded WebView shouldn't need [1]. Still work in progress though. [0] https://github.com/WebKit/WebKit/tree/main/Source/WebKit/WebProcess/InjectedBundle https://github.com/WebKit/WebKit/tree/main/Source/WebKit/Web... [1] https://github.com/tholian-network/retrokit https://github.com/tholian-network/retrokit

JimDabell 5y ago
> Not WebKit, WebCore. No, WebKit. Browsers on iOS use WebKit. Here’s Firefox for iOS using WebKit, for example: https://github.com/mozilla-mobile/firefox-ios/blob/main/Client/Frontend/Browser/BrowserViewController.swift https://github.com/mozilla-mobile/firefox-ios/blob/main/Clie... > Source: Forked WebKit into RetroKit As far as I can see, RetroKit can’t be deployed to the App Store. So what relevance is it to what iOS browsers use?
- 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 ago
    I 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.

JimDabell 5y ago

> Not WebKit, WebCore. No, WebKit. Browsers on iOS use WebKit. Here’s Firefox for iOS using WebKit, for example: https://github.com/mozilla-mobile/firefox-ios/blob/main/Client/Frontend/Browser/BrowserViewController.swift https://github.com/mozilla-mobile/firefox-ios/blob/main/Clie... > Source: Forked WebKit into RetroKit As far as I can see, RetroKit can’t be deployed to the App Store. So what relevance is it to what iOS browsers use?

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 ago
  I 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.