Masabists

London Technology Network - Intelligent Transport

2009-07-01T16:50:00.007+01:00

I just got back from presenting at London Technology Network's Intelligent Transport event just round the corner from Big Ben.

Rail Ticketing - London Transport Network

View more documents from alexandergeorge.

The content's very similar to the talk Ben gave at Mobile Monday a fortnight ago, but obviously with slightly less polished delivery.

Global Messaging 2009 - Mobile Ticketing and Payments

2009-06-24T17:39:00.003+01:00

I'm just back from presenting at the excellent Global Messaging 2009 event in Westminster, on the subject of what makes a good mobile service in the context of mobile ticketing and payments:

Global Messaging 2009 - Mobile Ticketing and Payments

View more presentations from Tom Godber.

It covers some of our standard reference points, like the need for a mobile service to address a user pain point and actually perform better than the alternatives to be used. I think this really applies to selling train tickets from the handset, something that a pure deliver-only model fails to achieve.

Masabi at Global Messaging 2009

2009-06-22T17:20:00.003+01:00

I'll be giving a talk on Secure Payment and Ticketing Applications at day 2 of Global Messaging Congress 2009 on Wednesday at the Queen Elizabeth centre in Westminster, so if you're at the conference please come along, and I look forward to meeting you afterwards! I'll post the slides up here as well, for anyone who is interested.

MoMo London Demo Night summary

2009-06-16T14:15:00.016+01:00

Last night Ben presented at Mobile Monday London's demo night round the corner at IPC’s office behind the Tate Modern. Ben was presenting our mobile train ticketing solution, and it seemed to go down pretty well. Also there was a great roof terrace and free beer - almost enough to make me code a TouchWiz widget in Samsung's Innovation Quest widget competition!

Our slides from the night:

Masabi - Rail Ticketing demo at MoMo London

View more presentations from Masabi.

Here's a quick rundown of all of the presentations for those who couldn't attend:

Vopium

Nice voip solution, fully integrates with phonebook and routes calls through multiple different channels. Smartphone-only, but if it's seamless then it could work.

Peepr.TV

Webcam hosting service, allowing streaming to mobile. Can be adapted for premium webcams as well; doesn't work on my SonyEricsson K660i.

0870.me

Finally, an *open* API for remapping 0870 phone numbers to cheaper alternatives.

Photofit

Fun iPhone app which lets you mix up the faces of your friends. Normally used by people in the pub; possible synergies with the Met.

Total Hotspots

Find wifi hotspots from your iPhone. Hopefully it will be possible for mass-market phones too at some point.

Audioboo

Audio blogging app for iPhone. I don't have an iPhone, but apparently Brian Clough does.

Artilium

Presented an easy-to-integrate LBS platform

Proxama

Demonstrated an NFC wallet application for the Nokia 6212 (has any network picked this phone up?). Could also probably work on the Nokia 6131NFC. Trialled with Vodafone last year; mass uptake by 2013? Read Masabi's thoughts on NFC here.

Ookl

A platform for interactive learning at museums, using mobile phones. Go try it at Kew Gardens or the National Maritime Museum.

Singtones

I really need to try Singtones, as apparently it can correct your Karaoke singing.

Corebridge

Corebridge have an integrated mobile/web CRM solution. Unfortunately their presentation was let down by the lack of signal in the building.

Spoonfed

A neat crowd-sourced location-based recommendations site for venues and events.

Masabi

We presented about selling train tickets on mobile using our pocket ticket machine. Read more here. Some screenshots of the app we actually demo’d:

Unfortunately many of the presentations were let down by a lack of mobile connectivity at the venue. Slightly surprising for a corporate building in central London; perhaps they should get some femto-cells in there? For the app developers, SMS failover has its uses!

I'm normally more self-effacing than this, but it wasn’t me presenting and it was nice to get some really positive feedback from our industry peers:

@edent: “Masabi get it right - open standard & works on low end phones. There's a world outside of iPhone #MoMoLondon”

@fj: “masabi I love you, marry me. You get mobile. #momolondon”

@kaihendry: “Enjoying the Masabi presentation of buying rail tickets from the mobile. Now will it work on my Android G1? On the Web? :) #momolondon”

@gslondon: “Masabi demo of their rail ticket purchase system was impressive”

Jag from O2: “This was the best demo of the lot - and they were all very good I have to say, but this one really stood out in terms of being very well thought out and executed.”

Thanks, everyone!

Carnival of the Mobilists 177

2009-06-08T18:04:00.002+01:00

Carnival of the Mobilists 177 over at A Consuming Experience included my last post on Sony-Ericsson, thanks! As always the Carnival covers a whole range of great articles, check it out for the best in mobile writing.
Incidentally I met Improbulus, who runs A Consuming Experience, whilst screening entries for the Vodafone Clicks competition last week with Helen Keegan - a very interesting evening with a few great entries we will be hearing more from in the future.

Speaking at Train Communications 2009

2009-06-08T14:53:00.002+01:00

Another chance to meet up with Masabi, when we speak on the Thursday afternoon of Train Communications 2009, held at the Royal Horseguards Hotel, near Charing Cross in London on 11th June 2009.

http://www.traincomms2009.com/

(This conference used to be known as the Wifi on Trains conference.)

Among the presenters will be train companies from India, Japan, Taiwan, the US, the UK and across Europe, including Indian Railways, Department for Transport UK, Virgin Trains, Thalys, National Express Trains, Arriva, NTT, Japan Rail and Orange

Masabi will be talking about mobile ticketing, credit card transactions, and the infrastructuire issues and design approaches to mitigate those issues when rolling out robust distributed authentication systems in an operationally challenging environment, such as rail and bus.

If you want to schedule some time with Ben at the event, please drop him an SMS on +44 7788 895 894.

ITS Transport Standards Seminar - summary

2009-06-04T18:30:00.008+01:00

Write up of the recent Intelligent Transport Systems' Seminar on Standards in UK Ticketing Wed 27th May 2009:

[ WARNING: The top third is mobile ticketing, the rest is more general transport stuff ]

Chair: Chris Queree, ATOC (Association of Train Operating Companies)

Speakers:

Ben Whitaker, Masabi

Andy Donelan, Virgin Trains

Grant Klein, Detica

Mark Cartwright, RTIG (Real Time Information Group)

Roger Slevin, DfT (Department for Transport)

Masabi got to speak first, and played a potentially unpopular opening card by pointing out the marked difference in Capital Expenditure between the expensive rollout of a smart-card system, and the much cheaper rolling out of a barcode ticket system.

Specifically, because of the fact that self-print and mobile delivered barcode tickets all have a human readable version of the ticket alongside the machine-readable barcode, means that in initial rollouts the vehicle guards can simply check the tickets visually, the same way they check existing paper tickets.

Occasional spot-checks of the e-tickets can be made by texting the manual ticket number to a central service, and a small number of shared scanners that guards or stations can use on rotation.

Permanent rollout of scanners and gates can then be staged for areas that see large volumes of e-ticketing, but completely avoided in those areas that only see a low frequency of e-tickets.

Smart-cards by comparison have no visual indications at all, and even the card owner cannot know what is on the card without a machine to interrogate the card. Any area that wishes to use smart card must be fully equipped with scanners before launching the service, meaning that the full capital expenditure must be comitted before the first users can start.

It was also pointed out that in London there is a significant financial penalty for people that refuse to use Oyster, with many fares being twice as expensive on a paper ticket. The proposed national ITSO smartcard system for rail tickets will almost certainly not have such a price difference (if any) to drive uptake.

We also haven't got to the bottom of how a national rail smartcard journey would be purchased by the consumer - I think you would still need to buy on the web, or queue at a ticket machine at the station to configure your journey before collecting it onto the smartcard, which won't reduce queues at all. (Oyster-style charging is not an option outside London.)

Masabi's presentation then got into the main topic of the new RSP barcode standard for UK rail tickets on mobile and self-print, highlighting some of the enhancements that provide better security, robustness, and cross-sales opportunities than previous barcode standards, and encouraged operators and other ticket sales companies to find ways to exploit it more.

The 3rd party opportunities come from the fact that under this scheme you can freely give away the ticket scanning software and public security keys, so that Coffee Shops, Retailers and major attractions like Alton Towers can all integrate ticket scanning and validation into their EPOS (tills) and gates (as long as they have an off-the-shelf 2D barcode scanner), and be able to read/verify the new rail tickets and any cross-sale entitlements that are inside, such as your early morning coffee and bagel, bought at a preferential rate, or alternately your group purchase of a weekend getaway including a music gig entry in one ticket.

Masabi also showed off a bit of their mobile ticket sales product, and the opportunity for it to reduce rush-hour queues at stations, and reach out to users when they are most in pain and keen to try a new system, i.e. when the queues are long, or when the ticket machine is broken - that's when a (non-geek) consumer will try a new way to purchase and travel.

(For people that haven't heard of it yet - the Masabi Mobile Ticket Machine allows a customer to buy a ticket straight from the phone, using a credit card, and then get the ticket on the phone. They don't need any sign up either, they can do it straight away, from the queue.)

Masabi Rail Ticketing ITS

View more presentations from Ben Whitaker.

There were a lot of questions from the floor, getting into the anti-copying and some of the low end (legacy) handset support issues that the new ticket standard addresses.

Then Andy Donelan from Virgin took the stand to tell everyone about Virgin Railways' success with barcode ticketing, this time focussing on the printed barcodes, and their part in "driving down distribution costs".

He said that consumers had been very keen on the new system, so the initial pilot has been rolled into full production use since September 2008 across all of their routes, taking over 4M in revenue, with over 1000 e-tickets sold per day.

For clarity - currently Virgin's printed barcode tickets are only valid on advanced tickets on Virgin-only routes. Virgin are now in discussions with Train Operators such as Cross Country that they share routes with to agree to honour each-other's barcode tickets too, so that these restrictions can start to lift, and more routes and fare combinations will be supported by the barcode format. (author's note - paper barcode tickets and mobile barcode tickets share the same format and the same scanners, so every rollout of paper barcode paves the way for mobile too.)

He also revealed that as a long-distance route, their proportion of tickets sold on line was 35% - far higher than the national average of 12%, and they expected that to continue to grow.

Their strategy was to enable remote booking as much as possible to easily expand their sales capacity, as they can't increase the number of ticket windows at their stations to cope with increasing demand.

One of the benefits Virgin found with the user-printed paper barcode ticket, (much larger than standard card rail tickets in the UK) is that they can contain the full travel terms and conditions of the ticket, which makes it easier for revenue enforcement officers (guards) to say that the traveller should know exactly what they are entitled to, in a way that the very small existing tickets do not. For our international readers, the "conditions of carriage" or rules of the railway ticket vary by route and ticket in an almost impossible to understand way, and there are large fines for mis-understanding the special restrictions known only to guards and railway experts.

In good news, they have had very few customer support requests about their e-tickets.

Interestingly, their initial trials of hand-held barcode scanners at Euston faced issues from dropping off-line when they went underground, so this would certainly be aided by the new off-line scanning capable ticket standard that has come in since they started their trial on previous on-line only tickets. It is exactly this sort of resilience that we have added to the standard to make it practical for real-world rollouts.

Andy agreed with the points that Ben had made, and saw mobile and self-print as complimentary, each suiting slightly different use cases, but both useful in servicing the travelling public, mobile especially suiting business travel travellers, self-print more for infrequent travellers.

The chair, Chris Querry summarised the morning talk by observing that barcode is growing of its own accord on it's own commercial merits, but he could only see Smartcard gaining much ground through legislation and franchise commitments forcing it to happen. "People will vote with their feet, or more likely their barcodes about which e-ticketing platform to use."

The next talk by Grant Klein from the hosts, Detica, covered some of the reporting and tracking requirements of e-ticketing, allowing more accurate data to be gathered about how many travellers there really are, and what their habits are. With paper tickets, just like cash transactions, all you can be sure of is the number of journeys, but you have no idea about how often those journeys are the same person - etickets instantly give you all of the benefits of loyalty cards in this respect for tracking users and building a history.

Chris Querree then gave a run-down of new public transport standards work in Europe, helping attendees to make sense of where each of the seperate, overlapping, and sometimes cooperating standards bodies is going.

From a ticketing point of view, I noted down the UIC 981-2 standard being used in Europe for long distance train tickets, CEN TC278 WG3 SG5 for ticketless travel, and security on self-print to follow up on later, but anyone else wanting to find the details on more standards work should get hold of Chris's actual presentation.

Mark Cartwright from the Real Time Information Group (RTIG.org.uk) talkup us through the efforts to unify access methods for joining transport and journey information accross multiple sources and viewing platforms, to support web and physical signeage and querying, such as the in-bus shelter wait-time indicators, and the unified journey planner websites.

Roger Slevin then took the final speaking slot to fill us in on some of the work that DfT were involved in, mostly on the passenger information side, following on nicely from the RTIG talk.

Relevant standards covered in Mark and Roger's talks were NeTEx (network and ticketing exchange protocol), DJPS (distributed journey planners), and IFOPT (with things like stop place models, alternate names for points of interest, where parking is etc). In the UK NaPTAN and NPTG are useful components too. With all of these people can model joined up transport much more effectively than ever before.

As a "how far have we got" statement, basically most of the South East of the UK now has a unified journey planner, and we should get in touch to find out more about it, or to gain access to the data.

There was some discussion about what shared standards there might be for exchanging this transport data, and the Google Transit Data format is gaining ground. Journeyweb in the UK may also be pushing a potential XML standard to get behind too, with EU-Spirit as a compromise against some competing European efforts, some of whom don't seem to be as eager to work with other parties.

The closing remarks basically summed up pragmatism over idealism, and in the debate that followed there was only one lone voice bemoaning the lack of loyalty to the previously un-touchable ITSO smartcard programme, with most people seeming to be quite happy to look into faster, lighter, more open, and above all cheaper alternative standards for e-ticketing and data sharing, such as the PKI based barcode standard, and the more open XML based journey planning and transport information systems.

Please leave the queuing system here?

Sony-Ericsson Handset Announcements

2009-06-01T13:28:00.005+01:00

There are a few interesting points raised in the technical details accompanying Sony-Ericsson's recent announcement of the Aino and Yari handsets - app usability should improve, whilst Sony-Ericsson's smartphone platform strategy is tending towards the Samsung "try 'em all" approach...

Concessions to Usability

Most importantly for developers, the new handsets aim to reduce the permission dialogue hassle that users experience when running applications on their handsets. This is a huge bugbear which just adds user pain without really improving security - because users rarely read the (often opaque) language of the message, they just click and get annoyed at the jarring interruption in their workflow:

The absence of these interrupting dialogues in iPhone applications adds to their usability. They have clear purpose, but MIDP has always erred too far to the side of caution, and allowed explanation messages to be written and translated by programmers not usability experts, to confusing effect. They simply annoy, and give the platform a slightly amateur feel.

Sony-Ericsson suggest that Unsigned apps will now show far fewer dialogues, and Trusted 3rd Party signed apps will be able to ask once and then never bother the user again. This is absolutely excellent news because it eliminates a key barrier to regular app usage.

Sony-Ericsson says this is in line with recommendations in the MSA spec - an umbrella JSR mandating the support for a huge range of APIs adding up to a very powerful platform, which is now gaining a lot of traction. This is also a great thing, because it implies that Sun recognise the problem, and that other handset manufacturers may be following suit.

Whilst in general I am in favour of reudcing the permission overhead to a secure minimum, this can go too far. I am quite worried about the idea that dialogues may not be required when implementing the upcoming Javascript APIs designed to allow webapps greater access to the handset hardware - the potential for malicious scripting is huge.

Hopefully Javascript will find a more sensible balance where MIDP at first did not, because HTML 5 is opening up some exciting opportunities. Given, however, that browsers shipping today appear to be replicating all of the proprietary manufacturer-specific API problems of early MIDP, I'm certainly not holding my breath!

Post-UIQ Smartphone OS Standardisation?

In the good old days, Sony-Ericsson were pioneers in the smartphone market with the P800, back when everyone thought a smartphone should be like a PDA. Looking back, my gut feeling is that on every subsequent revision UIQ (a UI layer built on Symbian) dropped further and further from the leading edge, striking an unhappy balance between mainstream usability and PDA power. UIQ finally went under when Nokia took Symbian open source without them, leaving Sony-Ericsson without a smartphone platform.

This is roughly the point when Sony-Ericsson launched the Xperia, a Windows Mobile handset that was very interesting, though ultimately didn't fully live up to expectations. A lot of effort was put into encouraging developers to build panels and things (proprietary UI extensions), but to the best of my knowledge they haven't announced any more Windows Mobile devices - and hopefully they'll stay that way.

Subsequently, Sony-Ericsson stated they would be focussing on the Android platform for future smartphones... and then announced two S60 handsets. They have dropped hints that Android wasn't to displace other OS platforms, but can a company in Sony-Ericsson's state really support simultaneous development on two or three smartphone OSs as well as their (actually very good) proprietary feature phone OS? Note that smartphones are only around 13.5% of current world handset sales (although at the lucrative end)...

Masabi speaking at ITS UK Ticket Standards Seminar, and at European Telco Strategy event

2009-05-13T17:46:00.003+01:00

For those of you on the conference circuit, you can see Ben Whitaker from Masabi speaking about new mobile ticketing approaches for public transport including mobile payments via credit card this month at the UK's ITS Passenger Information Interest Group's seminar on Options for Ticketing and Standards in Ticketing which is on the 27th May in London. Other speakers include Virgin Trains, Department for Transport, and our good friends Consult Hyperion.

We will also be speaking later this year in Berlin at the European CxO Telco Strategy event on the 30th November and 1st December, alongside speakers from several European network operators.

If you are attending these events and wish to schedule time with Masabi, feel free to book in a time in advance, via the ususal channels.

Interesting Blackberry Factoids for Developers

2009-04-22T17:40:00.009+01:00

We've just had a great chat with the extremely helpful RIM Developer Relations guys, and some things came out of it which we were only slightly aware of. None are secret, just buried in spec documents and forums, so I thought it would be worth putting them up on the blog in case they are helpful to other developers:

Applications Permission Manager

Since Firmware 4.2.1, there has been a manager object which can not only tell you what the current API permissions are for your app, but allows you to display the device's application permissions dialogue with your favoured settings pre-populated, which the user can then choose to save if they are comfortable with them.

Used correctly, this is a great way for the app to discretely flag how the user can make their life easier, without being too intrusive. We're all about removing pain in a secure fashion, and love this! There are some pointers in this presentation, and from there you can dig into the relevant API.

Device Upgrades can Migrate Applications

A user can migrate their applications to a new device alongside their contacts, mails etc. On the face of things this is very useful, but it means your app's cod files must be as happy working on a scrollwheel Suretype device with a 240x260 screen (eg. 7100) as they are on trackball QWERTY devices with 480x320 screens (eg. a Bold).

This could have real implications for games, which often use large graphics scaled and optimised for a particular screen size. It also impacts some strategies for providing UI movement and widgets across different keyboard and scroll/pointer types on fully branded Canvas-based applications.

The application's RMS memory migrates with the app, and applications can query the device to find out its unique ID and specification, so if this is a huge problem you should always compare IDs at startup and issue an upgrade so that the user picks up a more appropriate cod.

The Storm's Touch Screen Prefers Native Applications to MIDlets

If you want to provide proper support for the Storm's touch UI, you'll have to do it with a native UIApplication instead of a MIDlet. The MIDP Canvas touchscreen API is not expressive enough to handle the two levels of click used on the Storm.

Newer Blackberries Can Read Custom Jad Parameters

A huge bugbear with Blackberries before was their inability to read any parameter from the jad - this made the provisioning of unique information at installation time all but impossible. The MIDlet.getAppParameter() method simply returns any value stored in the Manifest at compile time, but nothing added in the jad afterwards.

Since firmware 4.3.0, this now works - and RIM are very good at providing clear User Agents identifying the device and its firmware when browsing (unlike some others), so you can make this call at provisioning time.

There's also a great tutorial on Blackberry vs. MIDP code signing (PDF). I hope some of that information is of use to people - the guys from RIM were extremely helpful and we certainly were very happily surprised how much we got out of the meeting.

On an unrelated side-note, we've started Twittering - we're just restricting the company tweets to information relevant to mobile applications, security and transport so if any of that is you're bag feel free to follow us!

Digital Money Forum - London 31st March

2009-03-25T18:17:00.004Z

This Tuesday I'll be at the Digital Money Forum, at the Guoman Hotel in Charing Cross, London.

As well as being on one of the expert panels on the afternoon on the first day, I'll be around all of Tuesday and Wednesday afternoon if anyone wants to chat.

The expert panel with the vague title "London Calling" sounds like it will have quite a wide ranging debate, but we'll probably be working around the following talking points:

UK Digital Rail Ticketing,
and the battle between SmartCard/NFC and Mobile Barcodes, and which might offer more bang for the buck, especially where public money is being spent
UK Payments Council Project - Mobile P2P bank payments in the UK,
our opinion on how to give it a chance of success where so many e-payment initiatives have floundered
Open (PKI) VS Closed (Oyster/MiFare/ITSO) Security models,
we're pushing the open approach, as Dave Birch knows.

All of which are topics with different points of view, and of course the debate will be steered by the moderator into which topics would be the best food for discussion between the panellists there.

The event is run by the security experts at Consult Hyperion, who Masabi strongly endorse for anyone looking for audits and advice on their business and technology security, especially if they are working in the brave new world of secure transactions on new platforms at the edges of conventional established practices.

You can also hear a chat between Masabi and Consult Hyperion's Dave Birch on this podcast if you are interested.

MWC 2009 talk: Challenges Building Secure Mobile Applications

2009-02-26T16:02:00.002Z

Ben Whitaker and myself gave a presentation in the App Garage of Mobile World Congress in Barcelona this year. The slides of the talk are reproduced here - let us know if you'd like the full code samples as well. Apologies for the front page, which seems to disagree with the Slideshare conversion system...

Challenges Building Secure Mobile Applications

View more presentations from Tom Godber. (tags: mwc 2009)

Carnival of the Mobilists #161

2009-02-18T11:57:00.004Z

Carnival of the Mobilists 161 over at Mobify Me has nominated my last transcoder post as Post of the Week, thanks! As always the Carnival covers a whole range of great articles, check it out for the best in mobile writing!

Transcoders round 2

2009-02-13T10:55:00.008Z

It has been incredibly busy pre-MWC and so I have not yet pulled together our research into mobile browser handling of SSL certificates (as promised when I described transcoders). However one piece of news inspired me to write an addendum – Novarra, a transcoder vendor, have now started offering a version of their transcoder for laptops using 3G dongles. Bill Ray isn’t certain about all the details, and Novarra still haven’t replied to my previous request for information so it is difficult to confirm anything, but I’ll restate the problem now and draw some possible conclusions from that.

The problem as it stands: transcoder vendors want to rewrite content to improve performance and accessibility of sites accessed through “mobile” connections. To do this for secure HTTPS sites, they insert themselves into the transaction quietly, breaking end-to-end encryption and creating a potential security hole – though if they are doing their job correctly it should be hard to exploit. More details here.

The transcoder vendors are asking the W3C to approve a new best practices guide which states that they will be allowed to insert themselves into an HTTPS connection, but if the server has set a special HTTP header they will immediately stop and allow end-to-end encryption to resume. If you’re interested in the politics WapReview have an excellent post covering them.

On the face of things the proposal sounds eminently reasonable. It isn’t.

One year ago Netcraft reported that there were 2,451,780 sites on the web responding to SSL (HTTPS) requests, 794,008 of which certificates verified by trusted third parties such as Verisign. Growth was nearly 40% year-on-year at that point, so we can assume there are at least 3m sites today, 1m of which are serious about their security.

There are approximately 5-15 transcoder vendors (that’s an educated guess – there are more than two and I can’t imagine there are as many as 20).

The vendors believe that for security to be guaranteed, the best thing to do is that they break the existing standard, and all 1m (or 3m) sites on the web must change their server configuration if they want to continue being secure. This agreement will be made by a committee of a few dozen people at W3C – no word yet on how widely it will be publicised, but the people publicising the process so far are largely outsiders who don’t like the sound of it.
Many might not care, because they don’t support mobile handsets directly and don’t plan to in the near future. The move to broaden transcoding into laptop connections may make those people think twice, especially when you consider that in the future WiMax and LTE will start to offer true broadband over the air and the entire nature of the internet connection industry will change and become more wireless.

It seems common sense to a layman: the 3+ million e-commerce sites, corporate intranets etc should be allowed to remain secure without having to change all of their configuration; the dozen or so transcoder vendors should honour the existing system. If it is neccessary to transcode HTTPS connections, this should be an opt-in service decided by each and every site, who should be given full explanations of the (minimal?) risks - because they have the burden of care to their users, adherance to banking/privacy regulations, etc.

Let’s hope the W3C make the right decision, but if you are concerned about this maybe it’s worth publicising it widely just in case?

Masabi Talking at MWC 2009

2009-02-05T16:15:00.003Z

Ben and I will be talking about mobile security and demonstrating various things you can do to increase it at Mobile World Congress on Monday 16th in Barcelona. Our talk should encompass everything from common mistakes which reduce security through to what to do about transcoders breaking your HTTPS end-to-end security, and we aim to demonstrate useful techniques you can take home and apply.

We'll be presenting at 4pm in Hall 5 Auditorium 3, as part of the GSMA's Mobile Application Developer Garage:

"This unique event will answer key questions and provoke informative debate through keynotes, discussions, on-stage coding and tutorials and presentations. A demo breakout area will offer hands-on experience with developers creating applications in realtime and offering an insight into the future of application development. The agenda can be found at www.mobileworldcongress.com."

If you don't yet have a pass but would like to attend, there is also a 15% discount available! To get it, register here, select any pass (including just a day pass for the App Garage) and enter the discount code 'APPAB'. Voila, 15% off!

If you can't attend the talk but you'd like to meet up, Ben will be attending from Monday through to Thursday, and I will be there Monday and Tuesday and also attending the full complement of Mobile Monday side events (including Mobile Sunday and the Peer Awards) in my role as a co-founder of MoMo Estonia. Contact us if you'd like to meet us and chat about anything to do with mobile applications, security, ticketing or anything else we do!

Carnival of the Mobilists #158

2009-01-26T12:09:00.003Z

Carnival of the Mobilists 158 over at RadVision has included my post on HTTPS and transcoders alongside a whole range of great articles, check it out for the best in mobile writing!

How Do Transcoders Affect HTTPS?

2009-01-23T11:44:00.011Z

After reading the interesting discussion about mobile transcoders and HTTPS security on the MoMo London mailing list (may require sign-in), based on some related discussion around the new W3C guidelines for transcoding, I thought there was some value in a blog post which explains the issues from more of a layman’s perspective.

First up – transcoders are servers which sit between a mobile phone and a web site, and reformat the web site to (hopefully) make it easier to navigate and use on a handset. A number of operators have installed them, and their customers generally not aware of this – hopefully they just receive a better user experience. This is a subject with a chequered past, that arouses considerable passion among those for and against – I’ll take a neutral stance in this blog post and purely discuss the security implications of what is going on!

In a conventional HTTPS connection, as made by a desktop browser, the browser makes an “unbreakable” connection directly to the web site you are accessing - anyone between you and the site can view the bytes passing between the two, but cannot understand what they mean. Note that, for our purposes here, an “unbreakable” connection is one which is impractical to break within weeks using currently available technology assuming no compromise of the server’s private key – in reality nothing is completely unbreakable! The same should hold true for an HTTPS Wap2 connection between a phone and a web site, without any transcoders:

If you double click on the little padlock on your browser when accessing a site over HTTPS, you'll see a certificate from a trusted certificate issuer (eg. Verisign) stating which domain you have the end-to-end connection with:

On phones, you should be able to do the same thing through the menu system – here’s one on Nokia S40:

Alarmingly, on this same Nokia S40 browser, the Organisational Unit label of the certificate is displayed instead of the Organisation name if both are specified, which often has no meaning to the user. For example Barclays Bank does an excellent impression of being a fake certificate to users not in the know:

However, in principle and when well implemented, the certificate system allows users to trust they are talking to the correct server with some rigorous maths in the background confirming everything. Desktop browsers are increasingly finding ways to automate additional certificate checks and flag up anything unusual, and the mobile web (with its more fiddly certificate checking) will doubtless follow along slowly.

It is worth noting that older Wap1 “secure” connections were not really secure. The handset communicated to the operator’s gateway over a WLTS connection, which was allowed in most cases to use lower key strengths and weaker algorithms which could be broken more easily. The gateway server on the edge of the operator’s network would then decrypt the information and send it on to the end web server over a true HTTPS connection. There were therefore two weaknesses - interception between handset and gateway, and hacking of the gateway to view the connection in plaintext:

These days almost all handsets use Wap2 – which allows for true end-to-end HTTPS. However, as an aside you can easily skip – and here I hold my hands up and declare I know nothing definitively – it is ambiguous what happens when a Wap2 handset connects using Wap network settings. Wap2 is allowed to work just like Wap1 through a gateway, but also prefers end-to-end TCP/IP that is bridged through the gateway but does not need extra translation done there, conventionally configured using “Internet” network settings on the handset. Most operators also provision “Wap” settings on handsets, which were traditionally used to connect an old Wap1 browser to the gateway using a different protocol which emulated some aspects of normal web protocols. When a Wap2 browser (that is also able to handle Wap1, as most are) tries to connect to a server over HTTPS through a Wap connection, is it using weak WTLS to the gateway as in an old Wap1 connection, or is it still using a true HTTPS connection? I am not certain of the answer, and I imagine it would depend on the handset model, browser software and network’s setup (as some gateways can auto-switch between both transparently) so it is difficult to test definitively. If anyone knows please clarify in the comments!

Back to transcoders. The controversial aspect is the way that a transcoder inserts itself into this secure connection in order to “improve” the page markup (I’ll leave the argument about whether transcoders do or don't improve the markup to others). The transcoder forces the browser to make its secure connection to the transcoder, which then makes a subsequent onward connection to the real web server – a model which looks remarkably like Wap1, with better security between handset and intermediary:

Click on that browser padlock while using this scenario, and you would see the transcoder’s certificate and not the certificate of the site you are connecting to. The end result is: whereas in a conventional HTTPS connection, you only share your private information with the site you have chosen, in the transcoding case you share it with the target site and any employee of the transcoder company who has access to the transcoding servers, plus anyone who has hacked the transcoder server.
In reality, any responsible transcoder company would operate their servers with PCI-DSS compliance (the standard required of any company which takes credit card payments), and this would be a minimal risk, but it is more risk than if they weren’t in the loop.

I have discussed this with Novarra (who run Vodafone’s transcoder service in the UK) and they confirmed that they do operate their servers to these standards, but I haven’t talked to any others – and I think some of the concern people feel is that this is not an opt-in service, it is something done to your “secure” connection without your knowledge.
As an aside, Opera have long operated this sort of system with their Mini browser, and their FAQ makes it clear that you should not use the browser for any confidential connections such as accessing your bank – however Barclays Bank, for example, have long recommended Opera Mini for customers wishing to access their accounts on a mobile (recently they have added a disclaimer stating they have no responsibility if you do this):

There is a second problem with any system – Wap1 or transcoders – that obscures the certificate of the end web server. One of the key advantages of HTTPS is that, by providing end-to-end security and trusted certificates, you always know who you are talking to. A major class of attack is the “man in the middle” attack, where a server sits between your browser and the end site and takes a copy of all confidential information passing between them. If a server tried to do this with a true HTTPS connection you would be able to tell, because the certificate you saw would not match the server you thought you were connecting to:

If there was a thief’s server pretending to be the web server, it would not have the correct certificate and you could tell an attack was taking place:

A transcoder in the middle prevents this, because the end user only ever sees the transcoder’s certificate – the end web server’s certificate is only seen by the transcoder. As the user knows nothing about the features of the transcoding software, and the specific deployment configuration of that transcoder on their operator, they cannot tell whether the transcoder has been implemented to correctly verify the end certificate against what the user was expecting:

A thief could easily sit on the other side of the transcoder, and the user would know no better:

This is clearly a retrograde step – moving back towards the insecurity and uncertainty of Wap1. The worry is, if breaking HTTPS security becomes "allowable", we are setting a very worrying precedent for trust in HTTPS and the security of mobile web commerce in the future. History shows that thieves and hackers are becoming rapidly more sophisticated with no signs of stopping – it is difficult to argue that, under those circumstances, we should make things easier for them.

Transcoding servers may take steps to confirm the identity of downstream web server's certificates, and they may not (I am waiting for some confirmation on this from Novarra, for example, and will update the post if and when they provide it). They may prevent the user from accessing sites which have incorrect certificates, or allow the user to choose whether to continue. They may have the ability to do this but allow operators to make these policy decisions, who may not understand the implications. Already we know that some transcoders will not break HTTPS for some banks, but that would be no consolation to a corporate IT department who may unwittingly open up a potential hole in their corporate network, for example.

This is a company blog so I have to mention - the lack of certainty and lack of security on mobile was a key motivator behind Masabi’s creation of EncryptME, which powers our secure applications. We always provide our own full end-to-end security to wrap up transactions, either over the top of SMS or HTTP, giving true desktop-strength security from the mobile, regardless of what the operator or transcoder attempts to do in the middle. Because we understand security and have complete control over application workflow, we also know when to use more than just end-to-end encryption, which is a component of system security but never in itself a guarantor of full security.

Carnival of the Mobilists #155

2009-01-05T12:08:00.002Z

Thanks to Helen for including Ben's last post on this week's Carnival of the Mobilists - check it out for writing on all sorts of interesting topics, and plenty of good New Year predictions!

New Mobile Barcode tickets for UK Rail

2008-12-16T10:50:00.008Z

Finally, after a year of work, the new mobile and self-print barcode standard for UK rail tickets has been approved by the central railway standards body, RSP, a part of ATOC.

The following post intends to give a more detailed understanding than that provided by the general media coverage.

What does this mean?

It means that mobile ticket systems have the chance to come out of the limited scale "Advanced Purchase" projects that they have been providing so far. Train companies can now being to offer instant ticket purchasing that will bring a step change in user convenience.

What's new?

Until now all of the UK rail mobile ticketing trials have used proprietary barcode formats, eligible for "advanced ticket" purchases only. These were valid on a limited set of single-operator routes, limiting their scope enormously.

Previous systems also had ticket scanning restrictions - the scanning device would either have to check all tickets against a central database using a WiFi or GSM connection, or carry a local database of valid tickets which had to be synchronised for every journey. Both of these methods have drawbacks - it is difficult to guarantee a network connection on a moving train, and obtaining one can take time slowing the scanning process; if a local database is used, the time that it is synchronized before a journey represents the last time that a mobile ticket may be purchased.

The new barcode standard has changed all of that. Firstly, one barcode format can now be used across all RSP/ATOC rail franchises. Secondly, by adding proven PKI security, scanners can check the validity of tickets without needing to be online. This is critical for any mass transit system - even after a total failure of the central server systems, thousands of travellers can still have their tickets scanned and pass through gates or guards without any delays (assuming the gates still have power!).

What about the Oyster security problems?

The Oyster system uses vulnerable symmetric cryptography, where the security keys are stored in every card and every scanner. In contrast, the new barcode standard uses asymmetric public/private key cryptography, which prevents anyone changing the content of a ticket after it has been issued. The private key which actually signs the ticket is kept safe on the rail operator's central ticketing server; the public key, which verifies the private key but cannot sign anything, is then installed on the scanners and ticket gates of every rail operator in the scheme.

Even if hackers completely take apart a guard's scanner or a barcode they will only be able to retrieve the freely available public key - they cannot make their own tickets unless they are also able to break 1024bit RSA at the same time. One day this will doubtless be possible, but no-one has yet and it forms the backbone of the HTTPS standard which secures every purchase and financial transaction you perform through your web browser.

Can't I just photocopy the barcode?

The more cunning readers of this blog are correct in seeing the opportunity to photocopy a printed barcode, and then distribute the copies to other travellers who show them to different train guards - as long as each guard's scanner is offline and cannot verify the ticket with the central database. One commenter cleverly suggested using a radio jamming device to ensure that the guard would definitely be offline!

The travellers will 'get away with' the fraud, in that they can continue their journey. When the scanner gets back online or is synchronised at the end of the day, the post-processing systems will identify the multiple uses of the ticket and place an alert against the credit card used to purchase the original, preventing further purchases.

Once the fraud has been detected it is up to the Rail Operator or merchant to invite the user to pay a penalty and unlock their credit card, or (in extreme cases) pursue the credit card holder for the value of the fraudulent travel. If the fraud is detected during the journey and transport police are available, they may even choose to catch the travellers red-handed.

Whatever happens, the window of opportunity for fraud is limited to the period that the scanner is offline for each credit card that you are willing to 'throw away'. A fraudster using a stolen credit card (that hasn't yet been detected by back-end anti-fraud systems) may as well buy two tickets, but the overall scope is limited.

Does everyone have to pay Masabi to use the new system?

Unfortunately not. It is based entirely on open, proven, royalty free algorithms and standards. We designed it this way to encourage rapid uptake by operators and passengers; we hope that the other mobile ticketing vendors already servicing other rail operators adopt this system as soon as possible - so that those rail operators can agree to accept each other's mobile tickets, and expand the choice of routes for mobile ticketing.

So what is the Masabi mobile ticketing product?

Masabi have two mobile ticketing options:

Mobile tickets can be bought on the web and delivered with an SMS link, allowing the customer to download and save the barcode image to their handset;

For best results, users download an application to their mobile phone, smartphone, or iPhone which allows them to purchase tickets as well.

Masabi's new downloaded application provides the full "ticket machine in your pocket" experience, where a brand new user can instantly buy tickets without any prior sign-up. They can buy tickets through their mobile from the back of a long queue, when the ticket machine at their rural station is broken, or from the back of a taxi on the way to the station. First time users type in their credit card number and CV2; repeat users only type their CV2 to confirm each purchase, with absolutely NO usernames or passwords to get in the way. See our ticketing page for more details.

Isn't the pricing too complicated?

Thankfully the new fare simplification process is cutting down the number of fare options on each route, especially for the "walk-up-tickets" that you buy in the station immediately before travelling. The mobile application makes a seperate price check with the server the first time that the user requests a ticket, and then uses those stored prices for any future purchase until the server indicates that they have changed, sending back new prices.

Does every rail operator get Masabi's Pocket Ticket Machine?

Nope, the Masabi ticket sales application is a Masabi product that rail operators, or the operators' ticket supplier, can choose to make available to their customers - we do a quick graphics job, a server integration and they're ready.

Will I need a seperate ticket purchase application for each Rail operator?

As long as all operators involved agree to use the new shared ticket standard, you should be able to buy a ticket from Operator A and travel on a route served by Operator B.

What do the Rail Companies need to do to use the standard?

When the volume of tickets is small, guards or stations can operate a manual ticket check system by typing in the ticket number and requesting ticket details from the server, either by SMS or via their portable ticket computer. If the volume of tickets increases guards should be issued with barcode scanners - either the standalone pocket-sized scanners or a scanner integrated with their normal carry-on ticket machines. When volumes of barcode tickets get even higher, scanners can be fitted to their gates. Check out pictures of the scanner options here.

Masabi are already working closely with Atos Origin, one of the dominant rail infrastructure providers in the UK, who supply most of those portable ticket machines that Rail staff carry on the trains; the integration process can be handled by Atos if the rail operator wants.

Operators that already have a mobile ticketing system will need to ask their supplier to change the barcode format, which should in most cases simply be a software change.

Where has this new ticket standard been launched?

The new barcode standard has only just been defined and approved by RSP, so it hasn't been used anywhere yet in it's final form. The Chiltern and Heathrow Express mobile ticket systems were built with barcode formats that pre-date the standards work, but the National Express East Coast system is running the final precursor to the actual RSP standard.

Any More Questions?

If you would like to know anything else, please ask away in the comments!

Carnival of the Mobilists 146

2008-10-20T11:15:00.002+01:00

Carnival of the Mobilists 146 over at London Calling has included Tom's post on NFC alongside a whole range of great articles, check it out for the best in mobile writing!

NFC - One Day, It'll Be Great

2008-10-15T19:24:00.004+01:00

Currently there are two potential candidate technologies for scanning an electronic ticket held on a mobile phone - 2D barcodes (visual scanning) and NFC (wireless scanning). From Masabi's point of view they are interchangeable - just connection technologies for our ticketing services, which can support either - but MoMo London's NFC event this week provided some very interesting confirmation that barcodes will be ruling the roost for some time.

The event had a great mix of speakers, covering the full breadth of the technology from potential use cases right through to a speaker from O2 covering their recently concluded London-based trial. Telefonica/O2 have been the most agressive European operator backers of the technology, and their trial stats were very positive on the surface, but they didn't stand up to much scrutiny.

The headline 80+% approval ratings all came from Londoners who had been given free handsets that they could use as Oyster cards (for travel on the Tube), with free credit to get them started - I'd certainly be very happy with that! The majority of the UK population - and the majority of the European and world populations - haven't been obliged to use a widespread NFC-based network every day for several years, so it is unlikely that these interest levels could be replicated elsewhere.

The most telling thing about Claire from O2's talk, though, was that the trial was so successful that O2 now had enough data for... directing another trial, at some point in the future. Moreover she stated that O2 had decided they were not interested in taking any revenue share from NFC payments, whilst acknowledging that they as the operator would bear the brunt of user support costs for on-phone NFC payments. Does that setup make O2 likely to spend money rolling out a service which will then cost them more money to run, with no revenue upside?

Just to confirm this pessimistic view, Claire declared that O2 would only consider a commercial launch in partnership with all operators, offering a wide range of NFC-enabled devices. However consider:

Currently only Nokia have an NFC handset on the market (a niche mid-range feature phone);
That handset isn't widely available through operators on contract;
No other major manufacturer has announced an upcoming NFC handset;
Handset manufacturers will only increase the cost of a device by putting NFC into it if the operators ask them to - clearly, they aren't.

Claire's tone of voice seemed... cautious when she suggested that analysts reckoned it might get big in 2012. Even if we ignore the impact of potential world recession on the technology industry, that seems optimistic:

New handsets take time to design and new features require new skills to integrate into hardware and firmware;
There is a clear lag between handsets first arriving in the shops and those same handsets becoming widespread, as users usually only upgrade at the end of a contract;
Handset upgrade cycles are slowing down as operators try and encourage customers onto 18 and 24 month contracts, instead of the more usual 12 (Orange recently offered me a massive discount for just such a move when I upgraded to Nokia's flagship N96, which contains every feature under the sun - except NFC).

Going mainstream in 2012 suggests a lot of new NFC handsets will be commissioned, designed, manufactured and shipped out in volume by the start of 2011, just over two years from now... possible, but unlikely.

So is NFC living on perpetual limited-scale-trial life support? That may be the case for on-handset NFC, but James from Mastercard hinted at the real future of the technology - already hundreds of thousands of normal credit and debit cards have shipped out NFC-enabled, even if their owners don't have any idea what that means.

It is not a huge leap of the imagination to see NFC as being "cheap enough" to just implement in next generation card processing terminals, so the natural upgrade cycle of those terminals leads to a widespread "stealth" deployment of NFC processing capability - without requiring retailers to actually pay out for a massive infrastructure upgrade so soon after Chip and PIN was introduced. Once the technology is out there, it may start to be understood and used, and once it starts to be used the added advantages of NFC on handsets may be compelling enough - and cheap enough - for a mass market roll out.

Until then, we'll stick to a two pronged approach: 2D barcodes for our mainstream ticketing solutions, and limited scale NFC deployments where the handsets and infrastructure are available.

FrontlineSMS (part 1) - the SMS Hub for NGOs

2008-10-10T17:48:00.014+01:00

Recently we've been working with kiwanja.net, a mobile-focused specialist in anthropology, conservation and development founded by Ken Banks, chair of the W3C's Mobile Web for Social Development Interest Group. Previously we've developed Silverbackers for Ken, and over the last 12 months we've been developing FrontlineSMS.

FrontlineSMS is an SMS hub aimed at the not-for-profit sector. Setup costs are minimal - all that's required is a computer and a mobile phone. The desktop client can then send and receive SMS messages in bulk, and organise contacts. More advanced functionality is also available, which we'll be going into in future blog posts.

The first public (beta) release was 6 months ago, and we've recently hit 700 downloads. As the map shows, usage has been widespread and varied.

Here are some of the most high-profile uses so far:

Malawi - Rural Healthcare

In St. Gabriel's hospital in Namitete, Malawi, Josh Nesbit used FrontlineSMS to set up a system to co-ordinate volunteer health workers. The hospital's catchment area covers 250,000 people over 30,000 square miles, with only three medical officers employed by the hospital. Using FrontlineSMS, St. Gabriel's 600 volunteer Community Health Workers (CHWs) can now get quick access to information about drug doses, keep the hospital updated with the status of discharged patients and request further assistance. The hospital can also contact a CHW if one of their patients has missed an appointment.

Afghanistan - Security Updates

A major international aid organisation has been using FrontlineSMS in Afghanistan to help keep their staff out of harm's way:
"Drivers receive updates on traffic congestion, road blocks, police operations, VIP movements, local minor security incidents and anything else that might be useful as they travel. Senior staff receive SMS messages regarding larger security incidents that may require them to modify program activities for the short term. Incidents that influence activities in other areas are sent to the sub-office group. Finally we have an 'All Staff' category for those situations where we need to notify or account for everyone as quickly as possible"

Zimbabwe - Election News Updates

Zimbabwean human rights NGO Kubatana used FrontlineSMS to share information during that country's turbulent elections earlier this year. As well as helping to distribute updates on the latest developments in the presidential struggle, they used FrontlineSMS it to collect and share opinions from their readership.

For more info on FrontlineSMS in action, check out this post on the kiwanja.net blog.

Job Vacancy: Server Programmer

2008-10-06T13:47:00.008+01:00

Masabi are looking for a London-based Server Programmer to come and work at our offices on the South Bank – our ideal candidate will be flexible and multi-talented, main responsibilities would include:

Building scalable reusable server proxies allowing J2ME and mobile web clients to talk to our partner's back-end web services;
Extending and maintaining our deployment and mobile web server, which identifies and optimises content based on the connected device.

Technologies we use currently:

JavaEE with Tomcat and Weblogic;
Hibernate, Quartz, Castor, Rome;
Integration into SOAP, REST, SMPP etc;
MySQL and MS SQL Server;
Hosting on Linux and Windows Servers.

We’re a small company so there are huge opportunities to get involved, learn and advise across the board and an ideal candidate would be able to show they bring a lot more to the table – surprise us! Experience working with a wide range of local and remote customers is definitely a bonus.

Email those CVs over to jobs (at) masabi.com with the subject line "SERVER PROGRAMMER OCTOBER 2008" or give Ben a call on +44 207 981 9781 to find out more - please also give us an idea of salary expectations and visa status for working in the UK.

Please - no agencies, and no contractors - we're after a full time employee.

The office that you might be coming to work in:

Some more photos:
Exterior, Interior

This map shows it has great access to food heaven at Borough Market, very close Tube stops at Borough, London Bridge and Southwark, and commuting access from the Thames Water Taxi as well as trains coming into Waterloo or London Bridge stations.

Carnival of the Mobilists #143

2008-10-01T10:33:00.002+01:00

Thanks to this week's host of Carnival of the Mobilists, The Phones Show, for voting my last post on fragmentation post of the week. There's plenty of other interesting stuff in this week's Carnival so go check it out!

The Mobile Web and Fragmentation

2008-09-24T12:09:00.006+01:00

Last week I read some interesting comments that came out of the last MoMo London event on whether the mobile web is the only way to deliver mobile services, and whether it will fragment like every other mobile development platform. I thought it was worth republishing my comments in an extended form here on our official blog as this is an area in which a number of people have an opinion, and there is a real divide between the optimists and the realists.

Firstly, the choice of platform for a mobile service is not clear cut and we strongly believe at Masabi that no single platform is the 'winner'. Some types of service are better SMS driven, some as standalone apps, some purely web-based, some as a hybrid and some will simply never actually work in the real world. At Masabi, we focus on areas where standalone apps deliver the best experience, but tie in SMS in various innovative ways and offer web fallback where viable, but we always assess every project on its own requirements.

Ultimately, mobile phone users wants easy to use services that make their lives better and are context-relevant. It is difficult to see evidence for many users clamouring for 'One Web' and access to desktop-optimised web sites on their small phone screens; the success (and clearly superior usability) of, for example, the iPhone-optimised GMail and Facebook sites show that 'one web' is often not actually in the user's interests. The even greater improvements achievable with dedicated apps - look at, for example, Google Maps on the iPhone - further suggest this is wishful thinking, and one size does not fit all.

The fragmentation issue is a thorny one. People mean many different things by fragmentation, and for some reason Java is a particular target for misinformed comment. Mobile fragmentation comes from a huge range of issues, from bugs and implementation inconsistencies, different screen sizes (a problem for any application that wants to look better than a 1996 web page), different interaction mechanisms (touchscreens, qwerty and numeric keypads are not alike), different hardware features (only some phones have GPS, camera, Bluetooth) etc. These issues apply equally to browsers and standalone applications.

The mobile web is still relatively young by many counts (despite the legacy of Wap), and it is only recently that users have been presented with browsers which are not a punishment to use. They are improving rapidly, as they must, but they are subject to the same Quality Assurance constraints that beleaguer all mobile phone firmwares – the lifecycle of a mobile phone is driven by the marketing department much more than the software development department, and TV advert deadlines are less amenable to change under pressure than bug lists.

The mobile browser world is extremely fragmented already when viewed as a whole - and even if you ignore 85% of users and look only at smartphones, it is still fragmented. There are many bugs even in rendering, and they don't get fixed because updating firmware is still non-trivial. Once you start looking at scripting the picture gets worse:

There are no standards for things like camera access, and all mobile history suggests that will lead to manufacturers adding proprietary extensions – some are being suggested, but none yet have Nokia, Samsung, Apple et al signed up.
There are and will continue to be differences in performance and implementation specifics for all of these new APIs even after standardisation, just like desktop browsers but with more variables - even when the underlying rendering engine is the same eg. Webkit.
Offline scripting engines like Google Gears really make things worse. A chat with one of the Gears guys at the previous MoMo London was revealing - Apple will never have Gears on the iPhone, which means instant fragmentation even if some parts of the API are copied over. They only offer it for Windows Mobile now with Symbian support hinted at soon - but Google will NOT pursue a strategy of bundling on devices, which means users must perform a complicated native app installation to get Gears. How many users will do this? Few, I think - and it leaves feature phone users, vastly outnumbering their smartphone brethren, out in the cold.

There are two ways to work around these handset differences - downloading a single big script which contains variants for everything (the current desktop way) or running servers which auto-switch based on the HTTP User-Agent header and a database like the WURFL. The former approach means more data shifted (which is still not free for most people, and certainly isn't instant) with a greater memory and performance overhead when it arrives. The latter will risk becoming a rat's nest of script conflicts - scripting is lovely for quick development but a nightmare for maintenance of multiple different library versions. Desktop browsers still require browser-specific workarounds in the script as they are still not all compatible, despite years of Javascript development and auto-updates over broadband - it is inconceivable that mobile, with more platforms, more browsers, more device variation and fewer updates, will not suffer similarly.

Even ignoring all of this, the kind of AJAX webapps people use today are feasible because PCs have effectively free always-on high bandwidth network connections, effectively free mains electricity supplies or laptop-style battery expectations, and fast processors tied to loads of memory and even more storage for caching, and a single consistent UI model with mice, full keyboards and big screens. XML may carry a huge overhead over the network, and scripting may consume a vast amount of clock cycles, but it doesn't matter because both are plentiful. A drag and drop UI model, like Flickr's Organizr, can work on Safari on the Mac and also IE on a PC with only a few code tweaks. Does this sound like a mobile device? Some of these areas are improving, some aren't, but it doesn't avoid the fact that AJAX webapps are not a natural fit for handsets.

The browser is a natural fit for a huge number of mobile services, and improvements in browsers are certainly very welcome (and overdue). The browser is not the be-all and end-all of the mobile user experience though, and developers who believe it is are to some extent working for the world they wish existed, not the one that does exist.

Despite immensely rapid technical innovation in the mobile world, actual adoption rates of new phone software like browsers is slow with upgrade periods lengthening and a very large installed base of users on legacy phones. Masabi recognises this and out applications support the very widest array of handsets possible, because for many real world services you can never be sure the users who would benefit from the service are the same as the users who always upgrade to the latest handset.

(Disclaimer/plug: I'm one of the MoMo Estonia chapter founders, but I keep referring to MoMo London events simply because they are extremely good and not because of any MoMo bias!)