Saturday, July 30, 2005

Greasemonkey 0.5 Beta

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.

Security

The 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.

Features

Since 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:

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 Authors

For 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.

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.

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.

Definitely let us know how it performs on that front. I think I had the memory issues licked in 0.4.x back before the security scare. But there have been some pretty massive changes to get to 0.5. It's possible that new leaks have been introduced (though I have not experienced them).

If you see any problem here, I can definitely fix it before we get to 0.5 gold.

What do you mean, adding? 0.3.5 has a "User Script Commands" submenu in the Tools menu already. The ability to remove it in prefs would be nice, but I bet anything you can hide it in userChrome.css too.

I don't know about everyone else, but my copy of 0.5 beta is still suffering from the memory leak problem. If it is not happening to anyone else, I will try testing individual user scripts and report back.

> I wound up going back, things just > weren't working right at all. But > that's to be expected, the 0.5 is > beta after all. It'll get there.

I know what you mean. Some scripts work fine. But some that are meant to work on pages that are dynamically updated when a button is pressed, only work when they are initially loaded. After the button is click, and a few elements on the page are changed, all the changes that the GM script made are gone, and the page behaves as if the script isn't even loaded (I'm guessing it's probably not). I stripped the script down to its bare essentials, having it do one simple operation (change a text string to Bold). When the page initially loads, it works. Press the button (which doesn't affect the text being bolded), and it doesn't work. I'd love to post the page and script, but can't for security reasons.

This version breaks 2 scripts I'm using: "Slashdot single page view" and "Slashdot live comment tree", both available from the Wiki.

I can tell that the scripts are loading (they modify some text content on the page), but they don't seem to actually work. No errors appear in the Javascript console, but the scripts may be catching exceptions, haven't yet looked at their source.

in Greasemonkey 0.3.5, when I go to "Manage User Scripts" and click "Edit" and then edit any user script, it doesn't change the information shown after I'm done.i had to change it manually in config.xml.could you fix this in 0.5 final?

But GM no longer works. When I download a .JS or install from a webpage, it shows the linked item downloading...but it does not show up in Greasemonkey's window. It's just blank. I've uninstalled & reinstalled GM several times.

Same happened to me, suddenly all my scripts where GONE and I can't add nor delete nor edit anything...greasemonkey just died on me. For what I saw at the greasemonkey page at Mozdev website, the same happened to several users. What happened??

Captivating blog. I love surfing the web for thetype of blogs that you do. It had me on the edge of myseat and I kept going back to again and again!Once you sign on, check for my medical staffing blog.

Hi there " boogs " --- I was in the search engines researching SEO Software when I came upon your blog..... I don't know if you are out of place in the engines, or I am out of place and just don't realize it :-)

Prodigious blog. Loved it so much I went to itagain! Just go online and search for blogs that areworth the value as yours.Want to see top notch work, peep my cash advance with savings account blog site for the bomb work!

Astonshing blog. I relished in the site and youknow I will be going to it again! Surfing the internethepls me to find blogs that arfe just as good.Sweetie, go and search my event jobs blog for what you need.

Unique blog my friend, I can hardly wait to vistthis site again. I just worship the site its comesfrom! Believe me in my extra time I'm consistentlylooking up blogs like this.Stop by and look at my america job bank blog site.