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 href="[yourpasswords]&muahahahah">

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.