brentashley

There have been some mentions and bit of buzz about my Secure Ajax Mashups article at IBM:

• Ajaxian
• ifacethoughts
• Dave Johnson
• Joe Walker (DWR)
• Shelley at Burningbird

On an entirely different topic, I’ll be playing the drums tonight at Zemra‘s regular wednesday night jam session hosted by Brian Allossery. The meaty stuff starts at about 11 p.m. and I’ll be taking the odd turn until about 12:30 a.m. if you care to drop by. It’s an open mic thing, so if you sing or play, put your name on the list at the bar and let’s jam!

IBM Developerworks has just published my new article “Shaping the Future of Ajax Mashups”, wherein I explain that browsers are still not well equipped to enable mashups that integrate input from multiple sources without falling prey to serious security and/or scaling issues. I then discuss some of the potential solutions to the problem and call for the development community to get involved.

I’m also interviewed by IBM’s Scott Laningham in a short podcast promoting the article.

One good way to get involved is to mix with the top people in the Ajax world – the browser manufacturers, the folks who create the libraries and APIs we use to build our Ajax apps, the big players in the industry. Ben and Dion at Ajaxian have just made a call for speakers for their Ajax Experience 2007 show slated for July 25-27 in San Francisco. Having established some great contacts and communication at the two previous Ajaxian shows, I can tell you without doubt that this is the one Ajax show of the year not to miss. It’s an opportunity to spend a couple of days rubbing shoulders with the people in the industry who can actually influence the future of the tools we use to build and use the interactive net.

Dave Johnson has posted a sample chapter from the upcoming book called Enterprise Ajax, written by Dave and his Nitobi colleagues Alexei White and Andre Charland.

I did the tech review on this book and I can tell you it’s filled with high quality writing and insight taken from some pretty serious experience – Andre and Dave started up EBusinessApps (which became Nitobi last year) at least 5 years ago doing Ajaxy stuff well before it was de rigeur.

The book should come out in early summer – you can pre-order a copy now.

In the post-demo schmooze at Toronto DemoCamp 12 last week, I was discussing Ajax-y things with a few people and I found myself articulating a notion that has been rolling around in my head unformed for a while – that of Javascript as Babelfish.

If you look some of the popular Javascript libraries and frameworks, an important aspect of their design is to make one’s Javascript code feel more like another environment that better suits the application or in which the designer (and ultimately user) is fluent.

• prototype => Ruby
• mochikit => Python
• JQuery => XPath
• GWT => Java

To be precise, GWT is actually written in Java, so it doesn’t fit exactly but continues to demonstrate the trend of people wanting to stay in the environment they understand but have Javascript do the work.

Javascript is remarkable in its flexibility of expression that allows you to apply it to various idiomatic styles. I can’t think of another language that would be quite so accomodating.

Is this trend indicative of Javascript’s power, or the ingenuity of developers who are stuck with using Javascript in the browser when it differs from their environment of choice?

A link from Techdirt to my recent post about the Script Tag Remote Scripting patent has got a lot of comments, mostly variations of the theme “I’ve just patented the definite article ‘the’ – you all owe me a squillion bucks!”.

In case you’re unclear on it, as some commenters seem to be, the point is that this is not just an application, this patent has been *granted*. The patent holders if they so choose can now start wielding injunctive power over those who use this technique.

Of course it’s not quite as simple as that. One commenter with more than a smattering of working knowledge of the patent process points out a couple of useful observations:

Without commenting on the actual validity of the patent, two observations: First, the issued patent claimed priority to a provisional “placeholder” application filed on Dec. 1, 2000 – this means that the patent examiner at the PTO evaluated the merits of the patent application based on what was available before that date. If the examiner did not find evidence that anyone was “doing” what the patent applicants claimed as of Nov. 30, 2000 or earlier, he or she would have come to the conclusion that it was novel. This seems to be shored up since Brent said, “Numerous people have ‘discovered’ and exploited the value in using the script tag to get code and data on the fly since that time.” (emphasis added)

Second, Brent wrote, “It’s an obvious logical use of the functionality for which it was designed.” Apparently, this is where the obviousness assault should have been levied by the examiner. It could be that this is where any successful invalidity challenge in court would occur. Brent correctly notes that the patentee “has the upper hand;” an issued patent is presumed valid and can be found invalid in the face of clear and convincing evidence that it was not novel or it was obvious. This is a tough standard to meet, but note that more than one patent litigation has terminated very early if there is clear evidence of prior art which renders a patent invalid.

So, it could well be that this particular patent will not survive if challenged.

I responded with a comment of my own:

I think the obviousness argument in this case comes down to this:

If the patent process is working properly, the general public’s first understanding of this technique should come from reading the patent itself, since it is the expression of a unique unobvious patentable idea.

The fact that this particular technique is in wide use and has been for 5 years means that either:

a) everyone’s knowledge of the technique has come from the revelations contained in the patent

or

b) it was obvious enough than many other people arrived at the same technique without having been exposed to the patent.

If b), then the patent should be found to be invalid by reason of non-obviousness.

As a person who has taken great interest in this field since 1998, I contend that b) is how it played out.

I had absolutely no knowledge of this patent application until late October 2006, however I had working knowledge of the technique since as far back as 2002, and many people claim to have independently arrived at this technique during that time. I haven’t polled all of them but of the ones I have spoken to, none claim any foreknowledge of this patent.

Let me iterate that I’m not aware of any instances of this patent being enforced against anyone using the script tag transport technique. Again, I’d be happy to hear from anyone who is aware of any such efforts, and anyone who can come up with prior art to go along with the obviousness argument should anyone decide to try to enforce this patent. As Peter Bromberg points out, we wouldn’t want to see this turn out to be yet another patent parking fiasco.

===

Update: the patent attorney who commented as quoted above (Gary Gex from MorganLewis) points out that the patent holders don’t hold injunctive power without a court granting injunction through litigation at which time the patent would be subected to the scrutiny we desire.

After seeing the NTP vs RIM case, where despite the patents being provisionally tossed out by the court, RIM was forced to pay 613 Million, I’m firmly of the opinion that the simple threat of injunction is too often enough to enjoin many a small company from continuing to practice a technique covered by even a phenominally poor but nevertheless granted patent.

Douglas Crockford points out at the top of his blog that a patent was applied for in 2001 and awarded late last year covering using the <script> tag as a remote scripting transport.

Numerous people have “discovered” and exploited the value in using the script tag to get code and data on the fly since that time. It’s an obvious logical use of the functionality for which it was designed.

Of course, once a patent is granted, arguments about obviousness or originality can fall on deaf ears – the patent owner has the upper hand and it could cost you a lot to prove your case in court.

Beyond the obviousness, inspection of both the client and server side code for the patent reveals that most of it is copied directly from my JSRS library, published a year earlier, not only without attribution, but claiming it as their own “NetGratus Remote Scripting”. Of course, my license is very liberal, allowing reuse for pretty well anything, however it does say:

The only thing you can’t do is to restrict anyone else from using it however they see fit. You may not copyright it yourself or change the rules I have set on how it can be used.

So, if you’ve been asked to license this patented technology, I’d be happy to have a look at the particular code being offered for licensing and see whether it violates my copyright by restricting you from using it without a license.

Also, as Danne Lundqvist, veteran script tag advocate points out to the latest person who has independently had the script tag revelation, there are many reasons that the script tag is an inferior transport layer, not the least of which are the security implications as I pointed out just this week

The upshot is this: the script tag hack’s days are numbered. If you can change to XMLHttpRequest while waiting for JSONRequest, by all means do.

It’s rather ironic that the appearance of this patent will have had exactly the opposite effect that a patent should: Rather than the patent informing the world about a hitherto unknown invention, explaining its workings and contributing to the furtherance of knowledge, the patent in this case informs the masses of people who came up with the same obvious idea that they had better stop using this technique in order to reduce their liability regarding the injunctive power of the patent holder.

As I said in my last post, the current browsers were not designed with mashups in mind. The current methods in use to make mashups work result in either overly restrictive or overly permissive security issues.

Take XMLHttpRequest – calls are limited to the server where the current page originated. Can’t mash up without proxying through the server. Doesn’t scale well.

Take iframes – you can embed a page from another site, but due to Javascript same-domain restrictions, you cannot communicate with that page without some quite obtuse hackery on which you’d like to avoid relying.

Take the script tag – you can execute code from another site, however you have no opportunity whatsoever to inspect it for security before it gets executed, meaning there must be a lot of trust in the other end of the transaction and no hope of avoiding man-in-the-middle attacks. Using script tag methods, cross-site cookie access can cause privacy issues. Insecure, undesirable.

What we need is browser features that were designed with mashups in mind. We need them to be added to the browsers without having to wait until IE8 and Firefox 3 (…Safari 3, Opera 10, etc).

Douglas Crockford has a set of proposals that begin to give us an answer to this dilemma. He proposes:

• JSON – a lightweight data-interchange format
• JSONRequest – a Javascript object designed to exchange JSON-formatted data flexibly, efficiently and securely
• the <module> tag – an addition to HTML to create secure zones from multiple sites on a single page with controlled communication between them

JSON support is already on the way to being built into Javascript.

The main browser vendors are aware of JSONRequest and have begun talking about it together.

Douglas only recently proposed the module tag, and we as developers need to help the browser vendors to understand that we want to build secure mashups, so we want them to discuss amongs themselves and with ECMA and W3C how this proposal or any other will help us to do that.

Do your part to get involved with organizations like the OpenAjax Alliance to promote advances like the ones Douglas proposes.

I’m just starting to settle back in after getting back from last week’s Ajax Experience show in Boston. It was a great conference, with superb speakers, fantastic swag, and lots of really interested and interesting attendees. I was extremely pleased that my friends Pete Forde and Joey deVilla came along not only as attendees but to participate wholeheartedly at every turn. Toronto’s vibrant tech community was well represented by our collective presence.

When I attend these shows, one of my main objectives is to seek out people in influential positions who can work together to effect advances in the state of the art and to put them in front of each other in the hopes that some strides can be taken in a fruitful direction. I was really pleased to have had some success in doing that this past week. It’s not that these things wouldn’t happen without my being a meddling matchmaker, but I like to think that as an independent without ulterior motives I can help to accelerate the relationship building process.

One of the biggest challenges in the Ajax world is that the whole “data channel back to the server” piece doesn’t support mashups well. The solutions that support cross-domain access do so in limited or insecure ways, and the solutions that can be made secure or that afford superior control lack cross-domain access. The parts of the browser that we have used to perform these tasks were designed either for entirely different purposes or for subsets of what we now want to do.

Douglas Crockford is well known in Javascript circles. He has an uncanny ability to distill complex concepts and, using a remarkable economy of expression, present them in such a way as to be simple to understand.

In his first talk at the show, Douglas offered a series of proposals that together would enable developers to build mashed-up applications that are secure and robust. The key would be to get the browser manufacturers to implement support for JSON, create a new JSONRequest object, and introduce a new <module> tag (see Doug’s module proposal: it would provide compartmentalization of secure zones from multiple sites on a single page with controlled communication between them).

Even if Douglas’s proposals don’t end up being the solution to these problems that is implemented , I believe that he has provided the most comprehensive place to begin discussions towards fixing up the browser to be a place that was purposefully designed for mashups.

My small part in helping to kick this into gear was to get some of the players involved to socialize and begin to discuss common goals in these mashup issues.

I found myself talking on Tuesday afternoon to Sunava Dutta, the program manager on the IE7 team responsible for the native XMLHttpRequest object. I invited him to have dinner at our table and also got Brendan Eich (Mozilla Foundation) and Douglas Crockford to join us. Nothing of import came directly from any dinner discussion, but hopefully the seeds are sown for some great interaction.

As Douglas observed on the expert panel later that evening, the web development industry has been turned on its head in comparison to the early years. Whereas originally the browser makers drove the browser feature set and imposed it on the public, the web development community is now ahead of the browser providers in demanding features to support innovation. Our collective voices can influence them to improve the browsers to suit our needs.

I’m really looking forward to the next Ajax Experience (which should be in San Francisco in April I understand) to see how far along these initiatives have come. Ben Galbraith and Dion Almaer from Ajaxian and Jay Zimmerman of NoFluffJustStuff all deserve accolades for making this show perhaps the most important venue of the current web lifecycle by attracting both the elements and the catalysts necessary to build the brightest future for web applications.