Policy files

[Deliverance]

I have a question regarding applets. I am writing an applet which is intended to run on localhost, or delivered through an internal network only. It requires that the host machine grants certain permissions (capturing audio from a datastream, I had a previous post regarding capturing some audio for this). This applet is actually part of a larger application which will handle audio recording multiple times, but I am trying to work around a security permission each time the applet is loaded which will prompt the user for permission to read/write from the disk (specifically to capture audio, and write back to the network host from which the applet was delivered, or the localhost in hosted mode).

My original idea was to ask for permission to write to disk, and modify the user policy file to grant permissions to my applet so that all future loads of the applet will not load this pop-up to the user. My only concern with this is that the master policy file in the jre directory works with all applets and I am potentially creating several risks in allowing certain permissions globally from any applets that the user may stumble upon on the internet.

Is there any other way to always grant permissions to a specific applet without getting a signed applet by a 3rd party company? I don't have the money to cover the per year licence costs of a digital signature.

[dlorde]

I think it's possible to grant permissions to a particular codebase by providing a Grant Entry for it in the policy file. So, you may be able to grant permissions only to code from the applet codebase.

See 'Grant Entries' in Default Policy Implementation (http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html).

Of course, you won't be able to modify the client policy file from the applet without explicit permissions.

These kinds of difficulties are just another reason why applets are not really suited to 'serious' applications (although they are sometimes useful as part of a larger application). Most developers I know consider applets to be either obsolete technology or of very limited usefulness.

There are features that should not be used. There are concepts that should not be exploited. There are problems that should not be solved. There are programs that should not be written...
R. Harter

[Deliverance]

I know what you're saying. I am already finding annoyances with recording through an applet but I am in a dilemma. I need to record audio in such a way that it is a web solution to allow for future portability of a completely hosted solution. (this is only one part of a larger system being developed). However, this isn't a very crucial piece and I thought it would be over the top to create a flash application backed by a Red5 server in order to capture the audio, and do an FLV conversion with FFMPEG or a similar decoder to go down to the required WAV format. This would include a lot of overhead and had decided that a simple applet with security permissions would suffice, thinking that it significantly reduce the overhead of the back-end. I have to do a bit more testing but it seems that on a windows system I cannot do recording from a USB headset with microphone capabilities. It immediately came to my attention (as in the previous post with USB) that this might be the problem, but I had assumed that windows installs any audio device as a sound card, and that when java requests a DataLine, it goes to the OS to stream, and not to the device directly.

I appreciate you pointing me in the right direction with the grant entries, I think this might work nicely if I choose to continue the route of the applet.

[dlorde]

Unfortunately, I don't really have any direct experience of the sort of thing you're doing, but it might be an idea to use an applet as a local test-rig for the development of the code, and when you have something that works, you can decide how to deploy it. In other words, defer the deployment decision until you really have to make it. This would preferably mean writing the functional code as separate, non-applet-specific classes, which can be used by whatever final deployment platform you choose. This is good practice in any case.

Good programmers know what to write. Great ones know what to use...
E. Raymond