Ajax one panel

[gem at cigital.com (Gary McGraw)]

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:info at secappdev.org]
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 at 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.
----------------------------------------------------------------------------