This all dates from the old days of Java 1.x and applets. The original idea was that the JVM could perfectly sandbox applications from hardware resources, so the smart people at Sun came up a very forward thinking architecture: Untrusted code could be cryptographically signed by a root of trust. Then, bytecode would be formally verified to prove the absence of certain kinds of bad behavior. Then JVM would take care of various low level details like memory management. Finally, for any high level behavior there was something called the Security Manager that allowed 'fine grained' permissions for so-called dangerous APIs. All of this was the sandbox.
What happened in practice:
* The bytecode verifier ended up being accidentally quadratic, leading to straightforward DoS attacks
* The verifier kept having bugs, some of which stood for years
* It was impossible to enforce resource usage policies like "don't use all of my CPU". Since cryptocurrency is now a thing, this problem has become somewhat more severe than it was 20 years ago.
* The security model was useless in practice, because unverified or native code broke the entire thing. This remains an research open question under most conditions.
* Oh god the bugs. They were endless and the practical result was that the sandbox was never secure. [1] recapped 20 years of exploits, if you're curious about examples.
By the tail end of the system's life, even the public was completely fed up with it and mainstream media was publishing articles like [2]. Eventually even Oracle gave up and just deprecated both Applets and the SecurityManager system entirely [3].
Not the GP, but the Java Sandbox is now deprecated.
There is an already closed deprecation ticket at openjdk.java.net.[1] For a blog post at inside.java see here.[2] Both links have some explanatory information.
What happened in practice:
* The bytecode verifier ended up being accidentally quadratic, leading to straightforward DoS attacks
* The verifier kept having bugs, some of which stood for years
* It was impossible to enforce resource usage policies like "don't use all of my CPU". Since cryptocurrency is now a thing, this problem has become somewhat more severe than it was 20 years ago.
* The security model was useless in practice, because unverified or native code broke the entire thing. This remains an research open question under most conditions.
* Oh god the bugs. They were endless and the practical result was that the sandbox was never secure. [1] recapped 20 years of exploits, if you're curious about examples.
By the tail end of the system's life, even the public was completely fed up with it and mainstream media was publishing articles like [2]. Eventually even Oracle gave up and just deprecated both Applets and the SecurityManager system entirely [3].
[1] http://phrack.org/issues/70/7.html#article
[2] https://www.reuters.com/article/oracle-security/oracle-fixes...
[3] https://openjdk.java.net/jeps/411