Loading ...
Sorry, an error occurred while loading the content.

The Module Tag

Expand Messages
  • Douglas Crockford
    http://json.org/module.html How does this fit in a capability network?
    Message 1 of 8 , May 11 1:52 PM
    • 0 Attachment
      http://json.org/module.html

      How does this fit in a capability network?
    • David Hopwood
      ... # Communication is restricted only to JSON text. JSON text allows exchange # of simple or complex data structures without the capability leakage that #
      Message 2 of 8 , Jul 10, 2007
      • 0 Attachment
        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@...>
      • Douglas Crockford
        ... exchange ... leakage that ... The parseJSON method is available at http://www.json.org/js.html It will be standard equipment in the next edition of
        Message 3 of 8 , Jul 12, 2007
        • 0 Attachment
          --- 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.
        • David Hopwood
          ... 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
          Message 4 of 8 , Jul 12, 2007
          • 0 Attachment
            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@...>
          • Douglas Crockford
            ... Exchange of strings between vats is safe because strings are immutable and do not carry capabilities to things like Object and Object.prototype. JSON
            Message 5 of 8 , Jul 12, 2007
            • 0 Attachment
              --- 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
              ... 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
              Message 6 of 8 , Jul 12, 2007
              • 0 Attachment
                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@...>
              • Douglas Crockford
                ... String, ... Congratulations on discovering a design flaw in JavaScript. Welcome to my world.
                Message 7 of 8 , Jul 12, 2007
                • 0 Attachment
                  --- 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.
                • Tyler Close
                  ... 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,
                  Message 8 of 8 , Jul 16, 2007
                  • 0 Attachment
                    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/
                  Your message has been successfully submitted and would be delivered to recipients shortly.