Hi yo! Closure is very helpful when doing things like crossing trust boundaries. If you look at the craziness involved in properly invoking the doprivilege() stuff in java2, the need for closure is strikingly obvious.
However, closure itself is not as important as type safety is. So the fact that javascript may (or may not) have closure fails in comparison to the fact that it is not type safe. Ajax is a disaster from a security perspective. gem -----Original Message----- From: Johan Peeters [mailto:[EMAIL PROTECTED] Sent: Sat May 20 15:44:46 2006 To: Gary McGraw Cc: Mailing List, Secure Coding; SSG Subject: Re: [SC-L] Ajax one panel I think Java would have been a better language with closures, but I am intrigued that you raise them here. Do you think closures present security benefits? Or is this a veiled reference to Ajax? I guess JavaScript has closures. kr, Yo Gary McGraw wrote: > Ok...it was java one. But it seemed like ajax one on the show floor. I > participated in a panel yesterday with superstar bill joy. I had a chance to > talk to bill for a while after the gig and asked him why java did not have > closure. Bill said he was on a committee of five, and got out-voted 2 to 3 > on that one (and some other stuff too). You know the other pro vote had to > be guy steele. Most interesting. Tyranny of the majority even in java. > > Btw, bill also said they tried twice to build an OS on java and failed both > times. We both agree that a type safe OS will happen one day. > > Here's a blog entry from john waters that describes the panel from his point > of view. > > http://www.adtmag.com/blogs/blog.aspx?a=18564 > > gem > www.cigital.com > www.swsec.com > > > Sent from my treo. > > > ---------------------------------------------------------------------------- > This electronic message transmission contains information that may be > confidential or privileged. The information contained herein is intended > solely for the recipient and use by any other party is not authorized. If > you are not the intended recipient (or otherwise authorized to receive this > message by the intended recipient), any disclosure, copying, distribution or > use of the contents of the information is prohibited. If you have received > this electronic message transmission in error, please contact the sender by > reply email and delete all copies of this message. Cigital, Inc. accepts no > responsibility for any loss or damage resulting directly or indirectly from > the use of this email or its contents. > Thank You. > ---------------------------------------------------------------------------- > > _______________________________________________ > Secure Coding mailing list (SC-L) > SC-L@securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > > -- Johan Peeters program director http://www.secappdev.org +32 16 649000 ---------------------------------------------------------------------------- This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ---------------------------------------------------------------------------- _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
