>> Wolfram Schulte: Okay. Good morning everybody. It's my pleasure to welcome our
guest for today, which is Douglas Crockford. We rarely met in the past conferences, but
it seems that we have the same passion in making our languages a little bit more secure.
And with this I, yeah, welcome Doug. And he will talk a little bit about the future of
JavaScript. Thanks a lot.
>> Douglas Crockford: Good morning, everybody. First a show of hands. Who's heard
of JavaScript? [laughter] it's not surprising that so many of you have heard of it. It has
unexpectedly become probably the most important programming language in the world.
I think there are more people writing in JavaScript now than anything else.
JavaScript has become an important programming language, which is really surprising if
you understand how the language actually works and where it came from. It's important
because it's a language of the browser. And the browser is growing in influence.
JavaScript is soon to become the language of mobile devices and perhaps in other venues
as well. So it's a language which is taking over.
Most of the people who do not know JavaScript hate it. And most of the people who
know JavaScript aren't really crazy about it either. There are a lot of really strong
emotions around this language, perhaps more so than any other language. The language
contains many flaws. It is far from a perfect language, but it also contains some good
parts, and it's because it has good parts that it's a language worthy of your consideration.
I'll offer as evidence that there are good parts this pamphlet which I wrote which
describes the good parts. I don't have time to read you the whole text; that would
probably take an hour or two, and I don't have that much time. So instead I'll just sort of
summarize what the best parts are.
Sort of a meta-best part is that this is a really short list, which I think speaks well to the
language rather than against the language. It sort of realizes the ideal of programming
language design in which you have a very small number of really good aspects which
combine together in really powerful ways, and JavaScript does this. It's the first lambda
language to go mainstream.
Lambdas came into programming language in '58 with McCarthy's Lisp, perfected by
Guy Steele in adapting Lisp in Scheme to demonstrate Carl Hewitt's [inaudible] pattern.
And first goes mainstream in JavaScript, something they weren't able to do at MIT in 50
years is in this silly little language. And JavaScript is now influencing the design of more
respectable languages.
It is a language of many contrasts. Some of the best ideas ever in the history of
programming languages can be found in JavaScript and some of the worst ideas in the
history of programming languages are also to be found in JavaScript. No other language
has this range of goodness and badness, from the ridiculous to the sublime, and
everything in between is here in this strange little language.
If you look at the community of people who use this language, it has the broadest range
of programmer skills of any language. We've got computer scientists who are doing
remarkable stuff in it, we've got cut-and-pasters who don't even know that they're
programming, and we've got everybody in between.
There is no other language in the history of languages which has this reach of expression.
And I think it is further evidence that this language is doing something right, perhaps
something unexpected, but the fact that it can reach such a broad range of users is quite
amazing.
To fill you in on some of the history which you might not be aware -- or not all of you
might be aware of, it started at Netscape in 1995. Brendan Eich was hired to produce a
scripting language. During the interviews he thought it was going to be Scheme. When
he was hired, he was told it's not going to be a Scheme, it's going to be something which
looks more like Java or Visual Basic in order to facilitate a hypercard-like style of
programming within Netscape 2. He very quickly produced a proof of concept, showed it
to management there who were surprised that it actually worked, and that was sufficient
to get it shipped in that form. So it was raw and buggy and that's the way it went out on
the Net.
And it might have been forgotten at that point in time except that at another company
called Microsoft they took notice of that and made an almost perfect copy of it,
identifying virtually everything that was defective in this original implementation and
faithfully rendering that in their own version.
That turned out to be a really important milestone in the history of JavaScript. And we'll
come back to that later. Netscape was alarmed at Microsoft's feat and was concerned that
they were going to loose control of their new language, so they undertook to create a
standard around it, thinking that would frustrate Microsoft.
They went first to W3C, which had been waiting for an opportunity to say no to
Netscape, so they did. So eventually they took it to the European Computer
Manufacturers Association, which was perhaps an unexpected place for a California
software company to end up. But they went there because they could get a standard.
And in fact this is the most successful standard that ECMA has ever published.
During the course of the work on this, the work was dominated by Microsoft and
Netscape who were both trying to destroy each other in the market and also within the
standards process. And so there was a lot of really bad stuff which got baked into the
standards because of the inability of these two companies to play nicely.
One of the aspects of this was that Netscape wanted to get a standard for this new
language, JavaScript, but they didn't control the trademark for it. Sun Microsystems
owned the trademark because it had the word "Java" in it. And Netscape had an
exclusive license to use the name and didn't want anyone else to be able to use the name,
even though they wanted to standardize the language. Which is why Microsoft called
their implementation JScript. They just didn't want to mess with the trademark problems.
ECMA couldn't deal with the trademark problems either. And so during the development
of the language, they entertained a number of potential titles, like NetScript and
WebScript and so on, but none of them stuck. So in the end they published with the
working title, which was ECMAScript, which is maybe the worst name ever put on a
programming language.
So we've got a strange little programming language with three names. There are a lot of
people who think there are three different but similar languages here, but they're not. It's
three names for one silly little language.
The next thing in this chronology is that Netscape self-destruct. So they leave the field.
And Microsoft, seeing that the browser wars are over, abandons Internet Explorer in
favor of Avalon. Lots of lessons were learned in developing the Web, and they moved
forward to a better world, expecting that the Web would ultimately wither and die and be
replaced by something much more fabulous.
Unexpectedly in 2005 the AJAX revolution occurs. And through AJAX the Web
blindsides Microsoft for the second time. AJAX provides a way of writing applications
that run in a Web browser which are much more interactive than in the previous
generation.
So how did lowly JavaScript become the world's most important programming language?
I think there are a number of key events which allowed this to happen. The first one was
Netscape's 1.2 edition of JavaScript. This went mostly unnoticed at the time, but this is
when lambda entered the language, which is when object literals entered the language.
It was at this point that it became a real language. Up until that point it had been a toy.
The reason the AJAX revolution was able to happen was that there was enough goodness
in the language that the language actually worked and was able to accomplish important
tasks, like the writing of applications. And that's because there was actually good stuff in
the language itself.
The second key event was JScript. Because Microsoft did such a brilliant job of cloning
the language and all of its defects, which are numerous and considerable, JavaScript was
able to keep the "write once, run everywhere" promise that JavaScript made and failed to
keep. Had Microsoft not done such a brilliant job of making the language compatible,
AJAX would not have happened.
The next step was Microsoft's DOM. The Netscape DOM was patterned after Hypercard
and was troublesome and quirky. Microsoft's DOM, which was done by Scott Isaacs -who might even be here. Are you here, Scott? Yeah -- generalized the thing, made it
much more regular, made it much easier to use. It's still deeply deficient as an
application platform, but it's significantly improved the level of usefulness to the point
where AJAX's libraries are able to repair it and turn it into a platform.
The final thing that happened, the final key event was Microsoft did absolutely nothing
for five years on this space. There are a lot of Web developers who criticized Microsoft
for having left the field and abandoned the Web. But it actually had a huge benefit,
which was that during the browser wars, both of the major browser vendors were
pumping bugs into the Web at a furious rate.
And bugs in the Web don't go away very quickly. It takes years for them to get flushed
out. So with each new release, while there was a promise of fixing old bugs, the old bugs
actually remain because you can't depend on everybody upgrading to accept the new
things. And each of those upgrades would include new bugs. So the bug list was
constantly growing and it took years for it to shrink. And that shrinkage occurred over
the five years from 2000 to 2005.
That was what allowed the browser to become stable enough to become an application
platform. Prior to that time all of the technology necessary for doing AJAX was already
in the field, but it was too unstable to allow for application development. So by doing
nothing, Microsoft allowed AJAX to happen. And I think that is maybe the best thing
Microsoft has ever done. Kudos on that. Keep it up.
So one of consequences of AJAX happening is we're now doing mashups. Mashups are
the ability to create an application by sticking components together in powerful ways,
almost like Lego. This is something we've been working on in research and in standard
setting. For years. We're finally seeing it come to life in a big way in browsers. This is a
huge leap forward, I think. This is the next big thing in software development. We look
at the steps of improvement where we went from Symbolic Assembly Language to highlevel programming to structured programming to object-oriented programming.
I think what we're currently calling mashups is the next thing forward. And it's
happening in browsers. And it's happening in JavaScript. Because this language, while
it's unconventional in many ways, actually has the right stuff for solving this problem.
Unfortunately there's also some serious bad stuff in this environment. There is a thing
called XXS, which stands for cross-site scripting attack, which is an inaccurate term
developed by Web security experts who are serving the development community by
giving important problems incorrect names in order to help us better understand what
went wrong.
The problem with cross-site scripting as a vulnerability in the browsers means that it's
really easy for bad code to get control of an environment and do bad things.
We're about to go into the holidays, and so I thought this was a good time to show this
slide. This is a turducken. This is a holiday dish which is made by taking a deboned
chicken, filling it with stuffing, putting that and some more stuffing inside of a duck, and
putting that with more stuffing inside of a Turkey and then baking it all together. So
you've got lots of nesting going on and some surprising results as a consequence of that.
We have a similar thing going on in the Web architecture. We've got http, HTML, URL,
CSS, JavaScript, and other languages which can all nest inside of each other. And the
Web is not a system; it's an amalgam of all of these distinct languages, each with its own
conventions for commenting, quoting, escapement and encoding.
So it turns out it's really easy for an attacker to hide one language inside of another. And
text which is inactive in one context can become active in another and in becoming
active, it becomes dangerous.
So what can an attacker do if he can get some script onto your page? It turns out there
are a lot of things that he can do. The first thing is he can ask for additional scripts, and
he can ask any server in the world to provide those scripts. Once he gets a foothold, he
can get all the script he wants in order to launch a more sophisticated attack.
He can read the document. So he can see everything the user can see. He can also see
things a user can't. He can see the hidden fields, he can see the comments, he can see the
scripts. He can see everything that the server has sent over. He can make requests of
your server. And your server cannot detect that the requests did not originate from your
scripts. If you have an interface which allows the client to send SQL to your server, then
you've given the attacker direct access to your database. This is a really serious
vulnerability.
Now, if you're securing your connection using SSL, the attacker gets access to your SSL
connection. So there's no -- and there's no way to tell who is sending the requests.
Now, one way to mitigate that is, before doing anything important, ask the user for a
password. But that's not really effective either because the attacker has complete control
over the display and can ask the user what is your password. Now, most users are not
paying attention to the security properties of the browsers that they're using. But if they
are, if they're looking at the anti-phishing chrome or the security chrome, it will tell them
this is a legitimate request from the site you think you're talking to, because the browser
cannot tell the difference either.
Then finally the attacker can send the information it obtains to any server in the world.
The browser contains a security mechanism called the same origin policy which prevents
an evil script from reading data from any server, but there's no restriction on the ability to
transmit data to any server.
So the browser does not prevent any of these things, which is why they happen. And the
consequences of a successful attack are horrible. There's harm to customers, loss of trust,
legal liabilities. And we're starting to even see possible criminal liabilities. And it's
really difficult for an operator of a service because these vulnerabilities are not in their
system, it's in the browser that the user is using.
These vulnerabilities are required by the Web standards. Now, we've heard about bugs in
the browsers and how there's security holes. And all of that's true. That's not what I'm
talking about here. The specifications published by W3C and ECMA require that these
vulnerabilities be present in all conformant browsers.
So that's really bad. This is not a Web 2.0 problem. This has been out there since
Netscape 2 and has been in every browser since then. And one of the reasons why it's in
IE is because IE did such a -- the IE team did such a really clever job of copying the
defects that Netscape had pioneered.
So when you look at what a mashup is, a mashup is a self-inflected cross-site scripting
attack. It is not possible for the page to adequately defends itself from its Widgets or for
the Widgets to defends themselves from the page or from each other. And for this
reason, mashups, as currently understood, are not safe in a browser if there is any
confidential information on the page. And virtually every page has some confidential
information, even if it's only the thing that identifies the user in this session.
So the Web's really bad, but as bad as it is, everything else is worse. The Web is actually
the best we have right now in doing secure distributed architecture, going clients to
normal users.
So why is this? Well, if you go back to the beginning of computing, you've got a
computer. And in that computer you're running software. And the software is capable of
doing everything that the hardware is capable of being commanded to do. There is no
understanding in that model of different roles or interests.
In the mainframe era when they started doing batch programming and then later doing
timesharing, there were persistent resources on the computer system that they couldn't
allow everybody to have access to, and they also wanted to maintain the reliability of the
system so they didn't have to be constantly rebooting it. So that led to the invention of
the system mode and the user mode. So now we've got two interests. We've got the
interest of the user and we have the interest of the system. So that allows the system to
defend itself against the user.
There's still confusion here in that it doesn't distinguish the interest of the user versus the
interest of the program that the user is running. Back in the old days, access to computers
was difficult enough and software was rare enough that it was assumed that those two
were the same. They're not.
As we go into is timesharing era, you've got multiple users who are all in the system at
the same time. And so the model is enhanced in that it's possible to distinguish the
interests of each individual user so that they can't interfere with each other.
It turned out this is also an annoyance, because sometimes the users want to be able to
cooperate, and the timesharing era, two users on the same machine were severely
constrained in the ability to do cooperative work. There was research leading toward the
solution to that problem, but then suddenly timesharing failed. And the reason was
because of personal computers.
So we introduce CP/M, MS-DOS, the Mac OS and Windows taking a big step forward
going back to the beginning of time, forgetting everything we had learned up until that
point about how to manage multiple interests on a computer. So in this model, every
program is assumed to be fully representing the user or the owner, in the case of a PC,
and is enabled to do anything that the hardware can allow.
Because the system can't distinguish the interest of the user from the interest of the
program, floppy-borne viruses are enabled. And then when you take that box and hook it
up to the network, now network-borne viruses are enabled.
And while there have been patches and improvements to the platform over time, it's still
problematic. In this case the Web now represents a big step forward. The browser is
able to manage its own interest, it can manage the interest of the user, and it can
independently manage the interests of each site.
So this is a huge improvement over what's possible on the desktop. But it's not perfect.
The model was not adequately understood at the beginning and has not been properly
repaired since then.
Within a page, interests are still confused. So an ad or a Widget or an AJAX library gets
the same rights and privileges as the site's own script. And this is why the browser is not
safe.
JavaScript as a language, as the language of the browser, as the language of AJAX got
close to getting it right, lambda actually has really important security problems, and those
are in the language and are not compromised. Unfortunately JavaScript has a global
object, and that global object is the root cause of cross-site scripting attacks. The
turducken problem contributes to it, but the turducken problem could not actually exist if
it were not for the JavaScript global object.
The reason JavaScript as a global object is it is a load-and-go system in that programs are
delivered to the execution site as source code are compiled at the site and immediately
executed. And in order to allow independent compilation units to work together, it
throws them all into a common global space. And in that global space, every bit of
software gets exactly the same rights. And so it's impossible to determine where source - where script came from, and it's impossible to restrict what capabilities it acquires.
Now, I think it is possible to repair a JavaScript because it didn't get that much wrong.
It's pretty close to being a language in which we could have object capability discipline.
And if we had that discipline, then we could do safe mashups.
So what do I mean by an object capability system? Let me give you an introduction.
Here A is an object, where it's a data structure that has state and behavior. Object A has a
reference to object B because objects can have references to other objects. Having that
reference, object A can communicate with B. It could send it messages, it could invoke
its methods. Object B provides an interface that constrains access to its own state and
resources, so object A doesn't get access to B's innards, it just gets access to B's public
interface.
Object A does not have a reference to object C, so object C cannot communicate or
object A cannot communicate with object C. In an object capability system, an object
can only communicate with the objects it has references to.
There's nothing really surprising here. This is just object-oriented programming, except
we're looking at it from a security perspective. An object capability system is produced
by constraining the ways that objects are obtained. A reference cannot be obtained
simply by knowing the name of a global variable or a public class. So in an object
capability system, there are exactly three ways to obtain a reference: by creation, by
construction and by introduction.
By creation is obvious. If I create an object, I need to get a reference to it, otherwise
there is no point in having created it. By construction means that an object may be
endowed by its constructor with references, and these could include references in this
constructor's context and inherited references.
Then the interesting case is by introduction. Here A has references to B and C. B has no
references, so it can't communicate with A or C, and similarly C has no references so it
cannot communicate either. References are unidirectional.
Here A calls B passing as an argument a reference to C. And once this is delivered, B is
now able to communicate with C. It has the capability now to communicate with C,
which is why this is called the object capability model.
If references can only be obtained by creation, construction or introduction, then you may
have a safe system. And if references can be obtained in any other way, you do not have
a safe system, which is the current state of the art.
Potential weaknesses we need to avoid are arrogation, corruption, confusion, and
collusion.
Arrogation means to take or claim for oneself without right. Ways of doing this are
global variables, which are a weakness in JavaScript. A similar weakness that you can
see in other languages are public static variables. Anyplace where simply by knowing
the name of a variable or something contained within it gets you access we need to avoid,
where standard libraries that grant powerful capabilities like access to the file system or
the network or the operating system simply by knowing the name of a class. And worst
of all obviously is address generation. So any language which allows you to generate an
address will never be secure.
We need to avoid corruption. It should not be only to tamper with or circumvent the
system or other objects.
Three, confusion. It should be possible to create objects that are not subject to confusion
because a confused object could be tricked into misusing its capabilities.
And then finally collusion. It must not be possible for two objects to communicate until
they've been introduced. If two independent objects can collude, they might be able to
pool their capabilities to cause harm. For example, I could give gasoline to one object
and matches to another, and there's no danger unless they're able to find a way to
communicate.
This allows us to have rights attenuation. Some capabilities are too dangerous to give to
guest code. So we can instead give those capabilities to intermediate objects that will
constrain the power. For example, an intermediate object for a file system might limit
access to a particular device or directory or limit the size of files or the number of files or
the longevity of files or the types of files, for example.
Ultimately every object should be given exactly the capabilities it needs to do its work
and nothing else. So capabilities should be granted on a need-to-do basis. So where we
think correctly about information hiding, we take it a step further and do capability
hiding.
Ultimately objects or facets can be very lightweight. Oh, this slide's out of order. And
they're really easy to make in a class-free language like JavaScript. In fact, classical
languages are much more awkward for creating facets. So what do I mean by a facet? A
facet is an object or an intermediary which can restrict access to a dangerous object.
So here I've got a guest object which wants access to a dangerous object. Instead we give
it a facet, so all of its requests get filtered by the facet, which can step down the power.
References are not revokable. Once you introduce an object, you can't ask it to forget it.
Actually, you can ask it, but you shouldn't depend on it honoring your request. And that's
sometimes regarded as a weakness in the capability model, but it's not. I'll just show you
a way of getting around that.
Here a guest object has a reference to an agency object, which is potentially going to
introduce it to a dangerous object. But instead it produces a facet and it gives the facet to
the guest object. And it could be a simple passthrough or it could be something that does
filtering.
When the agency wants to revoke the capability, it sends a message to the facet saying
forget your capability, so the guest code still has a reference to the facet, but that facet is
now inert. So we can't ask it to forget its reference to the facet, but we can make the facet
useless. A facet can mark requests so that the dangerous object can know where they
came from, which allows us to do accountability.
So facets are really nice. They're expressive, they're easy to construct, they're
lightweight, particularly in a class-free language like JavaScript. They allow us to do
power reduction. They provide patterns for revocation, notification and delegation. And
it turns out the best object-oriented patterns are also capability patterns.
So in looking at how to go forward with JavaScript, there are some competing views on
the way forward. I think that the most pressing problem we have in JavaScript and in the
browser is security, and that's the thing we should be fixing. But there are also voices
within the JavaScript community that are calling for more feature richness, which are
mostly rooted in being dissatisfied with JavaScript not being a different language and
wishing to turn it into a different language.
I think that's a bad idea, particularly in the case of this language, because Web standards
have extraordinary compatibility requirements. Once a mistake gets into a standard, it's
virtually impossible to correct it. It's made more difficult because users never opt into
this stuff. They're always opted in by default, but on schedules which are unenforceable.
So I think minimalism should be highly valued in standard. And committees are not
good at minimalism. Committees are famous for maximalism. And I think the best way
to make this language better is to make it smaller.
So we see standards, particularly in the Web, which are entertaining way too much
speculative technology. There was a battle for the soul of ECMAScript that happened
over the last year or two. And I'm very happy to report that the good guys won, where
the good guys were me and Microsoft in this case, but it could have been others but it
wasn't.
There was a desire to significantly increase the complexity of ECMAScript or JavaScript
without at the same time making it possible to write anything that we can't write now.
And, worse, not making it possible to prevent anything that we can prevent now. So
from my view, it was a lot of new complexity with very little value.
We're seeing the similar thing happening with HTML 5. I think that project is off the
rails. So they're looking at a lot of new features, any one of which you can look at and
it's sort of attractive, but there's just way, way too much stuff and it doesn't all work well
together and it's going to take much too much time to specify.
And the Web community is insisting that people be implementing the new proposal now
as though it were standard when it has not been through any kind of formalism yet. I
think that's a really bad state of affairs, and I'm hoping W3C will recall the current
HTML 5 effort and refocus it.
I think that a standards process must be risk averse. Because, again, once an error gets
into the standard, it's virtually impossible to get it out. And as a standard becomes more
popular, as it touches more people, our ability to modify it vanishes to virtually nothing.
If you have a standard which is not popular, which is not widely adopted, then you've got
a lot of license to fiddle with it and try to get people to like it.
The problem with JavaScript is it became big and important without anybody liking it.
So they're trying to improve its likability. But I think it's too late for that. We're stuck
with the language that we have. So the dilemma that we have is that good standards
happen slowly and our need is urgent. The Web standards are currently a frustrating
progress and endangering everybody who uses the Web. So we need to get this fixed.
And the standards process is failing us. So that is the difficult place where we are right
now.
One interesting approach to making the language safer in current implementations is
what's being called safe JavaScript, and there are three proposals which are all really
good. There's Caja being developed at Google. There's Scott Isaacs' Web Sandbox that's
being done here at Microsoft. And there is ADSafe that I'm doing at Yahoo!. All are
approaching the problem slightly differently, but are all similar in that they work with the
browser as it currently is and take steps to modify the language in such a way that
programs become safe.
All of these systems will make it possible to solve the mashup problem at least in the
short term in which we can have mutually suspicious code work together cooperatively
within a single page. This is a really, really good thing.
I'll talk a little bit more about ADSafe since I know it best. ADSafe is a system for safe
Web advertising. As currently practiced today, an ad on a Web page is a mashup. And if
that ad is allowed or is able using the turducken exploits to get code on that page, that
code gets access to everything the page can do. So for the cost of an ad you can steal an
identity, which is pretty attractive. So we need to fix that. And ADSafe takes an
interesting approach in defining a subset of JavaScript and that subset is a safe language
and within that subset we can allow a script to do whatever it needs to do.
ADSafe works by enforcing a safe subset of JavaScript. And it does it by statistic
validation. It does no code rewriting. One of the advantages of statistic validation is that
there's no impact on performance, so there's no runtime penalty for it. And it means that
we can do validation at every step in the delivery pipeline, from the creation of the
creative through the agency, through the aggregators, through the ultimate delivery
network, we could even do validation within the browser. And we can do it post delivery
to verify that in fact it's being done correctly at every step.
The downside is that it requires new programs being written to a specific set of rules.
The most drastic of the rules is that you cannot use this in a JavaScript program because
this can easily become bound to the global object and we can't allow guest code to get
access to the global object. But it turns out because of the power of lambda, you can do
everything you need to within the language without this. JavaScript without this is still
an amazingly capable language, but it means that new programs are going to have to be
written to those rules.
Web Sandbox and Caja have the advantage that they're going to work with almost all
existing code. But they're going to have a more severe performance penalty.
Ultimately, though, I don't trust any of these mechanisms to service well over the long
term. They depend on our having perfect knowledge of the browser platform to make
sure that we patch or interpret or prevent everything that needs to be prevented. I'm not
confident that we're going to be able to do that until the end of time. I am confident that
they will allow us to go forward for maybe the next two or three years, but ultimately
we're going to have to fix JavaScript.
So I'm proposing a new language which is currently called Secure JavaScript, which must
be incompatible with the current third edition or the proposed 3.1 edition. If it were
compatible, it would have to share all of the weaknesses of the existing language. Also,
incompatibility gives us a license to correct many of the problems that the current edition
cannot fix.
It turns out there are a lot of really bad features in JavaScript. None of those really bad
features are useless. All of them are useful in some way, and there are very clever people
out on the Web who have figured out a way to exploit every error in the language. And
so the dependency is such that we cannot correct the language without some serious kind
of opt in, and that's something that the Web platform doesn't have.
One particular downside of this is that lacking compatibility in the design process could
lead to a lack of feature discipline, similar to what we saw in the ES4 adventure.
So next week I'm hosting a meeting of TC39, which is the ECMAScript working group.
And we're considering a language which we call Secure ECMAScript. We'll be looking
at the smallest modification to JavaScript that we can make which will produce a
capability language. So stay tuned to that. Assuming we come up with a design, then
we'll have to be doing some testing and some experiments. And after the conclusion of
that, we'll look forward, doing some deployments, and if that works well, then we'll be
looking at writing some standards. But that's probably going to take a long, long time.
And a while to finish.
So that's all I've got. Thank you very much. I believe we have some time for some
questions. Yes.
>>: Will you be participating in the upcoming Web apps workshop on security?
>> Douglas Crockford: I will not be participating at the upcoming Web apps conference
on security.
>>: It would seem like a useful time, though [inaudible] some of the same questions at
the level you're raising here [inaudible] presentation for the other participants?
>> Douglas Crockford: Yeah. One difficulty I have at being at Yahoo!, Yahoo! is a
member of the W3C, but we do not participate, which is an unfortunate policy, but that's
our current policy. I'm hoping that we'll be able to change that. But I haven't yet.
I was able to get Yahoo! to join ECMA, so we've been able to have a good influence
there. But currently we're sort of locked out of W3C. Yes.
>>: And so if Secure JavaScript gets like standardized, are you hoping that browsers stop
work on JavaScript and continue on with Secure JavaScript and leave JavaScript as it is?
>> Douglas Crockford: That's a good question. So if the Secure JavaScript language
gets implemented, would I expect the browser makers to stop supporting and going
forward with the existing language? No. I would hope that they would do both.
There's a large class of what's out on the Web that doesn't care about security. And that
can continue to run fine with the existing language. But there are new, important
applications which are waiting for the secure language, and so we need both. So there's
going to need to be some mechanism which allows a page to describe or identify itself to
the browser and say this is the language that I want and all of the script which runs on
this page or in this application needs to be in this language or the other.
One thing we can't do is allow the attacker to choose what language he wants to use. So
if a page decides it wants to use a secure language, then that's the only language that will
work there. And I think that dual use pattern is going to be necessary for going forward.
Yeah.
>>: Earlier you brought up the idea that if an attacker could inject any sort of script into
the site, then essentially they can call any other script that it's run with full privileges.
But with the idea of introduction, even with this you still have that same problem because
this small amount of user attack run a certain script can introduce all the other scripts to
everything in the system. So ->> Douglas Crockford: Right. So an attacker can bring in scripts, but those scripts do
not have capabilities to communicate with the rest of the page or the browser
environment.
>>: [inaudible] introduced because the attacker has full privileges.
>> Douglas Crockford: You're mixing time frames. So in the current Web, there's no
restriction, so everybody gets access to anything. So we're going to have to fix
JavaScript. We also need to fix the DOM. Because the DOM is currently formulated. If
you have access to any node on the page, you can follow its parent up to the root. That
gives you access to every node. And the root also has access to the network, which
means you can go out and do bad things.
So in the capability model, in the secure language, a Widget will only have the capability
to mess with its piece of the tree. It can't get beyond that piece of the tree. And it doesn't
have access to anything in the global environment. So it is unable to communicate with
anything else until its introduced. It might be given the capability to request additional
scripts for itself or it might not. But if it is, those scripts will not have access to any more
capabilities than what the Widget itself has. So if the Widget is already constrained, the
new scripts will not be able to do anything else. Yes.
>>: It seems like you're going to be at odds with the developers themselves, like the
trend to -- the reason we have the global [inaudible] space is because it's convenient more
than anything else, right? And what you end up with basically, kind of like you don't
have the [inaudible] space you're going to end up with I've got a big object at the top
which I introduced to all my variables which is where I keep all of my state and
effectively a global [inaudible] space.
>> Douglas Crockford: Well, but it's not effectively. It's global only to the Widget. So
it means that we're going to be more reliable and that you're not going to have accidental
collisions with names of other Widgets.
Only stuff which needs to be explicitly exported from that will be visible on the outside.
So you can -- in terms of the current model, every compilation unit has its own little
global space, which is available only to that unit.
>>: Does it mean there's no discovery on any object [inaudible] facet that you can't
discover the way that the agent talks to the facet?
>> Douglas Crockford: A facet can reveal anything it wants to. So if it wants to provide
a call which allows for reflection or describing of what interfaces it provides, it can do
that. But if it chooses not to, then there's no way to get that information from it. Yes.
>>: [inaudible] to change the DOM. And I can imagine changing the JavaScript
language, but changing the DOM seems much more heavy weight. Is the success of this
project tied to success [inaudible]?
>> Douglas Crockford: The question was about changing the DOM and the difficulty of
that. It's something we're struggling with now. So if you look at Web Sandbox and if
you look at Caja and ADSafe, they're all wrapping the DOM. So none of them allow
access to -- direct access to a DOM node because that's too dangerous.
So the safety of those three systems depends on the quality of those runtimes in
protecting those nodes and making sure there's no leakage, which is a difficult thing to do
and they're all doing a pretty good job right now. But, again, I'm not confident that we're
going to do it forever. It's just -- I think it's hard. So that's why I think ultimately we
need to go further.
One interesting development in the AJAX experience is we have had lots of amazing
experimentation with APIs that ride on top of the DOM. So you look at every AJAX
library and they all have a radically different way of managing that API and presenting it
to the application, and they're all brilliant. You know, Prototype and Dojo, YUI and
jQuery -- jQuery was maybe the most influential and now everybody has copied that
pattern, which you can get a bundle of nodes and act on them all simultaneously.
So I think the way we're going to want to look at fixing the DOM is adopting one of those
or synthesizing a common one, something that gets the right idea, which gets the
application interface up at the right level, which right now it's way too low, getting it up
there, and also making it capability aware at the same time so that you can only mess
with nodes that you have reason to be messing with.
And so I think ultimately that will make the DOM more attractive to programmers,
because it's actually going to work right, and they don't have to manage libraries which
are going to be changing on them and worrying about the cost of loading them and
caching them. The browser will just work right for the first time. So that's going to be an
interesting thing.
But the Caja team is looking at the unified -- or one thing all the AJAX libraries have in
common is a DOM teaming layer, which they deal with weaknesses in the DOM
interface and incompatibilities that exist between different brands and different versions
within the brands. And that's something that they all do in a pretty similar way.
So the Caja project is looking at unifying that. They've got a project called Bridal, which
is going to attempt to take all of that out so that the AJAX libraries won't have to deal
with that anymore. And it will just be one common sanity layer which will be open and
available to everybody. And so that looks like a good place to start building this new
develop API from. Yes.
>>: These Widgets that you're talking about, are the Widgets just going to be
communicating with the browser or is there going to be communication between Widgets
and Widgets setting up facets for other Widgets?
>> Douglas Crockford: Yeah. We're going to have communication going on between
Widgets, we're going to have communication going on between Widgets and servers and
perhaps to other components, maybe on the desktop or maybe in some other place.
>>: But is that necessary? Because it seems like that's more opportunity to make
mistakes.
>> Douglas Crockford: Well, that's why -- it is an opportunity to make mistakes, which
is why we need to get it right. So, you know, I think it's about time to talk about getting
it right.
So if you look at the object capability model, and which you look at, you know, what
each object can do and how each object can communicate, take the same thing and do it
at a macro level. So each object now represents a computing vessel, which we call a vat.
And which is isolated, as good modules are, from other computing vessels. And they can
introduce each other using the same introduction patterns. And so we can then have
distributed capabilities, which can go from system to system. And that becomes the
plumbing by which we can make mashups.
And that will also allow for us to mash up components that are not written in JavaScript.
It will open it up so that we can mash up everything. And that's when the stuff gets really
exciting. And JavaScript leads the way. Yeah.
>>: Two questions. Are you trying to distinguish between intentional introduction and
unintentional introduction?
>> Douglas Crockford: The intention that all introduction is intentional.
>>: Okay. I'm worried about -- I mean, the problem of proving isolation within a shared
address space is -- in programming language resources is pretty difficult. It seems like it
would get to the things like ownership types and stuff like that. I assume that's not what
you're talking about.
>> Douglas Crockford: No. It's much simpler than that. It's simply managing the object
references. And if you can guarantee that references are only obtained in particular ways,
then it doesn't matter who owns it. Ownership is irrelevant. The only thing that matters
is what you have access to.
>>: The other question was if you look at other programming languages that are trying to
be Web programming languages [inaudible] specifically Silverlight, say, would you make
the same or different criticisms of the security?
>> Douglas Crockford: I would make the same complaint. Silverlight, AIR, Flash, all -I see having weaknesses. All of those are vastly superior to the Web browser in every
aspect except its security. That's one place where, despite all of its flaws, the browser is
ahead. Yes.
>>: There's some mechanisms built into the .NET system [inaudible] such as codecs
[inaudible] which is a sub-API level [inaudible] doesn't exist in any other language
[inaudible]. It seems like it solves a number of problems such as the all-or-nothing
access to reflection [inaudible] how would we get to that sort of [inaudible] it seems like
you've got now dozens and dozens of facets being created just so you can pass a limited
capability and secure fashion, and that's either a bunch of interfaces or it's, you know,
some other [inaudible].
>> Douglas Crockford: Right. That's more than I was planning to tackle today. So I'm
not here to suggest how you should fix C Sharp, I'm just here to talk about how we can
fix JavaScript. But I think the things that we can do to JavaScript will inform things that
we can do in other languages.
>>: Is it fair to ask just in response to that, to ask you to talk about mirrors for a
moment? Isn't that the usual capability-based collusion to partial reflection?
>> Douglas Crockford: I'm not really talking about reflection. I'm really talking about
constraining object references. And having that, you could then implement mirrors or
any other kind of reflection system. But the key thing is how you constrain the object
references. If you want to look at a language which actually demonstrates this, there's a
language called E which is available at a Web site called erights.org, which came out of
work that we did at electric communities 10 or 15 years ago.
E is an object capability language and demonstrates a lot of this stuff. And this thing
that's interesting about JavaScript is there's enough commonality that it suggests how we
can translate or transform JavaScript into such a language. Yes.
>>: Do you have a goal to run against the existing platforms? I mean, have you designed
this language where you're thinking about how it would actually run on -- with no
browser implementing language? Or is it something that requires that the browser adopt
it [inaudible]?
>> Douglas Crockford: I'm looking at a multi-tier approach. So in the short term, we're
reusing the safe JavaScript transformers or subsets. Which I think is a good short-term
solution, but I don't have confidence it's a long-term solution.
Concurrently I want to be developing the next browser platform, which will have
language -- secure language built in and a secure DOM built in. And then beyond that
I'm looking at getting away from the browser and trying to figure out how we would have
done the Web if we hadn't started there. You know, there are things we see in Silverlight
that are brilliant and should have been part of the Web from the beginning which weren't.
I'd still like to figure out a way to make that stuff work right.
>> Wolfram Schulte: So maybe since some people would like to [inaudible] maybe first
say thanks to and [inaudible].
[applause].
>> Wolfram Schulte: And I'm sure that Doug would like to take maybe more questions,
but if people want to leave, and Doug will be here today and tomorrow and there's a few
meeting slots left, so if you want to meet Doug, maybe send me an e-mail and I'll try to
schedule it. Thanks.
>>: One thing I'm just going to mention is [inaudible] Sandbox based on the questions
[inaudible] there's interest, I'll try to get another hour set up where I can drill into what
we're doing at Microsoft and the security capability [inaudible] websandbox.livelabs.com
to see some of the work we've done.
>>: Could you repeat that again, what Web site?
>>: Websandbox.livelabs.com. It's joint project between Live Labs, Windows Live and
a group of others.
>> Douglas Crockford: Yeah. I'd just like to say I think it's brilliant stuff. I'm a big fan
of a Web Sandbox. Certainly worth looking at. And I think it is what's going to save us
in the short term and buy us time to get things right in the long term.
>>: [inaudible] Doug and I are all on the same page [inaudible].
>> Douglas Crockford: Yeah. So one of the things we'll be looking at next week is can
we unify or find commonality or cooperation between the Caja efforts and the Web
Sandbox efforts. Because they're both doing really interesting things and taking
remarkably similar approaches at that. And so it looks like benefits could be obtained
from some increased commonality.
>>: So the capabilities are based on references, you talked about references to object.
The other references that seem interesting are reference from the page to the server,
which is URL, your reference from a server to a thing on the page, which doesn't really
exist [inaudible] can you imagine capabilities encompassing this?
>> Douglas Crockford: Absolutely. So one of the capabilities a Widget may expect to
be granted is the capability to communicate with its source server or some other server
that it's configured with. It can then either act as a proxy to that server for the other
components that it has to work with, or since that ability to interact with its server is a
capability, it could give it to another Widget it could introduce, then, to its server.
>>: And with that kind of same work across communications being intercepted
[inaudible]?
>> Douglas Crockford: No. So one of the assumptions there is that intersection by
malicious third parties is not possible. Rob.
>>: Just a -- this really isn't what you were talking about, but I mentioned in my e-mail
to you yesterday I was going to ask [inaudible] obviously there are more higher
performance [inaudible] machines [inaudible] anything related to secure JavaScript. So
on that front right now there's V8 [inaudible] Chrome [inaudible], there is GreaseMonkey
which is in Mozilla and scroll fish [phonetic] which is in Safari. Do you have any
opinions about the relative merits of any of the other actual implementations or their
[inaudible] approaches?
>> Douglas Crockford: I don't have a good understanding yet as to how the performance
of those is going to work out. Right now we're looking at sort of spec wars and we don't
know if any of the current benchmarks we're looking at are going to be meaningful. But
it is encouraging to see work in this dimension.
One of the arguments that had been made in favor of the ES4 proposal is that a lot of the
complexity they were adding to the language was necessary in order to improve the
performance of the language. That turned out not to be true at -- for a whole lot of levels.
So instead we're seeing people improving the language as it is. If we would remove a
couple of things from the language like width and fix eval, it gets easier.
So a smaller language rather than a large one benefits from that.
Given the approach that the Web Sandbox and Caja are taking, a high-performance
JavaScript engine definitely provides a lot of benefit. ADSafe doesn't care because it
doesn't have any performance overhead of its own.
The other benefits we're going to see from higher performance will be better battery
consumption on mobile. I don't know if that's going to be a significant savings, but it
could be. And it may also allow for a wider class of applications being possible in this
language than has been considered so far.
>>: One thing to keep in mind, though, is the benchmarks are highly focused on
[inaudible] execution but the real world [inaudible] probably more throttled by the DOM
interaction. It's really going to help apps, I'll just [inaudible] high performance
[inaudible] make a big difference [inaudible]. But a lot of the constraints are going to get
hit on the other side. So I think we're going to see a follow-through now with, okay, now
the engine [inaudible] how do you make the DOM fast.
>> Douglas Crockford: Yeah. That's really important. The IE 8 team showed us some
statistics that on Gmail in opening a thread, which is one of the most compute-bound
things that happens on Gmail, about 15 percent of the time was being spent on JScript.
You know, all the rest is in the DOM. So for most of the applications we're looking at
now, faster JavaScript engine's not going to make a significant difference.
Mozilla is looking at eventually reimplementing the entire browser in JavaScript, in
which case the DOM would be implemented in JavaScript, and so if JavaScript is going
faster, then that becomes feasible.
>>: So you talked a little bit about -- so information hiding is key to object capability.
And right now you're basically -- my impression is you're able to do it today the same
way Scheme programmers have done objects.
>> Douglas Crockford: Exactly.
>>: [inaudible]
>> Douglas Crockford: Yeah.
>>: Which is great theoretically, but it feels like many JavaScript programmers aren't
going to jump onto that and say, great, we have a new way of representing fields with
[inaudible]. Do you think we need to extend the basic standards notion of properties on
objects as well as information hiding?
>> Douglas Crockford: That's a really good question. So we are seeing much more
adoption of the closer patterns in JavaScript, so all the AJAX libraries are using it pretty
aggressively now and we're seeing more and more instruction in the general community
of it.
But at the same time, in the next edition of JavaScript we're providing more control over
objects and allowing for hardening them. So you'll be able to say this object can receive
new properties or you can designate objects as being read-only or unmodifiable. So and
we'll also have -- getters and setters so you can be doing some programmatic control over
access of things.
So we still won't have private properties of objects, but we'll have more options. And I
think that's going to be enough to get us along the way. Yeah.
>>: One follow-up question to [inaudible] question. So [inaudible] 2005 which is
reasonably represented as a benchmark for the service side, is there any question now that
we're kind of converging on a features set for [inaudible] on the client side that would
actually balance JavaScript and [inaudible] sort of have a reasonably large body
[inaudible] being executed?
>> Douglas Crockford: I would think that all the parties you mentioned are now visibly
making benchmarks in order to demonstrate the superiority of their engines. And they
will include those sorts of metrics.
>>: [inaudible] benchmark is representative of the real world.
>>: Right. But, I mean, what I was getting at was is there going to -- is there any kind of
industry -- larger industry push towards having something that everyone can agree is a
good benchmark? Because obviously individual ones get into [inaudible].
>> Douglas Crockford: I think that's going to be the state of the art for a while. I mean,
part of the problem is unless you're on a team that's actually writing these browsers, you
really don't have visibility on where the time is going. It was -- you know, like we only
got the IE 8 statistics at the Velocity conference a few months ago and was like -- you
know, we had always suspected that, but we'd never seen the numbers before. And it was
really useful to have seen them.
But for the most part, browsers are black boxes and they hide a lot of the details of their
operation. We can't declare anything as being dirty, we can't require a redraw. It just
kind of does what it needs to based on its own understanding of what's going on. And it's
pretty opaque.
>>: Always those kinds of things are a pain in the ass later on [inaudible] performance
benchmarks we have many the computers [inaudible] bunch of lying and cheating to get
past the benchmarks, you know, like, if this process is running, then skip all of this code
kind of stuff [inaudible].
>>: [inaudible] is to get a good performance [inaudible] yeah. At the end of the day,
computation is going to make us all get faster, more than a benchmark. I think it's in our
of ability which is going to be the heart of the problem [inaudible] how do you come up
with a performance suite. I mean, I don't know what your view is, but I think the Acid2
and 3 tests are a complete joke.
>> Douglas Crockford: Oh, they're terrible.
>>: They're meaningless. They're tests that are supposed to tell you if you're good at CS,
or good at JavaScript, they're focused on basically the most bizarre esoteric crap that no
one in the real world actually cares about, but they make a pretty [inaudible] screen
[inaudible] a real set of tests that actually reflect how you build your apps.
>>: I think that's going to be a lot more interesting.
>> Douglas Crockford: Yeah. And one of the discouraging things about the Acid2 test is
there's stuff in there which should not have ever been an HTML. It's just really bad,
nasty stuff. And IE just implemented all that stuff because they needed to in order to get
the pretty face or the silly face to appear on the benchmark page.
>>: [inaudible]
>> Douglas Crockford: No.
>>: I mean, that's Acid2 leading the test for standards.
>> Douglas Crockford: But it's not the right standards.
>>: [inaudible]
>> Douglas Crockford: Yeah.
>>: [inaudible] it doesn't resolve gray area.
>>: What are some of the horrible things you're thinking of?
>> Douglas Crockford: Oh, like data URLs in a particular position, stuff which shouldn't
happen. Yeah.
>>: [inaudible] communication fit in with [inaudible] ECMAScript? I mean, currently
there's like client access policies and [inaudible] bunch of hacks [inaudible].
>> Douglas Crockford: Yeah, definitely. So part of the -- our thinking about how we do
distributed capabilities, I think that becomes the way that we do communication.
One of the difficulties of maintaining the standards for the DOM or for the browser is that
there is the DOM and there is -- which could include these capabilities and there's
JavaScript, which doesn't, and they're maintained by completely different organizations
who as far as I can tell do not talk to each other ever about anything. And we need to fix
that somehow.
So even though it's outside of our charter in the ECMAScript working group, we're now
going to be looking at the DOM API and pulling that into JavaScript. Since -- if you look
at the mental model of most Web developers, that's where it is anyway. Most of what
you hear when people say "I hate JavaScript because," that because is almost never in the
language itself. It's almost always in the DOM. So I think the language should take that
work on. Particularly since I think it's being mismanaged by the HTML 5 group now.
>>: [inaudible]
>> Douglas Crockford: It's early yet. Yeah.
>>: [inaudible] initially it was like GWT and involve that that are basically taking
JavaScript and then turning it into the C portable assembly language that you don't
actually program that you want something that has a more static typing or type of ability
to split across server to client or whatever. Do you see that as being a trend or do you
think that JavaScript is going to continue to [inaudible] maybe even grow into its direct
usage by [inaudible]?
>> Douglas Crockford: Yeah. I think we're going to see more of that. It's amazing the
lengths people will go to to avoid having to learn JavaScript. And I would never have
expected that JavaScript was going to turn into the assembly language of the Internet.
But it is. And it's a language which is not well suited to that role. But it is. And I think
we're going to see more of it, not less of it. Yeah.
>>: Where do you see things like the Sandbox type of thing [inaudible]?
>> Douglas Crockford: I'm sorry, where --
>>: Where does sandbox [inaudible] what do you think of that, how do you see it fitting
in [inaudible]?
>> Douglas Crockford: I think it's well intentioned, but I don't think it's the right thing. I
would rather start over and do the stuff from principles. I don't think that's the case there.
It looks like a set of Band-Aids to me. And our experience with Band-Aiding the
browser in the past has not been terribly effective.
>>: So I've noticed -- I mean, as long as you're kind of stepping into another language,
I've noticed that a bunch of the important Web sites do some really wacky things to
improve performance and behavior, like, whatever, compressing names [inaudible] which
is really just [inaudible] shorter name if possible, eliminating line breaks and white space
and comments and other kinds of stuff like that. Do you think that's actually part of
something that JavaScript specification or ECMAScript specification should be
addressing?
>> Douglas Crockford: That's a really good question. We do see significant
performance improvements from minifying code and then G-zipping the code and
reducing the startup time on the page, it's big. It -- primarily it's big because as in most
browsers currently, when it's loading JavaScript, it stops all other processing. And so we
cannot be loading additional pictures or other assets in parallel to the script loading.
>>: [inaudible] performance model [inaudible] that are easy to control, right?
>> Douglas Crockford: Yeah. So we're seeing that fixed from now. So IE 8 is doing
some clever stuff, Mozilla is starting to do some clever stuff in which they're not
blocking on script loading.
In doing that the benefits of minification and G-zipping are reduced, but there's still a
benefit from doing that.
Should that be something that's talked about in the language standard? Depends on how
much of the DOM gets put into the language standard.
>>: Guess the reason I bring I up is because, you know, like C Sharp is [inaudible] CLR
has a CLI which has IL which is the thing that's compact and really represents the code
compiled [inaudible] seems like JavaScript if we're really talking about it being an
assembler of the future, I think you'd want some minified version of the language.
>> Douglas Crockford: Well, since the language already defines that, the minified
language has exactly the same grammar as the maxified language. So there's no new
specification required to describe that.
>>: Sure. But just like you said, the DOM there is [inaudible] the DOM is really part of
the language, then you have to keep the full content [inaudible] as a DOM grows or as the
public API surface grows or the shared API surface grows [inaudible].
>> Douglas Crockford: I'm not sure that's -- that we need to do any work in that area.
>> Wolfram Schulte: Maybe we wrap up here?
>> Douglas Crockford: Yeah.
>> Wolfram Schulte: Thanks again for [inaudible].