dw2

27 December 2008

Revocation infrastructure

Filed under: revocation, Symbian Signed — David Wood @ 1:30 pm

In the quest to stop bad applications from doing damage to the data or operation of a phone (or running up large bills, or otherwise adversely impacting the phone network), possible approaches divide into two main routes:

  1. Put the main focus on checking and testing software (and the originator of the software) before it is allowed to be distributed or installed;
  2. Be permissive as regards the initial distribution and installation of software, but withdraw (or “revoke”) these permissions if it becomes clear that the software has bad effects.

It seems to be the consensus view that it is impractical (if not impossible) to reliably identify bad software by any prior checking system. These checks will always fail on at least one criteria:

  • The tests will be insufficient to cover all usage conditions; applications which work well on some handsets on some networks may well go wrong on other handsets or other networks;
  • Any attempt to make the tests more reliable will introduce unacceptable time delays and cost.

The best that an application checking system can hope to accomplish is a quick sanity test – to spot significant errors. Inevitably, this means that some bad software will slip through the system. As a result, any anti-malware system on mobile phones needs to consider at least some revocation component.

In principle, here’s what revocation could accomplish:

  1. The process of releasing software (including alpha and beta versions) could be relatively quick and painless;
  2. An application that is subsequently found to generate problems on phones could be removed from distribution lists and application stores, to prevent anyone else from installing it;
  3. Messages could be sent to all phones on the network with the effect that users who have already installed the application could be warned about these problems – and given the opportunity to uninstall it;
  4. In more extreme cases, these messages could cause the applications to be automatically uninstalled, without waiting for the approval of the user;
  5. In yet other cases, the developer who signed the application could be barred from signing any more applications – this could be appropriate in cases where the developer has been caught out making pirated zero-cost versions of commercial software.

This picture is attractive. However, we need to be aware that it relies on the existence of a “revocation infrastructure”. One part of this infrastructure is the reliable identification of an application. This is accomplished via tamperproof digital signing. However, this is only the start of what’s needed for revocation to work.

It was because of the lack of a developed revocation infrastructure that the original Symbian Signed scheme followed route 1 above – Put the main focus on checking and testing software (and the originator of the software) before it is allowed to be distributed or installed – rather than route 2 – Be permissive as regards the initial distribution and installation of software, but withdraw (or “revoke”) these permissions if it becomes clear that the software has bad effects.

Here are some of the issues with the mechanics of revocation:

  1. By default, checking at install time for revoked certificates is currently turned off for most (if not all) shipping Symbian phones;
  2. The user would in principle have to pay for the data traffic to check for revocation;
  3. Operators ought ideally to agree on something like a free dedicated access point which is supported across networks while roaming, etc., before it’s acceptable to turn this on for the majority of users;
  4. Revocation checking is done on most phones at software install time, there is limited current support for push revocation;
  5. If the revocation checking was defaulted to on, the user could still turn it off for most (if not all) devices;
  6. Software that deliberately or accidentally broke PlatSec partitioning of processes & data could disable the revocation check.

In addition, there are some issues with the policy of revocation:

  1. There is bound to be controversy over who has the authority to decide to revoke a certificate;
  2. Some applications that run without problems on some networks may cause problems to other networks; does this mean that revocation may need to be specific to individual networks?
  3. Some applications that users like and admire may be viewed as malware by other users;
  4. For example, users may have entered considerable amounts of data into an application, that is subsequently forcibly uninstalled due to being revoked; users may complain about no longer have access to their data;
  5. Some application writers may seek to contest decisions to declare their software as malware.

I’m not saying these issues are insurmountable. There are candidate solutions for all these issues. But I do want to point out that revocation has its own costs.

My own view nowadays is that even a partially working revocation would probably still be a better system than the current reliance on centralised testing of applications before they can be distributed.

By “partially working revocation” I mean a system that works by community reviews. Users who notice problems with applications would be encouraged to publicise these issues, so that the community as a whole can weigh up the evidence. Popular application stores would take this information into account in the material provided to describe the applications available for download.

In principle, users would be willing to pay money for a premium service from application stores, as follows:

  • The application store remembers which users have downloaded which applications;
  • If an application is subsequently deemed to be problematic (on, say, particular phones), then relevant users would be sent messages alerting them of this situation.

In some ways, this premium service would be akin to the anti-virus monitoring solutions that are already available from some security specialist companies – although the implementation mechanism would be different.

Note finally that I’m not advocating opening all functionality to all developers, without any vetting. I believe that functionality such as AllFiles, DRM, and TCB, still needs to be carefully controlled, and cannot fall under a system of “use until revoked”. One argument in support of this view has already been mentioned (point 6 in the list above of issues with the mechanics of revocation).

24 December 2008

Symbian Signed and pirated applications

Filed under: piracy, Symbian Signed — David Wood @ 9:22 pm

In the spirit of “divide and conquer” I’d like to try again to focus on just one out of the many sub-topics that whirl around discussions of Symbian Signed. On this occasion, the particular sub-topic is:

  • Is there merit in using (or modifying) Symbian Signed processes to reduce the prevalence of pirated Symbian applications?

I stated the underlying requirement as follows in “Symbian Signed basics“:

c. Reducing the prevalence of cracked software

To make it less likely that users will install “cracked” free versions of commercial applications written by third parties, thereby depriving these third parties of income.

The idea is simple enough:

  • A developer D0 creates an application A0, has it signed, and sells it for a fee
  • To avoid users making and distributing copies of that application, without paying additional fees to the developer, the developer includes an element of copy protection in the application
  • This restricts the application to run on a device identified by (say) an IMSI or an IMEI
  • Some users will be developers in their own right, who possess the programming skills to alter the application to bypass the copy-protection code, creating a cracked version A1
  • In principle, A1 can be copied and will run on a wider number of devices, thereby depriving the developer of additional income
  • However, because A1 is a tampered version of A0, the original signature is no longer valid, so A1 will fail to install.

On the other hand, any developer D1 can access the Symbian Signed mechanism to put a different signature onto the application A1, thereby completing the circumvention of the copy-protection mechanism. The lower the expense of obtaining a signature, and the easier that process becomes (for example, by removing an independent testing phase), the more likely it is that cracked but installable applications (like A1) will circulate.

This is where the requirement to “make it easier for developers to carry out widespread beta testing” comes into tension with the requirement to “reduce the prevalence of cracked software”.

OK, having laid out the context, it’s time for me to state my own opinion on the matter.

I suspect that piggy-backing on Symbian Signed is probably not the best route for a developer D0 to avoid pirate versions of their application A0 circulating. That’s for the following reasons:

  1. It seems inevitable that the Symbian Signed mechanism will continue to become cheaper and easier to operate – in order to address the huge demand to “make it easier for developers to carry out widespread beta testing”
  2. The only kinds of apps which will be difficult for cracker developers D1 to re-sign are those which make use of some high-powered capabilities (like AllFiles or DRM or TCB), which in turn only apply to a small proportion of applications like A0.

So developers D0 ought instead to seek to use other copy-protection mechanisms – such as those involving DRM.

At the same time, the pressure for users to seek free copies of applications will reduce, provided the prices levied for these applications seem reasonable to large numbers of users. In turn, one thing that will allow these prices to remain low is if the population of users buying the applications is large, and if there is an efficient marketplace mechanism (akin to the iPhone AppStore) for users to discover and purchase applications.

(Aside: One more avenue to explore is if mechanisms could be put in place for developers to earn a proportion of ongoing network data or advertising revenues from the use of their application.)

To summarise: I’d like to take the question of “Reducing the prevalence of cracked software” off the Symbian Signed discussion table. (But I remain open to being persuaded otherwise.) That table is already cluttered enough, and the more we can remove from it, the easier it will be to reach a satisfactory consensus view.

Footnote: This posting is #3 out of N I expect to be making about Symbian Signed, where N could become as large as 10.

16 December 2008

Symbian Signed and control

Filed under: operators, Symbian Signed — David Wood @ 8:58 am

My posting yesterday on “Symbian Signed basics” has attracted more comments (containing lots of thoughtful ideas as well as evident passion) than I can quickly answer.

For now, I’d like to respond to Ian, who raised the following point:

There is no need for signing to ensure safety from malware. That’s what (platform) security is for.

Requiring signing without the option of user override is about control, pure and simple.

Can you give me a good reason why people should not have control of their property and why it should be in vendor’s hands instead?

The first answer is that, when users purchase a phone, they typically enter into a contract with the supplier, and agree to be bound by the terms of that contract. In cases when the phone is being subsidised or supported by a network operator, the network operator only enters into the relationship on account of a set of assumptions about what the user is going to do with the phone. The network operator can reasonably seek to limit what the user does with the handset – even though the user has paid money for the device.

That’s the reason, for example, why T-Mobile stipulated (and apparently received agreement from Google) that no application providing VoIP over cellular data could be installed onto the Android G1. Otherwise, the cost and revenue assumptions of T-Mobile would be invalidated. From Daniel Roth on Wired:

T-Mobile made a big deal about being one of the few carriers embracing open standards and open systems — which is true. Yet just how open is a (sorry) open question. When I talked to Cole Brodman, the CTO of T-Mobile, after the event about what would stop something like Skype from designing a program that could run on the phone, negating the need for a massive voice plan, he said he had “worked with Google” to make sure Android couldn’t run VOIP. “We want to be open in a way that consumers can rely on,” is the way Brodman put it to me.

Here’s another example. Suppose you spend a lot of money, buying a phone, and two months afterwards, you notice that the battery systematically runs down after only a few hours of use. You’re naturally upset with the device, so you take it back to the shop where you bought it from, asking for your money back. Or you spend hours on the phone to the support agents of the network operator trying to diagnose the problem. Either way, the profit made by the handset manufacturer or the network operator from selling you that phone has probably been more than wiped out by the cost of them attending to this usability issue.

But suppose it turns out that the cause of the battery running flat is a third party application you installed which, unknown to you, burns up processor cycles in background. Suppose it also turns out that you have been misled as to the origin of that application: when you installed it, you thought it said “This application has been supplied by your bank, Barclays”, but you didn’t notice that the certificate from the supplier said (eg) “Barclys” instead of “Barclays”. You thought you could trust the website where you found this application, or the people who (apparently) emailed it to you, but it turns out you were wrong. However – and this is the point – you’ve even forgotten that you installed this app.

The second answer is that, even when we own items, we have social obligations as to what we do with them. We shouldn’t play music too loudly in public places. We shouldn’t leave garbage in public places. We shouldn’t broadcast radio interference over networks. We shouldn’t hog more of our fair share of pooled public resources. And, we shouldn’t negatively impact the wireless networks (and the associated support infrastructure) on which our mobile phones live.

Both these answers are reasons in principle why users have to accept some limits on what they do with the mobile phones they have purchased.

The more interesting questions, however, are as follows:

  1. To what extent actual do application signing programs meet these requirements – and to what extent do these programs instead support other, less praiseworthy goals?

  2. Could variants of existing signing programs meet these requirements in better ways?

For example, consumers are already familiar with the idea that, when they disassemble the hardware of a device they have purchased, they typically invalidate the manufacturer warranty. (On my Psion Series 5mx, there’s still a sticker in place, over a screw, that says “Warranty void if removed”.) Would it be possible to educate handset users in a similar way that:

  • Their handsets start out in a situation of having a manufacturer warranty

  • However, if they install an unsigned application (or something similar), they are henceforth on their own, as regards support?

15 December 2008

Symbian Signed basics

Filed under: collaboration, developer experience, operators, Symbian Signed — David Wood @ 9:19 am

It’s not just Symbian that runs into some criticism over the operation of application certification and signing programs. (See eg the discussion on “Rogue Android apps rack up hidden charges“.)

This is an area where there ought ideally to be a pooling of insights and best practice across the mobile industry.

On the other hand, there are plenty of conflicting views about what’s best:

  • “Make my network more secure? Yes, please!”
  • “Make it easier to develop and deploy applications? Yes, please!”

If we go back to basics, what are the underlying requirements that lead to the existence of application certification and signing schemes? I append a list of potential requirements. I’ll welcome feedback on the importance of various items on this list.

Note: I realise that many requirements in this list are not addressed by the current schemes.

a. Avoiding users suffering from malware

To avoid situations where users suffer at the hands of malware. By “malware”, I mean badly behaved software (whether the software is intentionally or unintentionally badly behaved).

Examples of users suffering from malware include:

  1. Unexpectedly high telephone bills
  2. Unexpectedly low battery life
  3. Inability to make or receive phone calls
  4. Leakage without approval of personal information such as contacts, agenda, or location
  5. Corruption of personal information such as contacts, agenda, or location
  6. Leaving garbage or clutter behind on the handset, when the software is uninstalled
  7. Interference with the operation of other applications, or other impact to handset performance.

b. Establishing user confidence in applications

To give users confidence that the applications they install will add to the value of the handset rather than detract from it.

c. Reducing the prevalence of cracked software

To make it less likely that users will install “cracked” free versions of commercial applications written by third parties, thereby depriving these third parties of income.

d. Avoiding resource-intensive virus scanners

To avoid mobile phones ending up needing to run the same kind of resource-intensive virus scanners that are common (and widely unloved) on PCs.

e. Avoiding networks suffering from malware

To avoid situations where network operators suffer at the hands of malware or unrestricted add-on applications. Examples of network operators suffering from such software include:

  1. Having to allocate support personnel for users who encounter malware on their handsets
  2. The network being overwhelmed as a result of data-intensive applications
  3. Reprogrammed cellular data stacks behaving in ways that threaten the integrity of the wireless network and thereby invalidate the FCC (or similar) approval of the handset
  4. DRM copy protected material, provided or distributed by the network operator, being accessed or copied by third party software in ways that violate the terms of the DRM licence
  5. Revenue opportunities for network operators being lost due to alternative lower-cost third party applications being available.

f. Keeping networks open

To prevent network operators from imposing a blanket rule against all third party applications, which would in turn:

  • Limit the innovation opportunities for third party developers
  • Limit the appearance of genuinely useful third party applications.

g. Avoiding fragmentation of signing schemes

To avoid network operators from all implementing their own application certification and approval schemes, thereby significantly multiplying the effort required by third party developers to make their applications widely available; far better, therefore, for the Symbian world to agree on a single certification and approval mechanism, namely Symbian Signed.

26 July 2008

Naming the passion killers

Filed under: developer experience, fun, open phones, Symbian Signed — David Wood @ 6:06 pm

Passion makes a big difference. Posters all over Symbian premises (and on our websites) boldly declare that we “are at our best when we… love working for Symbian, drive to succeed, believe in ourselves, and take pride in what we do…“

That’s the Symbian description of the practical importance of passion. Along with people, collaboration, integrity, collaboration, and excellence, passion is one of Symbian’s six declared corporate values.

Like many other companies, Symbian each year carries out an internal employee satisfaction survey. The survey is conducted by an external agency, who provide us with information on how our results compare with broadly similar surveys held by other high-tech companies. In the most recent survey, aggregate Symbian employee views demonstrated strong Passion (80% positive rating). Of the six values, this one had the strongest support of all. The score also came in notably higher than the benchmark. In general, our employees enjoy working here, and put their hearts into their activities.

In some ways, “passion” is a longer word for “fun”. The good news is that, on the whole, Symbian employees enjoy and value their work. The bad news, however, is as I covered in my previous blog posting, “Symbian, just for fun“: many developers outside the company have a less positive feeling about working with Symbian OS software. They may persevere with writing Symbian OS software because their employer pays them to do so, and because of the somewhat attractive prospect of a share in a growing 200M+ unit market, but they often lack the kind of inner motivation and satisfaction that can put them into a super-productive state of “flow“.

The encouraging responses I’ve received to that posting (both via email and online) stengthen my view that it’s vitally important to identify understand the inhibitors to developer flow – the killers of Symbian passion. That’s a big topic, and I suspect I’ll be writing lots more on this topic in the months ahead. But let’s make a start.

Lack of clarity with Symbian Signed

The experience of my correspondent ilgaz is probably quite common:

I think the issue here is , we (even technical users) don’t really get what should be signed, what shouldn’t.

Ilgaz wanted to use a particular third party application (Y-Tasks by Dr Jukka), and thought that it would first need to be signed with a developer certificate. That proved to be an awkward process. However, it turns out that the application is ready to use (for many purposes) without any additional signing. So the attempt to get a developer certificate was unnecessary.

Some might say that Symbian Signed itself is intrinsically a passion killer. I disagree – as I’ve argued elsewhere. But what does kill passion here is the confusion about the rules for Symbian Signed. You can’t expect flow from confusion. I see six causes for this confusion:

  1. Different devices implement Symbian Signed in different ways. Some devices helpfully support a setting to allow the installation of self-signed apps, as well as Symbian Signed ones. Others do not;
  2. Different operators have different views about what kinds of applications they want to allow on their phones;
  3. The subject of permissions for the different capabilities of different pieces of software is intrinsically complex;
  4. The operation of Symbian Signed has changed over time. It’s great that it has improved, but some people still remember how it used to work, and that confuses them;
  5. “Once bitten, twice shy”: past bad experiences sometimes over-colour present views on the topic;
  6. A small number of people seem to be motivated to spread particularly bad vibes about Symbian Signed.
In this situation, we can’t expect to reverse all the accumulated mistrust and apprehension overnight. But the following steps should help:
  • Continue to seek to improve the clarity of communications;
  • Be alert to implementation issues (eg an overworked website – as experienced some months back) and seek to address them quickly;
  • Avoid a divergence of implementations of different application approval schemes by different network operators.
It’s my profound hope that the attractive statements of common aims of openness, made by the various parties supporting the Symbian Foundation, will translate into a unity of approaches towards application approval schemes.

Lack of reprogrammable devices

Another correspondent, puterman, points out:

Getting people to develop apps just for fun is one thing, but getting them to hack the actual OS is another thing. For that to be of interest, there have to be open devices available, so that the developers can actually see their code running.

I agree with the importance of quick feedback to changes made in your software. If you change the lower levels of the software, you’ll need to be able to re-program an actual device.

The Linux community shows the way here, with the Trolltech Greenphone and the FIC OpenMoko Neo1973 and FreeRunner devices. It’s true that there have been issues with these devices. For example, Trolltech eventually discontinued the Greenphone, and the FIC devices have proved quite hard to purchase. However, as the Symbian Foundation software becomes increasingly open source, we can reasonably expect the stage-by-stage appearance of phones that are increasingly end-user re-programmable.

Lack of well-documented API support for “interesting” features of a phone

Marcus Groeber makes a series of insightful points. For example,

One of the main things mobile developers would want to do is make use of the unique features of a mobile phone (connectivity, built in camera, physical interaction with the user). However, it is those area where documentation is still most patchy and API support is erratic (CCameraAdvancedSettings anyone?).

In my view, this aspect of mobilie development should be acknowledged to a much greater degree, and the documentation efforts focused accordingly: If there is a feature in a built-in app of the phone, chances are that a developer will want to try and improve on that. Can s/he?…

I believe that these moments of frustration – finding an API that looks useful in the SDK docs, then spending an evening writing an application that uses it, only to get KErrNotSupported in the end – is probably among the chief reasons for people abandoning their pet projects…

True, many “fun” programmers (me included) don’t want to wade through tons of documentation and whitepapers before writing their first proof-of-concept – but to me this makes it even more important that the existing documentation is streamlined, accurate and compact.

Improving our developer documentation remains one of the top-priority goals at Symbian. In parallel, we’re hoping that additional publications from Symbian Press (and others) will help to guide developers more quickly through the potential minefields of APIs for the more interesting functionality. The book “Quick Recipes on Symbian OS” (which I mentioned at the end of an earlier posting, “Mobile development in a hurry“) is intended to address this audience.

Of course, as Simon Judge points out, sometimes it’s not a matter of improving the documentation of existing APIs. Sometimes, what’s required is to improve the APIs themselves.

API awkwardness across the UI-OS boundary

The last passion-killer I’ll mention for now is another one raised by Marcus Groeber:

most of the “interesting” bits of developing for devices actually come from the licensee’s layers of API (in my case, mostly S60), and I believe it is here where there is most work to be done, as well as the interface between the two…

The ad-hoc-ish nature of the S60 UI, which seems to require a lot of experimenting and guesswork for developing even very simple screen layouts that mimic closely what is already present in the phone in dozens of places. Even after years of development, I still consider the CAkn and CEik listbox classes a jungle.

As one of the original designers of the CEik listbox class hierarchy (circa 1995-6) perhaps I should keep my head low at this point! (Though I can claim little direct credit – or blame – for the subsequent evolution of these classes.)

However, the bigger point is the following: both Symbian and S60 have recognised for many years that the separation of the two software development teams into two distinct companies has imposed drawbacks on the overall design and implementation of the APIs of functionality that straddles the two domains. Keeping the UI and the OS separate had some positives, but a lot of negatives too. Assuming the acquisition by Nokia of Symbian receives regulatory approval, the resulting combined engineering teams should enable considerably improved co-design. The new APIs will, hopefully, inspire greater fascination and approval from those who use them!

7 July 2008

Symbian signed and openness

Filed under: malware, openness, Symbian Foundation, Symbian Signed — David Wood @ 8:13 pm

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:

  1. Decide that there’s no possible solution, and therefore the power of a system like Symbian Signed should be criticised and diminished
  2. 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.

Blog at WordPress.com.