XMLHttpRequest Security

Scott brings up the dread topic of various security restrictions in XMLHTTPRequest that prove to be problematic in some of the more advanced AJAX style pages that try to mixup/merge data from multiple hosts.

I used to own Microsoft's XMLHttpRequest implementation, and I have been involved in multiple security reviews of that code. What he is asking for is possible, but would require changes to the was credentials (username/password) are stored in Windows' core Url resolution library: URLMON.DLL. Here is a copy of my comments that I posted on his blog entry:

The reason for blocking cross-site loading is primarily because of cached credentials. Today, username/password information is cached, to avoid forcing you to reenter it for every http reference, but that also means that script on yahoo.com would have full access to _everything_ in your gmail/hotmail/bank account, without a pop-up or any other indication that the yahoo page was doing so. You could fix this by associating saved credentials with a src url (plus some trickery when the src was from the same sight) but that would require changes to the guts of windows url support libraries (urlmon.dll)

Comparing XML to CSS or images is unfair. While you can link to an image on another sight, script can't really interact with that image; or example posting that image back to the script's host sight. CSS is a bit more complicated, since the DOM does give you an API for interacting with the CSS, but I have never heard of anyone storing anything private to the user in a CSS resource. At worst, you might be able to figure out the user's favorite color.

Ultimately, it gets back to the problem that there needs to be a way for the user to explicitly enable the script to access those resources. If done properly, it would actually be safer for the user than the state today, where the user has to give out their username and password to sights other than the actual host associated with that login.

I'd love to see Microsoft step up and provide a solution that addresses the security issues. I know I've run against this implementation many times.

Latest from Project Censored

I normally try to avoid too much political slant, but I always find the Project Censored collections to be thought provoking, regardless of your political slant.

http://www.projectcensored.org/

Censored 2006 from Seven Stories Press features the 25 most important news stories not covered by the corporate media in 2004-05. Government Secrecy, Media Failures in Iraq, National Voter Fraud, Citizen Surveillance, and Environmental disasters are just some of this year's topics.

I always find that the articles come across so left leaning, so anti-establishment, as to rub even me the wrong way. Still, I think it is worth reading some of the articles. You are guaranteed at least a few surprises.

Something New

It seems an amusing irony, that there has been such active discussion recently about people leaving Microsoft. (The ones I was tracking were: Mini-Microsoft,
Dare). I've worked at Microsoft for almost 8 years, and it has been an interesting time, full of amazing people and cool products. Yet... Microsoft was never my intensional destination, it was just a step. I came to Microsoft from experiences at much smaller companies (<50 people total for the 2 companies where I had worked) and ... well ... I like small start-ups. Thus it should not be too surprising that I am returning to the world of small start-ups. Last Friday (September 16th) was my last day at Microsoft.

What kept me at Microsoft, and what I will miss the most, is the people. I worked with such diverse collection of wonderful people... mostly. Not that you can't get that elsewhere, but the 'individual contributors' (as they are called at MS) are really one of Microsoft's assets. I felt like a I was leaving my family. I have worked with some of these people for my entire time at Microsoft. That is a long, and intense, time to build a friendship.

I've had almost everyone I know ask me "why I are you leaving?" Some factors: Whidbey is basically done, as is Yukon. Microsoft definitely is more bureaucratic that it used to be, as well. Mostly though, it was just time to move on. I was presented with an opportunity that fit my interests. (And no, I'm not going to Google... too big. I decided long ago, that if I was going to leave, I wanted it to be for a small company, something less than 100 people.)

As I get time, I hope to write some more about why I think that Microsoft is not the same place that it used to be. Dare's comments (here and here) hit some key points. Mini-Microsoft is another great source of information about working at Microsoft is really about. Steve Ballmer may not be reading these blogs, but he sure as hell should. He and Bill have no real interaction with 'the troops' and if he thinks the company poll is all the information he needs, then I think he will see many more key people leaving. Worse, the current attitude is discouraging the next generation of potential 'key players' from staying on, or even joining at all.

So on to a new adventure! I am not going too far, and will still be involved with the XML community, and will likely be doing some work that leverages some of the libraries and products that I helped ship at Microsoft. Back to the code!

RPC Under Fire

Via Lambda-the-Ultimate, Steve Vinoski's paper: RPC Under Fire.

Yet another article about RPC's failings. Also mentions SOAP and briefly goes into how SOAP has made things worse, rather than better. It is ironical, since one of SOAP's goals was to simplify interoperation, but it has actually made things worse. A large part of the problem may be XML Schema, aka XSD. XSD may have been designed with the best of intent, but it is proving to be a royal nightmare to implement, support, and worse-yet integrate into existing languages/environments.

I've been involved with all 3 types of activities, and they have all been painfully difficult. I've managed people implementing XSD, as well as a lot of experience managing people trying to fix Microsoft's implementations to be compliant. The specification is so complicated that a minor misunderstanding requires a significant API redesign to fix! The type system is so complicated that there is a constant stream of emails asking questions about why such-n-such a schema fails. The specification has a number of key controversial points where key vendors have had differing interpretations, leading to significant issues.

That said, XSD is what we've got. Relax-NG may be cleaner and simpler, but it still has the problem that it doesn't map back to any common OO language simply. That isn't so much Relax-NG's fault, as it is a central issue with XML itself. XSD is here to stay, given it's support in so many Microsoft products. That is not something to take lightly, in my book. From what I heard, the next version of Office is going to really address a lot of the issues people had with the XML support in the current version.

Back to the topic of RPC: RPC (and most especially all SOAP implementations) walk a fine line between enabling programmer productivity and distancing programmers from a core concern. I know far too many stories of RPC ruining products, where it all works great when the client and server have a fast, reliable connection, but fails miserably when deployed in the real world. Developers must keep the nature of the network in mind when developing a network application. Libraries which distance the developer to far from such a core concern, are asking for abuse, and are likely to result in applications that do not handle ugly realities of networks very well.

one truck = +40min

A truck broke down at the entrance to my onramp into 520 this morning (at Montlake). That one break down cost me 40 minutes of my morning. All they needed to do was tow it out of the way. sigh. I did get to listen to a decent amount of the Roberts Hearings on KUOW. This was one day that I really wish I had taken the VanPool.

I daydream of the day when cars have computers hooked into the local transit system that advises alternate routes, etc. I wonder if XML will still be in significant use...

Keep it simple...

I just returned from a week camping in the desert. One thing that this burned into my head (while the sun burned into my anglo-saxon skin) was the importance of keeping things simple. As a software developer, I am often reminded of this, but in less brutal ways. Somehow, watching the desert winds rip tarps to shreds, bend metal, and mutilate PVC pipes... is all more impressive than just getting a constant stream of bugs from code you thought finished.

KISS = Keep It Simple Stupid

Keeping it simple, is all about focusing on the core of the problem, not letting the desire for all the bells and whistles distract you. If you get the core problem solved well, then the design will be less cluttered with extra code that limits your ability to rework what is there. The best developers I have worked with all are constantly refactoring code they just wrote (or wrote 6 months ago). They are not rewriting it, they are reworking the logic that is there for better integration with the new features they are adding. For that to work, what is there should be clean and simple enough to understand. That doesn't mean that it is simplistic. That means that local dependencies and expectations are clear and reliable. It means that you can come back to the code in a few months and have a decent hope of knowing how a change will impact the existing functionality.

A lot of people confuse 'simple' with 'simplistic'. Sometimes 'simple' does equate to simplistic, but sometimes it means 'clean' or 'clear'. You can't write a real-world compiler that is 'simplistic', but that doesn't mean you can't apply KISS principles. Applying KISS means having clear boundaries. It means that you add complexity as necessary, in small, easily understood steps. Introduce enough new complexity and you should be refactoring it into small, simpler pieces again.

Part of my job at Microsoft has had me do security reviews of a lot of code. Trying to understand old code, potentially written by someone else, really makes one appreciate developers who truly apply KISS while developing their features. There have been features that I have had to give up on reviewing, just focusing on core code-paths, because I simply can not hold the entire design in my head... tens of mutually dependent state-variables are one give-away. Another is long methods of unbalanced if/else blocks, handling myriads of impenetrable special cases.

The developers who best apply KISS principles are also the most efficient. It may take them longer to get you the first working version, but that version has more functional features, than the version produced by the cowboy hacker in the next office, and the cowboy will spend many more late evenings tracking down yet another corner-case bug, while the KISS developer is working on V2.