All of us here in Greasemonkeyland are extremely happy to announce that
Greasemonkey 0.5 beta is now available for download. Horray!
It should go without saying, but:
this is beta software. There will definitely be bugs. Install at your own risk.
SecurityThe major news with this release is, of course, security. Greasemonkey 0.5 is much more secure than 0.3.5. Several important classes of attacks have been completely disabled and others have been made more difficult, particularly in Deer Park.
- In Greasemonkey 0.3.4, it was possible for JavaScript on webpages you visited ("content") to use DOM mutation events, watchpoints, or Mozilla's proprietary __defineSetter__ method to get references to the special GM API functions. This has been fixed by moving user script execution away from content completely. Now, user scripts are executed in a separate object -- a "sandbox" -- which is not part of the content window. That means that content scripts cannot acccess it, and thus, cannot employ any of the tricks above to get access to the special GM APIs.
- In earlier versions, it was possible to block Greasemonkey itself by redefining certain content DOM methods that it used to inject scripts. This has been fixed in 0.5 by only ever accessing content via the special XPCNativeWrapper objects provided by Firefox for this purpose.
- It has long been understood and accepted that it would be possible to block individual user scripts by looking at which core DOM methods they try to use and redefining those. This will be a lot more difficult to do in Greasemonkey 0.5 when it is running on Deer Park. On Deer Park, the window and document global variables for Greasemonkey user scripts are also XPCNativeWrappers.
- It was recently discovered that GM_xmlhttpRequest was able to access the file:// protocol and read local files. This has been fixed.
- In all previous versions of Greasemonkey, it was trivial for content to monitor what user scripts you ran and get the source code for them. Running Deer Park and Greasemonkey 0.5, it's significantly less likely. It's still not impossible, however, so please continue to not put passwords in Greasemonkey user scripts.
Of course, no software is ever perfectly secure. Greasemonkey's entire point of existence is to mash code from two different trust domains into the same space, so it has been particularly tricky. This will be an ongoing fight. But for now, I believe that there are no known major security issues with Greasemonkey 0.5 and that it is safe to use. I also think that any future fixes will be much easier to make.
FeaturesSince Greasemonkey 0.5 is actually the combination of a massive security audit and all the new code which was planned for 0.4, there are lots of new features too:
- GM_registerMenuCommand (documentation forthcoming) now takes extra parameters to add keyboard shortcuts.
- GM_registerMenuCommand no longer gets confused sometimes when switching tabs.
- Greasemonkey's previous memory leakage problems have been addressed.
- A new API, GM_openInTab has been added. You can now use a Greasemonkey user script to open a URL in a new Firefox tab.
- A new menu item has been added: New User Script, which you can use to start a new script. It adds all the boilerplate text to the file so you can get started typing right away.
For User Script AuthorsFor the most part, Greasemonkey 0.5 should be perfectly backward compatible with your existing user scripts in Firefox 1.0.x. In some cases, however, it can bite you when it didn't before. Generally speaking:
- Never add properties or functions to window. It's not safe because content can redefine these functions to mean something other than what you wrote.
For example, you should never write code like this:
window.handleClick = function() {
alert("something was clicked!");
}
button.setAttribute("click", "window.handleClick()");
Instead, do it this way:
function handleClick() {
alert("something was clicked!");
}
button.addEventListener("click", handleClick, false);
- When you want to manipulate the DOM, always fully-qualify your expressions with window or document. So if you want to call alert on the current window, say window.alert instead of just alert. By doing this, you are sure to get the real alert method instead of a new one that content has used to overwrite the real one.
In a future version of Greasemonkey, the ability to call methods and properties of window without this qualification will probably go away, so best to get in the habit now.
- Keep up with the current Deer Park best practices on the Greasemonkey wiki.
- Test in Deer Park if possible. Everything that works in Deer Park will definitely work in FF 1.0.x, but the reverse is not true. So it's best to test or develop your scripts in Deer Park for maximum compatibility.
So that's it. If you have any other questions, the
Greasemonkey mailing list is, as always, the place to ask them.
Happy scripting!
