I meant to say security is enforced thru java policy and/or digital signatures, and can be customized for evey applet compared to the sandbox model of 1.0 which was equally resrictive on all applets. When both are absent, it would fall into what
may be called a
sandbox or rather just default restrictions.
http://www.securingjava.com/chapter-three/
When combined with access control, code signing allows applets to step outside the security sandbox gradually. In fact, the entire meaning of sandbox becomes a bit vague. As an example of how Java code signing might work, an applet designed for use in an Intranet setting could be allowed to read and write to a particular company database as long as it was signed by the system administrator. Such a relaxation of the security model is important for developers who have complained about Java's restrictive sandbox. Writing code that works within the tight restrictions of the sandbox is a pain, and the original sandbox is very restrictive.
The addition of code signing to Java complicates things. As it now stands, the Java sandbox has been reduced to a default.
Also check this out -
a-brief-history-of-applet-security [ December 19, 2007: Message edited by: Abhinav Srivastava ]