Some folks keep pointing to section 9.1 of RFC 2616, the HTTP 1.1 spec, as the reason why they think Google is right and unsafe-GET websites are wrong.

From the mentioned section:

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".

In my view, SHOULD NOT is not MUST NOT. Being a web developer is also not a binding promise to obey and defend RFC 2616. As developer, however, we need to protect ourselves from attacks and misdoings. Clearly, both sides failed to do that.

Note that the same section also states:

Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature.

The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

So even the HTTP 1.1 spec states that it is not possible to ensure that all HTTP GET requests are safe. Yet GWA seems to assume otherwise. Are programs like GWA accountable? While others may feel otherwise, I think they are because it is GWA itself initiating the request blindly, not the user. Is the user giving GWA permission to make false assumptions on behalf of the user by installing the software? Even offered as-is, I think not.

According to Jesús Rodríguez, the Apache group finally released version 1.2 of Axis, still the most popular SOAP toolkit for Java despite being complex and slow, while I was celebrating my birthday with a particularly horrible cringe. Good. Now I can replace the RC version I've been using. It should show up here soon, but you can download it here until then.

Update:

Drools 2.0 RC1 was also released. I've been using a beta version in an ongoing project so I am glad to see a release candidate version. FYI, Drools is the fastest open source Rete-based rules engine that I know of. It supports JSR-94 (Java Rules Engine API) and domain-specific rule declaration languages. Definitely recommended.

Updates to two key third party components in a single day!

Sam Ruby and Jon Udell points to Nic Wolff's password generator as a simple ingenious simple single sign-on (SSO) solution. It's a neat technique but the core idea is definitely not a new one.

For example, Dan Boneh and Stanford students used it in PwdHash, an IE plugin, as an anti-phishing solution. Applying the technique on the password generation side reduces some weaknesses in the PwdHash solution but there are still significant user experience and security issues remaining.

Also, countless lazy yet paranoid users have practiced the technique manually ever since the password input box was invented. Please don't remind me how long ago that was. Not on my birthday.

If you haven't been paying attention, WHAT-WG has been on a rampage (of an exciting kind) defining what they hope will become the next generation of web standards.

Just checkout the advanced 2D graphics methods the new Canvas tag will be supporting (warning: large HTML file). My my. Look at them curves on that…web page. BTW, I hear recently released Lazlo 3.0 engine supports this API as well.

While Lua the little script language is not as well known as Python, it is popular in the game industry (World of Warcraft uses it to drive client UI) and there is even a sourceforge-like website just for Lua, LuaForge.net.

For persisting Lua data types, there is Pluto which converts any Lua data type (even functions, closures, and threads) into an octet sequence which can be written out to a file (i.e. game save/restore), sent over the net (LuaSocket), or inserted into databases using LuaSQL (ODBC, ADO, Oracle, MySQL, SQLite, JDBC, PostgresSQL supported).

For my recent need, persisting tens of thousands of small Lua tables to local storage, I used lgdbm (tar.gz file) with QDBM which I've been using in other projects instead of gdbm for performance. I am not releasing the source code to my Lua binding for QDBM (lqdbm?) because only minor modifications are needed. I'll do that when and if I expose other functionalities of QDBM like B+ tree.

Since I posted early last year about Edward Tufte's Sparklines, the paper was updated and some implementations have sprung up (via Sam Ruby):

• James Byers wrote a PHP version of sparkline which unfortunately hasn't been updated since last November.
• Joe Gregorio has a Python version of sparkline that works only for Firefox.
• And here is a Ruby version of sparkline.

I think the most important aspect of sparkline is the seamless inlining of graphics with text, so sparkline graphics should be resized automatically when the size of the surrounding text changes. I am not sure Mozilla/Safari's canvas tag can do this yet but I hope it does before the canvas tag becomes a de-facto standard.

One great feature I overlooked in Eclipse 3.1 feature list is Java2D-like advanced graphics support (antialiased lines, curves, alpha blending, and transformation). It's implemented using Cairo Graphics on Linux/Unix and GDI+ on Windows. I don't know what they are using on OS X. Quartz backend for Cairo is being worked on so they may use that or build their own.

I don't know why they are going with GDI+ though. GDI+ is slow, buggy, lacks features, and not present in older platforms. I've heard that Longhorn graphics API won't use GDI+ so why GDI+ when they could have used Cairo's own Win32 backend or, even better, an antigrain-based backend?

Anyway, anyone know if GEF 3.1 will use the advanced graphics?

One way to protect a desktop is to boot from a CD that makes sure critical parts of your system drive has not been compromised before passing control over to it.  The good news is that most desktops these days can do this.  The bad news is that CDs are read-only which means it can't be updated like anti-virus software does.

An alternative is the upcoming bootable USB drives.  When the computer boots up, BIOS passes control to the Boot Stick, a secure bootable USB drive, which checks the hard drive before passing control to the OS loader on it.  With appropriate BIOS support, USB drive can be updated over the Internet to protect against latest threats.

It's a good story so far, but a big problem with Boot Stick is that the BIOS itself is not secure.  While BIOS updates can be password protected, passwords are too frequently not set (do you know what your BIOS password is?) and, even worse, there are ways to bypass BIOS password.  Once compromised, the BIOS can bypass safety measures on USB drives.

So we are back to square one.

While CSecureEditEx doesn't protect against keyloggers, it is more secure than the standard Win32 edit control so I recommend it for Win32 GUIs.