Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-process app model #3

Open
RByers opened this issue Jan 15, 2024 · 2 comments
Open

Multi-process app model #3

RByers opened this issue Jan 15, 2024 · 2 comments
Labels
Platform: iOS Priority: 0 - Essential Highest level priority, a must have, required for Browsers, Web Apps or functional competition Status: Open Open for discussion Support: Google Support: Open Web Advocacy To: Apple Requests made to Apple

Comments

@RByers
Copy link

RByers commented Jan 15, 2024

Description

All modern browsers rely on multiple OS processes for security and reliability. For example this is essential to ensure that if one website crashes or hangs (uses too much memory, triggers a browser bug, or gets stuck in an infinite loop) that other websites can continue to function normally. For details see Chromium's multi-process architecture and Firefox's electrolysis project.

All modern OSes (including Windows, MacOS, Linux, Android and ChromeOS) make generic process creation and termination facilities available to applications. For example, see Android's processes and threads overview. On iOS these capabilities are restricted to the system and built-in WebKit browser engine, making any browser that doesn't use the built-in WebKit engine unreliable and insecure.

Outcome

APIs for spawning additional processes for a given application and killing processes which have been spawned. This must include at least:

  • Shared memory between processes in the same application
  • Sharing platform handles between processes (eg. mach ports / file descriptors)

Ideally, for performance optimization purposes, this would also include control over process and thread scheduling: freezing processes, setting process/thread priorities and core affinities.

@RByers RByers added the Status: Triage A new issue that has been added to the system, needs to be checked by moderators for scope/quality label Jan 15, 2024
@RByers RByers mentioned this issue Jan 15, 2024
@mtom55 mtom55 added Priority: 0 - Essential Highest level priority, a must have, required for Browsers, Web Apps or functional competition Status: Open Open for discussion Support: Google Support: Open Web Advocacy To: Apple Requests made to Apple Platform: iOS and removed Status: Triage A new issue that has been added to the system, needs to be checked by moderators for scope/quality labels Jan 16, 2024
@RByers
Copy link
Author

RByers commented Feb 4, 2024

Apple's newly announced BrowserEngineKit provides support for multiple processes as documented here. An initial review suggests the design looks reasonable, but we'll need to actually test it to be sure.

We have not yet succeeded in testing this in Chromium due to two issues:

  • The simulator seems to enforce "com.apple.developer.web-browser-engine.webcontent" entitlements (we have not had to add entitlements for builds running on a simulator before)
  • We have been unable to get the simulator to launch codesigned builds with the entitlement, eg: "Disallowing com.google.chrome.unittests.dev because no eligible provisioning profiles found"

Probably we are just making some mistake, but the limited documentation and lack of working sample code make this challenging. We are reaching out to Apple for support. I'd love to hear if anyone else has gotten this to work, perhaps we can use this issue as a public information sharing forum?

@bratell-at-opera
Copy link

While the use of multiple processes is reasonable based on security, it is still unclear how Apple's Application Extension model fits the monolith that is Chromium's architecture.

Application Extensions are supposed to be small add-on processes that perform a specific task or access a specific API only application extensions are allowed to use. For Chromium we reasonably have to use wrapper binaries on top of a shared Chromium binary and as far as I can tell, it is not clear from Apple's documentation if they are ok with such a solution. They are known to scan binaries for disallowed use of APIs and the shared binary will contain code that will reference APIs that are limited to specific Application Extensions. At the very least, Apple should make clear that this is ok.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Platform: iOS Priority: 0 - Essential Highest level priority, a must have, required for Browsers, Web Apps or functional competition Status: Open Open for discussion Support: Google Support: Open Web Advocacy To: Apple Requests made to Apple
Projects
None yet
Development

No branches or pull requests

3 participants