Feedback and criticism wanted: DOMCrypt API proposal

# David Dahl (14 years ago)

Hello JavaScript Enthusiasts,

I recently posted this draft spec ( wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) for a crypto API for browsers to the whatwg (see: lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html , summary is here: etherpad.mozilla.com:9000/DOMCrypt-discussion ) and wanted to get feedback and criticism from es-discuss/TC39.

Privacy and user control on the web is of utter importance. Tracking, unauthorized user data aggregation and personal information breaches are becoming so commonplace you see a new headline almost daily. (It seems).

We need crypto APIs in browsers to allow developers to create more secure communications tools and web applications that don’t have to implicitly trust the server, among other use cases.

The DOMCrypt API is a good start, and more feedback and discussion will really help round out how all of this should work – as well as how it can work in any browser that will support such an API. I think the main issue is creating an elegant API regardless of how it is implemented.

This API will provide each web browser window with a ‘cipher’ property[1] that facilitates:

asymmetric encryption key pair generation
public key encryption
public key decryption
symmetric encryption
signature generation
signature verification
hashing
easy public key discovery via meta tags or an ‘addressbookentry’ tag

[1] There is a bit of discussion around adding this API to window.navigator or consolidation within window.crypto

I have created a Firefox extension that implements most of the above, and am working on an experimental patch that integrates this API into Firefox.

The project originated in an extension I wrote, the home page is here: domcrypt.org

The source code for the extension is here: daviddahl/domcrypt

The Mozilla bugs are here:

bugzilla.mozilla.org/show_bug.cgi?id=649154, bugzilla.mozilla.org/show_bug.cgi?id=657432

Firefox "feature wiki page": wiki.mozilla.org/Privacy/Features/DOMCryptAPI

You can test the API by installing the extension hosted at domcrypt.org, and going to domcrypt.org

A recent blog post updating all of this is posted here: monocleglobe.wordpress.com/2011/06/01/domcrypt-update-2011-06-01

The API:

window.cipher = { // Public Key API pk: { set algorithm(algorithm){ }, get algorithm(){ },

// Generate a keypair and then execute the callback function generateKeypair: function ( function callback( aPublicKey ) { } ) { },

// encrypt a plainText encrypt: function ( plainText, function callback (cipherMessageObject) ) { } ) { },

// decrypt a cipherMessage decrypt: function ( cipherMessageObject, function callback ( plainText ) { } ) { },

// sign a message sign: function ( plainText, function callback ( signature ) { } ) { },

// verify a signature verify: function ( signature, plainText, function callback ( boolean ) { } ) { },

// get the JSON cipherAddressbook get addressbook() {},

// make changes to the addressbook saveAddressbook: function (JSONObject, function callback ( addresssbook ) { }) { } },

// Symmetric Crypto API sym: { get algorithm(), set algorithm(algorithm),

// create a new symmetric key generateKey: function (function callback ( key ){ }) { },

// encrypt some data encrypt: function (plainText, key, function callback( cipherText ){ }) { },

// decrypt some data decrypt: function (cipherText, key, function callback( plainText ) { }) { }, },

// hashing hash: { SHA256: function (function callback (hash){}) { } } }

Your feedback and criticism will be invaluable.

Best ,

David Dahl

Firefox Engineer, Mozilla Corp.

Hello JavaScript Enthusiasts,

I recently posted this draft spec ( https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) for a crypto API for browsers to the whatwg (see: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html , summary is here: http://etherpad.mozilla.com:9000/DOMCrypt-discussion ) and wanted to get feedback and criticism from es-discuss/TC39.

Privacy and user control on the web is of utter importance. Tracking, unauthorized user data aggregation and personal information breaches are becoming so commonplace you see a new headline almost daily. (It seems).

We need crypto APIs in browsers to allow developers to create more secure communications tools and web applications that don’t have to implicitly trust the server, among other use cases.

The DOMCrypt API is a good start, and more feedback and discussion will really help round out how all of this should work – as well as how it can work in any browser that will support such an API. I think the main issue is creating an elegant API regardless of how it is implemented.

This API will provide each web browser window with a ‘cipher’ property[1] that facilitates:

    asymmetric encryption key pair generation
    public key encryption
    public key decryption
    symmetric encryption
    signature generation
    signature verification
    hashing
    easy public key discovery via meta tags or an ‘addressbookentry’ tag

[1] There is a bit of discussion around adding this API to window.navigator or consolidation within window.crypto

I have created a Firefox extension that implements most of the above, and am working on an experimental patch that integrates this API into Firefox.

The project originated in an extension I wrote, the home page is here: http://domcrypt.org

The source code for the extension is here: https://github.com/daviddahl/domcrypt

The Mozilla bugs are here:

https://bugzilla.mozilla.org/show_bug.cgi?id=649154
https://bugzilla.mozilla.org/show_bug.cgi?id=657432

Firefox "feature wiki page": https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI

You can test the API by installing the extension hosted at domcrypt.org, and going to http://domcrypt.org

A recent blog post updating all of this is posted here: http://monocleglobe.wordpress.com/2011/06/01/domcrypt-update-2011-06-01/

The API:

window.cipher = {
 // Public Key API
 pk: {
   set algorithm(algorithm){ },
   get algorithm(){ },

  // Generate a keypair and then execute the callback function
  generateKeypair: function ( function callback( aPublicKey ) { } ) {  },

  // encrypt a plainText
  encrypt: function ( plainText, function callback (cipherMessageObject) ) {  } ) {  },

  // decrypt a cipherMessage
  decrypt: function ( cipherMessageObject, function callback ( plainText ) { } ) {  },

  // sign a message
  sign: function ( plainText, function callback ( signature ) { } ) {  },

  // verify a signature
  verify: function ( signature, plainText, function callback ( boolean ) { } ) {  },

  // get the JSON cipherAddressbook
  get addressbook() {},

  // make changes to the addressbook
  saveAddressbook: function (JSONObject, function callback ( addresssbook ) { }) {  }
  },

  // Symmetric Crypto API
  sym: {
  get algorithm(),
  set algorithm(algorithm),

  // create a new symmetric key
  generateKey: function (function callback ( key ){ }) {  },

  // encrypt some data
  encrypt: function (plainText, key, function callback( cipherText ){ }) {  },

  // decrypt some data
  decrypt: function (cipherText, key, function callback( plainText ) { }) {  },
  },

  // hashing
  hash: {
    SHA256: function (function callback (hash){}) {  }
  }
}

Your feedback and criticism will be invaluable.

Best regards,

David Dahl

Firefox Engineer, Mozilla Corp.

# Bill Frantz (14 years ago)

On 6/1/11 at 16:01, ddahl at mozilla.com (David Dahl) wrote:

Hello JavaScript Enthusiasts,

I recently posted this draft spec ( wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

In looking at this proposal, I am confused by:

cipherConfiguration

A JSON Object which labels the Key Pairs, staring with a "default" Key Pair. This allows for multiple Key Pairs in the future.

{

"default": {

"created" : 1305140629979,

"privKey" : <BASE64 ENCODEDED PRIVATE KEY>,

"pubKey" : <BASE64 ENCODEDED PUBLIC KEY>,

"salt" : <ENCODED or ENCRYPTED Salt>,

"iv" : <ENCODED or ENCRYPTED IV>,

"algorithm" : "AES_256_CBC",

}

This example seems to define public and private keys for a symmetric algorithm. The detailed format of public keys will depend on which algorithm is used. Are you planning on storing them in their ASN1 form, or as JSON objects?

window.mozCrypto All windows will have this property (in the current implementation) for the time being as this API is hashed out.

The property is namespaced in order to provide future capabilities. The current design is asynchronous and looks like this:

Is an asynchronous interface the best choice. I thought one of the great reliability advantages of Javascript was its single thread, synchronous nature.

) for a crypto API for browsers to the whatwg (see: lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html , summary is here: etherpad.mozilla.com:9000/DOMCrypt-discussion ) and wanted to get feedback and criticism from es-discuss/TC39.

Privacy and user control on the web is of utter importance. Tracking, unauthorized user data aggregation and personal information breaches are becoming so commonplace you see a new headline almost daily. (It seems).

We need crypto APIs in browsers to allow developers to create more secure communications tools and web applications that don’t have to implicitly trust the server, among other use cases.

The DOMCrypt API is a good start, and more feedback and discussion will really help round out how all of this should work – as well as how it can work in any browser that will support such an API. I think the main issue is creating an elegant API regardless of how it is implemented.

This API will provide each web browser window with a ‘cipher’ property[1] that facilitates:

asymmetric encryption key pair generation public key encryption public key decryption symmetric encryption signature generation signature verification hashing easy public key discovery via meta tags or an ‘addressbookentry’ tag

[1] There is a bit of discussion around adding this API to window.navigator or consolidation within window.crypto

I have created a Firefox extension that implements most of the above, and am working on an experimental patch that integrates this API into Firefox.

The project originated in an extension I wrote, the home page is here: domcrypt.org

The source code for the extension is here: daviddahl/domcrypt

The Mozilla bugs are here:

bugzilla.mozilla.org/show_bug.cgi?id=649154, bugzilla.mozilla.org/show_bug.cgi?id=657432

Firefox "feature wiki page": wiki.mozilla.org/Privacy/Features/DOMCryptAPI

You can test the API by installing the extension hosted at domcrypt.org, and going to domcrypt.org

A recent blog post updating all of this is posted here: monocleglobe.wordpress.com/2011/06/01/domcrypt-update-2011-06-01

The API:

window.cipher = { // Public Key API pk: { set algorithm(algorithm){ }, get algorithm(){ },

// Generate a keypair and then execute the callback function generateKeypair: function ( function callback( aPublicKey ) { } ) { },

// encrypt a plainText encrypt: function ( plainText, function callback (cipherMessageObject) ) { } ) { },

// decrypt a cipherMessage decrypt: function ( cipherMessageObject, function callback ( plainText ) { } ) { },

// sign a message sign: function ( plainText, function callback ( signature ) { } ) { },

// verify a signature verify: function ( signature, plainText, function callback ( boolean ) { } ) { },

// get the JSON cipherAddressbook get addressbook() {},

// make changes to the addressbook saveAddressbook: function (JSONObject, function callback ( addresssbook ) { }) { } },

// Symmetric Crypto API sym: { get algorithm(), set algorithm(algorithm),

// create a new symmetric key generateKey: function (function callback ( key ){ }) { },

// encrypt some data encrypt: function (plainText, key, function callback( cipherText ){ }) { },

// decrypt some data decrypt: function (cipherText, key, function callback( plainText ) { }) { }, },

// hashing hash: { SHA256: function (function callback (hash){}) { } } }

Your feedback and criticism will be invaluable.

Best ,

David Dahl

Firefox Engineer, Mozilla Corp.

es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss

On 6/1/11 at 16:01, ddahl at mozilla.com (David Dahl) wrote:

>Hello JavaScript Enthusiasts,
>
>I recently posted this draft spec ( https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

In looking at this proposal, I am confused by:

>cipherConfiguration
>
>A JSON Object which labels the Key Pairs, staring with a "default" Key Pair. This allows for multiple Key Pairs in the future.
>
>01. {
>02. "default": {
>03. "created"   : 1305140629979,
>04. "privKey"   : <BASE64 ENCODEDED PRIVATE KEY>,
>05. "pubKey"    : <BASE64 ENCODEDED PUBLIC KEY>,
>06. "salt"      : <ENCODED or ENCRYPTED Salt>,
>07. "iv"        : <ENCODED or ENCRYPTED IV>,
>08. "algorithm" : "AES_256_CBC",
>09. }

This example seems to define public and private keys for a 
symmetric algorithm. The detailed format of public keys will 
depend on which algorithm is used. Are you planning on storing 
them in their ASN1 form, or as JSON objects?


>window.mozCrypto
>All windows will have this property (in the current implementation) for the time being as this API is hashed out.
>
>The property is namespaced in order to provide future capabilities. The current design is asynchronous and looks like this:

Is an asynchronous interface the best choice. I thought one of 
the great reliability advantages of Javascript was its single 
thread, synchronous nature.



>) for a crypto API for browsers to the whatwg (see: 
>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html 
>, summary is here: 
>http://etherpad.mozilla.com:9000/DOMCrypt-discussion ) and 
>wanted to get feedback and criticism from es-discuss/TC39.
>
>Privacy and user control on the web is of utter importance. 
>Tracking, unauthorized user data aggregation and personal 
>information breaches are becoming so commonplace you see a new 
>headline almost daily. (It seems).
>
>We need crypto APIs in browsers to allow developers to create 
>more secure communications tools and web applications that 
>don’t have to implicitly trust the server, among other use cases.
>
>The DOMCrypt API is a good start, and more feedback and 
>discussion will really help round out how all of this should 
>work – as well as how it can work in any browser that will 
>support such an API. I think the main issue is creating an 
>elegant API regardless of how it is implemented.
>
>This API will provide each web browser window with a ‘cipher’ property[1] that facilitates:
>
>asymmetric encryption key pair generation
>public key encryption
>public key decryption
>symmetric encryption
>signature generation
>signature verification
>hashing
>easy public key discovery via meta tags or an ‘addressbookentry’ tag
>
>[1] There is a bit of discussion around adding this API to 
>window.navigator or consolidation within window.crypto
>
>I have created a Firefox extension that implements most of the 
>above, and am working on an experimental patch that integrates 
>this API into Firefox.
>
>The project originated in an extension I wrote, the home page is here: http://domcrypt.org
>
>The source code for the extension is here: https://github.com/daviddahl/domcrypt
>
>The Mozilla bugs are here:
>
>https://bugzilla.mozilla.org/show_bug.cgi?id=649154
>https://bugzilla.mozilla.org/show_bug.cgi?id=657432
>
>Firefox "feature wiki page": https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI
>
>You can test the API by installing the extension hosted at 
>domcrypt.org, and going to http://domcrypt.org
>
>A recent blog post updating all of this is posted here: http://monocleglobe.wordpress.com/2011/06/01/domcrypt-update-2011-06-01/
>
>The API:
>
>window.cipher = {
>// Public Key API
>pk: {
>set algorithm(algorithm){ },
>get algorithm(){ },
>
>// Generate a keypair and then execute the callback function
>generateKeypair: function ( function callback( aPublicKey ) { } ) {  },
>
>// encrypt a plainText
>encrypt: function ( plainText, function callback (cipherMessageObject) ) {  } ) {  },
>
>// decrypt a cipherMessage
>decrypt: function ( cipherMessageObject, function callback ( plainText ) { } ) {  },
>
>// sign a message
>sign: function ( plainText, function callback ( signature ) { } ) {  },
>
>// verify a signature
>verify: function ( signature, plainText, function callback ( boolean ) { } ) {  },
>
>// get the JSON cipherAddressbook
>get addressbook() {},
>
>// make changes to the addressbook
>saveAddressbook: function (JSONObject, function callback ( addresssbook ) { }) {  }
>},
>
>// Symmetric Crypto API
>sym: {
>get algorithm(),
>set algorithm(algorithm),
>
>// create a new symmetric key
>generateKey: function (function callback ( key ){ }) {  },
>
>// encrypt some data
>encrypt: function (plainText, key, function callback( cipherText ){ }) {  },
>
>// decrypt some data
>decrypt: function (cipherText, key, function callback( plainText ) { }) {  },
>},
>
>// hashing
>hash: {
>SHA256: function (function callback (hash){}) {  }
>}
>}
>
>Your feedback and criticism will be invaluable.
>
>Best regards,
>
>David Dahl
>
>Firefox Engineer, Mozilla Corp.
>_______________________________________________
>es-discuss mailing list
>es-discuss at mozilla.org
>https://mail.mozilla.org/listinfo/es-discuss
-----------------------------------------------------------------------
Bill Frantz        |Security, like correctness, is| Periwinkle
(408)356-8506      |not an add-on feature. - Attr-| 16345 
Englewood Ave
www.pwpconsult.com |ibuted to Andrew Tannenbaum   | Los Gatos, 
CA 95032

# David Dahl (14 years ago)

----- Original Message ----- From: "Bill Frantz" <frantz at pwpconsult.com>

To: "David Dahl" <ddahl at mozilla.com>

Cc: es-discuss at mozilla.org Sent: Monday, June 6, 2011 11:00:29 AM Subject: Re: Feedback and criticism wanted: DOMCrypt API proposal

On 6/1/11 at 16:01, ddahl at mozilla.com (David Dahl) wrote:

A JSON Object which labels the Key Pairs, staring with a "default" Key Pair. This allows for multiple Key Pairs in the future.

{

"default": {

"created" : 1305140629979,

"privKey" : <BASE64 ENCODEDED PRIVATE KEY>,

"pubKey" : <BASE64 ENCODEDED PUBLIC KEY>,

"salt" : <ENCODED or ENCRYPTED Salt>,

"iv" : <ENCODED or ENCRYPTED IV>,

"algorithm" : "AES_256_CBC",

}

This example seems to define public and private keys for a symmetric algorithm. The detailed format of public keys will depend on which algorithm is used. Are you planning on storing them in their ASN1 form, or as JSON objects?

This is in flux right now. It looks like we will be moving to a keyID mechanism that ties your use of the keypair to the origin where it was generated. In which case, the current way the implementation stores the keys will change to the standard why NSS uses keys. The spec is undergoing a lot of editing right now starting with a proper WebIDL representation.

There is a lot of discussion in this API on the web-app-security list:

lists.w3.org/Archives/Public/public-web-security/2011Jun/0000.html

Many questions and answers have been summarized from the whatwg and w3c here: etherpad.mozilla.com:9000/DOMCrypt-discussion

window.mozCrypto All windows will have this property (in the current implementation) for the time being as this API is hashed out.

The property is namespaced in order to provide future capabilities. The current design is asynchronous and looks like this:

Is an asynchronous interface the best choice. I thought one of the great reliability advantages of Javascript was its single thread, synchronous nature.

Browsers almost by default will frown on including any synchronous APIs. With Firefox, we just don't want any additional main thread I/O happening.

----- Original Message -----
From: "Bill Frantz" <frantz at pwpconsult.com>
To: "David Dahl" <ddahl at mozilla.com>
Cc: es-discuss at mozilla.org
Sent: Monday, June 6, 2011 11:00:29 AM
Subject: Re: Feedback and criticism wanted: DOMCrypt API proposal

On 6/1/11 at 16:01, ddahl at mozilla.com (David Dahl) wrote:

>A JSON Object which labels the Key Pairs, staring with a "default" Key Pair. This allows for multiple Key Pairs in the future.
>
>01. {
>02. "default": {
>03. "created"   : 1305140629979,
>04. "privKey"   : <BASE64 ENCODEDED PRIVATE KEY>,
>05. "pubKey"    : <BASE64 ENCODEDED PUBLIC KEY>,
>06. "salt"      : <ENCODED or ENCRYPTED Salt>,
>07. "iv"        : <ENCODED or ENCRYPTED IV>,
>08. "algorithm" : "AES_256_CBC",
>09. }

> This example seems to define public and private keys for a 
  symmetric algorithm. The detailed format of public keys will 
  depend on which algorithm is used. Are you planning on storing 
  them in their ASN1 form, or as JSON objects?

This is in flux right now. It looks like we will be moving to a keyID mechanism that ties your use of the keypair to the origin where it was generated. In which case, the current way the implementation stores the keys will change to the standard why NSS uses keys. The spec is undergoing a lot of editing right now starting with a proper WebIDL representation. 

There is a lot of discussion in this API on the web-app-security list: 

http://lists.w3.org/Archives/Public/public-web-security/2011Jun/0000.html

Many questions and answers have been summarized from the whatwg and w3c here: http://etherpad.mozilla.com:9000/DOMCrypt-discussion

>window.mozCrypto
>All windows will have this property (in the current implementation) for the time being as this API is hashed out.
>
>The property is namespaced in order to provide future capabilities. The current design is asynchronous and looks like this:

> Is an asynchronous interface the best choice. I thought one of 
  the great reliability advantages of Javascript was its single 
  thread, synchronous nature.

Browsers almost by default will frown on including any synchronous APIs. With Firefox, we just don't want any additional main thread I/O happening.

Regards,

David

# Brendan Eich (14 years ago)

On Jun 6, 2011, at 9:51 AM, David Dahl wrote:

On 6/6/11 at 11:00,frantz at pwpconsult.com (Bill Frantz) wrote:

On 6/1/11 at 16:01, ddahl at mozilla.com (David Dahl) wrote:

The property is namespaced in order to provide future capabilities. The current design is asynchronous and looks like this:

Is an asynchronous interface the best choice. I thought one of the great reliability advantages of Javascript was its single-thread, synchronous nature.

Browsers almost by default will frown on including any synchronous APIs. With Firefox, we just don't want any additional main thread I/O happening.

To say more: JS is single-threaded, but that means you can lock up a "main thread" and starve UI. Browsers use multiple threads and processes these days, but the rule still applies. Scripts run to completion and must pass continuations manually by callback functions if they need to run after some indefinite delay, or even after a just-too-long computation or local i/o operation.

On Jun 6, 2011, at 9:51 AM, David Dahl wrote:

> On 6/6/11 at 11:00,frantz at pwpconsult.com (Bill Frantz) wrote:
>> On 6/1/11 at 16:01, ddahl at mozilla.com (David Dahl) wrote:
> 
>>> The property is namespaced in order to provide future capabilities. The current design is asynchronous and looks like this:
> 
>> Is an asynchronous interface the best choice. I thought one of  the great reliability advantages of Javascript was its single-thread, synchronous nature.
> 
> Browsers almost by default will frown on including any synchronous APIs. With Firefox, we just don't want any additional main thread I/O happening.

To say more: JS is single-threaded, but that means you can lock up a "main thread" and starve UI. Browsers use multiple threads and processes these days, but the rule still applies. Scripts run to completion and must pass continuations manually by callback functions if they need to run after some indefinite delay, or even after a just-too-long computation or local i/o operation.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110606/d33b18c4/attachment.html>

# Bill Frantz (14 years ago)

[Sorry for the delay. I'm at Reed Collage and the internet service I've glommed onto doesn't let me contact my SMTP server, so I can't send email, only receive it.]

On 6/6/11 at 13:00, brendan at mozilla.com (Brendan Eich) wrote:

On Jun 6, 2011, at 9:51 AM, David Dahl wrote:

On 6/6/11 at 11:00,frantz at pwpconsult.com (Bill Frantz) wrote:

On 6/1/11 at 16:01, ddahl at mozilla.com (David Dahl) wrote:

The property is namespaced in order to provide future capabilities. The current design is asynchronous and looks like this:

Is an asynchronous interface the best choice. I thought one of the great reliability advantages of Javascript was its single-thread, synchronous nature.

Browsers almost by default will frown on including any synchronous APIs. With Firefox, we just don't want any additional main thread I/O happening.

To say more: JS is single-threaded, but that means you can lock up a "main thread" and starve UI. Browsers use multiple threads and processes these days, but the rule still applies. Scripts run to completion and must pass continuations manually by callback functions if they need to run after some indefinite delay, or even after a just-too-long computation or local i/o operation.

Thanks Brendan. That explanation answers my question and, assuming the continuations can't run at the same time as the "main" program, satisfies my implied objection.

Cheers - Bill

[Sorry for the delay. I'm at Reed Collage and the internet 
service I've glommed onto doesn't let me contact my SMTP server, 
so I can't send email, only receive it.]

On 6/6/11 at 13:00, brendan at mozilla.com (Brendan Eich) wrote:

>On Jun 6, 2011, at 9:51 AM, David Dahl wrote:
>
>>On 6/6/11 at 11:00,frantz at pwpconsult.com (Bill Frantz) wrote:
>>>On 6/1/11 at 16:01, ddahl at mozilla.com (David Dahl) wrote:
>>
>>>>The property is namespaced in order to provide future capabilities. The current design is
>asynchronous and looks like this:
>>
>>>Is an asynchronous interface the best choice. I thought one of  the great reliability advantages
>of Javascript was its single-thread, synchronous nature.
>>
>>Browsers almost by default will frown on including any synchronous APIs. With Firefox, we just
>don't want any additional main thread I/O happening.
>
>To say more: JS is single-threaded, but that means you can lock 
>up a "main thread" and starve UI. Browsers use multiple threads 
>and processes these days, but the rule still applies. Scripts 
>run to completion and must pass continuations manually by 
>callback functions if they need to run after some indefinite 
>delay, or even after a just-too-long computation or local i/o operation.

Thanks Brendan. That explanation answers my question and, 
assuming the continuations can't run at the same time as the 
"main" program, satisfies my implied objection.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | OAuth -  It's the best that  | Periwinkle
(408)356-8506      | the wrong way of doing things| 16345 
Englewood Ave
www.pwpconsult.com | can provide. - Mike Stay     | Los Gatos, 
CA 95032