Out of Hanwell

April 28, 2006

Not-So-Intelligent Spammers

Filed under: Humor/Mental Leisure — Matthias Miller @ 7:07 pm

This evening I got a spam comment on my recent post about Akismet spam filtering, and I thought it was too ironic to delete. The spam must have been triggered by the following sentence:

If Akismet reports a comment as spam, the comment is stored with a special “spam” comment type and the e-mail notification contains a bold “**SPAM**” in the subject. If an item is incorrectly flagged as spam, I can use the MySQL client or online administrator to turn it into a real comment.

The nascar flags spammer wrote:

I have a giant flag collection. I am thinking of starting a blog about its history. Now I am just doing research…thanks.

To which I responded:

Glad to be of help, nascar flags. I don’t know much about flags, but I’m pretty good at flagging spam. Sorry I had to remove the link to your website.

While you do your research, you might try limiting your comments to blog posts containing “flag” but not “spam”.

If you want me to keep your spam comments on my blog, try shooting yourself in the foot.


April 21, 2006

Drip Development

Filed under: Uncategorized — Matthias Miller @ 6:12 am

Drip now has a wiki and a SourceForge project, which means it’s got a public forum and Subversion repository. If you’ve got questions or want to help, now you know where to go.

That’s a short summary of a lot of work.

April 18, 2006

Drip 0.4 Finds More

Filed under: Uncategorized — Matthias Miller @ 10:19 pm

When Hristo Deshev contacted me about some of the limitations of Drip, I decided it was time to tackle these problems. I’ve released Drip 0.4, which reports memory leaks for elements created by:

  • cloneNode
  • innerHTML
  • insertAdjacentHTML

It does not report elements created by outerHTML.

You can get it from the IE Memory Leaks page.

April 17, 2006

More Details on the “Operation Aborted” Error

Filed under: Internet Explorer — Matthias Miller @ 12:45 pm

Quite a while back, I mentioned a strange “Operation Aborted” message in Internet Explorer. My description, however, too specific. This error seems to occur whenever an element is appended to another element that has an incomplete child element. It appears to be some kind of consistency check that is triggered when a script finishes execution.

Take the following example:

<div id="outer" style="color: green">
<div id="inner" style="color: red">
<script type="text/javascript">...</script>

Given this example, the script can add elements to “inner” because it has no incomplete child elements, but it cannot add elements to “outer” because the “inner” element is incomplete. Likewise, the script cannot add elements to document.body because the “outer” and “inner” elements are incomplete.

To work around this problem, find the outermost element that the script needs to modify. Make your script a direct child of that element or place your script completely outside that element.

April 13, 2006

The Future of the Internet: Perl and Prototype

Filed under: Uncategorized — Matthias Miller @ 5:29 pm

If the web will ever complete its upgrade to the Second Version, developers around the world must work together to develop the necessary tools and frameworks. Although the Prototype framework tries to facilitate this, it makes the mistake of being too verbose, even with its highly-abbreviated function names. Function names should be as short as absolutely possible. This not only reduces the amount of code developers must maintain (which is a big cost) but it also produces code that is already bandwidth-optimized. Also, small code is fast code, so the developer rarely needs to hand-tune scripts for execution speed.

Using short, commonly-used names is a highly controversial matter, and people like Alex Russell call it hideous and brain-damaged. That, however, is far from the truth. By introducing these functions into a global scope, the developer is forced to remain highly attentive when writing code and must be especially creative when naming functions. This high level of attentiveness enables to developer to avoid many bugs when he or she might otherwise be falling asleep at the keyboard. The intense creativity allows him or her to solve difficult problems in innovative ways.

But low-quality code is not the biggest cost of verbose JavaScript code. Day after day, some of the best programmers in the industry are turning away from web development, just because it is so verbose. Many Perl programmers cannot feel comfortable writing JavaScript code, even though their contribution would be of immense help in the New Release of the Internet. Perl developers have a proven history of being capable of solving tough problems. In fact, many of them can write scripts to solve any problem!

For these reasons, I am proposing some additions to the Prototype framework to make it less verbose and to appeal to the Perl community. This will allow Perl developers to contribute to the development of Internet II without giving up the terse language and familiar syntax they’ve come to love.

The Code

Don’t be scared. This is Perl-like, so you don’t need to understand it to use it. If you would like to try these examples, I suggest that you use the JavaScript Shell; you can run this code one block at a time.

Function.prototype._ = function() {
var v = this($_);
if (typeof v != "undefined")
$_ = v;
return v;

function foreach(fn, a) {
for (var s in a) {
$_ = a[s];
a[s] = $_;

function grep(fn, a) {
var out = [];
for (var s in a) {
$_ = a[s];
if (fn($_))
return out;

Native JavaScript coders can use foreach to double items in an array, just as they might expect:

function double(x) {
return x*2;
var a = [1,2,3];
foreach(double, a);

Native Perl coders, however, can use a more familiar syntax:

var a = [10,20,30];
foreach(function(){ $_ *= 2; }, a);

Native JavaScript coders can filter items from an array like this:

function isEven(x) {
return (x % 2) == 0;
var numbers = [1,2,3,4,5,6,7];
grep(isEven, numbers);

Native Perl coders can do it like this:

var numbers = [1,2,3,4,5,6,7];
grep(function() { return !($_ % 2) }, numbers);

But the benefits don’t stop there.

Native Perl coders can easily filter duplicates from a sorted array:

var sorted = [0,1,2,2,3,8,9,10,10,10];
var prev;
var no_dup = grep(function() { return $_ != prev && ((prev = $_) || true); },  sorted);

Finally, native Perl coders can take advantage of the sublety and propriety that $_ offers when calling functions.

For compatibility with traditional JavaScript functions, a special underscore syntax is required to use $_. But I’m certain Perl and Prototype developers can deal with unclear, unintuitive constructs that work like magic.

$_ = "What do you have to say?";

Or, to be a bit more sophisticated:

$_ = "What do you have to say?";
$_ = $_ && "You said: " + $_;
if ($_) window.alert._();

That’s where I’ve decided to stop, but I’m sure you’ll be able to come up with some great examples on your own. I hope that together we can follow the example of Perl and Prototype as we develop web applications for the New Release of the Web.

April 11, 2006

Great Software: Do Less, Do It Better

Filed under: Uncategorized — Matthias Miller @ 7:17 am

For many years, the focus of software development was on functionality. First, it was the challenges of developing for differing hardware, solved by “high level” languages such as C that allowed the compiler to provide (more or less) hardware agnosticism. Then, it was the challenge of developing a workable operating system, integrating diverse software components, and networking software.

But functionality alone does not define software’s usefulness. Simplicity can make all the difference. Do Less, Do It Better.

About five or six years ago I developed my own instant messenger called Gox Box. Then, instant messengers were something of a novelty, and it was great simply being able to chat between two computers. Today, the market is flooded with instant messengers. They offer everything–voice conferencing, webcams, file transfers, you name it! But they’re very difficult to set up. Gox Box, though it has its own share of quirks, is easy to set up and easy to use. Its value is in its simplicity.

This summer I plan to develop another software development tool, not because such tools are missing, but because other tools focus on functionality at the cost of simplicity. Simplicity will be at the core of this tool’s design. I hope it will be unmistakably easy to use.

I hardly need to mention Google’s homepage or search results, or Apple’s products. The more I develop and use software and the more I fight cumbersome interfaces, the more convinced I become that you have much to gain by simplicity.

Do Less, Do It Better.

April 8, 2006

Senior Citizen Surfers

Filed under: Uncategorized — Matthias Miller @ 6:57 pm

SitePoint had an interesting article last week describing how to Improve Usability for Older Users. Many of these obstacles can easily be overcome, but here’s what I found both interesting and disturbing:

It was also the case that all older participants preferred 800×600 over 1024×768 resolution.

In contrast, I have three 17″ LCD monitors (1280×1024) at work, and at home I have a notebook with a 1280×800 resolution.

I was recently testing a web application with a small resolution. I found that every toolbar counts–even something as small as the status bar can make a difference. It can be very difficult to design a web application that works well on a small resolution. Scrollbars have a way of making interactive pages next to unusable. But you can’t just decrease the font size to make more room, because older people will find it tough to read.

Sometimes web development is simply a battle.

April 6, 2006

Design HTML Injection Into Oblivion

Filed under: Uncategorized — Matthias Miller @ 6:30 am

I recently discovered and reported an HTML injection vulnerability in the login page of a certain subscription-based web site that shall remain unnamed.

The exploit is simple. A subscriber receives an e-mail and clicks a specially-crafted link to the site’s login page. The HTML injection causes the user name and password to be sent to a third-party website. The link would appear to be legitimate because it’s hosted on the correct domain, and the user would be unlikely to notice that anything is amiss. The e-mail harvester can then run scripts, taking advantage of the harvested credentials.

If the user has JavaScript enabled, it gets worse. When the user clicks a specially-crafted URL and logs in, he or she is taken to another page, which also contains an HTML injection vulnerability. From there, it’s a trivial matter to use an XMLHttpRequest object to modify account information, such as to reset the password. Although I haven’t been able to confirm this, if the account contains billing information, it may be possible to incur additional charges on the user’s credit card.

I have two observations about secure websites:

  1. Developing secure web sites is none too easy. Just as C does not protect the developer from a certain class of security problems (buffer overruns and stack corruption), languages and frameworks often make it too easy for novices to trip up.

  2. Many security vulnerabilities are caused by a poor design and can be solved by a good design.

HTML injection is one of those bugs that should be prevented by a good templating framework. When you’re developing a large web application, you shouldn’t have to remember to encode text every time you write it out. It should happen for you automatically. Although it appears to be a bug introduced in implementation, it is just as likely to be a bug introduced in design.

Create a free website or blog at WordPress.com.