Hi! I miss a more complete discussion in JEP 486 about the secondary effects of having a security manager installed other than achieving sandboxing, if they should be possible to achieve when a security manager cannot be installed or if they should be considered as not important going forward.
For example, there seems to have been an ambition to reduce information leakage in exceptions when a security manager is enabled, indicated by this comment and behavior: https://github.com/openjdk/jdk/blob/f2316f6829c9b671e992401ee39d7a1a1805857e/src/java.base/share/classes/java/nio/file/TempFileHelper.java#L127 The scenario I have in mind is transforming an application, that currently uses the security manager for sandboxing of untrusted code, to instead use OS level sandboxing, which in itself seems straightforward. Should such an application now consider exposing exception details as more prone to information leakage? Or will there in general be a way to keep those information leakage mitigations in place, to not have to make an active security decision here? Maybe the ambition to reduce information leakage with a security manager enabled was never documented, and maybe it wasn't very effective. Maybe exposing exception details always carried such a big information leakage risk that the few mitigations never made a practical difference. Either way it would be good to discuss it in relation to JEP 486 to guide developers transitioning from having a security manager enabled. Yours, Mikael Sterner
