> In-process sandboxing is falling out of favour.

Javascript and webassembly still aim for for in process sandboxing, though browsers add process level security as defense-in-depth.

They do not, at least not in the way "in-process sandboxing" means in the context of Java's Security Manager, which is now being considered for deprecation and removal. Java's Security Manager does not create a single set of permissions for the entire Java program, but rather assigns different permissions to different Java classes running in the same program and even on the same thread, through a mechanism that assigns different permissions to different subroutines on the call-stack, composing them in some elaborate way. The same operation can be allowed or blocked depending on the call-stack by which it is reached. For example, writing to a specific file or socket could be allowed if the call stack contains a trusted subroutine that is known to ensure the access is done "safely" but blocked otherwise.

The reason this is now being considered for removal is that even though this mechanism is very flexible and powerful in theory, it is too elaborate to be used correctly by most programmers in practice.

That actually sounds awesome... A bit like the setuid bit on unix for running the ping utility always as root (normal users can't receive ping packets), but with a whole lot more flexibility.

I can see how careless use of it can lead to an unintentionally rather massive security surface area though...

Yeah, it's a great idea and a clever design, but sophistication is often the enemy of security: http://www.cs.cmu.edu/~clegoues/docs/coker15acsac.pdf

Yes, it is pretty awesome. I am was sort of sad to hear that it is slated for deprecation and removal. After the Java focus shifted from running in the browser to running on the server, the security manager was seldom used.

There was a lot of interest in early days of Java and the internet in mobile code that could move between devices. It seems that interest in such systems has waned. I suppose this was more of a solution looking for a problem. However, I still think that there is potential there in some way.

Well now we have WebAssembly being marketed for such purposes as if it was the first of its kind.

Meanwhile the first security papers already started being shown.

There is a replacement in sight?

No, because Java's security hasn't been based on the Security Manager sandbox for years, and very few people use it (and almost no one uses it for sandboxing untrusted code -- what it was designed to do). There will be replacements, and in some cases there are already, for other (ab)uses of the Security Manager, such as tracking I/O events.

Yeah, the way we adopted threading and dynamic libraries for plugins is on the way out and we are back into multiple process with IPC, for more stability and security.

The downside is they are more memory hungry.

There are a couple of WebAssembly efforts that run things in-process, such as Cloudflare Workers.