What can't you do, thanks to Greasemonkey's security sandbox?

87 views
Skip to first unread message

Anthony Lieuallen

unread,
May 22, 2012, 2:15:44 PM5/22/12
to greasemon...@googlegroups.com, greasemo...@googlegroups.com
I'm finally starting work in earnest on Greasemonkey 1.0.  The major change is to move towards explicitly requesting access to the elevated privilege APIs that Greasemonkey has historically exposed to user scripts and, more importantly, _not_ imposing the convoluted security restrictions that make them safe, if you don't request access to them.

So I'd like to start assembling a list of things that would work in standard JavaScript in the page, but break in Greasemonkey.  I'd like to be sure that the changes made going forward make these things possible again.  I know of a few of these things and can test for them.  But I've understood the limitations for so long that I almost have a mental block for automatically not using them.

So, if there's a thing that should work but breaks in Greasemonkey please let me know.  This work is happening in https://github.com/greasemonkey/greasemonkey/issues/1427

Bluflonalgul

unread,
May 23, 2012, 12:10:39 PM5/23/12
to greasemonkey-users
I'm not sure that the trick we use in our GM script is relevant to
your question, but I prefer to ask, just in case our script might not
work well with GM 1.0.

The site we plug into relies heavily on AJAX and some kind of JSOND.
So we have some framework to deal with that and keep an abstraction
layer over this problem, in order to ease the different insertions we
handle.

The main technique we use is to "hook" on a callback function of the
site's javascript.

For example let say that the page DOM nodes are populated by a
js.SiteFillPage(data) function, from the site scripts.

Our script saves this function with
OriginalFunction=window.wrappedJSObject.js.SiteFillPage.

Then we replace this function by our own:
window.wrappedJSObject.js.SiteFillPage = function(data) {
... // checking things...
window.unsafeCall(function() { OurFunctions.ProcessPage(); });
return OriginalFunction(data);
}
The OurFunctions.ProcessPage is our main function in our script, and
it uses GM_ specific functions.

As you see, to be able to use GM functions from such a call, we use
this unsafeCall function:
window.unsafeCall = function(fn) {
if(typeof fn == 'function') window.setTimeout(fn, 0); else
GM_log("Error: window.unsafeCall argument must be a Function!");
};

I would like to know what impact the 1.0 version would have on our
technique, or what we could use for a stronger security.

Thanks a lot for Greasemonkey :)

Anthony Lieuallen

unread,
May 23, 2012, 2:36:34 PM5/23/12
to greasemon...@googlegroups.com
On Wed, May 23, 2012 at 12:10 PM, Bluflonalgul <bluflo...@gmail.com> wrote:
The OurFunctions.ProcessPage is our main function in our script, and
it uses GM_ specific functions.

This topic is probably complex enough for its own thread.  But if by "GM_ specific" you mean the privileged GM_ prefixed functions only available in current Greasemonkey, then things won't change for you (as long as you @grant the things you need).  (At least, I don't intend for them to change, and would consider a release that breaks them unworthy of release.)
Reply all
Reply to author
Forward
0 new messages