Browser history navigation bug in Chrome and Safari

I've been seeing some odd behavior in Chrome - occasionally browser history would get hosed pretty badly. When I noticed the same issue navigating the website I'm working on, I ended up spending a bunch of time trying to get to the bottom of the issue. Initially I suspected it was something wrong with the site, but I was eventually able to create a stand-alone repro for Chrome (v3 and v4) as well as for Safari (v4). I suspect this might be a WebKit thing, which both browsers share, but I don't know enough to be certain.

The problem seems to occur when you spend time moving around fully ajax sites that contain one or more iframes (I've seen this on GMail as well). In my case I worked around this issue by not using iframes but I imagine that's not always possible. Anyways, this is now Chromium bug 30693.

XSRF/CSRF Vulnerability Explained in Non-Geek Speak

I recently explained what cross-site request forgery (CSRF/XSRF) is to a friend who isn't a programmer/CS person and I was pretty amazed at how quickly he understood the implications of not protecting against such attacks. With the proliferation of social interactions on the web now, such attacks can be pretty damaging to consumers of new media and e-commerce sites.

The Wikipedia article about CSRF does a pretty good job of explaining the issue - most people familiar with web development should be able to understand it easily. Basically, this attack lets legitimate unsuspecting users submit changes to a site they routinely interact with, but without their knowledge. CSRF attacks leverage your own browser and the trust you associate with it to perform potentially damaging actions on your behalf.

Here's an example of what such an attack might look like. Let's assume that Facebook wasn't protected against such attacks, for the purpose of this illustration. In reality, I'm sure Facebook engineers have done a good job of making sure this can't really ever happen. That's not true of every site out there, though.

When you sign into Facebook, you have the option of remaining signed in. To do this, sites like Facebook set a browser cookie which identifies you to their servers. This is great because it lets you visit the site frequently and navigate the site without needing to enter your password every time. Browsers are good about securing your cookie - they make sure that no other site besides Facebook can see this cookie, so it's not possible for the author of www.hacker.com to steal your cookie and present it to Facebook and then impersonate you. However, each time you go to any URL that contains www.facebook.com, the browser diligently sends over all cookies associated with Facebook, because the receiver of those cookies is www.facebook.com.

Once on Facebook, you do things like update your status or write on a friend's wall. When you do that, the browser sends your new status update to Facebook along with the cookies. By inspecting the cookie, Facebook is able to validate that it is indeed you trying to update your own status, so it proceeds to allow the action. Under the covers, your browser is sending over two pieces of information - some data (your status update text, in this case) and the cookies. The browser was triggered to do this by you clicking the "Submit" button. This sounds pretty straightforward so far.

Now imagine you're browsing the web and land on this page that talks about world hunger and how you can help the cause by simply clicking a "Help the Children" button. With only altruistic intentions, you click on the button. Nothing visible happens, or maybe a "Thank you!" label replaces that button. Then you simply move on to the next thing you were going to do. Suddenly, you start receiving email notifications about friends responding to your latest status update on Facebook, except you never posted any update. You visit Facebook and sure enough your status now says "I am a loser!", updated 2 minutes ago. Huh?! You didn't set that status. You panic - maybe someone hacked your account? Or someone guessed your password? What's going on?

What really happened was that the world hunger website you were on was written by a malicious attacker, and when you clicked the "Help the Children" button that website didn't really contribute 10 cents to UNICEF, but instead told your browser to send a new status update with the text "I am a loser!" to www.facebook.com. This site couldn't access your cookies directly, so the browser didn't do anything bad and stuck to its promise of not letting anyone else see cookies that shouldn't be visible to them. Remember, the attacker never looked at your cookie at all while any of this happened. However, when the attacker asked the browser to send data to www.facebook.com, the browser added the Facebook cookies to the request. So now Facebook looks at the cookies and the data, thinks that it is indeed you and goes on to update your status. Boom!

So what went wrong here? The browser didn't do anything bad - it did exactly what it's supposed to. It hid your Facebook cookies from everyone except Facebook and it sent data that submitting the "Help the Children" button asked it to send. You didn't do anything bad - you simply clicked on a link that was meant to help needy kids. You did have cookies enabled (default for most browsers) and decided to check that "Log in automatically" option, but those seem like reasonable actions.

The flaw here is with the website you trusted - Facebook, in this example. Sites like Facebook that rely on cookies to identify and authorize user actions need to do more things than just validate your cookie when data is presented to the site on your behalf. They need to make sure that place from which the data was sent was 'good', or that a malicious author cannot create data the same way that www.facebook.com can. They need to make sure that when you update your status, the data contain more than just your new status text - there must be some kind of secret information in there that can only be generated by Facebook, and this secret must be different for each Facebook user. They can even control how long cookies and secrets remain valid, and have ways to periodically require users to sign in and generate new unique secrets for users.

Of course, this is just a silly example. I'm sure Facebook is perfectly adept and handling such attacks. However, a vulnerability like this could impact everything from online review sites to banking and e-commerce sites. It's always good to be aware of things that could go wrong online - the Internet is definitely not as safe as you might think it is.

So, how was your date?

A funny exchange at work today...

I designed this piece of UI putting together all my newly-acquired Javascript and Paint.NET (a free Photoshop-like tool) skills, and it looked pretty fancy for what I thought I was going to end up with. After playing with it for a bit my co-worker responded: "Thanks for putting that together Viraj - I really like the concept. I can't wait to see what a designer can do with it".

Lol... this sounds a lot like the "She's got a great personality..." line of the dating scene.

Like I said previously, UI design is so much harder than I thought it was!

Fix for slow Firefox/Chrome connects to localhost

While doing some recent testing I noticed that Chrome(v3) and Firefox(v3.5) are both very slow to connect to http://localhost on Windows 7 - both take ~1 second just to connect.

I initially suspected something was wrong with the webserver on localhost, but once I validated that wasn't it, I found some blog posts about others who had noticed this in Vista and XP. Essentially, disabling ipv6 takes care of the slowness.

However, to fix the issue, have the client use http://127.0.0.1 instead of http://localhost - it bypasses ipv6 without you needing to mess with browser configuration.

Know What you Inherit

I ran into a couple of bugs recently that took longer than they should have to fix. Like all bugs, it seems obvious now that I know what was wrong but I think I spent a total of 5-6 hours investigating and fixing this across multiple platforms (hey, this is what makes developing software fun!). Here's hoping that those fancy search engines will help someone else find this post and save them time incase they have a similar problem.

I was working on some code that launched another process. This is a fairly mundane task. Interestingly though, the process launched went on to kill its parent and re-launch another copy of the parent. So, process A is running and launches process B, which then kills A and launches A'. Sounds kinda simple, right?

Well, everything seemed to work until I noticed that some resources needed by A' weren't available (ports/files). That seemed odd, given that A had been using those same resources successfully, and those should now be available since A was gone. The title of the post gives it away, but the problem is that a fork causes child processes to inherit the file descriptors/handles of the parent, so the files/ports opened by A were inherited by B and subsequently by A'. This meant that they weren't really cleaned up by the OS when A exited. Hence A' could not re-open those resources (some were locked for exclusive use).

The really interesting aspect of this bug was how it manifest itself on different OSes and the different fixes.

On Windows, TCPView showed the ports in use by a "<non-existent>" process. The PID of this process was that of A, which was already gone by now and didn't show up in the list of running processes.

After some analytical debugging, I guessed that the handles were being inherited by the children resulting in these strange 'orphaned' ports. The solution on Windows was to use the CreateProcess API with the 'bInheritHandles' flag to FALSE. Problem solved. By the way, the not existent process IDs attached to those ports seem to imply that the OS tracks ownership by processID, and hence cannot validate that the new owner of these is the child process now that the parent is dead - the child obviously has a different process ID. This might not be really how it's done, but seems logical.

The Mac was much more interesting. The manifestation of the problem was simply unavailability of the resources. There isn't an equivalent of the bInheritHandles flag for the fork command on UNIX. To cut to the chase, the solution was to fork the process, close all open file descriptors that it inherits and then call exec.

Now, the Mac guys have added a nifty 'open' command to the system which helps launch processes as a child of the launchd process, which doesn't inherit the callers file descriptors (it's parent is the launchd process). However, this open command has a couple of pretty severe limitations. It can only open app bundles, not native binaries. And you can't pass in command line arguments to the application you open. FAIL on both counts! Mac purists will claim that command line arguments aren't the 'right thing' on the Mac, and that Apple Events should be used instead. That's BS, really. For anyone writing platform independent C++ code, it's just not practical. People don't realize that not every app on the Mac is a Cocoa/Carbon app. Anyways, so on OS X I needed to be a little creative and have A launch B, but before doing anything useful in B enumerate all open file descriptors and close them (readdir() /dev/fd on FreeBSD and Darwin enumerates all open file descriptors). Oh and by the way, you might not want to close FDs 0, 1 and 2 - they're stdin, stdout and stderr respectively. This post on StackOverflow has some good related information incase you're curious.

To Every Web/UI Developer I've Scoffed At - Apologies!

I am/was a cocky programmer. Having only worked on system and application level programming thus far, I really didn't appreciate how hard building a good, usable website or application is. I knew that an application or a system is only as good as how usable it is, but I really considered usability to be a 'simple' problem and by inference I assumed that writing the code behind what you see on a website or an application is also 'simple'. As my career matured I suspected I might be wrong, and now I know I was!

Over the last few weeks, I've been messing quite a bit with Html and CSS to make stuff look non-ugly and Javascript/Ajax to make stuff feel non-sluggish. And the combination of these together to make non-ugly things appear non-sluggish. Of course, this also means dealing with everything that goes on in the middle/backend to support non-sluggish, non-ugly things. Oh, and once you have something that's not ugly and not sluggish, you have to worry about the bad guys. Cross-site Scripting, Cross-site Request Forgery, cookie theft and poisoning, etc are things I didn't think much about previously. What cans of worm those are... !

And then a couple of months ago I spent some time making an mac application non-ugly and non-sluggish. Same deal, pretty much.

Working on these new technologies sure feels like being a kid in a candy store, but I have to confess my new found respect for good UI/Web developers (and I am not one, by a long shot). I may have snickered behind your backs previously, but it sure won't happen again!

What's your time worth?

One of the hardest questions I often find myself needing to answer is what my time is worth. Simple everyday decisions are influenced by what the answer to this question is - Should I get groceries from the store myself, or order online? Should I clean my own apartment or hire a professional? Should I contest the parking ticket by mail, in person or simply pay it? Should I go out an enjoy the weather instead of working overtime?

Of course, the right answer in most cases depends on more than just how you value your time. Tangible (I might pick better produce in person than online, or a professional could do a better job cleaning my apartment than I can) and non-tangible (I get to experience the judicial process at the municipal court myself if I contest a ticket in person) factors can sometimes influence these decision more than the absolute value of your time, and generally it's a combination of these factors + the value of your time which leads to the right answer.

What factors influence how you derive the value of your time? Here's a quick list of things I could think of:

• Your age relative to life expectancy. Generally, the older you get the more valuable your time is. Time does run out eventually, afterall.
• Real dollar value of gains from alternate activities you could be engaged in versus the intended activity. If you're paid by the minute on your job, the dollar value of every minute your spend in the break room outside of the allowed times better be worth more than your per-minute salary.
• The intangible value of alternate activities you could be engaged in versus the intended activity. Heh - good luck figuring this out!
• The tangible and intangible deferred value/costs of making a decision. Not feeding the parking meter in favor of enjoying your cup of coffee by the lake will cost you $25 next week.
• Risk associated with the decision you make. You're quite likely to hurt yourself sawing wood, and depending on how badly you're injured you could easily outspend in medical bills what you would have paid a professional instead. Again, look luck quantifying risk.

What else do you consider when deciding one way or another?

New Technology (for me) Roundup

Over the last almost 2 months, I've messed with several new technologies - some extensively, some briefly - that I hadn't used previously. This post is primarily a journal entry documenting my impressions of and experience with these, so far:

• PHP - Exposure : Medium
  I think I really like PHP. It seems like it's a good blend of a traditional programming language and a scripting language. I like that it allows for well designed software with OO constructs being first class citizens. I also like the flexibility that the scripting language aspect of PHP provides. I wish there were some kind of PHP compiler which helped catch silly typo-like issues before runtime, but I guess that's the price you pay for having the conveniences of PHP. I also think I would like having a good PHP debugger - currently I use code review and tracing as debugging aids. They've worked so far but I hope I never have to chase down something really nasty or subtle using these techniques.


• Objective-C/Carbon/Cocoa - Exposure: Medium High
  I previously wrote about my experience with programming for the Mac. For someone familiar with C and working with a runtime framework, this shouldn't be hard to grasp. I think I'm pretty comfortable with these technologies, but in many ways these are forced down your throat if you want to write software that runs on a Mac, and looks half decent. I dove deep into a few things related to these technologies (debugging crashes, file system events, application run loops, network support, deployment) and it was kinda fun and fulfilling to accomplish complex tasks with these technologies.


• Bash Scripting - Exposure: Medium Low
  To be productive in a Linux development environment, mastery of scripting is key. I know just enough to get me by, and I'm sure there's so much more I could do to improve. The rule of three seems to work well... if you do the same task three times, script it. And most times, you'll discover it's already been scripted by someone else or simpler still, exists as a built in set of commands. This seems like one of those endless holes of expertise that never ends. My goal is to deal with this as needed instead of being overly enthusiastic about becoming a crazy script monkey.


• Javascript - Exposure: Low
  I'm actually not too bummed about not having had to mess with more Javascript. I know people who just do the craziest things with Javascript and AJAX, but I'm not creative enough (or perhaps not motivated enough) to do anything more than the minimal. Unfortunately, a minimal website only works if you're Google or Craigslist. I haven't messed with Javascript for more than just a few hours, so I don't really have any strong opinions except that for someone who isn't familiar with scripting it takes some getting used to. Something like Script# might be an ideal transitionary tool though (I haven't played with it at all).


• MySQL - Exposure: Medium Low
  MySQL seems really slick. It feels great for simple database functionality (haven't really done anything too fancy with it) and supports some SQL syntax that comes in handy versus Microsoft SQL Server (insert ... on duplicate key update, create table if not exists, etc). PHP support for MySQL seems like a great integration win for both technologies. I haven't really dealt too much with administration and performance issues though, two areas which are super important to a great database solution, so I can't comment on those.


• Python - Exposure: Low
  I wrote a couple of python scripts to get some pretty powerful tasks done. I like that it has a bunch of libraries that enable you to write pretty fancy applications if you're so inclined (I'm not, and likely never will be). Like most scripting languages I'm amazed at how much can be accomplished in a few lines of code. Generally though, I don't like too much magic being done for me when I don't really understand what's happening and my experience with Python certainly made it seem very magical. Which is great for getting small tasks done, I guess.


• Vim - Exposure: Medium High
  This is a big once - even after almost two months of using this daily, I'm not nearly as comfortable with it as I was with the Visual Studio IDE, which makes me feel like I'm not being as productive as I can be. I think I learn one or two new tricks every day that make me wonder if there's anything Vim can't do. It's another one of those 'rabbit hole' technologies where experts can tune it to crazy levels. My approach is more along the lines of 'fix it when it annoys you' which seems to be working (slower than I would like, I admit). It certainly has the potentially to make me super productive once I get better with it, and that's making me stick with it.


• Others - Exposure: Low to High
  Technologies that aren't really 'new' for me but I was out of touch with for the last few years and have reconneced with recently:
  - C
  - Linux
  - Win32
  - Batch file scripting
  - Makefiles
  - gdb

So yea, as you might be able to tell, the last couple months have been insanely fun. I feel like an intern again (in more than one way ;-) )!

f.lux - I Like!

Staring at multiple computer monitors late into the night isn't as pleasant as it should be. I've noticed that the constant bright glare from the monitors causes a lot of fatigue. f.lux is a very simple and yet highly effective tool that has made coding so much more pleasant. I very highly recommend this to anyone who spends long hours working at a computer. Available for Mac, PC and Linux. (PS: MacBooks already have similar functionality built-in that uses the integrated camera to detect ambient light and adjust brightness accordingly).

Cocoa: What is "File's Owner" in a nib?

One of the things I had most trouble with while writing my first Cocoa application was understanding what a File's Owner in a nib file was and what role it fulfilled.

Apple's documentation seems to imply that understanding File's Owner is important (it is) but doesn't really do a good job of explaining the concept. And I'm not alone - this email thread contains a pretty good summary of what Apple's documentation says and the confusion it might create. That same thread has several peoples' attempts to explain what it is. I really didn't get too much from those explanations and ended up explaining it to myself by piecing together data from a few experiments. Now that I think I understand what it's for, I figured I should try and put my take out there as well in case it ends up helping someone else in the future.

The File's Owner of your primary nib file is, by default, the NSApplication class and this comes ready-made for you when you create your Cocoa application. If your application has just the one nib file, you really don't need to worry about File's Owner. But if that's true, your application is probably really trivial or not well written.

Generally, each new window/sheet your application creates should be contained in it's own nib for faster loading of your app and smaller runtime footprint. When adding a nib to your application in XCode, you'll noticed that the File's Owner is set to NSObject by default (select the File's Owner object in the nib and launch Tools -> Identity Inspector). I recommend setting this to a derived type for two reasons:

1. So that you're forced to think about who the File's Owner of the nib is.
2. So that you don't make a silly error while defining the owner of the nib - everything is an NSObject, after all.

A nib file is loaded dynamically at runtime usually in response to some user action (clicking a button, selecting a menu option, etc). Loading the nib is done, usually, using the NSDocumentController or the NSWindowController classes. Just because these classes help load the nib doesn't mean they must 'own' the nib. The File's Owner of the nib is the object that makes communication possible between this new nib and other parts of the application. Let's explore this further.

The document/window loaded in the nib can have one of the following purposes:

1. an informative view that isn't interactive (About box, for example)
   
2. get some more user input to feed into other parts of the application
   

#1 is the simple case - by my definition, since there is no communication to be enabled, the File's Owner for this nib is not important. But based on my previous recommendation of not using NSObject as the File's Owner, what class should be set as the File's Owner? The object (NSDocumentController/NSWindowController) which loaded the nib can be made owner of the nib, and the nib loaded using the method overload that doesn't need an owner specified.

#2 is the interesting case - if this is a form that takes in some user input it is required that this information be communicated back to another part of the application. But no one on the outside really has access to controls in this form. No one, except the File's Owner. In this case, the File's Owner should be an instance of a class that you've previously created, and the type of that instance is what you set to be the File's Owner's class in the Identity Inspector. It's important here to understand that the File's Owner isn't a 'new instance' of the class you specified. In fact, the File's Owner is set to an instance provided when the nib was loaded (see the last parameter of initWithWindowsNibName).

So your application likely had an instance of an object created previously, which is what you would pass in as the owner of the file. That instance can now expose IBOutlets linked to fields of the form, which can then be used by other parts of your application that already have a reference to this instance. This is what Apple documentation means when it refers to the File's Owner as a proxy.

Hopefully, this will help someone else who's learning to work with Cocoa and needs to get some clarity around the File's Owner.

Developing for the Mac - How does it compare?

I spent most of this week developing some Mac OS X software. Having never before written a single line of Objective-C or any Mac software, I was pretty excited. Here are a few observations of developing for the Mac compared to the Windows platform (primarily .NET) from a week's worth of writing an application using Cocoa. Of course this isn't exhaustive and only includes things I had to deal with (disclaimer - opinions subject to change as time passes):

• Overall, developer reference documentation on Apple's Developer site seems more current and easy to understand than that on MSDN. A nice touch is the reference to examples which use a particular method inline with the documentation of the method <example> (MSDN does it using inline code, so it's not too different). My favorite feature about documentation though is the logical grouping of methods and properties arranged by tasks - that makes it very easy to get stuff done. I think this is the result of being the underdog in this space.


• Mac OS X applications' uniform usability and consistent aesthetic isn't a fluke. Apple's documentation regarding recommended usage is precise down to individual visual controls and yet comprehensive as far as Human Interface Guidelines go.
  


• XCode doesn't have anything on Visual Studio. Visual Studio seems, hands down, a better integrated development environment and debugging application. VS 2008 is really pretty awesome.
  


• Cocoa is nice, but still has some catching up to do with .NET. Cocoa libraries provide just enough abstractions to get stuff done, but they don't seem to be nearly as comprehensive and well thought out as the .NET libraries are. I found myself cursing some abstractions/APIs in Cocoa for their primitiveness compared to Windows pretty often. Generics give .NET an edge that Cocoa still doesn't have. Microsoft has done a great job of handling little things, such as boxing, which make development easier than it is for Cocoa. 
  


• XCode and Interface Builder are unfortunate crutches required for Mac OS X development - I would claim that it's impossible to write any decent application without using both. This sounds great until you realize that IB, which really is a designer, does so much magic for you that you just cannot with code. Linking up IBOutlets, for instance, is something I cannot imagine can be done outside of Interface Builder and has way too much magic associated with it. As a developer I often felt at the mercy of these tools, instead of being the master of it. It's fortunate that this is not true of developing for Windows - there is a lot of helpful magic that Visual Studio builds in but it's certainly not required to develop a decent application.
  


• Overall, the Mac platform (Cocoa) seems more closed than it should be. This sounds weird, considering that it's all basically Unix and standard Unix libraries are provided or can be added relatively easily. My comment here related to how accessible and complete Cocoa/Carbon libraries are. Getting access to weird parts of the system is easier on Windows that on the Mac platform, I believe.
  


• Deploying Mac applications is a snap, better than Windows. However, I think this is related to how developers are accustomed to (ab)using resources in Windows (registry, etc). Not having a lot of Windows' 'legacy' facilities on the Mac makes developers think hard about what their app really should be doing. I claim that good developers should be able to create x-copy deployable apps even for Windows, though, so it's unfair to blame the platform here.
  


• The fact that it's built on Unix makes the mac support a lot more languages, especially scripting languages, out of the box. Windows is catching up fast though - integration of interpreted languages with .NET and PowerShell bring it at par with the Mac (I hear it might be better, but I don't have much experience).
  


• Testing on the Mac seems easier. The fact that there are a very finite set of configurations compared to the Windows platform makes life less complicated for developers. It's almost true that if it works on your Mac it's probably doing to work on most Macs (modulo a few exceptions).  History says this has traditionally been an advantage of the Windows platform, but I'm not so sure it's a good thing anymore. This one's probably the most controversial of my observations above and likely to change as I do more Mac work.
  

So, who wins? I would say Windows for the overall developer friendliness. Apple has some catching up to do in several areas. That said, the Windows platform could learn more than just a few things from what Apple seems to be doing right. 

It's a fun time to be a software developer.

A Run on the Bank of Microsoft?

Wow... did I just predict this? Yesterday, in my Problems at Facebook? post I referenced (somewhat jokingly) how I was kinda surprised that in the current economic conditions, the EU hadn't tapped into the Microsoft cash machine using some anti-trust excuse. Lo and behold, a few minutes ago Microsoft issued a press release in response to a 'Statement of Objections' it received from the EU about - you guessed it - European anti-trust law. Obviously, I had no knowledge of this when I posted yesterday - I'm just a foot soldier. The timing is a little spooky though... maybe I should muse of some good things happening. ;)

I wonder if this is the beginning of another run on the Bank of Microsoft by the EU...

Update: More coverage in the Wall Street Journal. This thing is probably going to go on for a while. Sigh!

Win 7's glowing reviews - a case of lowered expectations?

Windows 7 was publicly released as a beta last week, and has been getting some pretty glowing reviews. I haven't yet seen a single negative review - everything I've seen compares Windows 7 much favourably over Vista and in many cases even over XP. ZDNet's review is pretty typical of most reviews I've read. Even traditional Microsoft haters (who shall go un-named) seem to be reacting favorably to Windows 7. Of course there are some brand new features, but I'm more concerned with the stability and snappiness of the OS.

While a lot of the praise is well deserved and a lot of people have worked hard on making Windows 7 what it is, I can't help but wonder how much of it is a result of peoples' lowered expectations from Microsoft with regards to Windows. Vista wasn't nearly as good as it should have been when it released (SP1 seems to have fixed a lot of stability issues, though it is still a resource hog) and the generally negative buzz about Vista has probably reduced expectations to the point where anything that's not sluggish, bloated and resource hungry would've received good feedback.

Anyways, nothing wrong with good reviews... here's hoping that Windows 7 will exceed all expectations when it's publicly released.

Problems at Facebook?

I was thinking about the whole recession thing and how it impacts Microsoft. As I worked through my train of thought, I remembered the huge 899 million Euro fine that the EU slapped Microsoft with in Feb 2008. I remember thinking then that the EU was almost treating Microsoft like an ATM (probably inspired by this post).

I wondered why in this time of recession the EU hasn't yet again tapped its ATM and thought I'd update my Facebook status to say "Viraj wonders why, with this recession n all, the EU hasn't tapped its ATM (Microsoft) again using the same anti-trust excuse...". To my surprise, I got a little popup that said "Validation Error - A validation error occured" and nothing more informative.

Interesting. What exactly is Facebook validating, and did I have some red-herring text in there? I would expect filters for expletives, racial slurs, geo-political issues... but my status message didn't seem to violate any of those. I tried the following variants, which all failed:

"Viraj wonders why, with this recession n all, the EU hasn't tapped its ATM (MSFT) again using the same anti-trust excuse..."

"Viraj wonders why, with this recession n all, the EU hasn't tapped its ATM again using the same anti-trust excuse..."

"Viraj wonders why, with this recession n all, the EU hasn't tapped its ATM again..."

"Viraj wonders why, with this recession n all, the EU"

"wonders..."

Ok, so it's certainly not the text of my status message that's causing this. I started poking around, and my 'Home' page seemed OK - I had news items, status updates from friends, etc. However, when I jumped to my own profile, I was suprised to find that all data I had published was blank. No wall posts, no posted items, no recent history. However, my photo albums seemed to fine, as did my profile information.

My guess is there's been some kind of data loss-ish issue at FB (a lot of their data is simply held in caches so maybe a cache and replicas blew away - perhaps Wall posts are not persisted?). Anyways, I'll try to update status again and see if stuff comes back... meanwhile, I'm locked out of changing my Facebook status...

Any guesses about what might be going on?

Update: I can't seem to be able to clear my previous status message either... the status is cleared in the webpage (local javascript clearing it, I would assume) but on refresh I see my old status again...

Update2: And we're back... that didn't last too long. Cool!