Drop JSON from the language?

# Robert Sayre (18 years ago)

I think this feature might be better to add as a library. I'm working on a patch for Mozilla that provides a native JSON implementation like so: |new JSON()|. I had been basing the API on Bob's python simplejson API, but it looks like Google Caja did something similar in JS, so I might go with their method and argument names instead. It's pretty much the same otherwise.

google-caja.googlecode.com/svn/trunk/src/js/com/google/caja/safe-json.js

Note that Caja's implementation of JSON.serialize makes exactly the same changes that have been proposed (and greeted with silence) here...

        For json.js, other objects can provide their own implementation
        of toJSONString(), in which case JSON serialization relies
        on these objects to return a correct JSON string. If an
        object instead returns an unbalanced part of a JSON
        string and another object returns a compensating
        unbalanced string, then an outer toJSONString() can
        produce quoting confusions that invite XSS-like
        attacks. The primary purpose of safe-json.js is to
        prevent such attacks.

I think this feature might be better to add as a library. I'm working
on a patch for Mozilla that provides a native JSON implementation like
so: |new JSON()|. I had been basing the API on Bob's python simplejson
API, but it looks like Google Caja did something similar in JS, so I
might go with their method and argument names instead. It's pretty
much the same otherwise.

<http://google-caja.googlecode.com/svn/trunk/src/js/com/google/caja/safe-json.js>

Note that Caja's implementation of JSON.serialize makes exactly the
same changes that have been proposed (and greeted with silence)
here...

            For json.js, other objects can provide their own implementation
            of toJSONString(), in which case JSON serialization relies
            on these objects to return a correct JSON string. If an
            object instead returns an unbalanced part of a JSON
            string and another object returns a compensating
            unbalanced string, then an outer toJSONString() can
            produce quoting confusions that invite XSS-like
            attacks. The primary purpose of safe-json.js is to
            prevent such attacks.


-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

# Garrett Smith (18 years ago)

On 10/12/07, Robert Sayre <sayrer at gmail.com> wrote:

I think this feature might be better to add as a library. I'm working on a patch for Mozilla that provides a native JSON implementation like so: |new JSON()|. I had been basing the API on Bob's python simplejson API, but it looks like Google Caja did something similar in JS, so I might go with their method and argument names instead. It's pretty much the same otherwise.

google-caja.googlecode.com/svn/trunk/src/js/com/google/caja/safe-json.js

Note that Caja's implementation of JSON.serialize makes exactly the same changes that have been proposed (and greeted with silence) here...
        For json.js, other objects can provide their own implementation
        of toJSONString(), in which case JSON serialization relies
        on these objects to return a correct JSON string. If an
        object instead returns an unbalanced part of a JSON
        string and another object returns a compensating
        unbalanced string, then an outer toJSONString() can
        produce quoting confusions that invite XSS-like
        attacks. The primary purpose of safe-json.js is to
        prevent such attacks.

Objects can also override hasOwnProperty

json = { hasOwnProperty : document.body.appendChild // 'object' in IE "<script src='hackrz.net"></script> }

The current proposal is not well-designed.

Objects that need JSON Strigification should provide their own toJSONString, and that it should be optional. The current proposal makes it not optional.

Object.prototype.toJSONString complicates objects with responsibility that they should not necessarily have. It will be easy to misuse. It will conflate Object.prototype with implementation details possibly leaking into places they shouldn't. Instead of keeping reduced access, it maximizes access. It does not allow the functionality to be tested and debugged independently.

An interface or a JSON object (as you suggest) avoids these problems.

String.prototype.parseJSON returns an Object. This complicates String with something that is not about String behavior. XXX.parse should return an object of type XXX -- Date.parse returns a Number, which is odd and should not be a shining example.

If these features go in the language, implementations and library authors will be required to handle this method for all objects, of any type, forever. The change will be permanent and non retractable.

This feature is not critical; it can be added at any time. The flip side to that is that once added, it cannot be removed. ever.

Dropping JSON from ES4 is a smart idea. It can be added in 4.1. In the meantime, I would like to see JSON support, something along the lines of what you're working on, like Caja, implemented in the Host environment (Mozilla, Webkit, Opera, IE -- yeah right...). Once the wrinkles are ironed out, it can go in ES4.

Garrett

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

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

-- Programming is a collaborative art.

On 10/12/07, Robert Sayre <sayrer at gmail.com> wrote:
> I think this feature might be better to add as a library. I'm working
> on a patch for Mozilla that provides a native JSON implementation like
> so: |new JSON()|. I had been basing the API on Bob's python simplejson
> API, but it looks like Google Caja did something similar in JS, so I
> might go with their method and argument names instead. It's pretty
> much the same otherwise.
>
> <http://google-caja.googlecode.com/svn/trunk/src/js/com/google/caja/safe-json.js>
>
> Note that Caja's implementation of JSON.serialize makes exactly the
> same changes that have been proposed (and greeted with silence)
> here...
>
>             For json.js, other objects can provide their own implementation
>             of toJSONString(), in which case JSON serialization relies
>             on these objects to return a correct JSON string. If an
>             object instead returns an unbalanced part of a JSON
>             string and another object returns a compensating
>             unbalanced string, then an outer toJSONString() can
>             produce quoting confusions that invite XSS-like
>             attacks. The primary purpose of safe-json.js is to
>             prevent such attacks.
>
Objects can also override hasOwnProperty

json = {
  hasOwnProperty : document.body.appendChild // 'object' in IE
  "<script src='http://hackrz.net"></script>
}

The current proposal is not well-designed.

Objects that need JSON Strigification should provide their own
toJSONString, and that it should be optional. The current proposal
makes it not optional.

Object.prototype.toJSONString complicates objects with responsibility
that they should not necessarily have. It will be easy to misuse. It
will conflate Object.prototype with implementation details possibly
leaking into places they shouldn't. Instead of keeping reduced access,
it maximizes access. It does not allow the functionality to be tested
and debugged independently.

An interface or a JSON object  (as you suggest) avoids these problems.

String.prototype.parseJSON returns an Object. This complicates String
with something that is not about String behavior. XXX.parse should
return an object of type XXX -- Date.parse returns a Number, which is
odd and should not be a shining example.

If these features go in the language, implementations and library
authors will be required to handle this method for all objects, of any
type, forever. The change will be permanent and non retractable.

This feature is not critical; it can be added at any time. The flip
side to that is that once added, it cannot be removed. ever.

Dropping JSON from ES4 is a smart idea. It can be added in 4.1. In the
meantime, I would like to see JSON support, something along the lines
of what you're working on, like Caja, implemented in the Host
environment (Mozilla, Webkit, Opera, IE -- yeah right...). Once the
wrinkles are ironed out, it can go in ES4.

Garrett

>
> --
>
> Robert Sayre
>
> "I would have written a shorter letter, but I did not have the time."
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>

--
Programming is a collaborative art.

-- 
Programming is a collaborative art.