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

Re: ADsafe rules

Expand Messages
  • Douglas Crockford
    I want .get and .set to work without blacklists. They are intended to get and set data members in objects. So that is all they will allow. They will not get or
    Message 1 of 13 , Apr 5, 2008
    • 0 Attachment
      I want .get and .set to work without blacklists. They are intended to
      get and set data members in objects. So that is all they will allow.
      They will not get or set function values. They will not manipulate
      functions. JavaScript's functions are mutable objects. I think that
      was a mistake.

      Some of the member restrictions are motivated by obvious attacks
      (apply, call, eval, prototype, watch). Some are to prevent rights
      amplification even in cases where that does not lead to known exploits
      (callee, caller, constructor, unwatch). Some are because they make me
      nervous (valueOf).
    • Kris Zyp
      Great, thank you for the info. Kris ... From: Douglas Crockford To: caplet@yahoogroups.com Sent: Saturday, April 05, 2008 8:46 AM Subject: [caplet] Re: ADsafe
      Message 2 of 13 , Apr 5, 2008
      • 0 Attachment
        Great, thank you for the info.
        Kris
         
        ----- Original Message -----
        Sent: Saturday, April 05, 2008 8:46 AM
        Subject: [caplet] Re: ADsafe rules

        I want .get and .set to work without blacklists. They are intended to
        get and set data members in objects. So that is all they will allow.
        They will not get or set function values. They will not manipulate
        functions. JavaScript's functions are mutable objects. I think that
        was a mistake.

        Some of the member restrictions are motivated by obvious attacks
        (apply, call, eval, prototype, watch). Some are to prevent rights
        amplification even in cases where that does not lead to known exploits
        (callee, caller, constructor, unwatch). Some are because they make me
        nervous (valueOf).

      • Mike Samuel
        Function mutability can be a source of undefined behavior since the spec allows but doesn t require joining of functions that have the same body and scope
        Message 3 of 13 , Apr 5, 2008
        • 0 Attachment
          Function mutability can be a source of undefined behavior since the spec allows but doesn't require "joining" of functions that have the same body and scope chain, and mutations to one of a joined pair must be reflected on the other.

          JScript deviations section 3.7 says in
          function foo() {
            function bar() {}
            return bar;
          }

          var f = foo();
          var g = bar();
          f.x = 1;
          g.x = 2;

          alert(f.x + g.x);  // could legally be either 3 or 4



          On 05/04/2008, Douglas Crockford <douglas@...> wrote:

          I want .get and .set to work without blacklists. They are intended to
          get and set data members in objects. So that is all they will allow.
          They will not get or set function values. They will not manipulate
          functions. JavaScript's functions are mutable objects. I think that
          was a mistake.

          Some of the member restrictions are motivated by obvious attacks
          (apply, call, eval, prototype, watch). Some are to prevent rights
          amplification even in cases where that does not lead to known exploits
          (callee, caller, constructor, unwatch). Some are because they make me
          nervous (valueOf).


        • Kris Zyp
          AFAIK, no implementation has ever actually done this joining , and I believe ES3.1 and ES4 will very likely dissallow joining to prevent it from ever
          Message 4 of 13 , Apr 5, 2008
          • 0 Attachment
            
            AFAIK, no implementation has ever actually done this "joining", and I believe ES3.1 and ES4 will very likely dissallow joining to prevent it from ever happening in the future.
            Kris
             
            ----- Original Message -----
            Sent: Saturday, April 05, 2008 9:42 PM
            Subject: Re: [caplet] Re: ADsafe rules

            Function mutability can be a source of undefined behavior since the spec allows but doesn't require "joining" of functions that have the same body and scope chain, and mutations to one of a joined pair must be reflected on the other.

            JScript deviations section 3.7 says in
            function foo() {
              function bar() {}
              return bar;
            }

            var f = foo();
            var g = bar();
            f.x = 1;
            g.x = 2;

            alert(f.x + g.x);  // could legally be either 3 or 4



            On 05/04/2008, Douglas Crockford <douglas@crockford. com> wrote:

            I want .get and .set to work without blacklists. They are intended to
            get and set data members in objects. So that is all they will allow.
            They will not get or set function values. They will not manipulate
            functions. JavaScript's functions are mutable objects. I think that
            was a mistake.

            Some of the member restrictions are motivated by obvious attacks
            (apply, call, eval, prototype, watch). Some are to prevent rights
            amplification even in cases where that does not lead to known exploits
            (callee, caller, constructor, unwatch). Some are because they make me
            nervous (valueOf).


          • Mark Miller
            ... Yes, that s what we decided. ES3.1 and ES4 will be deterministic in this regard. No joining. -- Text by me above is hereby placed in the public domain
            Message 5 of 13 , Apr 6, 2008
            • 0 Attachment
              On Sat, Apr 5, 2008 at 9:09 PM, Kris Zyp <kris@...> wrote:
              > AFAIK, no implementation has ever actually done this "joining", and I
              > believe ES3.1 and ES4 will very likely dissallow joining to prevent it from
              > ever happening in the future.

              Yes, that's what we decided. ES3.1 and ES4 will be deterministic in
              this regard. No joining.

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

              Cheers,
              --MarkM
            • David-Sarah Hopwood
              ... If functions were immutable, joining would be a transparent optimization. Apart from the theoretical potential for backward incompatibility, why isn t this
              Message 6 of 13 , Apr 6, 2008
              • 0 Attachment
                Mark Miller wrote:
                > On Sat, Apr 5, 2008 at 9:09 PM, Kris Zyp <kris@...> wrote:
                >> AFAIK, no implementation has ever actually done this "joining", and I
                >> believe ES3.1 and ES4 will very likely dissallow joining to prevent it from
                >> ever happening in the future.
                >
                > Yes, that's what we decided. ES3.1 and ES4 will be deterministic in
                > this regard. No joining.

                If functions were immutable, joining would be a transparent optimization.
                Apart from the theoretical potential for backward incompatibility, why
                isn't this a better solution? I suspect that very few programs rely on
                mutating actual functions (as opposed to creating mutable objects that are
                callable as functions, or mutating Function.prototype).

                --
                David-Sarah Hopwood
              • David-Sarah Hopwood
                ... Actually not quite, because it would still be observable by using ===. ... -- David-Sarah Hopwood
                Message 7 of 13 , Apr 6, 2008
                • 0 Attachment
                  David-Sarah Hopwood wrote:
                  > Mark Miller wrote:
                  >> On Sat, Apr 5, 2008 at 9:09 PM, Kris Zyp <kris@...> wrote:
                  >>> AFAIK, no implementation has ever actually done this "joining", and I
                  >>> believe ES3.1 and ES4 will very likely dissallow joining to prevent
                  >>> it from
                  >>> ever happening in the future.
                  >>
                  >> Yes, that's what we decided. ES3.1 and ES4 will be deterministic in
                  >> this regard. No joining.
                  >
                  > If functions were immutable, joining would be a transparent optimization.

                  Actually not quite, because it would still be observable by using ===.
                  But my question stands:

                  > Apart from the theoretical potential for backward incompatibility, why
                  > isn't this a better solution? I suspect that very few programs rely on
                  > mutating actual functions (as opposed to creating mutable objects that are
                  > callable as functions, or mutating Function.prototype).

                  --
                  David-Sarah Hopwood
                • Kris Zyp
                  ... Really? It is actually even used in ADsafe s core library. Mutating functions is pretty core functionality, and AFAIK it is necessary to form multi-level
                  Message 8 of 13 , Apr 6, 2008
                  • 0 Attachment
                    > If functions were immutable, joining would be a transparent optimization.
                    >
                    Apart from the theoretical potential for backward incompatibility, why
                    >
                    isn't this a better solution? I suspect that very few programs rely on
                    >
                    mutating actual functions
                    Really? It is actually even used in ADsafe's core library. Mutating functions is pretty core functionality, and AFAIK it is necessary to form multi-level prototypical inheritance. If I want object A to delegate/inherit from preexisting object B, I must create a function and set the prototype (a mutation) to object B and then construct with that function. See the beget function in ADsafe.
                    I would extremely surprised if function mutation is less common than some of the things that the ES3.1 and ES4 groups have to maintain for backwards compatibility (the latest was being able override the Error built-in). I have used it other situations as well, like using storing a list of listeners on a AOP advising function. AOP style event listeners are common in popular JS libraries as well, and I would imagine they use such techiniques as well.
                     
                    > (as opposed to creating mutable objects that are
                    > callable as functions, or
                    mutating Function.prototype) .

                    How do make a regular object callable?
                     
                    Kris
                     
                     
                     
                    ----- Original Message -----
                    Sent: Sunday, April 06, 2008 9:17 AM
                    Subject: Re: [caplet] Mutability of functions in ECMAScript

                    Mark Miller wrote:
                    > On Sat, Apr 5, 2008 at 9:09 PM, Kris Zyp <kris@sitepen. com> wrote:
                    >> AFAIK, no implementation has ever actually done this "joining", and I
                    >> believe ES3.1 and ES4 will very likely dissallow joining to prevent it from
                    >> ever happening in the future.
                    >
                    > Yes, that's what we decided. ES3.1 and ES4 will be deterministic in
                    > this regard. No joining.

                    If functions were immutable, joining would be a transparent optimization.
                    Apart from the theoretical potential for backward incompatibility, why
                    isn't this a better solution? I suspect that very few programs rely on
                    mutating actual functions (as opposed to creating mutable objects that are
                    callable as functions, or mutating Function.prototype) .

                    --
                    David-Sarah Hopwood

                  • Mike Samuel
                    Does anyone know the rationale for putting joining in the spec in the first place? mike
                    Message 9 of 13 , Apr 6, 2008
                    • 0 Attachment
                      Does anyone know the rationale for putting joining in the spec in the first place?

                      mike




                      On 06/04/2008, Mark Miller <erights@...> wrote:

                      On Sat, Apr 5, 2008 at 9:09 PM, Kris Zyp <kris@...> wrote:
                      > AFAIK, no implementation has ever actually done this "joining", and I
                      > believe ES3.1 and ES4 will very likely dissallow joining to prevent it from
                      > ever happening in the future.

                      Yes, that's what we decided. ES3.1 and ES4 will be deterministic in
                      this regard. No joining.

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

                      Cheers,
                      --MarkM


                    • David-Sarah Hopwood
                      ... You re right, I don t know what I was thinking of. Making functions immutable in ES3.1/4 is not practical. -- David-Sarah Hopwood
                      Message 10 of 13 , Apr 6, 2008
                      • 0 Attachment
                        Kris Zyp wrote:
                        >> If functions were immutable, joining would be a transparent optimization.
                        >> Apart from the theoretical potential for backward incompatibility, why
                        >> isn't this a better solution? I suspect that very few programs rely on
                        >> mutating actual functions
                        >
                        > Really? It is actually even used in ADsafe's core library. Mutating functions
                        > is pretty core functionality, and AFAIK it is necessary to form multi-level
                        > prototypical inheritance. If I want object A to delegate/inherit from
                        > preexisting object B, I must create a function and set the prototype (a
                        > mutation) to object B and then construct with that function. See the beget
                        > function in ADsafe. I would extremely surprised if function mutation is less
                        > common than some of the things that the ES3.1 and ES4 groups have to maintain
                        > for backwards compatibility (the latest was being able override the Error
                        > built-in). I have used it other situations as well, like using storing a
                        > list of listeners on a AOP advising function. AOP style event listeners are
                        > common in popular JS libraries as well, and I would imagine they use such
                        > techiniques as well.
                        >
                        >> (as opposed to creating mutable objects that are
                        >> callable as functions, or mutating Function.prototype).
                        >
                        > How do make a regular object callable?

                        You're right, I don't know what I was thinking of. Making functions
                        immutable in ES3.1/4 is not practical.

                        --
                        David-Sarah Hopwood
                      • Mark S. Miller
                        ... I d guess it was to enable the optimization that David was suggesting. But I don t actually know. -- Cheers, --MarkM
                        Message 11 of 13 , Apr 6, 2008
                        • 0 Attachment
                          On Sun, Apr 6, 2008 at 12:30 PM, Mike Samuel <mikesamuel@...> wrote:
                          > Does anyone know the rationale for putting joining in the spec in the first
                          > place?

                          I'd guess it was to enable the optimization that David was suggesting.
                          But I don't actually know.


                          --
                          Cheers,
                          --MarkM
                        • Douglas Crockford
                          ... optimization. ... functions is pretty core functionality, and AFAIK it is necessary to form multi-level prototypical inheritance. If I want object A to
                          Message 12 of 13 , Apr 8, 2008
                          • 0 Attachment
                            --- In caplet@yahoogroups.com, "Kris Zyp" <kris@...> wrote:
                            > > If functions were immutable, joining would be a transparent
                            optimization.
                            > > Apart from the theoretical potential for backward incompatibility, why
                            > > isn't this a better solution? I suspect that very few programs rely on
                            > > mutating actual functions

                            > Really? It is actually even used in ADsafe's core library. Mutating
                            functions is pretty core functionality, and AFAIK it is necessary to
                            form multi-level prototypical inheritance. If I want object A to
                            delegate/inherit from preexisting object B, I must create a function
                            and set the prototype (a mutation) to object B and then construct with
                            that function. See the beget function in ADsafe.


                            beget is a workaround for the lack of an operator that produces an
                            object with a delegation relationship. It should not be interpreted as
                            proof that mutable functions are desirable.
                          Your message has been successfully submitted and would be delivered to recipients shortly.