We Keep Coding

Why I get error "Your security settings have blocked a local application from running”?

What you do to get rid of this? I wanted to make a game that is accessible from browser. Then I get error "Your security settings have blocked a local application from running".
I changed browser. nothing.
I added exception in "configure java". Nothing.
I looked internet and looked for "medium" security level but it was removed..

Honestly, I'm not sure. But, I might know what's causing the problem. I'll list most of them here (you can find the full list at What Applets Can and Cannot Do):
Applets cannot access the local file system.
Applets cannot connect to or retrieve resources from a third party server.
Applets cannot load native libraries.
Applets cannot change the SecurityManager.
Applets cannot create a ClassLoader.
Applets cannot read certain system properties.
In summary, don't try to make changes to the user's desktop or the client's windows folder. Have them upload the file instead. Don't try to access .pngs or .json from external servers like google or yahoo either, probably because java can't guarantee them to be safe too. Neither can you load native libraries, so you might want to avoid those if you can, and finally you don't have access to some info in SecurityManager, ClassLoader or some System Props.
If your app violates one of these, Java is likely blocking your app from running. But it all depends on your implementation too. Make sure your browser doesn't block certain applet features (and that java supports your browser, make sure everything is enabled too) and try again.
Or, you can ignore all of that and try making your app privileged. Unfortunately I have very little experience with the process of making your app privileged, but from what I can hear, it'll give your applet a little more room to move in.

Protecting .jar with .htaccess?

I want to prevent decompiling for my game client.
Is there a option I can some how protect the .jar file with .htaccess or any other method so the client (Browsing user, that loads the client via a applet) won't be able to get the file & decompile it.
I always wondered if there is a solution for this, is there? Maybe creating a crypt code, and whenever the server tries to get the client jar, it will send a crypt code via GET, if the crypt code matches, it will load the client from that page, I don't know, there should be a solution ?
Thanks!

For a browser to execute an applet, it needs to download the jar file containing the applet code. An if it downloads it, it's available for decompilation. To protect you against that, you can obfuscate the byte-code, or not use an applet at all, and simply use a traditional web application, where the code is at server-side, and the client only see HTML and JavaScript code.

No. You could stop the browser getting the file, but then it would be unable to run it.
Maybe creating a crypt code, and whenever the server tries to get the client jar, it will send a crypt code via GET, if the crypt code matches, it will load the client from that page,
The user could see the code and still get the file.

There is nothing you can do to prevent the user getting hold of the unencrypted bytecodes.
NOTHING.
The user's machine needs the applet's bytecodes in unencrypted form in order to execute them. Since a user (with sufficient knowledge) has totally control over what his machine does, you can assume that control will extend to allowing him / her to intercept the bytecodes at some point where they have been decrypted.
And if the user can intercept the applet's bytecodes, then he / she can change them to defeat any clever stuff you put into the code. And that includes changing the bytecodes to defeat any measure that you use to detect changes to the bytecodes.
"just make it so they have to use it in the browser then check if they are accessing it from our url" Could that work?
Nope. The user can modify the applet to remove that check.
"you could also make php create a session variable with a hash in and check if that hah is present and matches our hashing algorithm"
Nope. The user can modify the applet to remove that check too.
I don't know, there should be a solution ?
Unfortunately, there is no practical solution ... apart from running everything that needs protecting on the server side.
By the way, this problem is not unique to Java. Someone with the technical knowledge and the motivation can defeat any tamper protection measures in Javascript too, or even in native code plugins that you get the user to install (if he is foolish enough).

Is there a way to sandbox parts of a java process on Android?

I want to use an SDK in android, but I don't want that SDK to have any access to permissions that I haven't explicitly given it. On top of that, if the SDK throws an uncaught exception, I don't want it to bring down my entire application.
In C# there is the concept of an AppDomain where you can treat the code running inside of it like a sandbox, granting (or limiting) permissions, and only providing access to data that you explicitly want to share.
Is there anything that works like this in Java for the Android platform?

There are two questions here. The first one deals with handling exceptions in a piece of untrusted code; a carefully written try/catch block should take care of that, as long as the untrusted piece is pure Java. If native code is allowed, then nothing short of process level isolation would help. For running code in a separate process, read up on Android services; you can designate a service to run in a designated process. Then exceptions (the nonmanaged kind) won't bring down the main app. You'll just get a "service has died" exception.
A whole another issue is lowering the permission set. To the best of my knowledge, there's no way to lower the permission set within an app. Even a surrogate process won't help. If you ship a whole application (in the Android sense of the word) for wrapping and running custom code, that might help. But the logistics of app installation would get tricky. Google Market does not readily support the notion of app interdependence or prerequisites.

All the permissions you give to your app are the permissions that are allowed to otherwise it wont have permissions for almost nothing.
you set your permissions in your Manifest.xml otherwise than that you cannot set other kind of permissions.

Getting FileSystemException "A required privilege is not held by the client" using Files.createSymbolicLink in Play Framework

I'm trying to use the new Java 7 Files.createSymbolicLink() method within Play! Framework, and I got the following exception:
RuntimeException occured : java.nio.file.FileSystemException: c:\work\foo\bar:
A required privilege is not held by the client.
This is my first encounter with Java's permission model, so I understand what's going on, but don't yet know how to fix it (I'd like to give the Controllers more permissions).
If anyone can answer here faster than I'll find the answer, me (and future readers) will be grateful.

This isn't a problem with java permissions, but a problem with the operating system permissions. See FileSystemException.
The subclasses of FileSystemException are: AccessDeniedException, AtomicMoveNotSupportedException, DirectoryNotEmptyException, FileAlreadyExistsException, FileSystemLoopException, NoSuchFileException, NotDirectoryException, NotLinkException.
From AccessDeniedException:
Checked exception thrown when a file system operation is denied, typically due to a file permission or other access check.
This exception is not related to the AccessControlException or SecurityException thrown by access controllers or security managers when access to a file is denied.

After seeing this answer, and remembering I am running on Windows 7 with UAC, I understand this is a Windows issue.
Nothing can be done from within Java to make this go away.
I should be able to turn off UAC for Play specifically somehow (run as admin etc...), but the question isn't really related to Play (or java permissions) at all.
Indeed, when running:
runas /noprofile /user:Administrator cmd
cd c:\myapp
play run
everything works well.

How do I grant a site's applet an AllPermission privilege?

I'd like to specify certain applets to run with java.security.AllPermission on my computer (for debugging and security testing). However, I don't want to enable all applets that I run to have this permission. So, editing my user Java policy file (which I have ensured is the correct policy file through testing), I try to put this value:
grant codeBase "http://host_where_applet_lives/-" {
permission java.security.AllPermission;
};
This value fails when the applet tries to do something powerful (create a new Thread, in my case). However, when I put the following value:
grant {
permission java.security.AllPermission;
};
The applet is able to perform the powerful operation. The only difference is the lack of a codeBase attribute.
An answer to a similar question asked here [1] seemed to suggest (but never show or prove) that AccessController.doPrivileged() calls may be required. To me, this sounds wrong as I don't need that call when I grant the permissions to all applets (the second example I showed). Even if this is a solution, littering the applets I run with AccessController.doPrivileged() calls is not easy or necessarily possible. To top it off, my tests show that this just doesn't work anyway. But I'm happy to hear more ideas around it.
[1] Can't get AllPermission configured for intranet applet. Can anyone help?

The answer to the similar question you referenced suggests that calling Java applet code from JavaScript may lead to a SecurityException because the AccessController will do a stack inspection and fail because of the untrusted JavaScript. I tried out the code and sure enough, Firefox won't run the applet called by JavaScript without a doPrivileged() call but Safari will (at least on Mac OSX).
If you are calling your applet from JavaScript, you could try using the Applet.paint() method instead to automatically invoke your applet. Or, you could use the doPrivileged() method to short-circuit the stack inspection, and give yourself whatever privilege you need. Of course, then any untrusted code would be able to call into your privileged code.