Mobile security, proof-of-concept.

[David Edmundson]

I think it is important, and it's good to have some interest in this topic.

># Shared user files.

Sure, but I think we're glossing over what is by far the hardest part
of all this.
Security in itself is easy. The challenge is security that allows some
things through.

> # Why a different user, isn't containers enough?

FWIW, different unix users is how early Android works too so it's
certainly not completely insane, but it's not without it's share of
new problems that will need new infra to solve.
For example how is kwin going to kill a frozen app? If you're not on
the DBus session bus, how are you going to send a notification?

It's all solvable, but we're going to end up building quite a lot of
new stack to reach compatibility and I think that's always been the
big blocker on this. Finding a way to roll something out without
hundreds of really tiny regressions.

>Containers are not simple, at all.

Containers might not be simple, but you're only describing the need
for namespaces, which is quite far from the same thing.
Namespaces are very simple at a userspace level. If you're already
launching everything through a spawning process, calling setns isn't
much harder than seteuid, but with more flexibility.

My initial reaction is that you're absolutely right that given we
control the stack on plasma-mobile and expectations are different we
should have a dedicated app launcher that boxes things a bit more than
it does now.

But I think we need to reverse your question and ask what spawning new
user solves anything better than wrapping in line of bubblewrap.
To give an idea of the future challenges we're going to face: loading
shared configs, not constantly rebuilding kbuildsycocoa5, accessing
pulseaudio, we've got quite a lot of work ahead into solving what
seems to be an already solved problem?

David