Talk:Location hack

GM_eval vs. eval(s, unsafeWindow) vs. LocationHack

JavaScript in Mozilla/Gecko/Firefox is currently implemented by the SpiderMonkey engine written in C. It implements an eval function that takes an optional second argument to give the scope or context for the eval.

eval(string[, object])

It seems the two-argument eval can do all or more than the location-hack.

The main question is how secure it is in terms of giving a web page control over a browser. (Note that there are problems with this issue but particulars are purposefully rarely mentioned). I can't see how a JS statement like the following could leak any GM access to a web page.

eval(s, unsafeWindow);

But then, the following might be unsafe, particularly if r is later stored somewhere or more particularly if r gets some methods invoked off of it:

var r = eval(s, unsafeWindow);

The obvious solution to make r safe from potential terrors is to wrap it in a XPCNativeWrapper just like GreaseMonkey does.

r = new XPCNativeWrapper(eval(s, unsafeWindow));

Objections to: eval(s, unsafeWindow)

• It is not as obfuscated as sending the string 'javascript:...' to location.href and is thus not as cool.
• 2-argument eval is not standard JavaScript
  • While the true GreaseMonkey is based on Mozilla code, there are several other implementations for different browsers with different script engines, and those might not implement 2-argument eval.
  • Mozilla JavaScript is considering and may migrate to to standards such as ECMAScript for XML (E4X) and/or go to the open source Tamerin engine which Adobe wants. These new versions of JavaScript might not implement 2-argument eval (though I doubt it).
• Script writers who directly use eval may break security unless they take the extra step to wrap the result.

Advantages of: eval(s, unsafeWindow)

• It is less verbose than the location hack. You don't have to wrap strings in things like

javascript:void(...)

• It permits returning a value in a way that the target page cannot detect.
• You don't have to worry whether you need to encode special characters like with the location-hack.

GM_eval

To resolve this distinction I propose that the GM API include the function GM_eval. In Mozilla GreaseMonkey it is just defined as something like

function GM_eval (string) {return new XPCNativeWrapper(eval(string, unsafeWindow));

For other browsers/script-engines that don't have 2-argument eval one might want to make it a 2-argument function:

GM_eval(string, [boolean]);

that uses the location-hack and wraps and encodes the string appropriatly. If the second argument is true then that means the function should use some detectable means to record the result inside the target document and return it or just possibly complain with a security error.

Advantages:

• Using GM_eval semantically indicates that you are safely evaluating something on the target page as opposed to going through some hack back door.
• You don't need to extra wrap or encode things like for the location-hack.
• GM_eval would really simplify the documentation of GreaseMonkey. For example this page would disappear. There would be one page on GM_eval that explains what it means and how it can be imlemented through eval or the location-hack, and most of the other stuff on this page could go into "code snippits". [Though I have noticed some other references to location-hack that should be cleaned up]

Disadvantages

None seen so far other than increasing the API count by one.