module pattern provides no privacy in Firefox

Discussion in 'Javascript' started by Peter Michaux, Jun 27, 2008.

  1. The module pattern has been discussed many times and has shown how
    ECMAScript has the ability to encapsulate data as "private" variables
    by using closures.

    Today, in a comment on my blog, a reader, haysmark, points out that
    Mozilla's JavaScript(TM), the implementation in Firefox, has a second
    argument extension to eval that allows external code to spy on
    otherwise private variables.

    http://peter.michaux.ca/article/4947#comment-8061

    Try the examples below in Firefox.

    // Getting "private" variables
    var obj = (function() {
    var a = 21;
    return {
    // public function must reference 'a'
    fn: function() {a;}
    };
    })();

    var foo;
    eval('foo=a', obj.fn);
    console.log(foo); // 21


    // Setting "private" variables
    var obj = (function() {
    var a = 21;
    return {
    getA: function(){return a;},
    alertA: function(){alert(a);}
    };
    })();

    console.log(obj.getA()); //21
    eval('a=3', obj.getA);
    console.log(obj.getA()); // 3
    obj.alertA(); // 3

    I don't think about the second argument to eval very frequently and
    have never used it. This "hack" was a surprise to me and is a pretty
    neat trick.

    (I posted a slightly longer version of this message to my blog
    http://peter.michaux.ca/article/8069 to try to see what others who
    don't read this group think.)

    Peter
     
    Peter Michaux, Jun 27, 2008
    #1
    1. Advertising

  2. On Jun 27, 4:56 am, Peter Michaux wrote:
    > The module pattern has been discussed many times and has shown how
    > ECMAScript has the ability to encapsulate data as "private"
    > variables by using closures.


    Not the module pattern. Encapsulation using closures in javascript
    pre-dates the module pattern so the ability had already been shown.

    > Today, in a comment on my blog, a reader, haysmark, points out that
    > Mozilla's JavaScript(TM), the implementation in Firefox, has a
    > second argument extension to eval that allows external code to spy
    > on otherwise private variables.
    >
    > http://peter.michaux.ca/article/4947#comment-8061
    >
    > Try the examples below in Firefox.
    >
    > // Getting "private" variables
    > var obj = (function() {
    > var a = 21;
    > return {
    > // public function must reference 'a'
    > fn: function() {a;}
    > };
    >
    > })();
    >
    > var foo;
    > eval('foo=a', obj.fn);
    > console.log(foo); // 21
    >
    > // Setting "private" variables
    > var obj = (function() {
    > var a = 21;
    > return {
    > getA: function(){return a;},
    > alertA: function(){alert(a);}
    > };
    >
    > })();
    >
    > console.log(obj.getA()); //21
    > eval('a=3', obj.getA);
    > console.log(obj.getA()); // 3
    > obj.alertA(); // 3
    >
    > I don't think about the second argument to eval very frequently
    > and have never used it.


    Speaking of "the second argument" suggests that such an argument would
    be common and consistent. We are talking about a non-standard extension,
    and so not something that can be expected to be in the environment of
    cross-browser code except by coincidence.

    > This "hack" was a surprise to me and is a pretty
    > neat trick.

    <snip>

    It is not really a change in the situation. Because client-side code
    is transmitted to the client as source code and interpreted/compiled
    on the client from the source code it receives, there never was any
    guarantee that anything could be placed out of reach by a javascript
    programmer.

    Consider content inserting/re-writing proxies for a start. As the
    source code passes through such a proxy it can add a privileged
    getter and setter for every 'private' variable in the system and
    there is nothing the author of the original code could do to
    prevent that. (Even ES4, with its formal notions of encapsulation
    and 'private' is going to be vulnerable to content inserting
    proxies (say swapping all occurrences of a 'private' keyword into
    something more permissive)).

    Once in the DOM there are many browser which will expose the
    source code to javascript, so (other) javascript can manipulate the
    strings of source code and then re-compile them back to produce
    an environment that precisely as open as wanted.

    So it is within the user's power to take total control over the
    javascript code that executes in their browser regardless of
    where it originates. And there is nothing that the code's
    programmer can do to prevent that (or even to find out if/when
    the code executed is not the code that was broadcast). That
    situation is just the consequence of sending the source code
    rather than a pre-complied executable.

    An - eval - argument that re-establishes a scope from a previous
    execution context doesn't make client-side javascript any less
    of a bad place to holding important secretes or any less
    something that should be trusted to be doing (or not doing)
    any particular thing. It is just one more tool in a world where
    the people who want such tools already have a collection including
    everything they need.

    While the module pattern may have originated from ideas about
    having 'private' members of various sorts I don't think that
    was ever the primary reason for using it. More the ability
    of the module pattern to group related code into discrete
    units and keep the internal details of those units out of the
    global scope. So while the earliest examples may have internal
    variables and functions which are not exposed (and so might
    be regarded as private) they are not exposed not because
    there is an overwhelming reason for not exposing them but
    rather because there is no reason to expose them.

    Richard.
     
    Richard Cornford, Jul 8, 2008
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gene
    Replies:
    2
    Views:
    2,899
    Saravana [MVP]
    Apr 19, 2004
  2. Navain Goksin

    hosting that provides iis app ext mappings

    Navain Goksin, Jul 12, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    336
    Craig Deelsnyder
    Jul 12, 2004
  3. Annie
    Replies:
    3
    Views:
    437
    Annie
    Sep 4, 2005
  4. Damodar Periwal
    Replies:
    0
    Views:
    317
    Damodar Periwal
    Feb 29, 2004
  5. yogesh
    Replies:
    14
    Views:
    4,701
    Tony Morris
    Apr 20, 2004
Loading...

Share This Page