Re: ID#:3236 General Comment

Marianne Mueller (Marianne.Mueller@Eng)
Tue, 23 Jun 1998 18:58:05 -0700 (PDT)

Date: Tue, 23 Jun 1998 18:58:05 -0700 (PDT)
From: Marianne Mueller <Marianne.Mueller@Eng>
Subject: Re: ID#:3236 General Comment
To: java-security@java0.javasoft.com, kevin.goode@Eng, markw@cheerful.com

Kevin: be aware that java-security@java.sun.com is meant for folks
from outside of Sun to send email to the security team. It is automatically
archived to an external web page, so you don't want to use it for
Sun-internal email, or forward customer-private information to that alias.

Mark: thanks for the pointer. Didn't mean to suggest that trusted applets
can't read or write files; they can. There are two ways for an applet
to be trusted. If they are installed locally on CLASSPATH (as in your
case), they are considered trusted. If they are signed by an identity
marked as trusted in your identity database, they are considered trusted.

>
>
> ------
> > From:
> > Reply-To:
> > Subject:
> >
> > Name:
> > Email: markw@cheerful.com
> > Organization: Sitegeist Media
> > Phone Number:
> > Location: Europe
> > System: Win95
> > Referring URL: http://java.sun.com/sfaq/
> >
> > FAQ page ambiguity:
> >
> > On your FAQ page about Java security it states something
> > to the effect that "Java applets loaded into a java-enabled
> > browser are not able to read or write files **at all**". This
> > statement is ambiguous - Applets ARE able to read files that
> > are resident on the originating host (and I have an applet
> > to prove it!).
> >
> > The reason I bring this up is because I was searching the site
> > for information that might help me resolve my current problem
> > with security exceptions while writing to a file on the server.
> > At first I read this statement and interpreted my situation as
> > a lost cause, but then I realized that the statement must be
> > referring to the client's machine only...
> >
> > Anyway, just a comment. Otherwise, a great site!
> >
> > Mark
> >
> >
> >
>