write java.io.file using applet?

[Jonathan Doe]

hi all

what i try to achieve:
reading/(re)writing a file on a client host

why i try to achieve:
i tought about using a pendrive for authentication purpose for my own purpose and thus i try to store metadata which will be modified on the drive

the questions:
i have written a little applet and self signed it
using appletviewer and self defined java policy (which currently doesnt work - anybody knows a grant all rule just for testing - i dont get it work again?) everything worked
using firefox i got a security exception

what im currently really missing is not a solution for my problem but understanding it
i already searched a lot on this topic and i only find a few pieces of the puzzle - much speculative interpretations - some say it works but not how - others say it doesn work - others suggest using java web start without any further help - i also read it will work if the applet provides a security manager
with the right policy file it seemed working - although i know the client wont have them but its a valid working solution

with the following questions im asking more for an answer than an interpretation
Q1: is it possible to write a java applet/webstart app loaded from a webserver for current mainstream browser which can modify the filesystem on the client side (either hard drive or pen drives)
Q2: if yes - what would be easier to use for the user - an applet or webstart? (i dont really know webstart and thus cant decide where the direction should go)
Q2.0: what is the advantage if any on webstart for this topic?
Q2.1: which conditions have to be met to get the applet running without any filesystem restrictions on client side? (self signed - policy file modifications on client side - signed by a CA or just accepting the applet by the user?)
Q3: if no - are there any know alternatives to write/modify files like actionscript or something?
Q4: with standard browser policy for applets what file i/o can be achieved under which conditions? with i/o i mean reading/writing/deleting/... files/directories. with conditions i mean something like: "reading is always possible IF the applet is self-signed OR CA signed AND the applet has been accepted by the user" (i dont know if this is correct ^^)
Q5: if i run a CA applet does the user have to accept it too like a self signed applet? if yes why do i need a certified authority? how do i get CA signature? do i have to provide the source code which will be signed or only checksums

any technical valid hints for helping understanding the limits on this would be great
thanks in advance

[Joseph Macer]

If I understand you correctly, you're trying to have an applet write out to a file, based on network interaction with some other JVM on another machine. It seems that you have correctly removed the security policy from the equation for now. I'll try to answer your questions based on what I understand about your questions:

Q1: Yes, you can have an applet loaded from a webserver. If you write an applet, you can, for example, just slap it in the www folder of a default installation of Apache & it'll work! If you've had the applet signed & got a security policy it'll run in a browser. I have my applet running without being signed and a barebones security policy.
Q2: Applet will load right in the browser, no questions asked.
Q2.0: Webstart is good for deploying desktop solutions over the internet, which sounds like what you don't want to do.
Q2.1: That is up to the user and the browser, as it should be. Either it will ask, or expressly prevent it. In most cases, applets write to the filesystem through a protected cache, which is more common and might be more useful to you.
Q3: n/a
Q4: Not quite sure, you'll have to google it.
Q5: CA certs cost money, and self-signed certs trigger flags in some browsers. Plus, self-signed certs do NOT guarantee identity, just the the person using the cert is the same person every time. So unless your users must be mathematically sure that you are the same author every time, I'd say don't bother. But that's me being a casual small-timer.

Hope this all helps!

[Ulf Dittmer]

Q4: with standard browser policy for applets what file i/o can be achieved under which conditions? with i/o i mean reading/writing/deleting/... files/directories. with conditions i mean something like: "reading is always possible IF the applet is self-signed OR CA signed AND the applet has been accepted by the user" (i dont know if this is correct ^^)

The standard policy forbids any use of the java.io package. If it is signed, everything is possible, regardless of who created the certificate. Signing is an all-or-nothing approach. If you want the restrictions to be somewhere in the middle you'll need to use a custom security policy.

Q5: if i run a CA applet does the user have to accept it too like a self signed applet? if yes why do i need a certified authority? how do i get CA signature? do i have to provide the source code which will be signed or only checksums

The certificate authority is trusted; you're not. So unless the users know you (maybe because they're all friends or colleagues of yours), they may decide not to trust you and decline to accept the certificate.
You do not have to provide any code, source or binary. You'd receive the certificate from a company like Thawte or Verisign, and then apply it to your jar file using the tools that come with the JDK.

See HowCanAnAppletReadFilesOnTheLocalFileSystem for more information on policies and applet signing.

[Jonathan Doe]

thank you to both for much more detailed answer's than i found elsewhere

im not sure i understand the signing purpose completely
does ca signing only validate that an existing person spent money to get a signature?
which also means that the user is asked to accept the applet independent of self signed or ca signed?
what is the real advantage of a ca signature if the way to get it is simply sending money to a company which returns the signature i can use?
i tought trust means that i can trust the code of the applet!?


@Joseph Macer
yeah thats pretty much what i try to achive, but for testing and faster expirience on applets i created a simple javascript which calls the applet's functions as the server based on the network interaction would do

@Ulf Dittmer

The standard policy forbids any use of the java.io package. If it is signed, everything is possible, regardless of who created the certificate. Signing is an all-or-nothing approach. If you want the restrictions to be somewhere in the middle you'll need to use a custom security policy.

i didnt say that i was using javascript which calls my applets functions - my bad
what you said seems not fully correct

the interesting thing which is that only a few people out there know that it is not valid if a Javascript function calls a signed applet function which trys to write to the filesystem!
thats a big exception you can find related posts here:
same problem
alternative solution

i cant find the original post which helped me on this but i created a thread in my applet
public void init()
function which gets a notification when the file should be written
thus my javascript function calls an applet function which enqueues the action which should be taken and the thread writes the file

just to be clear: its not true that you can do everything with just a signed applet - writing a file doesnt seem working if the applet function is public AND/OR called from javascript

[Ulf Dittmer]

does ca signing only validate that an existing person spent money to get a signature?

No, it validates that the CA -which is implicitly trusted-has verified that you are who you purport to be. So if someone sees a certificate signed by Verisign for "Jonathan Doe", then they can assume that such a person exists, and that Verisign knows who it is.

Whereas if someone sees a certificate for "Jonathan Doe" signed by "Jonathan Doe", then it really means nothing at all in terms of security, because there's no reason to trust it. And since an applet that is signed can do very destructive things -including deleting files, or emailing your bank statements to an unknown 3rd party- this is not something one should do lightly.

which also means that the user is asked to accept the applet independent of self signed or ca signed?

Not quite sure what you mean by this. The assumption is that a certificate signed by a CA is implicitly trusted, but that self-signed certificates aren't.

what is the real advantage of a ca signature if the way to get it is simply sending money to a company which returns the signature i can use?

See above.

i tought trust means that i can trust the code of the applet!?

Not directly. You trust the CA to do the right thing, which is to verify that the person who has been issued a certificate is who they claim to be, and that -if worst comes to worst- they can provide you with (copies of) legal documents to prove who it is.

Since that person is now no longer a stranger, and can supposedly be tracked down if necessary, you extend the trust you have in the CA to that person's code.

[Sachin Adat]

@Ulf
That's quite an explanation........nice one