The team at Telco2.0 have run some good conferences, and there’s much to applaud in their Manifesto. Recently, the Telco2.0 blog has run a couple of hit-and-miss pieces of analysis on the Symbian Foundation. There’s a lot of speculation in their pieces, and alas, their imagination has run a bit wild. The second of these pieces, in particular, is more “miss” than “hit”. Entitled “Symbian goes open – or does it?”, the piece goes most clearly off the rails when it starts speculating about Symbian Signed:
…the Symbian signing process doesn’t just apply to changes to Symbian itself — it applies to all applications developed for use on Symbian, at least ones that want to use a list of capabilities that can be summed up as “everything interesting or useful”. I can’t even sign code for my own personal use if it requires, say, SMS functionality. And this also affects work in other governance regimes. So if I write a Python program, which knows no such thing as code-signing and is entirely free, I can’t run it on an S60 device without submitting to Symbian’s scrutiny and gatekeeping. And you though Microsoft was an evil operating system monopolist…
This makes the Symbian signing process sound awful. But wait a minute. Isn’t there a popular book, “Mobile Python – rapid prototyping of applications on the mobile platform“, written by Jurgen Scheible and Ville Tuulos, that highlights on the contrary just how simple it is to get going with sophisticated Python applications on S60 devices? Yep. And what do we find as early as page 45 of the book? A two-line program that sends an SMS message:
import messaging
messaging.sms_send(“+14874323981″, u”Greetings from PyS60”)
I tried it. It took less than an hour to download and install the SIS files for the latest version of PyS60 from Sourceforge, and then to type in and run this program. (Of course, you change the phone number before testing the app.) Nowhere in the process is there any submitting of the newly written program “to Symbian’s scrutiny and gatekeeping”. The fanciful claims of the Telco2.0 piece are refuted in just two lines of Python.
So what’s really going on here? How is it that normally intelligent analysts and developers often commit schoolboy howlers when they start writing about Symbian Signed? (Unfortunately, the Telco2.0 writers are by no means unique in getting the Symbian Signed facts wrong.) And why, when people encounter glitches or frustrations in the implementation of Symbian Signed, are they often too ready to criticise the whole system, rather than being willing to ask what small thing they might do differently, to get things working again?
I suspect three broader factors are at work:
1. An over-casual approach to the threat of mobile malware
Symbian Signed is part of an overall system that significantly reduces the threat of mobile viruses and the like. Some developers or analysts sometimes give the impression that they think they stand immune from malware – that it’s only a problem that impacts lesser mortals, and that the whole anti-malware industry is a “cure that’s worse than the disease”. Occasionally I sympathise with this view, when I’m waiting for my desktop PC to become responsive, with its CPU cycles seemingly being consumed by excessive scanning and checking for malware. But then I remember the horrors that ensue if the defences are breached – and I remember that the disease is actually worse than the cure.
If we in the mobile industry take our eye off the security ball and allow malware to take root in mobile phones in ways similar to the sad circumstances of desktop PCs, it could produce a meltdown scenario in which end users decide in droves that the extra intelligence of smart mobile phones brings much more trouble than it’s worth. And smartphones would remain of only niche interest. For these reasons, at least the basic principles of Symbian Signed surely deserve support.
2. A distrust of the motivation of network operators or phone manufacturers
The second factor at work is a distrust of control points in the allocation of approvals for applications to have specific capabilities. People reason something like this:
- OK, maybe some kind of testing or approvals process does makes sense
- But I don’t trust Entity-X to do the approving – they have mixed motivations.
Entity-X could be a network operator, that may fear losing (for example) their own SMS revenues if alternative IM applications were widely installed on their phones. Or Entity-X could be a device manufacturer, like Apple, that might decide to withhold approval from third party iPhone applications that provide download music stores to compete with iTunes.
Yes, there’s a potential risk here. But there are two possible approaches to this risk:
- Decide that there’s no possible solution, and therefore the power of a system like Symbian Signed should be criticised and diminished
- Work to support more of the decision making happening in a fully transparent and independent way, outside of the influence of mixed motivations.
The second approach is what’s happening with the Symbian Foundation. The intent with the Symbian Foundation is to push into the public sphere, not only more and more of the source code of the Symbian Platform, but also as much of the decision-making as possible – including the rules and processes for approval for Symbian Signing.
Incidentally, the likely real-world alternative to a single, unified scheme for reviewing and signing applications is that there will be lots of separately run, conflicting, fragmented signing schemes. That would be a BAD outcome.
3. A belief that openness trumps security
This brings us to the final factor. I suspect that people reason as follows:
- OK, I see the arguments for security, and (perhaps) for quality assurance of applications
- But Symbian Signed puts an obstacle in the way of openness, and that’s a worse outcome
- Openness is the paramount virtue, and needs to win.
As a great fan of openness, I find myself tempted by this argument from time to time. But it’s a misleading argument. Instead, freedom depends on a certain stability in the environment (including a police force and environmental inspectors). Likewise, openness depends on a basic stability and reliability in the network, in the underlying software, and in the way the ecosystem operates. Take away these environmental stability factors, and you’ll lose the ability to meaningfully create innovative new software.
The intention behind Symbian Signed to help maintain the confidence of the industry in the potential of smartphones – confidence that smartphones will deliver increasing benefits without requiring debilitating amounts of support or maintenance.
It’s true that the rules of Symbian Signed can take a bit of learning. But hey, lots of other vital pieces of social or technical infrastructure likewise take time to appreciate. In my mind, the effort is well worth it: I see Symbian Signed as part of the bedrock of meaningful openness, instead of some kind of obstacle.
dw2 
David / thx for contributing to the open source debate! I wonder what security implications are being presented to Symbian?
In the computing world there’s plenty of debate about the impact of opening up previously proprietary code. The primary concern being that an open source model exposes code not only to benevolent practitioners but also to malevolent attackers.
With much of the mobile industry steering towards m-commerce initiatives, potential security risks must be considered. The mobile terminal (including the SIM card) is being positioned as a trusted m-wallet solution with users able to transfer funds and pay for good and services through channels such as NFC (near field communications). Will the storage of highly personal data on the mobile device, combined with the world’s most commonplace mobile operating system going open source collide to become the catalyst that makes mobile security breaches a very threat?
Conversely, green-field open source projects benefit greatly from the open source community. The power of a collective community means security flaws are continuously peer reviewed. Is it thus true to say that while green-field open source projects will be able to mitigate major security threats prior to mass-market adoption, it will be some time before a previously closed operating system reveals and patches all of its flaws.
How much of the legacy Symbian code will be scrapped and built from scratch according to open source best practice?
Keen to get your views. Also blogged at http://wirelessinformaticsforum.wordpress.com/
Comment by wirelessinformaticsforum — 8 July 2008 @ 9:40 am
Whilst I agree that making code open source will tempt malevolent developers to exploit the weaknesses of the system, it will only add to the robustness and security of Symbian OS in the long run. And don’t forget that opening up a security system (e.g. Platform Security in this case) will hopefully not reveal any major flaws in it – good design shall survive the “threat” of publicity.
On the other hand, open source often means free at the same time. If everything (Symbian Signed, advanced IDE, etc.) was free (just requiring the burden of administration) or at least reasonably cheap, people would complain less, I guess.
Comment by Gábor Török — 8 July 2008 @ 8:20 pm
Hi Gábor
There are tensions with a mobile phone OS that is open for applications.
Mobile phone carriers worry about the integrity of their network. Phone makers worry about the support costs of fubared phones.
Meanwhile the OS company wants a lively ecosystem to make their offering more attractive than the competition.
Many useful applications do not need signing, e.g. a tool that interfaces to your contacts database to remove or merge duplicates. Even things like FExplorer can achieve nearly everything it does with no signed for capabilities.
Symbian does not have a huge tools development team to work on an IDE, issue signing certificates or perform the Symbian Signed testing. These are not our core compentencies, and so must be obtained from third parties.
If you are willing to supply any or all of these at lower cost I’m sure you will have market. 🙂 But I am not sure how solvent your business would be.
Comment by Tony — 8 July 2008 @ 11:11 pm
From Forum Nokia:
# What is a Symbian developer certificate and when do I need it?
#
A Symbian developer certificate is needed if your application requires certain capabilities and you want to test the application on a real device (for S60 3rd Edition applications only). A developer certificate can be requested at http://www.symbiansigned.com -> Request DevCerts; authentication depends on how many devices you have and which capabilities you request.
Number of IMEIs: 1
Authentication: Symbian Signed Account
Granted capabilities: LocalServices, ProtServ, UserEnvironment, NetworkServices, Location, ReadUserData, WriteUserData, SW Event, SurroundingsDD, ProtSrv, PowerMgmt, ReadDeviceData, WriteDeviceData, TrustedUI.. NetworkServices being the group messaging falls into.
Comment by Alex — 10 July 2008 @ 4:36 pm
Did you actually test the symbian signed site, e.g. freely signing a non malicious application?
As for today, I tried to sign Dr. Jukka’s excellent tool to provide crash reports, watch RAM usage.
It doesn’t work. Host communication error. I tried to get an account, it hated my @fastmail.fm claiming it is a free address… OK, used my own sites POSTMASTER account, it rejected that one too.
Someone seriously jokes with end users at Finland. Stop pushing people to “hack” their phones while there is NO reason.
Comment by ilgaz_public — 24 July 2008 @ 9:49 am
sorry for duplicate, there is another issue that people who has hard time getting their app signed gets diverted to some weird sites in foreign languages which they give their IMEI number.
As you are all in telecom business, you should know what kind of dangerous thing it is.
Comment by ilgaz_public — 24 July 2008 @ 9:52 am
Hi ilgaz_public
>I tried to sign Dr. Jukka's excellent tool to provide crash reports, watch RAM usage.
Can you please give me a pointer to where I can find the tool you mention?
Thanks in anticipation.
// dw2-0
Comment by David Wood — 24 July 2008 @ 6:24 pm
Hi David
I think the tool ilgaz is referring to is Y-Tasks for S60, here:
http://www.drjukka.com/YTasks.html
ttfn
Comment by Tony — 24 July 2008 @ 8:26 pm
Hi Tony,
>I think the tool ilgaz is referring to is Y-Tasks for S60, here.
Thanks for the pointer. It’s an interesting tool set. (It reminds me of a “Spy” app that I helped to write many years ago, but that’s another story.)
The apps (apart from the “Mainserver”) are all self-signed by Dr. Jukka. They install fine onto my Nokia E61i (since I run with the setting that allows installation of self-signed apps). Once installed, they all do useful (and in some cases fascinating) things.
Hi ilgaz,
>I tried to sign Dr. Jukka's excellent tool to provide crash reports, watch RAM usage
My experience is that you don’t need to (re-)sign the tools, in order to provide crash reports or watch RAM usage. These features seem to work fine, even without installing the Mainserver. For example, on my device, the crash monitor shows lots of processes as having exited. So Symbian Signed doesn’t seem so awkward in this case.
Apologies if I have misunderstood what you’re asking!
The remaining question is how to get the few additional pieces of high-powered functionality that the Mainserver would enable. Yes, so far as I can see, that last step does require the creation of a Developer Certificate, which in turn requires the creation of TC TrustCenter Publisher ID. But since these last pieces of functionality can cause significant damage to any device that this server runs on, I can see the argument for why some extra checks are imposed in this case.
// dw2-0
Comment by David Wood — 24 July 2008 @ 9:20 pm
I think the issue here is , we (even technical users) don’t really get what should be signed, what shouldn’t.
I am trying to help Symbian developer community (both commercial or free) by running beta apps or provide crash reports on commercial apps I bought.
I thought the crash data should be accessible only by signed apps so I tried to sign it myself (with my IMEI). As the symbiansigned didn’t work, it diverts me to a much more dangerous situation as signing the app with a third party which I sure don’t know who they are or plain hacking the phone (which will force me to full feature AV).
I wanted to express that when I saw Symbian Signed, in real World, for advanced users, at least for that day, it didn’t work.
I am completely against my favorite computer vendors idea of doing things but people, at least knowing how things work should be able to sign their own stuff better.
Comment by ilgaz_public — 25 July 2008 @ 10:37 am
Exactly the kind of misleading half-truth I’ve come to expect from Symbian Signed people. Yes, you can write that python script in the script shell, and it will work. Only because you very carefully selected your example.
What happens if you want to package that same scriptlet in a sis to make it easy to run and install, so you don’t have to run it awkwardly through the script shell every time? Not so simple any more.
What happens if you want to include your current location in the said message? Not so simple any more.
What happens if you want to distribute it as freeware to other people without forcing them to jump through “open”signed hoops, or paying yearly wads of cash for publisher ID? Oops, impossible.
Comment by Juhaz — 3 September 2008 @ 3:56 pm
Exactly the kind of misleading half-truth I’ve come to expect from Symbian Signed people. Yes, you can write that python script in the script shell, and it will work. Only because you very carefully selected your example.
What happens if you want to package that same scriptlet in a sis to make it easy to run and install, so you don’t have to run it awkwardly through the script shell every time? Not so simple any more.
What happens if you want to include your current location in the said message? Not so simple any more.
What happens if you want to distribute it as freeware to other people without forcing them to jump through “open”signed hoops, or paying yearly wads of cash for publisher ID? Oops, impossible.
Comment by Juhaz — 3 September 2008 @ 3:56 pm