Wednesday, May 18, 2005

More obvious user script alterations?

Rael made a pretty high-profile mistake in posting that Google had added delicious tags to its results page. It turns out that these tags were supplied by the Annotate Google user script, which he'd installed and forgotten.

He raises the point that the user-writable web is likely to raise more such issues:

While I'm as much a fan of the writeable and rewriteable Web as anyone..., is
that cute little Greasemonkey in the bottom-right corner of my browser
notification enough? (Apparently not.)

Point taken. But is this something that should be solved by more obvious changes, or by more awareness of the augmented web? I don't expect my email client to show the same contacts as Rael's. Why should I expect my search results to be the same as Rael's?

OK, it's a stretch, but maybe we can agree that if the augmented web continues to become more popular, this becomes a non-issue.

If we can't agree on that, how could the augmentations be made more obvious? Mouseover'd aura element borders? A monkey icon that smiles more largely when scripts have been injected? A siren that sounds when you've forgotten, again, that this page is augmented?

That last one may be a bit annoying.

Suggestions? Comments welcome, or send 'em to the list.

Monday, May 16, 2005

Slashdot (ouch)

Apologies for the downtime and slow responses experienced on the script directory and home page. DiG warranted a Slashdot post, and we're all hurting. Except for DiG. Mark was prepared, of course.

Anyway, uh, this is temporary. Probably. ;)

Sunday, May 15, 2005

0.3.3 (not beta)

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

Tuesday, May 10, 2005

Greasemonkey 0.3.3 (beta)

No big changes over 0.3b. The main news is that it should work for the latest aviary (soon to be 1.0.4). Still working on latest trunk fix. Sowwy.

Details here.

Since mozdev takes a while to propogate mirrors, you can also try getting it here.

Dive into Greasemonkey

If you're interested in Greasemonkey, you'll be interested in this: Dive into Greasemonkey, another fine publication by Mark Pilgrim, whose enthusiasm Greasemonkey has benefitted from greatly.

Dive into Greasemonkey is
  • Patterns
  • Case studies
  • API reference
  • Screencasts
  • GPL-licensed
It's also excellent, and includes the latest features. If you'd like to know something about coding for Greasemonkey it's there. If you'd like to evangelize Greasemonkey to someone else, it's there. If you'd like to learn how to use Greasemonkey, it's there.

Fully buzzword compliant, just the right length.

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 (the classic XPI/mimetype issue). Sorry about the false start. Reposting now to 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


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 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]">
... your html, css, javascript here ...

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

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

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

Friday, April 08, 2005

I posted something very like this to the mailing list, but I wanted it to get out to more people for consideration.

So far, Greasemonkey has gotten by with a wiki page, but it's quickly outgrowing that.

So I'm starting to work on a new user script directory, which will live over on

I'm interested in input on how I'm planning to do this (or if someone would like to help). If you think I'm doing something wrong, please convince me.

To set the stage, here are the goals I'm attempting to address:

  1. Provide versioning and update notification.

  2. Improve ability to judge trustworthiness of scripts

  3. Provide an easy way to find user scripts.

  4. Encourage sharing of scripts.

  5. Provide a home for the idea of user scripts, including other browsers.

That's all fairly ambitious, so I'll be reluctant to take on new goals.

In order to serve goals 1-4, the directory will need to discover scripts, and regular spidering won't be very useful, I think, because there are relatively few user scripts, and I'm not sure how to go about finding good sources of scripts.

(Well, there are obvious things like checking domains you've found them on before, and taking outbound links from those sites if url like *user.js, but even so...)

I think using delicious for discovery is a pretty easy win, because people will tag for Greasemonkey if it's useful, and delicious is useful as a directory to start with, and we can seed the tagging with quite a number of scripts already.

Of course the directory will allow form-post submission of a URL to a script so that authors can have a more direct way of discovery.

So assume we've got a directory and it has lots of scripts and no trouble finding more.

I plan on managing versioning as follows: once a script has been discovered, it will be hashed, and this hash will be the basis for differentiating the originally retrieved script from any later version. Scripts in the directory will be periodically retrieved, and changes in hashes will create new versions in the directory.

Why take this route over allowing (read: requiring) authors to explicitly version?

1) Because this versioning is meant to allow not just for update notification, but also for assignment of trust. A popular script that has not changed in a month is very likely trustworthy, but once a new version is published, all bets are off. If the author controlled the versioning as well as the script, there'd be no basis for trust.

2) Because authors won't consistently version their own scripts. User script authoring is meant to be relatively fluid and lightweight, and making backups and renaming and re-versioning is a bunch of overhead when the author just wants to spend a couple seconds fixing a bug.

So assume we have a directory with scripts and versioning. With this, we can provide update notification. Syndication seems the obvious choice; it's lightweight, and people interested in Greasemonkey are very likely to use it. I suppose we could also do email notification, but, well, I don't know much about administering a mail server or mailing list software.

So the user's been notified that there is a new script he may be interested in. How does she know whether its OK to install? There've been suggestions that sand boxing user scripts would be good, and breathless descriptions of how this is the end of e-commerce (OK, that's a small hyperbole).

(Thanks to Adrian Holovaty for pointing out that Craigslist has this problem and has proven that a community review process is all you really need to keep bad things from happening.)

I think generally people will be interested in controlling this problem, and keeping stuff completely safe is sort of an impossible goal. All you can hope for is to keep things from going off the rails and exposing lots of people to rude things. We'll have people using these scripts, and some of them will peek under the hood, and some of -them- will notice that the script is doing rude things. These people should be able to flag scripts as evil, and a trusted group (perhaps recruited on the basis of correct flagging) will review a queue of flagged scripts. Anything sufficiently flagged (what's sufficient? I dunno) will be unavailable in the directory until it's reviewed. Anything that's been reviewed and has the Good Webkeeping seal of approval will be exempt from flagging (or have a higher threshold, or something complicated). Things reviewed and found to be evil will be banished from the directory, along with the IP subnet and country of author. OK, maybe just the script.

Along the same lines, I'd like to have a flag that says "doesn't work", and eventually, I'd like this to be integrated in GM's client so that when people say something doesn't work, we can have a list of injected scripts for clues as to script compatibility problems (because that really is a problem, and it's only going to get worse).

Further along trust lines, there's also the idea that a script that's been out unchanged a while and followed out and unflagged is probably a good and Good script, so those scripts might get some bonus in ranking. Which leads us into actually finding the script you're looking for.

There'll be full text search (so you can see how people are using GM_* functions or find a script through a comment), there'll be header search (show all scripts which match URL x, or have name y, etc). There'll also be a tag search, which will just use delicious' tags.

So now you've got some search results. They'll be ranked by number of delicious links to start with, and maybe that'll be good enough. If not, we can throw in trust or search noise, or something else complicated.

Also, particular script versions will be available off of stable URLs on the directory. The search results will take you to the original publishing location, but if your favorite ~user/script goes down, the directory will still be there. I haven't decided what the stable URL should look like. /root/namespace/userscript seems obvious, but of course, lots of people aren't setting their namespaces, so who knows. I also plan to have all versions available, so that if /root/namespace/userscript is current, then /root/namespace/userscript/20050110-164502 was the script as of that date and time (and it'll use the normal W3 date format, of course). I dunno, maybe this isn't version 1 stuff, but I think it'd be useful to see evolutions or to have a stable pointer for some discussion and such.

That about does it for goals 1-3. But assume you're a script author, and you'd like to share your script. You just post it on your site (Or submit it to the directory for hosting? This might get complicated.) Everyone knows where to find user scripts, so it's way out there, even if you're not an A-lister. And if you change something, everyone that wanted to know will know.

Another benefit of the hash approach is that the GM client could some day support auto update by hashing its installed script and asking the directory for any updates.

We also have a situation where authors modify functionality of scripts after publishing (say, to support UPS tracking after publishing a FedEx-only linker), and an accidental benefit of the wiki has been that script authors could say what changed easily. I'd like a @longdesc so that script authors could write a book (like this one!) about how great their user script is, and the directory would scrape this so that updated functionality just shows up in search.

That's up to goal 4.

Goal 5 is a bit broader, but I'm pretty stoked to see user scripts in Opera and IE. Safari already had Pith Helmet, and we apparently didn't inspire Opera, but I don't care. I just want user scripts to be useful and for them to spread, so I'd like to do what we can to provide a home for user scripts in general, and help other projects that don't have mozdev and mozillazine to help them with hosting and community. will start out GM-only, but I hope that changes.

This last one is months or longer out, but it seems worth doing, and I'd like to do it.

Of course I don't plan on doing all this stuff before putting something out there, and I hope you readers will tell me what I'm doing wrong, but this is the general direction I'm headed.

If anyone got to the end, congrats, and please take a few more minutes to tell me how this could better, but please keep the goals listed above in mind.

P.S. There's already been useful discussion on the mailing list. If you're interested in this stuff, I recommend you join.

Thursday, March 31, 2005

GreasemonkIE: user scripts for IE

I'm telling you, this user script thing is, err, useful.

Todd Ostermeier has gone and implemented a user scripting host for IE.

It's a little shaky so far, but it's fantastic to see the hackable web spreading to the other 80(?)% of desktops.

Thanks, Todd!

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:

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.

Sunday, March 27, 2005

The user script arms race has begun!

The incomparable Dean Edwards has posted a well-written example showing how a site owner can gum up the works for unwanted scripts.

This was a small matter of time. User scripts are a new thing on the web, and the concerns Dean raises are valid. Besides, when user scripts get more popular, there's too much money in advertising for workarounds not to be sought.

We can work through this.

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 >

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

A thought:

Greasemonkey has the exact same security context as bookmarklets.

Hello World!

It occurred to me that greasemonkey ought to have a blog.