Apple CPUs: SLAP and FLOP

[DiTBho]

We need hierarchical identities, dynamically created user sub-accounts that only exist at run time, used for processes and process groups (in case some task needs sub-sub-processes or multiple processes in parallel, for example one to render content and run Javascript, and the other to decode media stream; they might even have completely different process and I/O priorities) and as a mark at each directory the sub-account may access.

I don't know, so it's just my impression, but I think this is the direction Linus T.&C would all like to go
with the > 6.15 kernels to give a new strong "development reference" (1)
on the userspace side to applications that are otherwise increasingly vulnerable.

Kind of I add strong kernel side support, and provide several userspace side application examples,
now follow them to rewrite more sensitive applications!

Excellent, just ...
... if it works for GNU/Linux ... it will take a while to become a "towing" directive for other kernels too?
Especially for Haiku/OS which is very promising but is far behind ...

And I would like to be FreeBSD, OpenBSD and then MacOS? Will they follow?

[Nominal Animal]

I've seen [Linux] distributions that run Firefox in a container.

Sure.  Containers are one possible solution, but not without their own limitations.

FreeBSD, OpenBSD and then MacOS? Will they follow?

FreeBSD already has jails, and macOS app sandboxes.  IIUC, OpenBSD rejected even BSD jails two decades ago.  Linux also has namespaces for implementing somewhat similar containers.

One can argue that containers are the solution, but then we get the current situation, where kernels cannot leak any information (via e.g. speculative execution) or security problems will ensue.

If we had hierarchical runtime user account delegates (so that 'user' can control what 'user.delegate' has access to, but not vice versa), at least scheduling from an 'user.delegate' process to 'user' process would not need strong countermeasures against information leakage.  Right now, we need those countermeasures everywhere (except on systems running only trusted code belonging to the same human or mutually trusting human group); even when scheduling between processes belonging to the same user.