Just got back from a week of Snowboarding

I just got back from 5 days in the Snow at Mt Hotham in Victoria. Despite the weather forecasts looking like complete arse all week, we got to ski 4 days out of 5 which is not a bad for Australia. Only friday let us down with bucketing rain and howling wind. Given we were due to head back to Melbourne on Friday anyway, we packed it in and headed back early.

One of these days, I'm going to go to a country with real snow and find out what Snowboarding is really about :)

Why is requesting resources from other hosts such a big problem in Javascript?

Recently, I found out that Yarra Trams has published a web service interface for finding out information on tram arrival times. This is awesome, and I've been trying to think of cool little apps that I can write to take advantage of it. As I'm also playing with GWT at the moment, so perhaps I could do something that way... There is a problem however, in that the Same Origin Policy will block any attempts by my javascript code to access the webservice, as it will come from a different origin.

There's a couple of things that I could do about this:

1. Ask Yarra Trams if they could host my work, but that kind of defeats the purposes of a mashup, doesn't it. Plus, to be honest, the chances of me ever coming up with something that they would want to host are minimal :)
2. Write a proxy service that I host myself, and send any requests through it. This kind of seems pointless, as there is already a perfectly good webservice out there that I can use. Besides, if what I wrote ended up becoming popular, I'd be up for a bandwidth bill for all the traffic to the web service.
3. Try and convince YarraTrams to use a cross site friendly interface, such as is provided by google data. Fat chance of that happening. Besides, there's nothing wrong with web services. This callback based approach seems like a hack, probably because it is.
4. Use a new HTML5 extension called CORS which allows for fetching resources from other origins.

The first three options all are really really nasty. The fourth solution seems like it is perfect. It is specifically designed to allow for fetching resources from differing sites. It requires the destination server to include a header however that specifies what external domains are allowed to access it however, so it still won't work for me :(

I've been thinking about the SOP restrictions and how CORS works, and I must admit I'm confused. The restrictions that it places on requests just seem too over the top. I understand that it is important to stop XSS attacks, but there should be a way for the javascript programmer to explicitly state that (s)he understands the risks and he promises to treat the requested data as potentially dangerous so that he can use it. To require any form of server side change means that almost all mashup style applications can't operate correctly.

To come back to my example, if I want to perform a POST operation to a Web Service, which returns XML, which I then parse and use as data to, say, plot on a map, I can't see any security problem with allowing me to make a XMLHttpRequestObject request to go do exactly that. If I were to eval() the result, I could potentially open up my application to XSS attacks, but I'm not that stupid.

Now perhaps I haven't spent enough time thinking about this, but I don't see why we can't have an override flag on the XMLHttpRequestObject to allow us to disable the SOP for an individual request. That would give me the flexibility to decide where I want to perform an unsafe request and take the appropriate steps to make sure I don't get burned by the results. Perhaps the security experts out there can educate me as to what I've missed.

Google Apps allows for custom SMTP servers

I've been using my google account to store mail for a while now, including forwarded mail from client organisations, where this is allowed. The only problem that I've had so far is that when I'm sending mail as another identity (like a client one), it would always come up as "from me@brucecooper.net on behalf of me@the.right.domain" Its a bit annoying, but thats what Google had to do in order to be good email citizens and not get everything marked as spam. As it turned out, many Exchange servers automatically mark such email as spam anyway, so some people lost mail that I sent them.

Google recently introduced a new feature, whereby you can specify your own SMTP server to use when sending mail, and you can specify a different one for each identity. This is great, as you no longer get the on behalf of bullshit, and your mail doesn't get spammed any more. I was originally stumped by the fact that I couldn't get to the SMTP servers of the organisations that I wanted to send mail from, but then it dawned on me that I could use any SMTP server that would allow me to relay mail as other identities. I used my ADSL provider and all is good. Of course, if the organisations that I'm sending mail as had SPF rules set up to disallow this sort of stuff I'd still be in trouble, but so far that hasn't been a problem.

TramTracker has a Web Service!

I'm a fan of the TramTracker iPhone application. Its a little doohickey that fetches information from Yarra Tram's real time tram arrival service to tell you when your next tram will be coming. Having used it a lot over the last couple of months, I wondered last night how the app got its data. What service did it contact to fetch the data.

So I hooked up a logging proxy to my iPhone and traced the calls it was making. Turns out, TramTracker has a fully functioning and documented Web Service just sitting there begging to be used by people. I'm now trying to think of what other nice apps could be made. My first thought was an Android version of the TramTracker application, but that's just a clone (plus I don't own an android handset)... How about a dashboard widget? Oh, turns out there already is one! Its good to see that there is a qango out there that is doing its IT right for a change...

What other sorts of mashups could we make? One other thought I've had is making a Google Transit datasouorce from this information, but I suspect Google is already talking to Yarra Trams about that.