We all have to start somewhere!
On an Intranet you can make certain assumptions (if not outright DEMANDS!) on the user configuration that you can't on the Internet. I prefer not to, because it's good practice, and often in-house things turn out to be good to provide to a more general audience later.
One thing that causes many people grief here is the situation where they code up a solution and debug it in their
IDE and/or the AppletViewer, but then they embed it in a web page and it doesn't work. You can sign the applet and fight the firewalls, or you can grit your teeth and do it the Sun (3-tier) way. Sometimes you NEED to be able to write to local files, which is why applets can be signed. The reason things like that require special authorizations is because there are jerks out there who would find it "funny" to create a web site that filled up your hard drive behind your back or even tampered with OS-critical files.
I'll repeat a good quote I ran across a while back - it may save you some wasted effort:
"Because the default behavior for Java applets and applications
running in restricted environments is no access to system resources, all access to system resources such as file systems, networking facilities, screens, keyboards, disk drives, and printers is not allowed unless specifically granted. The restricted environments also prevent communications between Java programs."
from
http://developer.java.sun.com/developer/technicalArticles/Security/ReallySecure/ 
