Monthly Archives: August 2005

The AJAX danger that never was

Posted on by

I can’t believe how much hype this article is generating. From the article:

Like so many technologies-gone-bad before it, this technology was created for the purpose of good. And until now, the XMLHttpRequest has been so good it could almost be considered saintly, providing users and developers alike with such conveniences as input validation without post-back, text area spell checkers, and Gmail. Interfaces built with AJAX are fun to use and even more fun to program. It’s almost hard to imagine that such a miraculous object could ever do wrong.

But even without the discovery of a giant security hole, the XMLHttpRequest will likely fall from grace. Its fall will be in the form of “user over-profiling” for want of a better description. Currently, user profiling helps Web site owners detect trends, track page viewing habits and iron out usability problems. Until now though, developers could only analyze posted data—data that users decided they wanted the server to get, and were happy to send off for processing.

This is just ridiculous. Not only is it dead wrong technically, it makes assumptions that just because a technology is gaining recent popularity, the potential is there for security flaws to appear.

Let’s take a look at this claim from the article: Until now though, developers could only analyze posted data—data that users decided they wanted the server to get, and were happy to send off for processing.

Let me share some information with you: The internet is not private. Ever since the first day you opened a web browser and started visiting websites you have been tracked. This is no secret, everyone knows about cookies and how websites use them to store data. Recently there have even been reports of people realizing that they might not need cookies and starting to regularly delete them.

You don’t need to submit any forms for them to track you. You don’t even need AJAX or even Javascript. You merely need to visit their website with a web browser that accepts cookies or images. Nearly every browser does this by default and behind the scenes so you never know it’s happening. Advertising companies are tracking the ads you view, remembering which ones you click on so they can target you with ads they think you will click more. Websites you visit are tracking your movement through their site to see which pages you view most, and which pages you miss. They’ll be analyzing this data in their board rooms and asking questions about how to make you stay longer and click more ads.

AJAX brings nothing new to the table. Even in a browser that doesn’t support XMLHttpRequest, I can track your movements and clicks and any information you put into forms (yes, even before you submit that form). All you need is some very simple Javascript and a server side language to catch the input. This can be done easily in Netscape Navigator 3.

When you use the internet, you are giving up parts of your privacy. When you enter information into a website you are trusting that website with whatever information you give it. This is how the internet works, and how it will work for years to come (if not forever). Either get used to it, or it’s time for you to get a bigger tin foil hat.

Anyway, back to my original point: The article is simply uninformed whining, and I’m very surprised any technical website would publish such a hyped up piece of crap. They may as well have written an article on the ‘Dangers of cookies’ and published that instead. I’m even more surprised at the amount of attention it’s getting.

The new Macromedia Flash Player detection kit

Posted on by

With the announcement of Flash 8 today, Macromedia also quietly pushed out their new detection kit. The detection kit has has been around for the last few versions of Flash, and usually changes with each version to include whatever the latest trends in Flash detection are.

It’s no wonder then, that the latest version uses Javascript as the suggested detection method. Unfortuntely, it’s not perfect. While it’s a good first try, it is greatly lacking in a few basic needs of most web developers. Here’s the issues I have with it:

  • Inline Javascript code (and lots of it) – Who wants to copy a bunch of Javascript and VBscript onto every single page that uses Flash? While it might be possible to move the Javascript into an external file, you would still have a small amount of VBScript on each page (or another external file to include). I’m not sure why they decided to leave in the VBScript when there are other reliable ways to create and test for ActiveX objects. Also: what happens if you need to upgrade the Javascript for some reason? While the code should be very futureproof, you never know when a bug might pop up, and you’ll be stuck editing all of your HTML files that have Flash movies included in them.
  • Tough to modify the code – It suffers from the same drawbacks as most Javascript embed techniques – placing tons of Javascript document.write() calls and writing out your object or embed tags to the page. This is a hassle to edit if you need to make changes, and makes it very tough for designers who don’t know Javascript to go in and modify attributes.
  • It’s not valid HTML or XHTML – Valid XHTML documents aren’t for everyone, but when you have clients specifically asking for them it’s nice to be able to deliver. The new detection doesn’t even come close to validating.

If you want to compare the new Macromedia detection to my FlashObject script, check out this new article that shows how to use it:

Best Practices for Flash Player Detection

Then compare the steps needed to get that working with using FlashObject:

  1. Include single .js file.
  2. Add a few lines of code (see example of bare minimum).
  3. Sit back, relax.

I think the choice is clear.

Now when you downloaded the new detection kit you may have noticed another folder hiding out in there with the name of “Express Installation.” This is Macrmedia’s new way of upgrading your Flash player without the need to go to macromedia and download the new plugin. I’ll be writing up a new entry soon that gives some tips and best practices on using this method in the very near future.