JSON-Enabling your Web-Application: Tread. Very. Carefully.

None of what follows is new. Many issues below stem from recurring tempting circumvention techniques of cross-site data-loading security policies that were put in place by browser vendors a very long time ago, for very good reasons.

So you've created a very elegant and easy to maintain Web Application, perhaps leveraging some MVC patterns.

Your Controllers may be mapped to URLs such as these:

• FavoritesController: list() and view(int id) methods:
  
  
  1. /favorites/list
  2. /favorites/view/1
  3. /favorites/view/2
  4. ...
• SomeOtherControllers following similar patterns

Your web-based application works pretty well and features a decent amount of no-nonsense better-practices among which you might find: user account creation with e-mail verification and CAPTCHA, md5-hashed password authentication against a large salt unique to each user, it's devoid of very obvious SQL-Injection vulnerabilities because you're using a decent database abstraction layer, you're not allowing users to post unchecked input so you're not feeling too vulnerable to obvious XSS Attacks, you've avoided using non-idempotent RESTful URLs so you're less vulnerable to insanely obvious CSRF Attacks, but you're clearly not stopping there, by requiring all transactional HTTP POSTs to send a non-guessable and unique session-lived token as a parameter.

At this point you're pretty confident that a determined cracker will actually have to do some work to mess with your application to uncover any sensitive data it may have.

Then you get ready to Go Mobile. It only makes sense: you have a compelling application and you wish to offer your users a compelling extension of your application to their Mobile Universe, while creating additional revenue opportunities. Everybody wins.

As a design team starts putting together mock-ups of the handheld experience, which may take quite a few weeks, you realize that regardless of what they come-up with, the handheld application will almost certainly need to exchange data with the web-based application. So you figure you might as well start exposing web services to cater to various use-cases.

Your MVC stack looks neat, and now just plain screams for exposing a JSON interface to most of your Controllers. It only makes sense. Once you're done, you can send the API to the Objective-C/Java Developer who'll be building your mobile apps for Blackberries, iPhones and Droids.

So you rig your controllers to become "json-aware": instead of only being able to output HTML, you're now also able to send a JSON payload:

• FavoritesController: list() and view(int id) methods:
  1. /favorites/list/json
  2. /favorites/view/1/json
  3. /favorites/view/2/json
  4. ...

Before doing any of this, STOP and realize this:

JSON is valid JavaScript. Valid JavaScript can be loaded in a good ol' HTML script element through any site on the Web directly from your site. Whatever your script returns, such as a list of an authenticated user's favorites, is more or less fully-accessible to any other script running on that foreign document.

Forget your Handheld/Mobile project for a second as this isn't the vector of the gaping vulnerability you've just created:

Consider http://evilsite/somebadwebpage.html with the following line of code: <script src="http://yoursite/favorites/list/json"></script>

If evilsite manages to lure some of your users, perhaps thru some crafty social-engineering sprinkled with bit.ly obfuscation, they're now in a position to capture a victim's favorites.

If you're going the JSON route, you might consider the following simple techniques:

• Require a completely separate authentication handshake for your JSON services, they should not function if a user happens to be "authenticated on the site" while browsing from their desktop.
• Wrap your JSON payload in a light XML enclosure: it'll be enough to make browsers barf on a JavaScript parse error should someone try to reference your JSON URI in their web document.
  

  <data>{jsonpayload}</data>

  
  Don't go loading a full XML/DOM parser, just substring/indexOf/lastIndexof your way to the JSON payload.

iPhone: Apple's VoIP End-Game

Update 01/2008: SIP-based VoIP on the iPhone has been coming:

• TouchMods Microphone and SIP Client

---

When Steve Jobs first demoed the iPhone in January 2007, he made it clear that reaching someone by typing their phone number onto a keypad was no-longer acceptable, albeit tolerated. Instead, he showed an Address Book interface that unifies the concept of a "Person" across all forms of communications on the iPhone, be it iChat, e-Mail, or a Normal Phone Call. Since version 10.2, Mac OS X has pushed Address Book integration across disparate Applications to unify the concept of a "Person", and iPhone simply builds upon the same philosophy.

While an "Address Book" seems as trivially simple a concept as it isn't new to anyone who's used a mobile phone within the last decade, seeing it executed "The Apple Way" in a larger synchronized ecosystem, helps paint a picture of possibilities that lie ahead.

Picture unlimited free calls over WiFi/IP without even having to "think about it", by simply picking a Person from your Address Book, and hitting "call" ... The same way you'd make a Normal Phone Call. All this powered behind-the-scenes by an outstandingly executed convergence of enabling technologies and open-protocols.

E-Mail addresses define a universal mechanism for a message to make its way into our INBOX, regardless of who provides the sender's E-Mail service. E-Mail functions on-top of open and interoperable standards. As such, there is vibrant competition to obtain "E-Mail Service".

Wouldn't it be nice to enjoy the same type of competitive and interoperable landscape when it comes to actually speaking to and video-conferencing with people? Beyond those silly phone numbers controlled by a handful of phone companies, what if we could pick from a myriad of competing "Providers" to obtain a global address allowing people to "call us" over the Internet, regardless of who their "Providers" are?

This is where SIP comes-in. It's been around and used on computers for a while, but it's been waiting for the right combination of enabling devices and software to truly break onto the handheld mainstream.

iPhone, with its WiFi capability, Address Book integration, and advanced operating system, is getting us one step closer.

A SIP Address looks just like an E-Mail address. A Person's SIP Address could easily be stored in the iPhone's Address Book. Apple could build SIP-capability right into the operating system, pre-configured with a number of existing SIP Providers for one-click setup, while still allowing for custom configuration, following a model very similar to E-Mail.

There are a few SIP Providers out there. But Apple could easily roll out its own SIP infrastructure as part of the .Mac framework, increasing their chances of providing a superior out-of-the-box experience, while promoting the .Mac brand to ... competitive usefulness. From here, the sky's the limit as to what Apple can do, leveraging iPhone's brand and near ubiquitous and still increasing WiFi penetration. Forget about fighting over 3G vs GSM. WiFi and IP are universal world-wide.

SIP call quality can be vastly superior -- think CD quality -- to a Normal Phone Call, as it strives to remain pure data exchange over the Internet Protocol on broadband connectivity, without ever getting wedged thru the codec limitations of any Normal Phone System.

When calling somebody, the iPhone could detect whether WiFi connectivity is available, and whether there is a SIP Address for the person i'm looking to call. If both these conditions are met, the iPhone could perform a "pure SIP Call" over the Internet, without ever touching the carrier's or any phone company's network. Blam. Free call. An icon might indicate to me that this call is a free, un-metered Voice-over-IP call.

Even if the person i'm trying to call doesn't have a SIP address, some SIP Providers offer the ability to relay calls to the Normal Phone System (aka PSTN in industry jargon), at substantial cost savings for unlimited plans, at which point all the iPhone has to care about, is that WiFi connectivity is present.

In terms of user experience, I wouldn't do anything differently: I'd pick the person I'm looking to call from my address book, and push the "call" button. What's behind-the-scenes is magic-sauce I, as a user, don't care about beyond vaguely knowing that the iPhone picked some Internet-WiFi thingie to save me money, and some icon is telling me I can keep talking for as long as I want.

Update 6/21/2007: As pointed out in comments below, WiFi+VoIP on "phones" aren't new, and carriers have somehow "dealt with it". Even if Apple further blurs the line between VoIP and Normal Phone Calls, there are still profit incentives and competitive market pressures that may very well entice AT&T to embrace VoIP.