Tatham Oddie

Update 1, 1:20pm: I’m moving to Internode. After consulting with Twitter, @corneliu and @DavidBurela both suggested Internode. @snagy suggested a T1 complain with the communications ombudsman. iiNet – you will be hearing from me soon to start processing my cancellations. Don’t even dare charging me for the last 6 weeks of anti-service.

Update 2, 3:55pm: After emailing this link to the iiNet MD, I rather quickly got a phone call. Lets see how this gets handled … I’ll keep you all posted.

Update 3, 6:05pm: Telstra tech booked to investigate Exchange problem. Target resolution date is tomorrow. Although apparently there’s also a major disruption at the moment that could delay my resolution.

Update 4, 9:24am next morning: Internet resolved. Turns out the MD had passed my request to the “Business Improvement Team”. They said that they’ve read the points below and will take them onboard in their next monthly review cycle. I genuinely tried all the proper channels, but when that failed I changed tact. Never underestimate the power of Twitter, a blog and the odd email to an MD.

I’ve been a passionate iiNet customer for 2.5 years now. I’ve paid almost $12,000 across my multiple contracts, and recommended them to countless customers. (I signed another one up just last fortnight.)

Unfortunately, they have quickly become just another character in the tale of organisations that failed to scale. Nobody cares anymore. Nobody listens. This used to be what they were great at.

In the six weeks since I moved in to my apartment I’ve had 1 week of internet.

I acknowledge that ADSL is a flakey technology at the best of times, but the one month rigmarole to get connected could have definitely happened faster. This was a one-off pain though, so that I accepted.

A week after getting up and running I lost line sync at 10:50am on the 17th May. That’s 10 days ago now.

We have agreed that it’s not my modem – I’ve tried two. We have agreed that it’s not a problem between my wall socket and my MDF – that was inspected during the first internet hiatus. We have agreed that it’s not a problem between my MDF and the exchange – through a combination of Vision Stream and Telstra we also resolved this during the first internet hiatus. Finally, we agreed that the problem is my with DSLAM port at the exchange.

You’d think with all this information they could have fixed this by now.

Their engineers did go out an investigate the problem, and fixed something. They then closed the fault. Did anybody call me to check if it was actually resolved? No. Was it actually resolved? No.

My fault has now been lodged four unique times. I have four different fault reference numbers. I have had to explain my problem eight times now to eight different CSRs (Customer Service Reps).

From an organisational perspective, this could be solved relatively easily:

1. Introduce a new state of “Complete – Awaiting Verification”. This does not mean “Closed”.
2. Send customers and SMS when their fault enters the “Complete – Awaiting Verification” state. A message like, “Your fault, 44564172 is now complete but waiting verification. Please call 13 22 58 within 24 hours if your problem continues.”
3. Introduce a new state of “Reopened – Resolution Denied”.
4. If a customer responds to the SMS to say that they are still experiencing the problem, move the fault to “Reopened – Resolution Denied” instead of opening a brand new fault.
5. If customers do not reply within 24 hours, allow the fault to automatically progress from “Complete – Awaiting Verification” to “Closed”.
6. Prioritise the fault resolution queue by lodgment date. This means that if a fault is reopened 5 days after it was lodged, it is still considered to be 5 days old. The current processes consider it as a new fault and prioritise it accordingly (ie. not at all).

If my fourth fault is once again closed without actually being fixed, it will be time for me to say goodbye to iiNet. So long, and thanks for all the fish.

Being an Outlook addict, I’m always pleased when I see an “Add to Outlook” or “Download as ICS” button on a website. Everyone from Virgin Blue to Facebook do it.

Unfortunately there was no such file for Remix so instead of just loading it into my private calendar, I thought I’d make the ICS feed.

Here they are:

http://tatham.oddie.com.au/files/RemixSydney.ics

http://tatham.oddie.com.au/files/RemixMelbourne.ics

See you tomorrow / Thursday!

Update 21/5/08: Just in time for tomorrow, I’ve added the room assignments to the Melbourne file.

I know where I am. My phone knows where it is. Why doesn’t the webpage know where I am?

Think about these scenarios which will become more and more prominent as “the mobile web” starts to prevail:

1. I visit a cinema website on my mobile. Rather than having to choose my cinema first, the website already knows which suburb I’m in so it defaults to the nearest cinema first.
2. I need a taxi. I don’t know where I am, but my phone does. I want to be able to book a taxi and have the website discover my location automatically.

The key idea that I’m exploring here is the ability for a webpage to access this information through the standard browser interface.

I have a plan for making this a reality.

Windows Mobile has already taken a step towards baking location awareness into the OS with their GPS Intermediate Driver. The idea is that the operating system handles communication with the GPS unit, including all the various protocols. Applications then have a unified API for accessing GPS data. This proxy effect also facilitates non-exclusive access to the GPS.

But this doesn’t go far enough. Even with this unified API, very few applications are actually location aware. More importantly, I don’t want to have to download and install a piece of software on my device just to be able to see movie times. It’s just not going to happen.

We’ve also been making the assumption that location data comes from a GPS. Enter GeoPriv.

With the continuing rollout of VOIP, there are obvious challenges about the loss of location awareness. The current analog network makes call tracing relatively easy. It’s a fixed line of copper and the phone company knows where it terminates. This is a legal requirement for emergency call routing, as well as being immensely useful for scenarios such as a national number auto-routing to your nearest local store. Both of these scenarios become immensely difficult when you can’t even rely on there being a physical phone anymore – a piece of software with a network connection is now a fully fledged communication device that needs to support these scenarios somehow.

There’s an IETF working group tasked to solve this exact problem. The privacy impacts of sharing location data are so important that it’s in the name. They are the “Geographic Location/Privacy working group”, or “GeoPriv“. The best part is, they are living in a reality and delivering useful technology – and fast.

There are a number of key concepts they have identified:

• We can’t go jamming a GPS chip in every single device we manufacture. We need to be able to capitalize on the ecosystem surrounding our existing devices to surface the information we already have.
• Privacy is a critical element of any solution expecting wide spread adoption and trust.
• There are two possible types of location you could need:
  • civic location (level, street number, street, suburb, etc)
  • geographic location (latitude, longitude, elevation)

Lets step away from mobile devices briefly and consider the laptop I’m writing this post on. My laptop doesn’t know where it is. Neither does my WiFi router, or my DSL modem. My ISP does though.

At some stage in the future, my modem will start receiving an extra DHCP option. In the same  way that my ISP supplies me with network settings like DNS when I connect, they will also start pushing out the address of their Location Information Server. My DSL modem will then push this setting out across my network. Finally, my laptop will be able to query this service to find out my current civic and/or geographic location. The privacy controls around this are beyond the scope of this post.

By asking the service provider for the information, these same techniques also works for mobile devices, 3G data connections, and all those other wonderful wireless technologies. Cell-based triangulation is already in use by phone companies around the world, including our national carrier here in Australia, however the interfaces are in no way standardized. The Location Information Server (LIS) and the HTTP Enabled Location Delivery protocol (HELD) solve this problem.

Now that our device is capitalising on the network ecosystem, getting it into the browser is the easy part. All that’s left is a thin veneer of JavaScript.

Location awareness is only becoming an increasing demand. I want to start the process of rolling in the JS layer now, so that as the supporting technologies come to fruition, we have the access layer to make them useful.

Inline with the XMLHttpRequest object that we’ve all come to know and love, I’ve started writing a spec for a GeographicLocationProvider object.

With XMLHttpRequest, we can write code like this:

var client = new XMLHttpRequest();
client.onreadystatechange = function()
{
    if(this.readyState == 4 && this.status == 200)
        alert(this.responseXML);
}
client.open("GET", "http://myurl.com/path");
client.send();

I want to be able to write code like this:

var provider = new GeographicLocationProvider();
provider.onreadystatechange = function()
{
    if(this.readyState == 2)
        alert(this.geographic.latitude);
}
provider.start();

Again, usage is conceptually similar to the XMLHttpRequest object:

1. Initialize an instance of the object
2. Subscribe to the state change event
3. Set it free

The potential states are:

• STOPPED. This is the state the the object is initialized in, and the state that it returns to if stop() is called.
• RESOLVING. The object has been started, but not location information is available yet. In this state the browser could be:
  • prompting the user for permission,
  • searching for location sources (like GPS hardware, or an LIS endpoint), or
  • waiting for the location source to initialize (like connecting to satellites, or talking to the LIS)
• TRACKING. A location source has been found and location data is ready to be queried from the provider.
• UNAVAILABLE. No location data is available, and none is likely to become available. The user may have denied a privacy prompt, their security settings may have automatically denied the request, or there may be no location sources available. It is possible for the provider to return to the RESOLVING state if a location source become available later.

In more complex scenarios, the provider can be primed with a specific request to aid in evaluation of privacy policies and selection of location sources. For example, browsers may choose to hand over state-level civic location data without a privacy prompt. This data could also be obtained from an LIS, without needing to boot up a GPS unit. If the webpage requested highly accurate geographic location data, the browser would generally trigger a privacy prompt and boot up the most accurate location source available.

While we’ve now simplified the developer experience, the complexity of the browser implementation has mushroom clouded. How do we reign this in so that it’s attractive and feasible enough for browser implementers? How do we demonstrate value today?

You might have noticed that in my discussion of the JS layer I drifted away from the GeoPriv set of technologies. While any implementation should be harmonious with the concepts developed by the GeoPriv working group, we aren’t dependent upon their technology to start delivering browser-integrated location awareness today.

There are numerous location sources which can be used:

• Statically configured location – with the network fingerprinting technology already in Vista, it would be relatively easy to prompt users for their civic location the first time location data is needed on a particular network.
• GPS Intermediate Driver – already rolled into the Windows Mobile platform.
• Location Information Servers – can be added to the mix later as LIS deployments become prevalent. This is the only one that is GeoPriv dependant.

The civic and geographic schemas have already been delivered by the working group as RFC 4119. There has been an incredible amount of discussion involved in developing a unified schema that can represent civic addresses for anywhere in the world, and this schema should be adopted for consistency. (Do you know the difference between states, regions, provinces, prefectures, counties, parishes, guns, districs, cities, townships, shis, divisions, boroughs, wards, chous and neighbourhoods? They do.)

Who is responsible for delivering this unified location layer?

I keep talking about the browser being responsible for managing all these location sources. Other than the JS layer, all of this infrastructure is client independent, so why don’t we just make the browser a dumb proxy to a unified location service. This service should be a component of the operating system, accessible by software clients (like Skype) and webpages via the browser proxy.

Windows Mobile has already started in the right direction with their GPS Intermediate Driver, however this is only one element of a wider solution.

What do I want?

1. I want to see a “Location” icon in the settings page of my mobile device, the Control Panel of my Vista laptop and the System Preferences panel of my Mac.
2. I want the browsers to expose the GeopgraphicLocationProvider object for JS clients. (The start of this specification is online now already.)
3. I want the browsers to proxy location requests to the operating system store, along with hints like which zone the website is in.
4. I want the operating system store to be extensible, implementing its own provider model which allows 3rd party developers to supply their own location data from software or hardware services as new discovery mechanisms are developed. We shouldn’t have to wait for widespread adoption before sources are surfaced into the store, and this should be open to software developers as well as driver developers.
5. I want the operating system store to be accessible by any application, including 3rd party browsers.

How am I going to make this happen?

Dunno.

Right now, I’m documenting the start of what will hopefully be a fruitful conversation. Participate in the conversation.

At CodeCamp I caught up with ShaneMo quickly to talk about my upcoming Remix session.

I just got an email from Microsoft a few minutes ago about their launch of the MS Press store here in Australia – www.mspress.com.au.

Best of all, for the month of May we all get 50% off! Just use the code MSPLIVE0508 when you checkout.

If you provide some feedback about the site you go in the draw for an XBOX 360.