That sounds like a very exciting idea, but I am not sure about the
mechanics of getting that to work. I assume the permissions for the
untrusted code would be in the closure's environment. Who would put them
there? How would the untrusted code call privileged code?
Has anyone done this?
kr,
Yo
Gary McGraw wrote:
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
_______________________________________________
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
