I think there’s a script injection vulnerability with a site I use, and I’m itching to find a proof-of-concept attack. I haven’t had time, or the chutzpah to pick at it yet, but I did disable their client side verification. I don’t know why it just occurred to me today to make a “Run arbitrary code in the context of the page” bookmarklet.

To use it, drag this: Run Code onto your links toolbar. All the code is:
javascript:(function(){eval(prompt('Run this code on this page:'))})()

1. Standard javascript: protocol and wrapping in a function to prevent being treated as a URL
2. Ask for a string
3. Eval the string

If there’s a client-side script CleanBadCharacters(s), you can run “CleanBadCharacters=function(s){return s}“, no quotes and you’ll need to do a little reading to find the exact validation.

Update: Not an hour after I added that hammer (metaphorically), everything’s looking like a nail. Eval-ing “document.body.style.color='white' ” is useful if someone thinks grey on gray is an acceptable colour scheme.

Joel Spolsky has a nice article that summarizes some of the difficulty of my job. Disclaimer: I work for Office but have nothing to do with the OOXML format and the opinions herein don’t reflect those of my employers (unless it’s a sheer co-incidence) and some details may be changed to avoid revealing confidential information (similarly, I briefly worked on a project for ISO, but I don’t even know their opinions). This is not an official document from any corporation and there is no fiduciary warrantee implied.

To summarize, the “Office” file formats were first designed to work on real, widely available computers. I put that in quotes because originally they weren’t even the Office file formats, they belonged to separate programs. Later, over many years (in fact it’s really still going) the programs were designed to work with each other and with documents from other vendors and the formats were updated to reflect these changes. All of this happened in software-time, which before we had the internet bubble was the fastest kind of time that companies worked in.

Compare this to the way many standards tend to get born: Bureaucrats and functionaries, lawyers and academics have meetings for years (and I’ve sat in on one or two of the conference calls from these — 90% of the phones are on mute since the participants are doing something else). Maybe, if you’re lucky, a reference implementation gets built. I’m surely exaggerating, right? I mean, the CSS 2.0 Specification was finished in 1998 and there was *a* browser that implemented it in 2005, that’s only… 7 years (support from the major browsers is likely coming in 2008). And that’s for software for the internet, some of the most dynamic stuff the human species has ever been involved with, SGML took decades.

A lot of the complaints I’ve read (and they’re in the comments on Joel’s article as well) are from people who want the standard to be written and designed for the hundred or so people who might consider implementing it rather than retaining functionality for the hundreds of millions of people who only care about their features. People who want to “cut out cruft” seem to think that the codebase is rife with Prince songs and disco-era dance moves rather than methods that are very useful to Tamil speaking law firms using Lotus Notes and the French Republican Calendar (pre-emptive snarky comment: this is a contrived example, but just because you don’t need a feature doesn’t mean it isn’t valuable to someone).

The most confusing part of my job tends to be getting my feature X to work with the Y & Z features from the A and B products. Somebody needs X, Y and Z together, and if I don’t make it work, they’re going to write their own code and end up 500% over budget and a case study on The Daily WTF. It’s hard to design features, it’s hard to build them and it’s hard to document them; the reason we didn’t build the product over a weekend is not that it never occurred to anyone.

I’m drifting rant-ward now, but I just wanted to stress there’s a huge difference between the small programs that we write to solve our problems (which I enjoy doing) and the large programs that solve everyone’s problems (that I’m paid to design).