Global variables safety

[tvgemert]

If I attach a variable to the window element (like: window.myGlobalVar
= 'something'
How secure is that? Is it possible for the value of the myGlobalVar to
be tampered with?

 

[Stevo]

If I attach a variable to the window element (like: window.myGlobalVar
= 'something'
How secure is that? Is it possible for the value of the myGlobalVar to
be tampered with?

You'll need to go into way more detail on who/what you think might be
tampering with your globals. Certainly any code on the page will be able
to tamper with it.

 

[Thomas 'PointedEars' Lahn]

If I attach a variable to the window element (like: window.myGlobalVar
= 'something'
How secure is that?

Not at all. `window' refers to a host object (which does not need to
implement augmentation) and `window.myGlobalVar' is _not_ a variable
(but, if it works, a property of that object).

You meant to say something along

var _global = this;

function...(...)
{
_global.myGlobal = ...
}

instead. See

Is it possible for the value of the myGlobalVar to be tampered with?

As long as the owner of the property permits it.


PointedEars

 

[Thomas 'PointedEars' Lahn]

You meant to say something along

var _global = this;

function...(...)
{
_global.myGlobal = ...
}

instead. See
<https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference#Global_Objects>

Supplemental: _global.myGlobal is also not a (global) variable as it does
not have the `DontDelete' attribute. Only

var myGlobal = ...;

has that. However, the former is a globally available property.


PointedEars

 

[Jorge]

(...)
Not at all.  `window' refers to a host object (which does not need to
implement augmentation) and `window.myGlobalVar' is _not_ a variable
(but, if it works, a property of that object).

You meant to say something along

  var _global = this;
(...)

alert( this === window ); //-> TRUE

 

[tvgemert]

You'll need to go into way more detail on who/what you think might be
tampering with your globals. Certainly any code on the page will be able
to tamper with it.

Thanks all for your insight!

OK, I haven't been to strict in terminology but this is what I found
to be a nice (easy) method of creating a value that is globally
accessible to my javascripts. It represents the path to the root of my
server (which differs for our local and online situations). I need
that path in some functions, but I don't *like* to send this as an
argument each time.

Since my knowledge of javascript is at a mediocre level I am not sure
if in this situation it would be possible for i.e. a hacker to put up
a script that changes this path to say their own server.

 

[Thomas 'PointedEars' Lahn]

[...] OK, I haven't been to strict in terminology but [window.myGlobalVar
= 'something'] is what I found to be a nice (easy) method of creating a
value that is globally accessible to my javascripts. It represents the
path to the root of my server (which differs for our local and online
situations). I need that path in some functions, but I don't *like* to
send this as an argument each time.

Since my knowledge of javascript is at a mediocre level

You qualify as a beginner at most. Therefore, you should not be playing
with things that you do not (yet) understand and that your assessment of
"nice" would be correct. Use the Global Object as specified.

I am not sure if in this situation it would be possible for i.e. a hacker
to put up a script that changes this path to say their own server.

You've got your answer already.


PointedEars

 

[Stevo]

You qualify as a beginner at most. Therefore, you should not be playing
with things that you do not (yet) understand

You've got your answer already.

PointedEars

Do you ever regret any of your nasty responses Thomas ? If I wrote
messages like you do, I'd think "I'm such a condescending holier than
thou asshole". Not that I'm saying you're one though. I just know if I
posted the responses you do then I would be.

 

[tvgemert]

[...] OK, I haven't been to strict in terminology but [window.myGlobalVar
= 'something'] is what I found to be a nice (easy) method of creatinga
value that is globally accessible to my javascripts. It represents the
path to the root of my server (which differs for our local and online
situations). I need that path in some functions, but I don't *like* to
send this as an argument each time.

Since my knowledge of javascript is at a mediocre level

You qualify as a beginner at most.  Therefore, you should not be playing
with things that you do not (yet) understand and that your assessment of
"nice" would be correct.  Use the Global Object as specified.

I am not sure if in this situation it would be possible for i.e. a hacker
to put up a script that changes this path to say their own server.

You've got your answer already.

PointedEars

Gee, thanks man! Very usefull...
I'm definitely not a beginner, but uncertain of some aspects of js
because I just don't use it extensively every day. I just wanted some
more insight in this.
f.y.i. I've learned a lot of just reading these reactions.

 

[tvgemert]

What would "put up" mean in this context?

Someone sitting at a browser accessing the page containing the variable
could easily change its value to point to another server, but what do
they gain from that? Presumably they already know everything about
themselves that they may be interested in.

Redirecting to another server is only useful if the "hacker" can
redirect another user to that server. If this "hacker" can access that
user's browser while the page is loaded, or modify the set-up on their
local computer (install a re-writing proxy, or something) then they
could modify the variable to achieve the redirect. That is a security
issue, but it is not yours. It is a security issue in that user's
environment (and any vulnerability in that regard is unlikely to
exploited by modifying your javascript variables).

The variable assignment could be re-written as the code passed through
any proxy in its path between your servers and the end user, if the
"hacker" could gain access to those proxies. That is a security issue,
but again it is not yours.

Leaving the "hacker" with the option of modifying the source code on the
server (or having the server re-write it at the point of transmission,
if he can gain access to the server. That is a security issue, and it is
likely to be an issue that either is yours or is close to you. But
securing your own servers is not a javascript issue, though it is
something that is under your influence.

People do import scripts from common repositories (Google and Yahoo host
such repositories). That is a good idea from the caching point of view,
but introduces uncontrollable unknowns from the security point of view.

Suppose, for example, you assigned your variable and then imported
something like JQuery from a common repository. Then someone at (or with
access to) that repository could arrange (using, say, the Referer header
to know which URL was importing the script and tailor the response
appropriately) for the library to be sent with some additional code that
re-set your variable to another location. You would have no control over
whether that was happening and only someone's say so as an assurance
that any repository was "secure" (not even necessarily that).

Richard.

Richard,

Thanks very much for this! Examples help a lot in understanding how
this works.
I have some stuff to think about now and probably reconsider how I'm
going to use this.

Thanks all for your efforts!

Tom

 

[Thomas 'PointedEars' Lahn]

[...] OK, I haven't been to strict in terminology but [window.myGlobalVar
= 'something'] is what I found to be a nice (easy) method of creating a
value that is globally accessible to my javascripts. [...]
Since my knowledge of javascript is at a mediocre level

You qualify as a beginner at most. Therefore, you should not be playing
with things that you do not (yet) understand and that your assessment of
"nice" would be correct. Use the Global Object as specified.

I am not sure if in this situation it would be possible for i.e. a hacker
to put up a script that changes this path to say their own server.

You've got your answer already.
[...]

Gee, thanks man! Very usefull...

You're welcome.

I'm definitely not a beginner, but uncertain of some aspects of js
because I just don't use it extensively every day.

People who are using `window' for global variables, who do this only because
it is "nice" (easy) (and don't quote properly) qualify at most as beginners
for me. Overconfidence about one's level of knowledge is common in this
field. That is not to say that this condition must or should be permanent,
only something one should be aware of at all times. It helps to avoid the
most common blunders (like this).

I just wanted some more insight in this.
f.y.i. I've learned a lot of just reading these reactions.

Good.


PointedEars

 

[Matt Kruse]

People who are using `window' for global variables, who do this only because
it is "nice" (easy) (and don't quote properly) qualify at most as beginners
for me.

Oh I don't know, perhaps they are confused by the fact that it works
just fine in _every single browser_. While it may not be as purist as
you would prefer, it is no doubt as equally effective as your
approach.

Matt Kruse

 

[Thomas 'PointedEars' Lahn]

Oh I don't know, perhaps they are confused by the fact that it works
just fine in _every single browser_. While it may not be as purist as
you would prefer, it is no doubt as equally effective as your
approach.

Of course it isn't.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Well that was short and pointless. Could you expand on that?

Again? Well, to begin with, think about the built-in host properties the
object referred to by `window' has and that the ECMAScript global object has
not. This should give you pause.

You mentioned in a recent post that you prefer variables, because they
have DontDelete set. I don't quite see the relevance.

That is unsurprising.

If it's globally available, anyone can change it,

Since nobody uses them but me, not anyone can.

or set it to null (ignoring 'const', for the moment). [...]

I know this. You missed the point of that posting completely.

And BTW, yes, I'm assuming that 'window' points to the global object
here. This is a valid assumption in browser scripting,

Because of what -- proof by example? You should know better than that.

and it's even mentioned in the ECMAScript specs (10.1.5): [...]

As an example. How many times do you need to be told that examples in
specifications are never normative?


PointedEars

 

[JR]

Well that was short and pointless. Could you expand on that?

Again?  Well, to begin with, think about the built-in host properties the
object referred to by `window' has and that the ECMAScript global object has
not.  This should give you pause.
[...]

And BTW, yes, I'm assuming that 'window' points to the global object
here. This is a valid assumption in browser scripting,

Because of what -- proof by example? You should know better than that.

Well, this code snippet shouldn't work but it does:

something = "I belong to window";

function test() {
window.alert(window.something);
}

test(); // returns "I belong to window".

It seems that the browser (FF3) is adding the global variable
('something') to 'window'. So, window.something = 'test' is the same
as something = 'test'.

But I think you'll come up with an example defying that...

 

[Thomas 'PointedEars' Lahn]

So what about them? That's not a reason to prefer variables over window
properties.

Let's see: `window' refers to a host object that has quite a few built-in
host properties. Per Specification, host objects do not need to implement
ECMAScript's [[Get]] and [[Put]] algorithms as they are. And you say that
this is not reason enough not to use that host object as a container for a
poor substitute of well-specified global variables?

Any script on that page can change it.

I know what I am writing.

or set it to null (ignoring 'const', for the moment). [...]

I know this. You missed the point of that posting completely.

Then enlighten me: [...]

Not possible. You are too fixated on the `DontDelete' part to notice
anything else.

Nobody said anything about a proof (except you),

So you'd rather jump to conclusions?

and a theory isn't made worthless by the technical inability to prove it.
[...]

The theory argument again. How boring. Don't you think that things known
for sure, because they are specified and implemented so, have a little bit
more value in practice than things that can only be theorized about?

It cannot be known for sure that the host-defined `window' property is
always available, if available refers to the Global Object, and thus these
two are interchangeable; that is only a theory (of yours), if that. By
contrast, it is known for sure that there is a Global Object that can be
referred to by `this' in global context, and in an immediately called
function expression.

It cannot be known for sure whether properties of the Global Object are
always reflected in the properties of the object that `window' refers to.
By contrast, it is known for sure that global variables are properties of
the Global Object as this object is the Variable Object of the global
execution context.

and it's even mentioned in the ECMAScript specs (10.1.5): [...]

As an example. How many times do you need to be told that examples in
specifications are never normative?

I never said it was normative, [...]

You implied it. Why else would you have quoted it in that context? Only to
support your fallacious argumentation that is only based on proof-by-example
("Here, mommy, I found another one! Even the Spec says I'm right!"), or
bare assertion.


PointedEars

 

[Thomas 'PointedEars' Lahn]

On 27/06/09 00:42, Thomas 'PointedEars' Lahn wrote:
Well, to begin with, think about the built-in host properties the
object referred to by `window' has and that the ECMAScript global
object has not.
So what about them? That's not a reason to prefer variables over
window properties.

Let's see: `window' refers to a host object that has quite a few
built-in host properties. Per Specification, host objects do not need
to implement ECMAScript's [[Get]] and [[Put]] algorithms as they are.
And you say that this is not reason enough not to use that host object
as a container for a poor substitute of well-specified global
variables?

Now we're finally getting somewhere, [...] Its getters and setters can
have side effects, for example window.location = [...]; that makes it
dangerous to use, at least when accessing properties which are already
defined in window. Thanks for this.

You're welcome. I'd rather not have to lead you from A to B to C that
often, though.

If this bores you, maybe you shouldn't automatically dismiss everything
which can't be proven.

Or maybe you should not jump to useless conclusions.

[...]
The reason why this is coming up again and again is that you have a habit
of labelling people's statements with various logical fallacies, and yet
you demand proof where none is possible,

I say as described because ...

and make logical errors like the above.

(There is no error. It is logical to seek proof for a conjecture.)

Let's try some more logic:
[...]

It cannot be known for sure whether properties of the Global Object are
always reflected in the properties of the object that `window' refers
to. By contrast, it is known for sure that global variables are
properties of the Global Object as this object is the Variable Object
of the global execution context.

I also agree with that, but...

....none of this argues against my conjecture that 'window' is available
in all browsers as a reference to the global object (whether this is
"known" or not). That was the second part of my post, and not directly
related to the first, in which I asked why global variables were superior
to defining properties on the global object. The availability of "window"
is a de facto standard.

.... your logic *is* flawed, and your reasoning *is* fallacious.

Allow me to quote you again, from the same thread, and in very similar
context (you recommended the use of a non-standard header):

| You are missing the point, i.e. that there are widely used features
| that are not standardized or registered but work anyway because they
| are widely supported as well.

http://groups.google.com/group/comp.lang.javascript/msg/399ab29f309dfaba

Couldn't agree with you more!

Your inept attempt at twisting my words, undoubtedly in order to try turning
your failure into victory, is unsuccessful. The context in which I said
this had nothing to do with what we are discussing here; as the dedicated
reader will no doubt notice, I had been referring to the `type' attribute of
the `script' element that, which value, "text/javascript", was at that time
not yet registered at IANA but worked anyway.


PointedEars