Posts from June 2005

So it turns out that crackers can mess up your Web site with nothing more than a malformed HTTP packet.  You might think something as simple as HTTP would be basically risk-free, but no, I’m afraid not.  All it takes is interaction between programs that handle HTTP data slightly differently, and hey presto, you’ve got a security hole.

Ben Laurie weighed in on this:

“It is interesting that being liberal in what you accept is the base cause of this misbehaviour,” Laurie says. “Perhaps it is time the idea was revisited.”

That’s a reference to the late Jon Postel‘s dictum (from RFC 793) of “be conservative in what you do, be liberal in what you accept from others”.  This is done in the name of robustness: if you’re liberal in what you accept, you can recover from data corruption caused by unanticipated problems.

Laurie’s right.  The problem is that being liberal in what you accept inevitably leads to a systemic corruption.  Look at the display layer of the Web.  For years, browsers have been liberal in what markup they accept.  What did it get us?  Tag soup.  The minute browsers allowed authors to be lazy, authors were lazy.  The tools written to help authors encoded that laziness.  Browsers had to make sure they could deal with even more laziness, and the tools kept up.  Just to get CSS out of that death spiral, we (as a field) had to invent, implement, and explain DOCTYPE switching.

In XML, it’s defined that a user agent must throw an error on malformed markup and stop.  No error recovery attempts, just a big old “this is broken” message.  Gecko already does this, if you get it into full-on XML mode.  It won’t do it on HTML and XHTML served as text/html, though, because too many Web pages would just break.  If you serve up XHTML as application/xml+xhtml, and it’s malformed, you’ll be treated to an error message.  Period.

And would that be so bad, even for HTML?  After all, if IE did it, you can be sure that people would fix their markup.  If browsers had done it from the beginning, markup would not have been malformed in the first place.  (Weird and abnormal, perhaps, but not actually malformed.)  Håkon said five years ago that “be liberal in what you accept” is what broke the Web, markup- and style-wise.  It’s been a longer fight than that to start lifting it out of that morass, and the job isn’t done.

Authors of feed aggregators have similar dilemmas.  If someone subscribes to a feed, thus indicating their interest in it, and the feed is malformed, what do you do?  Do you undertake error recovery in an attempt to give the user what they want, or do you just throw up an error message?  If you go the error route, what happens when a competitor does the error recovery, and thus gets a reputation as being a better program, even though you know it’s actually worse?  That righteous knowledge won’t pay the heating bills, come winter.

“So what?” you may shrug.  “It’s not like RSS feeds can be used to breach security”.

Which is just what anyone would have said about HTTP, until very recently.

In the end, the real problem is that liberal acceptance of data will always be used.  Even if every single HTTP implementor in the world got together and made sure all their implementations did exactly the same strictly correct conservatively defined thing, there would still be people sending out malformed data.  They’d be crackers, script kiddies—the people who have incentive to not be conservative in what they send.  The only way to stop them from sending out that malformed data is to be conservative in what your program accepts.

Even then, it might be possible to exploit loopholes, but at least they’d be flaws in the protocol itself.  Finding and fixing those is important.  Attempting to cope with the twisted landscape of bizarrely interacting error-recovery routines is a fool’s errand at best.  Unfortunately, it’s an errand we’re all running.

• Liberal vs. Conservative was published on Thursday, June 16th, 2005.
• It was assigned to the Browsers and Web categories.
• There have been twenty-one replies.

It’s update day!  I just pushed WP-Gatekeeper 1.5rc3 into the public eye.  The major change in this version is that Gatekeeper no longer prevents trackbacks (or pingbacks) from ever reaching your site.  See, before, it was effectively destroying all those without notice or appeal.  Now it just lets them through, whatever their content.

What this means is that Gatekeeper is, as it always was meant to be, a way to prevent comment-form spambots from succeeding.  Trackbots will now get through unless you take other steps, like disabling trackbacks or running another spam filter or something.  I’d actually like to see WordPress split tracks/pings apart from comments, and let you set their “always moderated” flags separately.  Thus you could set things up so all tracks and pings are moderated, but comment-form comments are not.  That would work great for me.  Maybe not so well for others, though.

Unfortunately, rc3 still has that problem where it doesn’t always automatically add a challenge to your comment forms, though you can still get the challenge by manually adding gatekeeper_pose_challenge to the comment forms in your theme.  My grep-fu (or maybe it’s my PHP-fu; or, hell, both) is weak; I can’t figure out why the routine fails.  Anyway, head on over to the Gatekeeper page if you’re interested, and especially if you can figure out why the auto-challenge routine is failing.  Thanks.

• Gatekeeper 1.5 rc3 was published on Tuesday, June 14th, 2005.
• It was assigned to the Tools and WordPress categories.
• There have been six replies.

Thanks to a comment from Pritt, the Safari arrow-key bug in S5 1.1rc1 has been, so far as I can tell, fixed.  I’m therefore releasing S5 1.1rc2, which will be the final release candidate unless any major bugs are encountered.

Also new to this revision are some slight modifications to the CSS that drives the system’s presentation.  The changes were all in the vein of changing div.slide to .slide.  Why bother?  Because with these slightly more generic rules, it’s now possible to create your slide show using a XOXO format instead of the OSF-compatible div-based markup.  (And the XOXO version may be OSF-compatible; the only real difference is that you’re using a list instead of a series of divs, but I’m not sure how much OSF cares that each slide be in a div instead of some other element with the appropriate class.)

I’ve included a XOXOized version of the testbed slideshow in the rc2 package, so feel free to check it out, if you’re interested.  Long-delayed thanks to Tantek for helping me work out the few changes that needed to be made to the CSS, and providing me with an example XOXOized S5 file so I could use it as a reference.

• S5 1.1rc2 was published on Tuesday, June 14th, 2005.
• It was assigned to the S5 and Tools categories.
• There have been five replies.

Just a quick note for any of you who might be both a BBEdit user and an S5 author:  BBEdit 8.2.1, the latest update, will crash if you try to open any valid S5 presentation (I don’t know what happens with invalid files).  Apparently there’s a bug in BBEdit’s XHTML scanner that the S5 file structure triggers.  Version 8.2, which you can get from the Barebones FTP site if you don’t still have it locally, does not have the same bug, and will edit S5 files without any trouble.

The folks at Barebones are aware of the problem and have indicated that a fix will be in the next maintenance release of BBEdit.  For now, if you want to edit S5 files in BBEdit, stick to 8.2.

(And if anyone wants to take a crack at helping out with the problems in S5 1.1rc1, see my earlier post on the subject.  Thanks!)

• S5 vs. BBEdit 8.2.1 was published on Monday, June 13th, 2005.
• It was assigned to the S5 and Tools categories.
• There have been seven replies.

A fair portion of the feedback I get whenever I talk about microformats runs along the lines of “How is this any different from stuff like RDF, besides it being written using a far less structured vocabulary?”.  Tantek has laid down the basics of the answer to that question.  In a severely limited nutshell: the more visible the data, the more likely it is to be made relevant and to be kept that way.

What about search engine spamming?  Well, it’s usually easily recognizable as such by a human, so that’s in keeping with visibility and human friendliness.  If we suppose a spammer uses CSS to hide the spam from humans, as many do, it’s become invisible—exactly the same as traditional metadata, and exactly what happened to meta-based keywords before the search engines started ignoring them.  Some day (soon?) the search engines may start ignoring any content that’s been hidden, and as far as I’m concerned that would be just fine.

Now, what about farther down the road—will semantic information always have to be visible?  An interesting question.  Tantek and I have had some pretty energetic arguments about whether the kind of stuff we’re putting into microformats will eventually move into the invisible realm of Semantic Web-style metainformation.  As you might guess from his post, Tantek says no way; I’m more agnostic about it.  Not every case of structured data lends itself to being visible, and in fact making some kinds of strucuring data visible would be distinctly human-unfriendly.  There’s a reason browsers don’t (by default) display a page’s markup.

Besides, to some extent there’s invisible information in microformats, although it’s pretty much always tied to visible information (dates in hCalendar being one such example).  Sure, the class names and title values are there in the markup as opposed to off in some other file, but from a user point of view, they’re as invisible as meta keywords or RDF.  Usually it’s stuff we don’t want to be in the user’s face: markers telling which bits of content correspond to what, ISO versions of human-readable dates, that kind of thing.

Then again, the truth is that the kind of information most people want to consume and manipulate is the kind of information that lends itself to being visible.  Structuring that data in such a way that the same data is useful to both humans and machines—turning the stuff you’re showing to people into the stuff that machines process—is a much more elegant approach, and one that frankly stands a higher chance of success, at least in the short term.

(A quick example: as Andy Baio says, “If hCalendar gets popular, Upcoming.org could scrape events off of websites instead of people entering them directly into Upcoming”.  Bands, who are already maintaining their own touring pages, could mark up said pages using hCalendar, and Upcoming would just suck in the information.  The advantages?  The band’s webmaster doesn’t have to set up the tour page and then go enter all the information into Upcoming; he just creates or updates the page and can then ping Upcoming, or wait for its spider to drop by.  The visible information, which is structured in a machine-parsable way, only has to be updated once.  Of course, the same would be true with regard to any event aggregator, not just Upcoming, and that’s another advantage right there.)

But will the semantic information stay baked into the visible information?  That’s a harder trend to forecast.  I remember when presentation was baked into the structure, and it’s been a massive struggle to get the two even partially separated.  On the other hand, it makes sense to me to pull presentation and structure apart, so that the former can rest upon the latter instead of having them bolted together.  I’m not sure it makes sense to do the same with semantics and structure.  Of course, what that really means is that I don’t think it makes sense to argue for their separation now.  Perhaps we’ll look back in a decade or two and, with new approaches in hand, chuckle over the thought that we’d ever bolted them together.  Alternatively, perhaps we’ll look back from that vantage and wonder why we ever thought the two could, let alone should, be separated.

In either case, it seems clear to me that the way forward is with visible data being used both for human and machine consumption; that is, with the microformat approach.  It’s a lightweight, easily grasped, infinitely extensible, and infinitely flexible solution, totally in keeping with the design principles that underpin the Web itself.

• Long-Term Visibility was published on Friday, June 10th, 2005.
• It was assigned to the Microformats and semantic web categories.
• There have been two replies.

I go to England and Apple launches the switch campaign to end all such campaigns: moving from IBM’s PowerPC chip to Intel architecture.  Coincidence?

Pretty much, yeah.

I know that a zillion electrons have been spilled on this topic, and I’m going to add my own thoughts without the benefit of having actually read what anyone else has said about it.  So if everything I say here is a duplication of everyone else’s writing, it’s at least an original duplication, if you see what I mean.

At the core (Ha! I kill me!), it shouldn’t really matter what chip sits at the heart of a Macintosh.  Did it bother me when Apple switched from Motorola’s chips to the PowerPC?  No.  I’ve historically been far more bothered by changes in interface, like the jump from OS 9 to OS X.  I have made that transition, but it took me a long time and I still sometimes pine for the old days.

Regardless, it does seem to bother me at some level that I could be running an Intel-based system in the semi-near future.  Maybe it’s all those old jeering comments I made about fundamental addition bugs and excessive heat production coming home to roost.  Maybe it’s that the hipper-than-thou, apart-from-the-crowd semi-cultishness of the Mac extends down to the hardware layer: now instead of having l33t hardware that I paid good money to get, I’m merely going to have a different OS on the same basic computer as all those boxes out there running Windows, pardon my French.

These are emotional reactions, and I admit that freely.  But emotion is bound up in anything we take seriously, and given that it’s the tool with which I create personal wealth, I take my computer very, very seriously.

I’ll step back from that, however, and look at this with a larger field of view.  Apple has apparently been maintaining Intel versions of OS X for years now, so it isn’t as though they still have to undertake that conversion.  There’s a PowerPC chip emulator called Rosetta that should smooth the transition of software to the new architecture.  Sure, the stuff running on the emulation layer won’t be as efficient as software written natively for Intel architectures, but it’s a whole lot better than nothing.  (And also makes me wonder why it’s been such a long, hard trip getting a Mac emulator for the PC.)

Here’s the thing, though: this potentially brings the ability to run OS X to the ninety-plus percent of the computing world that has an Intel machine, of which ninety-plus percent are running Windows.  The success of iTunes for Windows has demonstrated that Windows users don’t give a flip who wrote their software, as long as it gives them something they want and is easy to use.

So the move has the distinct potential to play to Apple’s strengths as a software developer.  It could put the whole iLife suite on desktops everywhere through Intel-compatible OS X or even some other route.  It could make it easier for Apple to create a Windows-compatible version of iLife.  It might (though I can’t be sure, not being a developer) make it easier for Windows applications to be ported to OS X, thus making switches between Windows and Mac OS a lot less painful.  It might even make it possible to have Windows running on Apple hardware, and it’s darned sure going to make VirtualPC a lot less virtual.

I freely acknowledge that most users, even given a choice, will pick the classic Wintel combination—how many buy Linux-driven Intel machines these days?  (Yes, it’s more than before, but still not that many.)  How many more would buy non-Apple OSXtel machines, even assuming such a thing to be possible?  Not many.  A lot of the cachet of being a Mac user is having the super-fine hardware, all sleek and well-designed and a heck of a lot sexier than the guy running a Dell Latitude or whatever.  (Yes, some PC makers do go sexy, but they’re usually either trampy ripoffs of Apple’s designs, tricked-out Alienware gamer boxes, or Sony Vaios.)

As I said at the outset, intellectually I don’t care whose chip drives my Mac, so long as my programs still run and the performance isn’t slower than I’d have gotten with the PowerPC chip.  Emotionally, though, I’ll be breaking my long-standing rule against decorating my computers.  After all, I’ll need something to put over the “Intel Inside” sticker.

• Apple Intel was published on Wednesday, June 8th, 2005.
• It was assigned to the Mac category.
• There have been ten replies.

I think that, overall, the workshops went very well indeed.  Probably the most frustrating thing was that the hotel lacked net access for the entire time I was there.  Oh, they had a network, with drops in the rooms and a first-floor wifi cloud.  It’s just that the network was completely broken for the entire five days, save a two-hour window in the middle of one of the days.

But that annoyance aside, everything else was great.  The attendees asked a lot of interesting questions and soaked up the firehose of information I was blasting their way.  There was some good (and good-natured) give-and-take on the subject of tables versus CSS for layout, with plenty of examples of where each approach might be better or worse than others.  And hey, I wore a tie!  Both days!  Ryan has the picture to prove it!

He also has the British spelling of “favorite” to prove that he’s been away from Colorado for too long.

Anyway, I’d like to send a huge thank you to everyone who attended for making it a great experience.  I had fun, and I think you did too.  Now for two bits of trivia about the attendees:

• The quiet, bearded man who sat house right in the third or fourth row on Saturday was none other than Michaël Guitton, a significant and early contributor to S5, the slide show system I used to present the morning notes.  I didn’t find this out until the end of the day, or else I’d have made him stand to take a bow.  (Which might be why he waited until the end of the day to introduce himself.)

  He was also the only person at lunch to order the salmon, although I came very close to doing so myself.

• On Friday, as a number of us headed up the street for social hour, one of the attendees mentioned he’d been in Cleveland and Columbus many years ago.  I asked what had brought him there, and he said he’d been touring with a band.

  “Oh, really?” said I.  “That’s cool.  Um, any chance it’s a band I might have heard of?”

  “The Jesus and Mary Chain”, he said.

  “WHAT?!?!?”

  I had to ask him three times if he was having me on.  Turns out he wasn’t: I was talking to Dave Evans, who was their guitarist in the late 80s.  Seriously.  I could not make this up even if I tried.  I really had a former member of the Jesus and Mary Chain in my CSS workshop.

  That’s so far beyond incredible that I can’t even describe where it ends up.

• Workshop Wrap-Up was published on Wednesday, June 8th, 2005.
• It was assigned to the (X)HTML, CSS, and Speaking categories.
• There have been six replies.

Earlier this evening, I ventured from the Hilton Kensington to find dinner.  I ended up at The Mitre, an upscale pub a block east of the Holland Park tube stop.  I found the food to be quite excellent, and on a Thursday night things were fairly quiet.  I proceeded to slowly kill two bottles of still water and a full three courses.

As I was eating, a few degrees to the left of my straight ahead sat a couple, sharing a pint and talking animatedly to each other.  Gradually, I came to realize that there was something unusual about the young woman, but I wasn’t quite sure what.  I watched them a bit more closely for a while, and then as she reached up to brush back her hair it hit me: her left hand had only the thumb and first two fingers.

To be nakedly honest, I experienced a deeply visceral reaction—not revulsion, but a certain kind of personal horror.  There is something about physical deformations that primally disturbs and scares me.  Every time it does, however, I confront the reaction and examine it as if it were a stranger.  I stare into my own bias and try to understand it a little more fully, to lessen its power.  I think that perhaps my reaction springs from a projection of the observed deformity onto myself.  What if I were without fingers, or blind, or had an amputated limb?  I feel some faint echo of an alternate self, alien to me and yet all too real.  Most real of all is the fear that given such a burden, I would not bear it well.  In the distorted mirror that reflects my deformed body, I see a darkened face and an angry soul.

As I force myself to stare into that face, I wonder if it is an accurate self assessment, or a projection of my fears.  I tell myself it is a projection, believe that it is with all my might, and perhaps believing will make it so.

After watching a few minutes more, I could clearly see what had initially seemed odd about her.  She had a distinct tendency to wedge the deformed hand between her crossed legs, or to keep it in her lap under the table.  If the left hand came up, it usually rested next to her ear, the hand buried in her hair.  Every movement was natural, her body at ease in every moment; she’d obviously had a long time to develop these tendencies so that they were not affected, but totally unconscious.

When she had to pick up a plate with her right hand and reached out with the left to move her glass as well, I could see why her habits were so ingrained.  The shape of her hand, wrist, and arm convinced me that no accident had befallen her except that of birth: she’d never had the fingers.

I studied her again in this new light.  As before, she was quite pretty, with a wonderful smile and an easy laugh for her companion, who was clearly a romantic partner.  Her movements were animated, and she had that enthusiasm and energy that only the young seem to truly possess.  In every observable way, she was a very happy and lovely person.

I wondered what it was like for her, growing up with a deformed hand.  Children need little enough excuse to be cruel to other children; how must she have been taunted?  And yet it did not seem to have made her angry or bitter.  I cannot claim to know the details of her personality based on an hour’s observation, but I am convinced she was not that way.  If anything, she seemed like the kind of person to whom happiness came almost naturally.  She seemed like someone it would be a joy to know.

When people asked Kat and me what kind of baby we wanted, our answer was always, “A healthy one—ten fingers, ten toes, that kind of thing”.  Yet here was a woman who was, to all appearances, fully healthy except for a malformed hand.  And is such a thing really unhealthy?  It is different, but that isn’t the same thing.

We are all imperfect, some more visibly than others.  Between the two of us, this bright young woman and me, who was the more flawed: she with her hand, or me with my fears?

• How Many Fingers? was published on Thursday, June 2nd, 2005.
• It was assigned to the Personal category.
• There has been one reply.