Update: I jotted down some initial theory in my Safe String Theory for the Web post.

For a while now, a lot of talk has been going on about XSS, aka Cross Site Scripting. In October 2005, an XSS worm nearly took down MySpace. Most XSS attacks however are not as benevolent as that. They can be used to steal passwords and other sensitive information, perform distributed Denial-of-Service attacks on sites or generate fraudulent advertisement income.

XSS problems are still rampant in many web applications today though, with PHP applications being especially vulnerable. This has caused some to conclude that XSS problems are even impossible to avoid or at least impractical to completely audit for. However, from a purely technical standpoint, XSS problems are not unique at all. They belong to a wider class of security problems which stem from incorrect handling of user-supplied data (e.g. SQL command injection or e-mail header injection).

So, what makes the web so tricky to secure? Is it because web programmers are inherently 'stupid' and can't 'code properly'? I don't think so.

However, I do think that most web languages (such as PHP) tend to promote a bad approach to coding and by extension, to security. By letting the programmer jump in directly, learning as they go, most people never build-up a complete overview of the programming environment, but simply tweak code 'until it works'. The same applies to security issues: when a bug is found, those people will just tweak a particular line of code until the problem goes away. They won't see the big picture and will make similar mistakes later.

Another serious problem in my opinion is that there is no well-defined vocabulary for the tools used to solve these problems. Umbrella words such as 'filtering' are all too often used and stand in the way of a more precise description. With only vague notions about 'validation', 'special characters' and 'escaping', you cannot understand what's really going on. Such a lack of insight also prevents people from seeing beyond individual issues.

So I've decided I want to build up a more formalized explanation to text handling. Expect one or more blog posts about this in the future. At least the next time people "lock up" on me, I can point them somewhere.

After an Ajax related chat today, a battle plan has been created for integrating the jQuery Javascript library into Drupal. As this is the result of a long discussion in private mails and on Drupal Groups, I wanted to jot down the reasons in one place for future reference.

Though several people have suggested integrating third party JavaScript libraries in Drupal, I rarely heard good arguments for doing so. The last thing we want is just to add some 'bells and whistles'. I wanted a good, small platform that would serve as a suitable base for both the (relatively small) core JavaScript work as well as the extended needs of the Drupal community at large.

The most important thing is to keep in mind the context of the Drupal system. We have a very advanced code base on the server-side already: text filtering, access control, localization, form API, theming, etc. A well-written, Drupal-like module has to use these systems to integrate with Drupal. Heavy client-side JavaScript applications are not likely to happen soon, as that will lead to self-contained functionality that does not 'play nice' with others.

This means that browser platforms such as Dojo are not good candidates. Though well written, they are simply overkill for what we need. When we look for small, functional libraries, jQuery stands out as the most suitable:

• It focuses on making common JS tasks easy to do, without much fuss or overkill. There are no grand claims, just a set of well written, self-contained utilities. This means you can focus on your functionality.
• It is centered around CSS-like queries. Finding and interacting with DOM elements is done with a CSS selector. This means it is easy to pick-up even for those with no JavaScript knowledge.
• It provides much bang for your buck. In only 10KB, you get the CSS-query system, basic Ajax, basic animations and smart events.
• It is built by smart, dedicated people. In fact, John Resig (the author) has personally gotten involved in discussions and answered our many questions.
• It has a modular plug-in system. This means that contributed module authors can easily include advanced functionality, while we can keep core simple. Including an existing or custom plug-in is as simple as adding in another .js file.

To summarize: we chose jQuery because it is compact enough for core, easy enough for non-JS experts and because it provides a broad platform onto which rich contributed modules can be built.

The concrete steps for getting this stuff into Drupal:

1. Remove those parts of drupal.js that have equivalents in jQuery, and rewrite the left-overs to use jQuery's APIs.
2. Rewrite the other .js files in core to use jQuery functionality. This is mostly the replacing of complicated code with very simple calls.
3. Add in new functionality that jQuery makes easy, thus proving how this was a smart move.

I'm confident we can get this done for Drupal 4.8.

I had some fun with iMovie and the Flickr Drupal tag.

Drupal over the years. I swear the high amount of Borises is accidental. He appears on nearly every picture.

Pigs can fly: Drupal 4.7 is out!

Update: check out the awesome new Drupal videocasts by the guys from Lullabot (and be sure to digg up the link on digg.com).

This is definitely the best Drupal release ever. It's a bit late, but the huge amount of new things more than make up for it. In particular, check out some of the Ajax features (file uploading, updating, ...) and the new improved search. I spent quite some time developing them ;).

Yesterday I was collecting the contributor and commit statistics for the announcement, when I was quite stunned:
There have been over 338 contributors to this latest release with over 1500 patches which is almost triple our previous record with Drupal 4.6 of 523 commits by 50 developers.

Yes, those numbers are correct. The Drupal project issues with file attachments were posted by 338 different people. 1500 patches got applied. We've not just tripled our productivity, but increased our developer group by 575%!.

I got back earlier today from Amsterdam after CDH (see below). We had a smashing weekend with lots of things being done. The atmosphere and vibe was great. When I compare it to BarCamp and DrupalCon Amsterdam, there were a couple of things which made CDH much better:

• Focus: when everyone is there to make things in Cocoa, the productivity soars. Instead of watching and giving presentation after presentation, people are actually sitting down and getting some work done.
• Great location: the event took place in a very big room with tons of space. It was actually a video exhibition which we commandeered for our own geeky purposes. Or maybe we became part of the exhibition?

  We started off with some table 'islands' spread around, but ended up with one big table. It felt like a cross between a bar, a garden party and an office. This allowed everyone to move around easily and always see what was going on. Big thumbs up to Mediamatic for offering up space.

• Great people: everyone was very friendly, very open. Thanks to the organisers (Katie Lips, Paul Stringer, Andy Smith) for setting it up.
• No Schedule: in contrast to DrupalCon and OSCMS, the atmosphere was much more relaxed and fluid, because there was no rigid timetable and pace to keep. Everyone who was there was always doing something (coding, testing or just plain learning).

If we have a Drupal coding sprint sometime which is only even half as good as CDHA, I'll be very happy indeed.

There's a less serious anecdote which could explain the high productivity though. Due to the particulars of the room (lawn chairs, rubber floor, ...) there was a serious build up of static electricity everywhere. Any geek who deserted his post and came back later to his or her shiny metal PowerBook would get zapped when touching it. All the more reason to keep coding. Hoorah for positive reinforcement electrotherapy!

Some quick tips for better productivity when developing Drupal core:

• Alias your editor to e. If you use a GUI editor see if it comes with a command-line shortcut to use. TextMate by default has mate. Not nearly short enough ;).
• Set up a d command to perform diffs. I use the following:
  
  #!/bin/bash
cvs diff -u -N -F^f . | grep -v -e ^\? > $1.patch
e $1.patch
  
  This opens up my editor afterwards so I can review the patch before submitting. The grep strips out unnecessary junk (unknown files).
• Set up a p command to apply patches. I use the following:
  
  #!/bin/bash
wget -O - $1 | patch -p0
  
  This will take a patch URL and apply it locally.

Anyone else have anymore ideas?