Java Applet sandbox security, local vs external ac

I had a bug in our (code signed) java applet "access denied (java.net.SocketPermission x.x.x.x:443 connect_resolve." We had an html "save" button that was calling (via javascript) an applet method to save a file, loaded into the applet, onto the webserver. After some extensive google research, I fixed it by wrapping our applet's save method code in doPrivileged(). Bug seems to be fixed, people are happy.

I want to confirm that I completely understand the original circumstances and the solution I applied (backwards, I know, but turn around time didn't allow me to really research the issue).

Whats specifically confusing me is that we tested our applet on a test server in our in-house network extensively and never got this error until we attempted the javascript "save" button from a client machine external to our network. So at this point, I'm just making an educated guess: that is how the java applet sandbox mechanism works.

Is this true? As long as the client applet is accessing web server resources from a client machine that is within the same domain network it is considered within the sandbox walls? And if the client machine is external to the web-server's local network the applet request is considered outside of the sandbox walls and needs the doPrivileged? Or is there another explanation here that I am missing?

I haven't been able to find anything in sun's documentation or through google that specifically proves or disproves my assertion. Clarification from someone with more experience in java applets is greatly appreciated

As long as the client applet is accessing web server resources from a client machine that is within the same domain network it is considered within the sandbox walls?

If by that, you mean a sand-boxed applet can 'phone home' to its own server, then yes.

And if the client machine is external to the web-server's local network the applet request is considered outside of the sandbox walls and needs the doPrivileged?

An applet needs trust (digitally signed + accepted by the end user) to access resources from other servers. The thing that further complicates it is the JavaScript. Suddenly there is an 'untrusted' element to be considered by the JRE. By wrapping the code in the doPrivileged() method we are saying to the JRE that this code is to be trusted even if called by something else such as JS.