A coarse-grained solution requires some sort of containment vessel for
the modules or widgets or gadgets or portlets, and a conduit system
which provides for limited communication, restricting message flow
only between authorized pairs, and keeping the messages free of object
references.

The containment vessel is sometimes called a vat.

The conduit should be based on capability discipline. It should permit
communication between vats which are hosting programs in incompatible
languages. It should permit communication between vats on a page. We
should consider allowing communication with vats on different pages,
and vats in different applications. The immediate problem is to fix
the browser, but this could easily unify the browser and the new
client platforms.

I quote from the MashupOS paper from Microsoft that Doug referred us to:

There is either no trust across principals through complete isolation
or full trust through incorporating third party code as libraries.

Where can I learn about these libraries--who can add to them and who
can call them?
Is there an implication that the 'third party' is mutually trusted?

--- In caplet@yahoogroups.com, Norman Hardy <norm@...> wrote:
>
> I quote from the MashupOS paper from Microsoft that Doug referred us to:
>
> There is either no trust across principals through complete isolation
> or full trust through incorporating third party code as libraries.
>
> Where can I learn about these libraries--who can add to them and who
> can call them?
> Is there an implication that the 'third party' is mutually trusted?

There are lots of Ajax libraries out their. You can find some pointers
to them at Ajaxian.com. The web developer selects scripts from the
library and includes then using HTML script tags. These scripts have
access to everything. The scripts generally do not have secrets of
their own.

Most libraries get copied to your server. Some libraries, such as Dojo
and YUI, can be loaded from 3rd party servers.

A recent fad on sites with user-generated pages (like MySpace) is
inclusion of 3rd party JavaScript badges on web pages. These badges
provide access to logging, galleries, and video. And the badges have
access to everything.

Google Gears, a set of tools for offline Ajax applications, was
introduced today at the Google Developer Day in San Jose. Gears is
currently a browser plugin. It could ultimately be standard equipment.

http://code.google.com/apis/gears/

The most interesting component of Gears is the WorkerPool. It allows a
script to create a new JavaScript execution context, and to have a
script executed in it. That context is isolated in its own process.
Communication is provided in the form of JSON message passing. In its
current form, communication is constrained by the Same Origin Policy.

The Worker context is a vat. I think it would be very interesting to
apply capability discipline to the management of message passing, so
that messages can be safely and appropriately be exchanged between
widgets, gadgets, badges, iframes, other pages, other applications,
and other computers.

There is a lot of interest in Gears, and I think this is the right
moment to push it in a more secure direction.

We now have two webvats, the HTML frame or iframe, and the Gears's
worker pool. What we need next is a safe common way to let them
communicate.

I think that takes the form of some kind of vat manager, which assigns
unique, unguessable IDs to each vat, and routes messages which are
addressed with those IDs. The messages can be represented as JSON
texts, so the messaging will not cause capability leakage.

What other services should the vat manager provide? Should it mark
every message with a return address? Should it provide location
services for vats sharing a common domain, or must such discovery be
done through the server? Should it send disconnection messages when it
sees vats disappear to correspondents of those vats?

On 6/5/07, Douglas Crockford <douglas@...> wrote:
>  I think that takes the form of some kind of vat manager, which assigns
>  unique, unguessable IDs to each vat, and routes messages which are
>  addressed with those IDs.

Typically, we don't do access control at the vat level, but at the
reference level. Typically, the vat identifier is just a
self-authenticating identifier, like a fingerprint of the Vat's public
key. Since the communication channels in this case are local, we don't
need crypto to secure them, so really, any old string is perfectly
fine as a vat identifier. This is fortunate, since the Gears API
doesn't seem to give us any control over the worker ID.

Looking at the Gears API, it also appears that the messaging system
does not allow forging of the sender's worker ID. If this is so, we
can implement an actual object-capability protocol, using a per-sender
clist, and so we won't need any crypto at all. Each worker keeps a
clist for each of its clients and an inter-Vat reference is just the
pair ( worker ID, clist index). It seems likely that we could borrow a
lot of the design of E's CapTP protocol for managing these clists.

Tyler

--
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/firefox/957/

> Typically, we don't do access control at the vat level, but at the
> reference level. Typically, the vat identifier is just a
> self-authenticating identifier, like a fingerprint of the Vat's public
> key. Since the communication channels in this case are local, we don't
> need crypto to secure them, so really, any old string is perfectly
> fine as a vat identifier. This is fortunate, since the Gears API
> doesn't seem to give us any control over the worker ID.

Naturally. One of the peculiar aspects of widget architecture is that
you have multiple vats that represent a common interest, but which
initially have no knowledge of each other, which want to communicate,
but cannot rely on the page to do the introduction.

They could manage the introduction through their common server, but
that will add a couple of roundtrips to the startup time, something
we'd like to avoid.

An alternative would be if the vat manager could facilitate such
introductions. For example, it could accept requests of the form:
Please introduce me to all of the services that were vended from the
same domain as myself.

A recent development in web application development is The Mashup. A
mashup is a page that is obtaining data from multiple sources and
producing a useful result. A popular example is getting listings from
a real estate site, and applying that location data to the display
from a mapping site.

Mashups are sometimes represented as widgets or gadgets. They take up
some visual space and cooperate to produce valuable services. This is
a powerful indication of the evolution of web architecture.

The Problem comes from applications getting significantly ahead of the
security architecture of the browser. The browser assumes that all of
the components of a page are equally trusted. All scripts run with the
same authority and have access to all of the information and
connections that are available to the page. The only exception is the
iframe, which because of the Same Origin Policy is unable to cooperate
with the other components at all. The Same Origin Policy is too
restrictive, so developers are circumventing it by putting all scripts
where the Same Origin Policy does not apply. This allows mashups to
work, but it is dangerous.

The Caplet Group is looking at a communications method that will allow
putting widgets into iframes or worker pools, and allow them to safely
exchange messages. This would give us a pattern for mashups which is
not dangerous.

The communications method would ultimately connect all our client
technologies, including Flash, Silverlight, JavaFX, Yahoo Widgets, and
advertisements. It will also allow communication with web services
which conform to the method.

The mission for this group is to recommend the interfaces and
mechanisms for this communication method, and to show why it will be safe.

On 6/21/07, Douglas Crockford <douglas@...> wrote:
> The Caplet Group is looking at a communications method that will allow
> putting widgets into iframes or worker pools, and allow them to safely
> exchange messages. This would give us a pattern for mashups which is
> not dangerous.

Which method is that?  Or did you mean that the group trying to come
up with one?
--
Mike Stay
stay@...

--- In caplet@yahoogroups.com, "Mike Stay" <stay@...> wrote:
> Or did you mean that the group trying to come
> up with one?
> --
> Mike Stay

Right.

JavaScript is dependent on global variables. Because of that
dependency, it is unlikely that JavaScript can ever be made secure.
HTML's DOM interface is similarly insecure.

But if we step up a level, we have vats. The HTML page runs in a vat.
Each iframe is a vat. Each worker in the Google Gears worker pool is a
vat. All of the sandboxed client technologies are vatty.

So I think we can solve a much simpler problem. I think it takes the
form of a capability communications manager that can issue unguessable
ids to each vat, provide message routing via those ids, and provide
location services.

It could be implemented in the short term as a browser extension, so
we could enjoy a much faster adoption curve than if we had to wait for
the browsers to be ungraded.

It also could civilize the upcoming battle between Silverlight, Air,
and JavaFX. A common capability communication mechanism would allow
all of these technologies to be mashed up.

This is a great topic for us to explore.
We, from Microsoft Research, have been working on the MashupOS project. Back in
March, we submitted a paper on the topic of protection and communication
abstractions for web browsers. The submission is now accepted to SOSP 2007.

I attached our submission version of the paper; we are working towards a
camera-ready, final version of the paper -- so please don't distribute the paper
without communicating with me first. We'd love to hear your feedback and
critiques. I am particularly interested in hearing your thoughts on the
"sandbox" abstraction/tag, and the "restricted service".

Cheers,

Helen

> -----Original Message-----
> From: caplet@yahoogroups.com [mailto:caplet@yahoogroups.com] On Behalf Of
> Douglas Crockford
> Sent: Thursday, June 21, 2007 11:48 AM
> To: caplet@yahoogroups.com
> Subject: [caplet] The Mashup Problem
>
> A recent development in web application development is The Mashup. A
> mashup is a page that is obtaining data from multiple sources and
> producing a useful result. A popular example is getting listings from
> a real estate site, and applying that location data to the display
> from a mapping site.
>
> Mashups are sometimes represented as widgets or gadgets. They take up
> some visual space and cooperate to produce valuable services. This is
> a powerful indication of the evolution of web architecture.
>
> The Problem comes from applications getting significantly ahead of the
> security architecture of the browser. The browser assumes that all of
> the components of a page are equally trusted. All scripts run with the
> same authority and have access to all of the information and
> connections that are available to the page. The only exception is the
> iframe, which because of the Same Origin Policy is unable to cooperate
> with the other components at all. The Same Origin Policy is too
> restrictive, so developers are circumventing it by putting all scripts
> where the Same Origin Policy does not apply. This allows mashups to
> work, but it is dangerous.
>
> The Caplet Group is looking at a communications method that will allow
> putting widgets into iframes or worker pools, and allow them to safely
> exchange messages. This would give us a pattern for mashups which is
> not dangerous.
>
> The communications method would ultimately connect all our client
> technologies, including Flash, Silverlight, JavaFX, Yahoo Widgets, and
> advertisements. It will also allow communication with web services
> which conform to the method.
>
> The mission for this group is to recommend the interfaces and
> mechanisms for this communication method, and to show why it will be safe.
>
>
>
>
> Yahoo! Groups Links
>
>
>

Sorry that the MashupOS paper I sent out earlier was defective.
Here is a better copy:
http://research.microsoft.com/%7Ehelenw/papers/mashupOS03-19-2007.pdf

We'd love to hear your feedback!

Helen

> -----Original Message-----
> From: caplet@yahoogroups.com [mailto:caplet@yahoogroups.com] On Behalf
> Of Douglas Crockford
> Sent: Thursday, June 21, 2007 11:48 AM
> To: caplet@yahoogroups.com
> Subject: [caplet] The Mashup Problem
>
> A recent development in web application development is The Mashup. A
> mashup is a page that is obtaining data from multiple sources and
> producing a useful result. A popular example is getting listings from
> a real estate site, and applying that location data to the display
> from a mapping site.
>
> Mashups are sometimes represented as widgets or gadgets. They take up
> some visual space and cooperate to produce valuable services. This is
> a powerful indication of the evolution of web architecture.
>
> The Problem comes from applications getting significantly ahead of the
> security architecture of the browser. The browser assumes that all of
> the components of a page are equally trusted. All scripts run with the
> same authority and have access to all of the information and
> connections that are available to the page. The only exception is the
> iframe, which because of the Same Origin Policy is unable to cooperate
> with the other components at all. The Same Origin Policy is too
> restrictive, so developers are circumventing it by putting all scripts
> where the Same Origin Policy does not apply. This allows mashups to
> work, but it is dangerous.
>
> The Caplet Group is looking at a communications method that will allow
> putting widgets into iframes or worker pools, and allow them to safely
> exchange messages. This would give us a pattern for mashups which is
> not dangerous.
>
> The communications method would ultimately connect all our client
> technologies, including Flash, Silverlight, JavaFX, Yahoo Widgets, and
> advertisements. It will also allow communication with web services
> which conform to the method.
>
> The mission for this group is to recommend the interfaces and
> mechanisms for this communication method, and to show why it will be
> safe.
>
>
>
>
> Yahoo! Groups Links
>
>
>

So, someone created this group and subscribed me to it, which I do not
object to, the idea is interesting.

But I'm wondering who did that, and why?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

The protocol I spoke of is described here: (http://cap-lore.com/
CapTheory/Dist/Glass.html#introducer).
It assumes two agents on the same platform and a trusted 'introducer'
which both agents can call.
The agents want to communicate quickly but they have only a
roundabout channel.
No secrets need be kept. In particular a rogue is permitted to see
all communications.
All calls on the introducer are prompt.

(There is a secret buried in the message authentication module.
    If the rogue could impersonate one of the agents over the slow
initial channel the scheme would fail.)

> On 6/25/07, Ben Laurie <ben@...> wrote:
> > So, someone created this group and subscribed me to it, which I do not
> >  object to, the idea is interesting.
> >  But I'm wondering who did that, and why?


On 6/25/07, Marc Stiegler <marcs@...> wrote:
> I would say that markm is the one who subscribed you, except, it would be out
of character
> for markm to surprise you. It would be much more in-character for him to goad
you, as he
> goaded me, into joining yet-another-object-cap-group. This one, though, has a
very specific,
> narrow purpose: to figure out and standardize an obj-cap version of
JavaScript.


Hi Ben,

As far as I remember, as a moderator, I sent you a Yahoo-generated
email invitation. This email msg likely contained a link for accepting
the invitation. Perhaps you clicked on this inadvertently?

In any case, if I did somehow accidentally subscribe you, my
apologies. But I'm glad to have you here!

--
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM

Posted on cap-talk. I will reply on cap-talk and forward my reply here
as well. Further discussion of this should occur on cap-talk, but I'll
forward here any particular messages I consider especially relevant.

The cap-talk list only posts messages from subscribers. To subscribe,
visit <http://www.eros-os.org/mailman/listinfo/cap-talk>.

---------- Forwarded message ----------
From: Kevin Reid <kpreid@...>
Date: Jun 29, 2007 11:16 AM
Subject: Re: [cap-talk] The Caplet Group
To: douglas@..., "General discussions concerning capability
systems." <cap-talk@...>


On Jun 18, 2007, at 12:14, Douglas Crockford wrote:

> The Caplet Group is discussing the situation of the web browser, in
> particular the Mashup Problem, and the possibility of using a
> capability messaging system to allow safe and useful communication
> between frames, worker pools, and other client technologies.
>
> To join, you will need a YahooID.

Why has a new separate forum, which also requires a special signup,
been created?

Personally, I would greatly prefer to see such discussions occuring
on cap-talk *until* they are high-volume enough to justify a forking.

Creating separate forums eliminates the possibility that people will
become interested by seeing the discussion.

--
Kevin Reid                            <http://homepage.mac.com/kpreid/>

---------- Forwarded message ----------
From: Mark Miller <erights@...>
Date: Jun 30, 2007 3:14 PM
Subject: Re: [cap-talk] The Caplet Group
To: "General discussions concerning capability systems."
<cap-talk@...>
Cc: douglas@...


On 6/29/07, Kevin Reid <kpreid@...> wrote:
> On Jun 18, 2007, at 12:14, Douglas Crockford wrote:
[... as previously quoted...]

My sense is that there may be a significant number of people who 1)
are interested enough in various browser security problems that can be
addressed by in-browser language-based object-capabilities, including
mashup and crippled web-app problems, but 2) are not interested enough
in general object-capability issues to join cap-talk. Even if they did
join, the occasional large volume on cap-talk would, I suspect, cause
too many of them to stop paying attention, when they might continue to
pay attention to a more focused discussion.

Since the proposed mechanisms will be specific to language-based
object-capabilities, e-lang would be more plausible than cap-talk
anyway, and e-lang does have a much lower volume lately. However, I
would have the same concern: That the occasional flurry of discussion
about issues not relevant to browser security might lose the attention
of this audience.

--
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM

Let's look at some cases.

Case 1. Pirate.net has a page with an iframe from penzance.org. The
penzance widget is willing to talk to anything, and so is receptive to
messages from the pirate page. This looks pretty easy.

Case 2. Penzance.org has several widgets on the pirate page. Some of
them come from penzance.org, and some from sister site penifore.com.
These widgets want to communicate and mashup with confidential
information, but do not want to allow the pirate page to intercept or
insert messages.

Perhaps there are two facets, a public facet that pirate.net is
allowed to have, and a private one that is only for trusted relationships.

Then there is a discovery problem. How do the penzance and penifore
widgets get introduced if pirate.net is not trusted to do the
introductions? They could do the introduction through their servers,
but that is really inefficient. Is there a safe way that they can
discover and introduce each other strictly on the client side?

Please excuse the misspelling of pinafore in the previous message.

Douglas Crockford wrote, in May:
>
> http://json.org/module.html
>
> How does this fit in a capability network?

# Communication is restricted only to JSON text. JSON text allows exchange
# of simple or complex data structures without the capability leakage that
# would occur with the exchange of JavaScript objects.

Restricting to JSON is a good idea only if there exists a standardized
Javascript function that decodes *only* JSON. Otherwise people will try
to do that using 'eval'.

However, I think it would be cleaner to exchange deep-copied Javascript
objects, where the deep copying is equivalent to converting to JSON and
back. That avoids the Javascript code needing to explicitly invoke encoding
and decoding functions (and has minor efficiency advantages).

--
David Hopwood <david.hopwood@...>

--- In caplet@yahoogroups.com, David Hopwood <david.hopwood@...> wrote:
>
> Douglas Crockford wrote, in May:
> >
> > http://json.org/module.html
> >
> > How does this fit in a capability network?
>
> # Communication is restricted only to JSON text. JSON text allows
exchange
> # of simple or complex data structures without the capability
leakage that
> # would occur with the exchange of JavaScript objects.

> Restricting to JSON is a good idea only if there exists a standardized
> Javascript function that decodes *only* JSON. Otherwise people will try
> to do that using 'eval'.

The parseJSON method is available at http://www.json.org/js.html

It will be standard equipment in the next edition of ECMAScript.

Douglas Crockford wrote:
> --- In caplet@yahoogroups.com, David Hopwood <david.hopwood@...> wrote:
>> Douglas Crockford wrote, in May:
>>> http://json.org/module.html
>>>
>>> How does this fit in a capability network?
>> # Communication is restricted only to JSON text. JSON text allows
>> # exchange of simple or complex data structures without the capability
>> # leakage that would occur with the exchange of JavaScript objects.
>
>> Restricting to JSON is a good idea only if there exists a standardized
>> Javascript function that decodes *only* JSON. Otherwise people will try
>> to do that using 'eval'.
>
> The parseJSON method is available at http://www.json.org/js.html
>
> It will be standard equipment in the next edition of ECMAScript.

That's good. I still think that exchanging deep-copied objects directly
would be more convenient. It also allows immutable objects to be shared
between sender and recipient, rather than being copied unnecessarily (as
well as saving the memory for the [Unicode] JSON string).

Note that if the deep copy is defined to be equivalent to converting to
JSON and back using the JSON bindings of the sending and receiving
languages, there is no cross-language interoperability problem with this.

--
David Hopwood <david.hopwood@...>

--- In caplet@yahoogroups.com, David Hopwood <david.hopwood@...>
> I still think that exchanging deep-copied objects directly
> would be more convenient. It also allows immutable objects to be shared
> between sender and recipient, rather than being copied unnecessarily (as
> well as saving the memory for the [Unicode] JSON string).

Exchange of strings between vats is safe because strings are
immutable and do not carry capabilities to things like Object
and Object.prototype. JSON provides the best encoding for the
environment.

It is not safe to exchange object references in JavaScript.
There are no immutable objects in JavaScript. Let's not get
fixated on optimization prematurely.

David Hopwood wrote:
> Douglas Crockford wrote:
>> --- In caplet@yahoogroups.com, David Hopwood <david.hopwood@...> wrote:
>>> Douglas Crockford wrote, in May:
>>>> http://json.org/module.html
>>>>
>>>> How does this fit in a capability network?
>>>
>>> # Communication is restricted only to JSON text. JSON text allows
>>> # exchange of simple or complex data structures without the capability
>>> # leakage that would occur with the exchange of JavaScript objects.
>>>
>>> Restricting to JSON is a good idea only if there exists a standardized
>>> Javascript function that decodes *only* JSON. Otherwise people will try
>>> to do that using 'eval'.
>>
>> The parseJSON method is available at http://www.json.org/js.html

I see that even that page says:

# To convert a JSON text into an object, use the eval() function.

before pointing out why you shouldn't do that. It should be changed
to be less self-contradictory.

>> It will be standard equipment in the next edition of ECMAScript.

The .toJSONString() methods specified and implemented at
<http://www.json.org/json.js> will not terminate successfully when
passed a cyclic structure. I don't think it is OK to place a requirement
on the caller to pass an acyclic structure, without specifying what
happens if it is cyclic.

If for some reason it isn't considered desirable to pass cyclic
structures between compartments (vats, iframes, etc.), then this
should be specified to cause an exception, rather than a stack
overflow exception being a side-effect of a particular implementation.

Another problem with those methods is:

// Values without a JSON representation are ignored.

This is broken; values without a JSON representation should cause an
exception.

> That's good. I still think that exchanging deep-copied objects directly
> would be more convenient.

... and would correctly handle cycles.

> It also allows immutable objects to be shared
> between sender and recipient, rather than being copied unnecessarily (as
> well as saving the memory for the [Unicode] JSON string).

Actually this is not straightforward to implement because of the ability
to perform uncontrolled modification of prototypes in Javascript. If a
compartment is to be allowed to change the prototypes for object, String,
etc., then objects can't safely be shared between compartments [*].

I consider this a language design flaw, BTW.


[*] At least, not without some deep magic, such as treating an object as
     having different prototypes depending on what compartment it is being
     used from. Actually, forget I mentioned that; I disclaim all
     responsibility for that idea ;-)

> Note that if the deep copy is defined to be equivalent to converting to
> JSON and back using the JSON bindings of the sending and receiving
> languages, there is no cross-language interoperability problem with this.

--
David Hopwood <david.hopwood@...>

--- In caplet@yahoogroups.com, David Hopwood <david.hopwood@...> wrote:

> Actually this is not straightforward to implement because of the ability
> to perform uncontrolled modification of prototypes in Javascript. If a
> compartment is to be allowed to change the prototypes for object,
String,
> etc., then objects can't safely be shared between compartments [*].
>
> I consider this a language design flaw, BTW.

Congratulations on discovering a design flaw in JavaScript.
Welcome to my world.

On 7/12/07, David Hopwood <david.hopwood@...> wrote:
> // Values without a JSON representation are ignored.
>
> This is broken; values without a JSON representation should cause an
> exception.

Actually, I'd prefer to pass in a function that is given the
opportunity to convert the value to one that does have a JSON
representation. For example, this feature could be used to export a
web-key (capability URL) for the non-JSON values.

Tyler

--
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/firefox/957/

I have three things to report that might be of interest to this mailing list.

First, IBM Research has developed an approach called SMash whose goal is to achieve secure mashups in today's browsers:

* http://domino.research.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/0ee2d79f8be461ce8525731b0009404d?OpenDocument

Second, the OpenAjax Alliance has developed a mini JavaScript library (the OpenAjax Hub) to allow multiple components (potentially from different Ajax toolkits) to integrate together on the same Web page. We are about to finalize and ship version 1.0 of the Hub which addresses publish/subscribe requirements within the same browser frame. More significant to this list, we are are in early discussion about OpenAjax Hub 1.1 and seeing if we can add extensions to address the issues of secure mashups and cross-frame communications. Here are some links:

* http://www.openajax.org/OpenAjax%20Hub.html
* http://www.openajax.org/member/wiki/OpenAjax_Hub_1.1_Roadmap

Our open source reference implementation of OpenAjax Hub 1.0 can be found at:

* http://sourceforge.net/projects/openajaxallianc

Finally, we have recently launched a Security Task Force to work on issues related to Ajax security, where secure mashups is a prime topic.

* http://www.openajax.org/member/wiki/Security_TF

Jon Ferraiolo
IBM & OpenAjax Alliance

We have the Mashup, which is the most interesting innovation in
programming in years. But as practiced in the web browser, it is
insecure. There is a clear need for a mechanism that allows components
to discover each other and communicate without giving up all of their
secrets.

There is interesting work being done on this at a lot of places,
including Microsoft, IBM, HP, Google, and Yahoo.

What I would like to do here is to pool this work, and come up with a
fully minimally adequate solution that can connect mashible components
wherever they may be.

I'm thinking that it could connect desktop widgets with pages, and
even services on other servers. It could connect Air with Silverlight.
It could mash up everything.

It could be a service offered by browsers or by operating systems. I
am thinking that in the short tern it could be provided by popular
extensions, such as Google's and Yahoo's toolbars. This would allow us
to shortcircuit much of the latency of software distribution.

---

From: caplet@yahoogroups.com [mailto:caplet@yahoogroups.com] On Behalf Of Douglas Crockford
Sent: Thursday, July 19, 2007 09:33
To: caplet@yahoogroups.com
Subject: [caplet] A Good Outcome

We have the Mashup, which is the most interesting innovation in
programming in years. But as practiced in the web browser, it is
insecure. There is a clear need for a mechanism that allows components
to discover each other and communicate without giving up all of their
secrets.

There is interesting work being done on this at a lot of places,
including Microsoft, IBM, HP, Google, and Yahoo.

What I would like to do here is to pool this work, and come up with a
fully minimally adequate solution that can connect mashible components
wherever they may be.

I'm thinking that it could connect desktop widgets with pages, and
even services on other servers. It could connect Air with Silverlight.
It could mash up everything.

It could be a service offered by browsers or by operating systems. I
am thinking that in the short tern it could be provided by popular
extensions, such as Google's and Yahoo's toolbars. This would allow us
to shortcircuit much of the latency of software distribution.