Local file access change with new Java update

[Gregg Wonderly]

It seems rather unfortunate that obscurity is being pushed as a form of security.  It isn't, that's why security problems are discovered in the field.  You can't obscure problems forever. The subtle implication is that "file:" urls are treated specially by the security manager, in applet mode, compared to network based urls.  In the end, everyone is going to jump up and down, and scream and lament about this change for quite some time, and then work around the issue, and try to move on.  But, practically, it is exactly this kind of "API usage" change to create security that just amplifies the issue that Sun/Oracle still don't understand the desktop and web use of Java to understand where dependencies are at, and why there is little reason to keep breaking APIs to fix things.

For decades (since JDK1.2), people have complained about the in abilities of Java's "shepards" to do an adequate job of creating a stable and productive software development environment.   Based on how things are going, visibly to us on the outside, it would seem that some key people who knew what was going on, have left, and now we have all this "discovery" going on with new people trying to figure out what's there, how it works, and still fix problems without breaking things unnecessarily.

I'm of the opinion that the edge of the cliff is getting closer rather than far away, even this far into the process of Oracle taking over Java.  Adequate training, adequate experience and ultimately acceptable responsibilities for code and the welfare of the developers is what makes a programming language live.  Oracle is still painting themselves into a smaller square that is looming closer to the edge of the cliff in my view.

Joe, please try and understand, people are making money off of writing software, and if the value is not there, or the dependability and stability doesn't meet the needs of their customers, something will change.  You can hold onto "the size of the code base is a huge anchor to keep developers here" for as long as you want.  Just understand, that there are non-Java developers creating or recreating all the same software systems on other platforms, in other ways, and at some point, if the weight swings far enough, Java's going to be pushed over the cliff, and that seems like a really stupid event to be a part of…

Gregg Wonderly

On Jul 8, 2013, at 3:13 PM, Joe McGlynn <joe.mcglynn at oracle.com> wrote:

> We can't discuss those details, sorry.  Fundamentally applets aren't designed for running from the local filesystem.  The best practice is to set up a web server deployment environment for development, which gives you a much better approximation of the behavior in actual deployments.
> 
> We will have another mechanism that developers can use to run applets in this more in a controlled way in the near future.
> 
> 
> 
> On Jul 8, 2013, at 10:53 AM, Gregg Wonderly <gregg at wonderly.org> wrote:
> 
>> Joe, which security issue does disallowing local access to a filesystem loaded web page address?  It seems like a horrible limitation for developers to work around.  I appreciate that there are things that the security manager needs to do better in this regard, but I'm not at all sure why this needed to be changed.   Is there a bug report or other history/discussion to read about this via?
>> 
>> Gregg Wonderly
>> 
>> On Jul 8, 2013, at 11:59 AM, Joe McGlynn <joe.mcglynn at oracle.com> wrote:
>> 
>>> This is the expected behavior.  
>>> -- 
>>> On Jul 8, 2013, at 8:16 AM, Joshua Smith <jesmith at kaon.com> wrote:
>>> 
>>>> One of my users likes to test their applets locally by just opening the HTML file from the file system (instead of running a local web server). This worked before the most recent update:
>>>> 
>>>> Java Plug-in 10.25.2.15
>>>> Using JRE version 1.7.0_25-b15 Java HotSpot(TM) 64-Bit Server VM
>>>> 
>>>> It appears that there are two issues. One is that getCodeBase(), when running from the local filesystem, is returning an empty string. getDocumentBase() still gives the right result.
>>>> 
>>>> If I work around that by using getDocumentBase instead of getCodeBase (which, in this particular case is OK because they should be the same), then I get:
>>>> 
>>>> java.security.AccessControlException: access denied ("java.io.FilePermission" "/Other/download/etc..." "read")
>>>> 
>>>> So it appears that with "Medium" security (the lowest available setting), applets will run but they cannot read from the file system, even if that's how they ran.
>>>> 
>>>> Note that I do have the "Disable Local File Restrictions" checkbox set in the Safari Developer Menu, but I'm guessing that Safari doesn't tell Java about that.
>>>> 
>>>> Obviously, the user can just run a local web server, which is what I've told them to do. However, I wanted to make sure that these are both "as designed" security changes, and if not, figure out who I should report the bug to.
>>>> 
>>>> -Joshua
>>>> 
>>> 
>> 
>