Mike Rowehl: This is Mobility

There are a few interesting things going on with “carrier networks” on the whole that have had me wondering about how folks at the carriers/operators can be so painfully dense. There’s the problem with Sprint deploying a proxy transcoder and expecting folks to get whitelisted to not be adapted instead of using standards, stunningly similar to the Vodafone issue which has already been replicated with TeliaSonera. And I have an issue that hits more close to home, my startup company Mowser is apparently subject to some access restrictions on the 3 network in the UK which apparently do not apply to Google or Yahoo.

The common response to issues on these network is that standards be written up to specify the behavior so that carriers stop doing it. I’m going to have to cry bullshit on that one. While listening to a talk by Tim Bray from Rubycon I learned there’s a document up describing the overall architecture of the world wide web. How convenient.

A quick look through the document shows where carrier networks already diverge from published recommendations. For instance take a look at the very first section after the introduction:

In order to communicate internally, a community agrees (to a reasonable extent) on a set of terms and their meanings. One goal of the Web, since its inception, has been to build a global community in which any party can share information with any other party. To achieve this goal, the Web makes use of a single global identification system: the URI. URIs are a cornerstone of Web architecture, providing identification that is common across the Web. The global scope of URIs promotes large-scale “network effects”: the value of an identifier increases the more it is used consistently.

Well when you whitelist and blacklist sites at the network level guess what you’re doing? You’re segmenting the URI namespace based on your access network. Depending on where you are and how you’re accessing the network you might or might not be able to access a resource. And when a transcoding layer is introduced for all requests through a network independent of source link structure, you’re having the network make a decision to change the semantics of a URI, selectively mapping a whole chunk of URIs to other resources. Leaving aside the whole other issue of the general Internet principle of the intelligence for any given set of protocols being at the edge of the network instead of the core, this also conflicts with the overall principle of consistent global identification.

We’ve already had decades to understand and refine the proper functioning of the Internet, and there’s already a tremendous body of work laying down and describing how to replicate and interact with it. But carrier networks continue to break the most basic and fundamental principles when there seem to be obvious and simple alternatives to get to the same goals. I strongly doubt that yet another standard will do anything to help.

Almost all of the Mobile Web docs out of the W3C that I see reference the base W3C architecture description base document like the one I was just looking at. Yet still they go ahead and define something like “in network adaption” when talking about best practices. Best practices on the Internet say that no application decisions should be applied between the two communicating endpoints. Full stop. It’s just incorrect behavior.

Unfortunately nothing really seems to be affecting these folk’s decisions to do things that are disruptive, limiting, and destructive to the long term environment. You can always vote with your feet though. If I were on Sprint I would switch off their service, same thing definitely for 3. It normally only takes a few people switching off and giving the reason of “I can’t access the web sites I want the way I want” for their customer relationship systems to form the correlation and realize it’s an actual problem. I’ll help maintain a list of carriers not to use if you care about the mobile web also, cause people might be more likely to form their decision going into a purchase rather than after they already have things up and running. So here’s my list of carrier not to get service from if you care about the mobile web:

• Vodafone UK and Portugal
• 3 UK
• Sprint

If there are others let me know in the comments.

Thanks to Russell for pointing out that a new set of MMA guidelines is up for review. Apparently I’m supposed to post feedback in their public forums, but I’m getting a bit tired of having to follow discussions in other places. So I’m posting my feedback in my public forum, just like they posted their recommendation on their site. Just seems proper.

As soon as I read Russell’s post I thought “Yay! Finally some structure around an accepted practice for audience measurement on the mobile web!” Cause any effort to democratize serving ads in a medium and put everyone on equal footing just needs to set down conditions of input (media styles and formats, standardize terms and minimum specification of a buy) and expected output (what should be reported and how should it be measured?) The guidelines as they stand make a point of dealing with the media formats and sizes, not bad, I have no real comments there. However, the mobile web part says nothing at all about audience measurement. Which is kind of conspicuous cause the messaging and downloaded app sections do talk about metrics and reporting.

It’s almost like it was intentionally left out, hoping no one would notice the smoking crater? I’m looking for something along the lines of the IAB Campaign Measurement guidelines. Look at the detail in there: delivery mechanisms and which inclusion tags count as which style and dealing with caching. And most important, it doesn’t matter if it’s right or wrong in every case, just that it’s consistent. Why is there information about handset screen sizes in China, and no mention of how to measure reach on the mobile web? Bad form.

Okay, I know I said the report included sections on application download and messaging audience measurement. Technically that’s true, in that their presence in the report calls into attention their absence for the mobile web section. But these are the counting and reporting “guidelines” for mobile messaging:

Operators could use counting tools that use digital fingerprinting or similar technologies to track message
distribution among users in the network. This could enable the service provider to track the dissemination
routes, to identify social leaders, and to reward users for forwarding messages. However, all these
capabilities must comply with existing national level regulatory and legal frameworks covering privacy and
the use of personal data. In addition end users concerns and expectations will always need to be
carefully managed. Taking all steps necessary to ensure end customers fully understand any proposal to
user their data, together with providing a clear choice to opt in or out of this type of service is essential for
its long term success.

Umm. I’m not sure “The carriers might do something to help count users. And oh yea, be sure not to break the law” really counts as a guideline. That’s not helpful at all, to anyone.

Then there’s the section on mobile video, which says pretty much “we’ve got no guidelines, but here’s some info about mobile video.” What the hell? Are these guidelines for usage? Or marketing material? If you don’t have guidelines for mobile video don’t include a section on mobile video in your guidelines. It’s reminiscent of padding out a book report. Was there a minimum word count for this assignment? I actually scrolled back to the top of the document and checked the title of the report again, thinking that maybe this was really just an informational release. The mobile marketing strategic overview and not a set of guidelines. But that’s what the report says, “MMA Global Mobile Advertising Guidelines”.

So lets create a specification for them so we don’t have to go through the process again. Audience numbers must be counted using the MSISDN if available and fall back on cookie based counting in all other cases. MSISDN presence is dictated by the presence of one of the following headers in a request from a mobile terminal:

• X-MSISDN
• X-NOKIA-MSISDN
• X-UP-SUBNO
• X-WAP-MSISDN
• X-UP-CALLING-LINE-ID
• USER-IDENTITY-FORWARD-MSISDN
• X-WAP-CLIENTID

It’s relatively easy to pick out which headers to use if folks publish some info about the traffic they’re getting. Cookies must be delivered with the domain of the central advertising network if appropriate, which means image based recording even for text adverts. 1×1 gif, which admittedly carriers could block.

That’s it, that’s a spec, it’s the kind of thing I would expect the MMA to put in their “guidelines”. Furthermore, given their position as the premier global organization pulling membership from carriers, software providers, and manufacturers I would expect them to:

• quantify in what percentage of cases the guidelines are expected to yield valid numbers given global averages
• work to improve the guidelines to decrease the error rate over time
• provide recommendations and guidelines to carriers, software providers, and device manufacturers to decrease the error rate going forward

If something like that happened we might have something that could “stimulate the growth of mobile marketing and its associated technologies.” As it stands now however, I don’t really see the point. It clarifies a few points if you already have an advertising business up and running. But say you’re an independent site owner looking to sell your own inventory directly, or an open source advertising platform looking to add mobile adverting to the mix of features your package provides. Read through the guidelines with that perspective in mind and it’s obvious it doesn’t provide any of the necessary clarity at all.

I did a search this morning to see if there was anything related to the cookie issue with Openwave software. Instead I found a post from Dennis saying that it appears that Sprint has now followed Vodafone in disrupting the mobile web. Ouch. And their partner in crime? Openwave. I was hoping to find some positive reaction, instead I find a new mention of negative behavior. Damn.

Great post from the Mippin folks explaining a problem with cookies on mobile devices, in the US in particular. I’ve heard support numbers all over the place from folks. Some say cookies fail 50% of the time, others say they work in all but 5% of the cases. Apparently there’s some major issues with using a bare TLD with Openwave (either browsers, gateways, or browsers and gateways - see this Openwave FAQ for some info about how they’ve mucked up identifiers). Good info to know.

If this is a browser plus gateway issue it would be nice to see it get fixed. If this is a browser issue that can’t be fixed I think we all need to make sure to continue giving Openwave folks the evil eye when you see them (I’m assuming you all do already, just keep it up). Come on Openwave! This is your chance to prove to us all you’re not completely useless. I’ll be keeping an eye out for major network changes.

The second part of a series of mobile payments posts I’m making to get ready for BarCampBankSF later on this month. The first part was a problem overview for the issues. This part is about the Fear Uncertainty and Doubt (FUD) that stand in the way of trying to get a global system going for moving money around.

I was going to hold off on this topic for a while, but then I ran across this gem of a report from our beloved US government explaining why mobile payments could destroy the world. The whole topic area right here just strikes me as backward, small minded, and at it’s base just really stupid. Here we have the potential for a fantastic system, uncoupling the concept of money from bits of paper and metal. Making it easy for people to do what they want with their money when they want. Being able to reach out and help friends and relatives in far away places instantly.

But instead of seeing the potential upside (not, potential upside, most of us don’t have the ability to do the things discussed in that report under the current set of services), instead what’s called out is the potential for abuse by a very small percentage of the population. I just don’t get that mentality at all. It’s like not allowing cars because people could get drunk and drive around in them. Or declaring that everyone has to walk around naked cause someone could hide weapons under their clothes. It’s just absurd. Why cripple everyone because you’re concerned about the behavior of a few? Apparently all you have to do is include the word “terrorism” and you can propose just about anything you want.

I personally don’t buy it at all. If you want to cut off the potential use of a system by terrorism, sure, by all means! I’m not going to stand in your way. But if you want to cripple a system that dictates what I can do with my money, how I can do it, and when I can do it, well then we have a bit of an issue. If you want to cut off terrorism do things that affect terrorists and money launderers. Inconveniencing everyone in order to do so is just lazy thinking. Unfortunately people have strong and irrational feelings about things like this cause they feel their safety is threatened (Surprise! You never really had safety, you’ve just become more aware of not having it), and any bit of absolutist thinking they can hold on to in order to make them feel better. Well darnit, that’s just going to have to do. Cutting off terrorism by cutting off their funding is one of those areas (Surprise! That’s not going to work either, probably won’t even slow it down).

Unfortunately what we’re working at here, at heart, is a fundamental change in the way people think about money. And like any major change, that really makes people nervous. Especially people who have a vested interest in the particular limitations, controls, and structures brought about by the incidental effects of the current system. People like governments and banks, who unfortunately are holding most of the cards in this game. In order to figure out a workable system we either need to work around the folks who would normally stand in our way, or convert them to our side. Most of the efforts that have come before are based around a third option of giving incentive to the existing folks and caving in to their restrictions. I don’t consider that option to be on the table, limiting a new system to make the players in the old system happy isn’t a path to progress in my opinion.

Converting the existing folks to our side seems like it could be pretty difficult. Hard to say though with the setup the way it is in mobile payments. With the carrier sitting in the middle of every significant transaction we might be able to play the banks against the carriers to come up with a system that works at scale to break open that market for the banks. But the banks have their own sets of issues. Working completely around the existing system might be the real option we have. Direct user to user payments with something only vaguely resembling a bank in the middle. Using alternative “payment” methods like trading prepaid minutes or prepaid messages. That gives us a bit of a foothold, but how does the regulation and legal arena look for schemes like that? For instance can I take $25 from someone in CA and at their request provide it to someone in NY for withdrawl? What needs to be reported and recorded in that case, and what base restrictions are there? If someone has good pointers please share them.

We had the automotive focused Mobile Monday in Silicon Valley last night. It worked out quite well, there were quite a few new faces in the audience. Two main presentations for the evening were Dash and BMW.

The folks from Dash were showing off the base functions of their system, but also talking quite a bit about how the Dash acts as a base platform that users and service providers can build off of. One of the things that I liked was the “send to car” function they demoed. You can select an address in a desktop browser and send the info over to your device using their web site and it gets pushed out to the device. The kind of base function I can really see being included in just about any connected device down the line somewhere, but they have it working in their system now.

They also went into some detail about how their traffic monitoring system works. Most traffic monitoring systems use sensors embedded in the road and companies can subscribe to the feed of traffic info and republish it. However it only gives you info about the major roads, highways where the sensors are deployed. The Dash uses the units out in the field as a mobile sensor network to time travel between points and track estimated travel time. That means they can provide traffic on sidestreets and smaller roads (if there are other Dash systems driving around and generating the necessary data). That’s awesome.

Chris from Dash (their brand spankin’ new platform evangelist) went over some of the functions of the APIs. Using the website you can feed in info from KML or GeoRSS and use it alongside the information that the device uses by default. Right now that consists of updating the feed each time you select the entry on your device, so that fresh info is pulled each time. But they’re working on a “dynamic API” that gives the developer more control over the results returned, and can do things like select geographically bounded sets of results based on the current location of the driver if you have a huge data set behind the service.

The Dash isn’t out yet, but it’ll be shipping end of this month. The base platform that it’s built on is actually OpenMoko, so I’m finding it lustworthy on a number of different levels.

We also had Jeff Zabel from BMW come and present an overview of what BMW is working on and some vision for the future. There’s a BMW Technology Office right downtown Palo Alto (BMW Technology office in Palo Alto, maps isn’t recording the zoom level, but the location is correct), I had no idea and I used to walk right around that corner at Cowper and Hamilton on a daily basis for months. Sneaky!

Jeff showed off the set of services that BMW has been working with. Many of them are flavored by the demographics of a typical BMW driver, which doesn’t necessarily overlap with the engineering techy crowd in Silicon Valley. For instance their base service is a voice connection back to a support center so that you can get voice turn by turn directions from a person or help in case of an emergency. As a techy that just sounds horribly wasteful, but that’s what the people who end up in BMWs typically want. I had flashes of the stories people used to tell in Rochester about the execs at Xerox and Kodak who would have an assistant that would filter and then print out their email so they could get it as paper, and then hand write their responses to be transcribed as responses. Shudder. To each their own I suppose. He was also talking about improving those base level systems, providing stuff like seat occupancy info to emergency response in case of a crash. Or sending ahead emergency contact info of medical alerts for the folks expected to be in the vehicle.

They did have some cool features that resonated with my geek side. Jeff was into a shared route feature they have, and I very much agreed with where he was going with it. It’s a feature that allows you to download a preset route and information about it. His example was that lots of folks who come out from Germany want to drive the legendary highway 1 when they’re in town, so they could download a route that takes them along the interesting parts of 1 and gives them info about the road. Personally, I would do Woodside instead. Highway 1 is beautiful, but boring. Waste of a perfectly good BMW. If I found myself in a Z4 M with some time to kill, hell yea, I would do Woodside between Skyline and the coast. And I would love it it said things like “there’s a set of switchbacks in half a mile that will give you goosebumps, let the car in front of you get ahead some so you can gun it.” It should also have a lap timer, but I’m sure that would require a whole other set of warnings on the startup screen.

Jeff said a lot of the purpose of the facility in Palo Alto is to search out interesting new ideas in the valley, wrap them up and work them through, prototype every once in a while, and attempt to ship stuff back to Germany that can make it into future generations of the cars. Great news, I didn’t know something of the sort existed. A whole other fantastic resource in a new direction for folks working on mobile services.

I was surprised to see another SMS service that I hadn’t heard of, and apparently Russ was as well. But what I was paying more attention to was the original Radar post that got me to the service, which references a “How to Build an SMS Service” paper at O’Reilly Safari. I haven’t read the whole paper, just the preview snippets, but I noticed that they reference 411sync as an example way to send SMS (in the chapter “Using a Mashup”). 411sync has since shut down, not being able to find a workable model for sending out SMS messages on behalf of internet services.

I totally agree, SMS services are killer. People have their phones in their pocket all the time, they already text, it’s a real genuine asynchronous response mechanism and possibly the ultimate thin client. But the fact that SMS services pop up, get used by people outside of the normal geekery that take advantage of hacks of the sort, and then unfortunately have to get shut down cause the payment model for SMS doesn’t line up with any apps. That’s just not good. It’s going to lead to the general public getting frustrated with services and walking away from them like they did WAP the first time around.

I’ve been looking at using SMS for services, and Russ has been pulling on some threads as well. We all see the value of adding SMS messaging from the application and user experience side. But how do we make the thing work as a whole, cost to the service provider included? Everyone keeps ignoring this cost of actually sending SMS messages, running a service for a while, and then eventually getting plowed under and forced to quit.

Monetizing batches of messages with advertising I just don’t see working at all, it’s been tried a number of times before and the technical problems and user interest issues really get in the way. Across all mediums chat is one of the hardest things to monetize, it’s hard in a dedicated desktop client, damn right it’s going to be hard to do jammed onto the tail part of a 160 character message. Put that together with not knowing if the user is going to be able to click a link out of the messaging app on their phone, or even have a data plan, and it’s a hard sell to fill SMS inventory. Even when you have segmented and channeled content like sports notifications. If what you’ve got is random messages being sent between teenagers, your potential advertiser group is even smaller.

Some of the more interesting SMS “applications” are the ones that go viral. The community action or political messages that see users forwarding info to other users in order to get the word out about something. The effect of a message is multiplied there, and it’s using the social network of users not just for finding where to send the message, but also to bear the cost of transmission and spread that load around. The same thing isn’t possible if your technical hack needs to be the hub for these connections.

What if you could send virally though? What if someone using your service said “I’ll commit 100 messages every month of my 300 free messages and donate them to your SMS service.” We could either implement that as the carriers opening up their billing systems to outside marketplaces for prepaid messages and minutes…. Wahahahaha! Just kidding, they’ll never do that any time soon. Though it would be FANTASTIC for worldwide payment and mobile web billing solutions. Even I can’t dream that big yet.

How about a peer-to-peer system though? Say you were able to get a java application out on handsets that was able to multiply the leverage of a single inbound message on a command port and forward it to a number of other devices on your behalf. There’s all sorts of potential issues with response paths and making sure your app doesn’t play host to SMS botnets. But it just popped to mind and I figured I would share it. Has anyone fooled around with this out there? I can’t even get Betavine to send messages to the US yet, so I haven’t been able to test any of this out on my own.

As part of investigating SMS applications and non-standard usage I’ve been playing around with the Vodafone Betavine APIs. However I can’t get them to deliver messages to my handset. I had a thread going in the discussion forums, but haven’t seen a response in almost a week. Anyone out there using the Betavine APIs in the US? I have the full command I’m using the send my request in there, is there something I’m doing incorrectly?

The March 2008 Silicon Valley Mobile Monday announcement is up:

• What: March 2008 Mobile Monday (Automotive)
• When: March 10th, 2008 7:00pm
• Where: Google, Tunis Tech Talk, Building 43, 1600 Amphitheatre Parkway, Mountain View, CA 94043
• Who: Anyone interested in mobility
• Cost: Nothing!

Presentations from BMW about their connected car work, something that I’ve heard of but seen little about online. And the folks from Dash are going to be there to show off the APIs for their internet connected navigation system. See you there!

I kept seeing commercials on TV saying Vehix has a mobile version. I went and poked at it however and had some issues. First off was that my N95 brought up the full web version. I’ve seen a bunch of discussions online saying things like “if the user is on a device with a full browser or using Opera Mini of course they want the full version.” From expert users sometimes even. That’s just stupid. I’m pretty sure the problem was just that the platform Vehix used just didn’t recognize the N95 But in case someone made the explicit decision to return the full version to Webkit on the N series, you were wrong. Definitely in the state it’s in now.

One of the major problems is that there’s no actual link over to the mobile version if you end up on the desktop version by mistake. I searched around on the web and didn’t find any mention of it. So I pulled on Firefox on my desktop where I have a bunch of mobile user agents saved in modify headers. The first two user agents I tried resulted in an “unsupported browser” error page. Well, that also is just dumb when you’re dealing with mobile. Seriously, if you’re going to do things all half-assed, at least allow your users to pick the right version manually if they should happen to understand what’s going on. Throwing up an error page and suggesting a bunch of desktop browsers to be using instead, that’s just poor form.

Turns out the mobile version is at http://mobile.usablenet.com/mt/www.vehix.com/ if you want to check it out. Once you can get there it really is a pretty nice mobile site. The layout is clean, selection options were a bit funky at times but workable, and it seemed like a perfectly practical site. My car is holding its resale value very nicely, that’s always great to see. Can’t really thank Vehix for that, but it put me in a good mood at least.