
<html>


<head>


<meta http-equiv="Content-Type" content="text/html; charset=utf-8">


</head>


<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">


<br class="">


<div><br class="">


<blockquote type="cite" class="">


<div class="">On 29 Apr 2021, at 13:06, Peter Firmstone <<a href="mailto:peter.firmstone@zeus.net.au" class="">peter.firmstone@zeus.net.au</a>> wrote:</div>


<div class="">


<div class="">


<p class="">Is there a simpler way to limit permissions of library code?<br class="">


</p>


</div>


</div>


</blockquote>


<div><br class="">


</div>


Limiting permissions of library code is a spectacular idea, and the stack-dependent deep sandbox offered by the Security Manager</div>


<div>is the most spectacular software sandbox ever created. The problem is that while the idea is terrific, it does not seem to work</div>


<div>in practice in any way that is simple and scalable enough to give assured security for applications written by millions of developers. </div>


<div>That a select few could, perhaps, use it to build secure systems while the rest just get a false impression of security is not a viable</div>


<div>security strategy for a popular platform.</div>


<div><br class="">


</div>


<div>There are simpler, and therefore more scalably-secure ways to either sandbox an application or restrict the Java APIs </div>


<div>accessible to untrusted plugins. I don’t believe that semi-trusting and selectively sandboxing third-party libraries that otherwise</div>


<div>make use of the full range of Java’s core APIs is cost-effective and obviously secure. Companies need SMT solvers these days to </div>


<div>check the security of policy files that are much simpler than those that would be required to sandbox arbitrary third-party libraries.</div>


<div><br class="">


</div>


<div>


<blockquote type="cite" class="">


<div class="">


<p class=""></p>


<p class="">Perhaps if we instead address the performance and usability issues, we could improve adoption,so it adds to Java's appeal, rather than detracting from it?</p>


</div>


</blockquote>


<br class="">


</div>


<div>Let's take is as a given that everyone here is interested in adding to Java’s appeal, yet there might be disagreement over which </div>


<div>decision would do that. Clearly, those who propose removing the Security Manager believe it will add to Java’s appeal, if for no</div>


<div>other reason than freeing resources to features many people actually use, while also having a positive effect on security.</div>


<div><br class="">


</div>


<div>— Ron</div>


</body>


</html>