NNTP-Posting-Date: Sun, 28 Apr 2013 06:11:13 -0500 From: "Chris Uppal" Newsgroups: comp.lang.java.programmer References: <5dntm85s55qmuh8cort7l0uuji2mpo9eav@4ax.com> <516f2a09$0$32108$14726298@news.sunsite.dk> <517b33c0$0$32112$14726298@news.sunsite.dk> Subject: Re: > Sandboxed power == More secure??? Date: Sun, 28 Apr 2013 12:09:45 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Message-ID: Lines: 67 X-Usenet-Provider: http://www.giganews.com X-AuthenticatedUsername: NoAuthUser X-Trace: sv3-6bJKd5hdBSUns8CNXUdLR+jT/0Hy0/ibuMfRYGIZw3YaOUbnkBcGyX5GjSq1sWS8nv1TzspWl6SgIU2!95Mrq+BpfWfiR8z+03oim+4IvOx+R+LmXsDczHCdW/M4uMOgcVKHFupp45lhnQjEEGgRlMXPvSU= X-Complaints-To: abuse@btinternet.com X-DMCA-Complaints-To: abuse@btinternet.com X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 4647 Path: csiph.com!usenet.pasdenom.info!news.stben.net!border3.nntp.ams.giganews.com!Xl.tags.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!local2.nntp.ams.giganews.com!nntp.bt.com!news.bt.com.POSTED!not-for-mail Xref: csiph.com comp.lang.java.programmer:23693 markspace wrote: > Exceptions cause a security breach? How the heck I'm I supposed to deal > with that? > > And applets are all callbacks, so apparently the Java plug-in can't even > call my applet correctly at all. > > Those are all issues, and they need to be addressed in a serious way. > Or Oracle is simply not going to have any presence on the desktop in any > way. Which would be too bad, because imo there's a need for more > platforms than just the vendor supplied (Windows, *nix) ones. I don't see anything much that's specific to desktop apps (let alone applets). Quoted: These guidelines are of interest to all Java developers, whether they create trusted end-user applications and applets, implement the internals of a security component, or develop shared Java class libraries that perform common programming tasks. Any implementation bug can have serious security ramifications and could appear in any layer of the software stack. The main thing that's wrong with it, to my mind, is that it's so bloody long! And as a result I haven't bothered to read all of it (and don't intend to). By my impression of it after a quick skim is that it's made up of four kinds of guidance: Motherhood and apple pie stuff (Restrict privileges, Do not log highly sensitive information, Validate inputs,...) which would apply to pretty-much any code in any language on any platform (where security is any kind of concern at all). We can't fault them on that, but it might be better split out into separate guidance ("What every would-be programmer should know before being allowed within twenty miles of a computer"). Stuff that basically can be paraphrased as "Yup, Sun designed the language wrong -- we'll all have to live with it. Sorry..."). Integer overflows (not only do they happen but they happen silently!). Lack of a /convenient/ way of managing limited resources (such as C#s "using" syntax). Lack of immutable references (though I have my doubts about whether that can be made meaningful /and/ useful). Even /having/ public (or protected) mutable fields in the language at all. Public constructors (rather than factory methods). Etc... A few examples of plain daft behaviour of the platform classes which should be fixed pronto. (Such as allowing HTML in Swing components by default). Just about everything to do with serialisation. And the last category can be summed up as "the security model is too complicated, and very easy to get wrong". That's the biggest (by linecount) item. Not sure what to do about that. Maybe a library along the lines of Doug Lea's concurrency stuff that hides all the fragile mess inside nice tight interfaces with clear simple guidelines ?? I say that, but I'm not going to claim that /I/ could design and implement such a beast (not without language/JVM changes anyway). BTW: > All of those are big areas of concern. I honestly don't see what to do > with the mutable statics. You need globals in any non-trivial app. I was under the impression that each applet ran in its own classloader. Am I wrong ? If not then mutable statics are no worse a problem in applets than they are anywhere else. -- chris