Did you know that Google is related to evil (admittedly via an anagram of Elvis)? Dirk does.

John Gruber’s latest blog entry made me laugh. In the midst of it, he writes: “enormously irresponsible for ostensibly professional security researchers”.

It seems to me that many “security researchers” are neither (a) professional nor (b) responsible. Last time I looked they were much more interested in publicity than in protecting the computer using public… there are even recent stories in the media about them making thinly veiled threats to software vendors unless they are involved in the bug fixing process.

And precisely what is their business model anyway? I mean, who exactly pays them to search for flaws? I’ll tell you who isn’t paying them… Apple. They have plenty of very clever engineers who quite clearly already understand how these things work. So why would they want to pay these people, especially as they seem more concerned with publicising the flaws they find than they are with the security of the user base? Let’s not forget that many security vulnerabilities only become vulnerabilities once published. Quite a few of the recent PC viruses only appeared after the flaws they exploit were published on CERT or Bugtraq. It isn’t exactly rocket science:– if you don’t know how to break into a system, you have to find out first, which takes time and usually requires access to a similar system (since repeated crashes of the target system, which commonly happen during the “research” stage of a hack, are a bit obvious to most people). If, on the other hand, someone publishes all of the details, some section of the user base won’t be up-to-date—even if the vendor has been given time to release a fix—and it’ll be much easier to break in.

As far as the whole Mac wireless vulnerability thing, there certainly have been vulnerabilities there in the past (e.g. via LDAP, which AFAIK used to be enabled by default), but only time will tell whether this one is real or not. I don’t think that Brian Krebs and George Ou really helped matters, what with Krebs’ original post on the subject, the title of which was ill-chosen, and Ou’s remarks about a so-called “vicious orchestrated assault” on the originators of the claims.

The fact is that the researchers clearly intended to upset the Mac using community—remarks such as Maynor’s “it eventually makes you want to stab one of those users in the eye with a lit cigarette or something” are pretty convincing evidence of that. If I were Krebs, I wouldn’t have published that statement, and as far as George Ou’s article goes, I have to say that someone who says things like Maynor did should expect a certain amount of flak as a result. Not that I’m condoning any of the things that apparently have been said to him… but let’s get this into perspective: Maynor clearly intended to upset some elements of the Mac community. He’s done so. If he’s surprised how upset they got, perhaps he (and Ou) should reflect on the fact that journalists and security researchers have been telling Mac users for some time now how naïve and vulnerable they are, usually with undertones of “You’re too smug. Just you wait, we’ll prove you all wrong”. Is it really a surprise that people who openly espouse or support this agenda get jumped on?

Well indeed. Who is Alastair?

I must say that I’m quite pleased to be sharing a name with some of these people, particularly Alastair Reynolds (I’m a big fan of his work; hard sci-fi is very much my kind of thing :-)).

Am I the only one who thinks that the current airport security measures here in the U.K. are just plain stupid?

Sure, terrorists won’t be able to get on aeroplanes to detonate their bombs, but by clogging everything up, we’ve created huge crowds of people in the airport buildings themselves, outside the security checks. I can’t think of a better target for a terrorist; they’ll do many times more damage if they detonate a bomb in those crowds than they would be able to do if they blew up a plane. Well, with a big enough bomb, anyway.

I’m not saying that we shouldn’t be careful, but I think we should be wary of doing things that simply move the risk from the air to the ground, which is—I think—all we’ve actually achieved here.

I’m beginning to suspect that MovableType has a bug in it relating to character encoding, though the “smart” behaviour of some web browsers makes it very difficult to tell where the problem actually lies.

What I’m seeing is that the characters are encoded incorrectly on the index pages, but not on the articles’ individual pages. At least, I think that’s what I’m seeing.

Hopefully, permalinks should now use dashes rather than underscores too.

Once I’d worked out that a backup script had managed to overwrite some of the new MovableType files with copies of the previous version, things seemed to sort themselves out :-)

The new site design has some interesting features, in particular:

• Live comment preview.
• Live search.

Both of these are implemented using Bob Ippolito’s MochiKit, which I’m now a big fan of; it makes writing Javascript a lot less about tediously hitting the differences between the various implementations and a lot more about getting on with what it was you wanted to do.

I’ve finally updated the site templates for my blog, and also updated to the latest MovableType at the same time.

There seems to be a character encoding issue somewhere or other, and I’m having trouble with comments too :-(

Since my original post on this topic, I've done a bit more work on the ICU regexp engine. It now supports named groups, and conditional expressions, including support for group numbers and names as well as lookahead and lookbehind expressions as the conditions on which to branch.

The syntax supported by this patch now includes:

(?P<name>…)

Named capture group. Can be accessed via overloaded group(), start() and end() methods from C++, or using the uregex_groupIndexFromName() function from C.

(?P=name)

Named backreference.

(?(name-or-id)then-part|else-part)

Conditional expression; if the group identified by the numeric ID or name has been matched, then attempt a match against then-part, otherwise against else-part. The else-part is optional, in which case the '|' should also be omitted.

(?(?expr)then-part|else-part)

Conditional expression using a lookahead or lookbehind expression in place of ?expr. In this case, a match is attempted with the lookahead or lookbehind expression, and the result (true or false) used to choose whether to execute the then-part or the else-part as appropriate.

This version of the patch also fixes a couple of bugs in the previous version, simplifies the implementation of named capture groups (and at the same time disallows multiple capture groups with the same name), and adds quite a few new tests to the intltest and cintltest test suites to verify the operation of the new code.

It also adds the C functions uregex_namedGroupName() and uregex_namedGroupCount(), and the C++ method getGroupNames(), which provide a means for C and C++ code to obtain the names of the named capture groups for a particular RegexPattern object.

Mmmmm… dual-core 3GHz Xeons, 1.6-2.1 times as fast as a PowerMac G5 Quad.

(MacNN are running a live feed from WWDC.)