Coding In Paradise

[Update: I posted this and then realized that having it on the client side doesn't solve things, since people can just shoot it over to the server other ways. Oh well... back to the drawing board]

You know, expecting developers to handle every single way of launching a Cross Site Scripting (XSS) attack is way too complex and unreliable. Can we get one of two things:

• Either the browser makers give us a single nice method, let's call it makeSafe() or clean(), that I can run on a DOM node or string and which will completely remove any unsafe code: someNode.clean()
• Someone create a client-side JavaScript library that does all this, super modularized and easy, and put it out under a BSD license so everyone can incorporate it into their systems. This library will expose just one method: clean(). This method can run on strings or DOM nodes.
  

Once we have either of these, we can hook them into blogging systems, Wikis, etc.; you just grab the new content from the user that they entered into a textarea, call clean() on it, and then send it over to the server side.

Practice Safe HTML!

Wow, this guy went to alot of work. He documented every (known) way a Cross-Site Scripting (XSS) can be launched. Update your regular expressions to clean all of these out! This can affect RSS aggregators as well.

Holy cow, Cory Rauch is a god. He saw my post last night:

"Here's a crazy, evil thought. What if someone took the Trimpath SQL layer, an open source component that lets you have the power of SQL queries while running in a web browser, and layered that over the AMASS permanent browser storage system I've built? This would mean AMASS becomes a generalized storage system, simulating a relational database running on the client side that can be queried using SQL."

This morning I came into the office and saw an email from Cory that he had implemented a prototype of that overnight. Wow; I'm impressed. Good work :)

He even wrote good documentation:

"A piece of the offline AJAX application puzzle. This idea was in response to a blog post found here.

The Demo | The Files

This is a quick hack of both the example pages from AMASS and TrimPath projects combined together to form a basic javascript database. If you are not familiar with either project here is quick overview:

AMASS - A method for storing a large amount of data in a web browser via JavaScript and Flash. Provides a better storage mechanism than cookies with larger storage.

TrimPath - Is an sql query parser that works with data stored in arrays.

Together, I created a quick hack, you may say, to store an array of data in AMASS storage, then the script allows the user to run a query on stored data by grab the data back from storage and using TrimPath to parse and filter the data array. You can try out the demo if you like or even just go to the project for more information.

If these projects mature we eventually have an even more reliable and fault tolerant generation of AJAX applications."

This stuff is cooking! Now we just need someone to get it working on the Mac on Firefox (I don't have a Mac), and someone to see how it works in Linux on Firefox.

I want to clear up a few points about AMASS, the Ajax MAssive Storage System, that I've seen around the blogosphere:

1) AMASS can store much more than 100K, up to megabytes of information. AMASS can store up to 100K of information without prompting the user; afterwards, the underlying Flash system prompts the user, which AMASS detects to make the Flash "Do you give this website permission to store X amount of information" dialog appear. Afterwards, you can store an arbitrary amount of information; I've successfully stored up to 10 megabytes. Why don't you try more and see where it falls over?

2) AMASS is not a security threat. The underlying Flash SharedObject system that AMASS uses keeps storage partitioned between domains (though be careful using something like AMASS on a website where different providers have the same host name). Also, at each level of magnitude of increasing storage (i.e. storing 100K, 1 Meg, 10 Megs, etc.) AMASS reprompts the user to make sure the user gives the site permission.

3) AMASS, by itself, does not make offline access possible. However, it is one of the essential ingredients in achieving offline functionality for AJAX apps, which is one of the reasons I created it.

4) AMASS is in alpha, so expect bugs :) In November and December I will have more time to focus on making it reliable.

5) I need help on making AMASS work on Firefox for the Mac!

6) AMASS does not uses the Flash JavaScript Integration kit; I built an early prototype of AMASS using that framework. The Flash JavaScript Integration kit is excellent and well designed; however, the internal mechanisms it uses to achieve communication between Flash and JavaScript have serious performance and data size issues for large datasets. Instead, I use the Flash ActiveX methods in IE, which are fast, and the Flash LiveConnect methods in Gecko based browsers, which are also fast. A small point is that all methods calls have to be asynchronous in the Flash JavaScript Integration kit, which would have made the AMASS API more difficult, while the ActiveX/LiveConnect methods made it possible for me to make synchronous methods for the AMASS API.

7) AMASS uses features that have been in Flash since the Flash Plugin Version 6; over 95% of the installed PC base on the Internet have the Flash features necessary to support AMASS (according to Macromedia statistics), so it is essentially everywhere. I didn't use Flash 8's Flash/JavaScript communication facilities for exactly this reason.