" /> Kazuho at Work: September 2008 Archives

« August 2008 | Main | October 2008 »

September 13, 2008

Greasemetal version 0.2 released

I have just uploaded version 0.2 of Greasemetal to greasemetal.31tools.com. I originally intended to add management UI for userscripts in the second release, but hearing the users' request for improved compatibility with Greasemonkey, I changed my mind. The main focus of the release is to improve compatibility with Greasemonkey. The changes from version 0.1 are as follows.

Improved Compatibility with Greamemonkey

After the initial release a number of users requested support for GM_* functions, to improve compatibily with many existing userscripts written for Greasemonkey. So in version 0.2, we have implemented following functions:

  • GM_log
  • GM_addStyle
  • GM_openInTab
  • unsafewindow
GM_registerMenuCommand is also defined as an empty function, so that scripts calling the function would at least not fail by its inexistence. Unsafewindow simply refers to the window object, since there is no support for Greasemonkey functions that require higher security (GM_xmlHttpRequest, GM_setValue, GM_getValue).

The functions were written by my colleague Amachang. He is the developer of a Javascript-based presentation tool S6 (an example) and JavaScript-XPath.

Execution Log of Userscripts

Greasemetal will write execution log of userscripts to the inspection window (to open the window, right click anywhere in the browser window and select Inspect). Greasemetal logs which userscripts are executed, and names the ones that failed and the reason why. Unfortunately the line number at where the error occured cannot be logged, but still I hope it would be helpful for developers makeing their userscripts compatibile with Greasemetal.

Suppress Unnecessary Error Logs

The debug.log file is no more generated. If you find one next to Greasemetal.exe, you are free to remove it. Also you would no more see the error message "Uncaught TypeError: Cannot call method 'setAutomationId' of undefined" in the inspection window increasing forever (although you would see one message per tab, it's inevitable).

Passing Command Line Arguments to Google Chrome

Command line arguments following " - " are passed to Google Chrome. For example, command below will start Google Chrome with Greasemetal but without displaying images.

> Greasemetal.exe - --disable-images

Possibility of Supporting other GM_* Functions and Security Implications

4:43pm added: Now that we have added support for some GM_* functions, the left ones are: GM_xmlHttpRequest, GM_getValue, and GM_setValue. The three functions require a different security model than that of ordinal web scripts (known as same domain policy). Even if we dismissed the pontential danger of not supporting a non-safeWindow, the functions will require a secure channel from userscripts to the internal web server of Greasemetal (that malicious web sites cannot intervene), for storing and accessing persistent data, or performing cross-domain access through the web server. However, since there is no way to enforce the order of JavaScript execution so that the script injected by Greasemetal is run before any scripts on a web page gets executed, it is difficult to create such a channel (a malicious web page might redefine necessary functions for communication, such as document.createElement). In other words, it would be mandatory to implement an encrypted channel (with replay attack-resistency) between the injected JavaScript and the web server, however it would require some ammount of engineering.

This is our current understanding on the technical aspects of supporting the functions, and thus, until these situation changes, we have little (if not any) interest in implementing them.

September 11, 2008

Greasemetal - the next step

Thank you to all, the release of Greasemetal seems to have been successful. Looking at the responses, I plan to do the following in the next release:

  • eliminate generation of unnecessary log files and error messages (as much as possible)
  • add management UI for userscripts
  • add some kind of error logging for debugging userscripts

I hope I can release it soon.

Sep 12 5:12pm: We plan to add support for most GM_* functions, if not all of them (it might not be in the next release, though).

September 10, 2008

Greasemetal - a userscript runtime for Google Chrome

For more than two years, I have been using Firefox. And Greasemonkey. Then, last week, came Google Chrome. It was at the moment I tried the new browser that I suddenly noticed I could no more live without userscripts (especially, AutoPagerize). So I started looking into the source code of Google Chrome, and found out a way to implement a userscript runtime. And that's Greasemetal. It is now available from the link below.

Technically, Greasemetal executes userscripts in the following steps.

  1. setup a local web server that sends userscripts to Google Chrome
  2. launch Google Chrome specifying the browser to connect its AutomationProxy (an interprocess communication channel of the web browser implemented for automated UI tests) to Greasemetal
  3. periodically execute JavaScript in each browser tab that inserts <script> tags to download necessary userscripts from the local web server
As can be seen, since the entire userscript is run at the browser level, there is no support for GM_* functions (they require userscripts to be executed under a previleged environment for security reasons). In other word, some userscripts that rely on Greasemonkey-specific features would not work on Greasemetal. Userscripts compatible with Safari (or Opera) would mostly work.

The userscripts I checked and found compatible are;

This is the first release of Greasemetal, and it still lacks a number of features (especially the UI for managing userscripts). I hope I can release the next version early (hopefully a code-signed version), but if you find any bugs or have any suggestions, please let me know (although I am afraid I might not be able to answer to compatibility problems of each userscripts). Anyway, have fun!

September 03, 2008

Q4M becomes part of FreeBSD Ports Collection

Thanks to Akinori MUSHA, Q4M has become part of the FreeBSD Ports Collection.

If you are using FreeBSD, Q4M can be installed by following the steps below.

# cd /usr/ports/databases/mysql-q4m
# make install
# echo 'mysql_enable="YES"' >> /etc/rc.conf
# /usr/local/etc/rc.d/mysql-server start
# mysql -u root -f mysql < work/q4m-0.8.3/support-files/install.sql

Running either cvsup or portsnap might be necessary to update the installed ports collection to the newest state. Since the port depends on mysql51-server, you should make deinstall if an older version of mysql is already installed via the ports collection. If you want to test the installation, type:

# chmod 755 work/q4m-0.8.3/support-files/q4m-forward
# make test

The chmod seems to be necessary due to the fact that the install script for non-executable files of the ports collection drops the execution bits. Since there is no particular reason for keeping q4m-forward in the support-files directory, I plan to move it to somewhere else in the next release of Q4M.

September 02, 2008

Release of Q4M 0.8.3 and support for FreeBSD

Q4M (Queue for MySQL) Version 0.8.3 has been released with following Changes.

  • fix race condition error that might lead to deadlock on shutdown
  • support for FreeBSD
With support for FreeBSD added, prebuilt binaries are provided for the platforms below.
  • linux (i386)
  • linux (x86_64)
  • freebsd-6 (i386) (should work on FreeBSD 7 as well with compat6x package installed)
  • Mac OS X 10.4 (x86)