JSON and the Quest for the Javascript-friendly Feed

Submitted by User ProfileRob on 12:54am, Wednesday, 2006-02-01
Johan and Jeff have started a discussion on the relative merits of JSON/JSONP. I think it's time I threw my two bits in. There are a couple compelling features of JSON as a format to Javascript coders (I count myself in here). Johan talks about getting around the same-origin policy. I understand the frustration, but I feel uncomfortable opening the door for someone else to execute whatever code they deem fit on my visitors' browsers. I know they're not supposed to, but the can. It's a lot of trust. It's true that Javascript executes in a sandbox, but the code in question doesn't have to be intentionally "bad" as Jeff implied. It could be accidentally bad code. Accidentally bad code happens a lot more often than intentionally bad code. It can be worse because it's Accidental. Accidentally bad code can excersise memory leaks or any other bugs in a browser. I'm not saying that I write better code than everyone else, just that I can debug more easily if it's all served from my site. Mixing code and data makes things tougher. Not that we haven't already gone pretty far down that road. After all, Javascript in a web page is executable code mixed in data. That said, JSON is clearly a simpler format to process on the client side for JS engines that are not inherently XML-aware. This is changing with support for XPath showing up in browsers, so JSON might be a shortcut for now. As a content-provider, it looks pretty simple to create a JSON feed from an existing XML feed, so I've got no issues with supporting it that way. Well not at first glance. Then again, the feed isn't guaranteed to be valid Javascript syntax though if I don't test every feed with a Javascript parser. If I'm doing that and the client also has to validate what I've sent them then suddenly we're both doing a lot more work. What's more, if users start throwing in references to their own scripts that the server producing the feed can't see, then how can the server possibly guarantee a valid feed? That's the problem with formats that look easy. Most of the time they end up needing some kind of patching later that starts quickly to look like a kludge. JSON's not the first place this has shown up, just the latest. I mean PHP has had plenty of growing pains and broken plenty of existing code in order to get more secure default behaviour in place. Things like register_globals and the ability to reference a variable without defining it first are places that PHP used the normal behaviour for a script, but that normal behaviour caused big security issues when the language was used to build huge applications. And don't even get me started on the nightmare of escaping script embedded in text embedded in XML embedded in PHP. Each of those started as an idea to make things simpler and more readable. When shorthand syntaxes like JSON crop up it indicates that developers feel that there's too much overhead in dealing with the predominent formats: Atom and RSS XML feeds. Someone could have come up with an equivalent PHP syntax. There's as much PHP code handling XML out there as there is Javascript handling XML. PHP has an eval() function analagous to Javascript. PHP supports associative arrays and objects. Why not feed my PHP script with PHP code? I don't know the answer for sure, but I'd guess that it has to do with the fact that PHP has an established method (well, many established methods) for handling XML. JSON just seems to be a request for data that's easier to parse. My answer? I guess I believe in proxying on my own server and getting the data ready for my clients in some Javascript that's easy to run.
0
Your rating: None
At 1:57am, Wednesday, 2006-02-01, Jeff Schiller said:

"When shorthand syntaxes like JSON crop up it indicates that developers feel that there’s too much overhead in dealing with the predominent formats: Atom and RSS XML feeds."

I don't think JSON was created to take the place of RSS/Atom at all. Either the term "feed" confused you or I'm confused. JSON is just another means of encoding data and it's the simplest way possible for a JavaScript client end since it's already in the format of the code language. No parsing required.

And you CAN feed your PHP code with PHP code, use the "include" command :P

At 3:10pm, Wednesday, 2006-02-01, Rob said:

Include or eval or a bunch of other methods. My point is that people don't send out data as PHP script-encoded objects.

I guess I'm talking about JSON specifically as an alternative to RSS/Atom, which it is in the case of some Yahoo services. It's one option for a feed format, not the only one.

The thing is, JSON was initially introduced as a format for supplying data. The fact is that you're actually evaluating that data as Javascript code to get stuff out of it (assuming you're using it in a Javascript app). Since (with a feed) you're actually executing any code that's sent to the browser, anything that shows up in that feed will be run - whether it's what you expected or not.

At 10:03pm, Tuesday, 2006-02-07, Bob Ippolito said:

The security models for JavaScript and PHP are very different. JavaScript already lives in a sandbox. The worst you could do is resource consumption or a browser crash.. and browsers already have defenses against those sorts of "attacks". Though not perfect, it's improving over time.

It's unfortunate that the only way to deliver content without a proxy is to transmit code, but it's not a deal-breaker for most scenarios. I trust Google, Yahoo, etc. to Not Fuck With My Users.

It is somewhat hypocritical that you're criticizing the same mechanism that you're using to make money off this blog. Google's Adsense would not exist if it weren't for different-origin script tags...

At 12:19am, Wednesday, 2006-02-08, Rob said:

I consider resource consumption and browser crashes for my visitors to be a problem.

It's obvious that I trust some companies enough to serve ads, which are arbitrary code. I think it should be pretty clear from the post that I'm unsettled by the idea of the mechanism, but I'm not against JSON just because it's not XML.

I don't trust a company to obey the NFWMU policy just because they're large. I'm also uncomfortable with the barriers that raises to small companies - delivering executable content directly to my users requires more trust and it's therefore is tougher for a small company to get started.

Then there's the issue of providers supplying invalid code or data. At least if it's a feed of just data then I have an option to preprocess it on the server side and ensure my page will be valid.

With the situation we already have today, it's futile to try to make a page with adverts that validates. You can't guarantee the code you have to insert validates. I posit that JSON makes this problem worse and not better.

I don't need Adsense to use different origin script tags, I need a mechanism to serve advertisements (I could generalize further but let's assume ads are a given). If the deal says this is the method that I use, then that's what I use. If I could do it server-side and make things more simple and secure for my users, I'd do that.

I'm just being objective, if I'm guilty of problems that I find, then I'm guilty. There's no special blogger jail, is there?

At 3:37pm, Wednesday, 2006-02-08, Jeff Schiller said:

Rob, I agree with your points, except I didn't understand your point about validation. JSON doesn't make validation any easier/better, but I fail to see JSON makes validation worse.

At 6:12pm, Wednesday, 2006-02-08, Rob said:

On validation, I mean that today we have html code from many advertisers that may or may not validate. The javascript code that's used today may raise errors in some browsers because it's not valid.

With Javascript I'm using the more general sense of the word "valid."

In the original post I meant that with a JSON formatted feed, as a feed producer or repeater, it's more difficult to be certain that I'm serving working Javascript if people can add their own callbacks to it.