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:
- To what extent actual do application signing programs meet these requirements – and to what extent do these programs instead support other, less praiseworthy goals?
- 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?
dw2 
>>To what extent actual do application signing programs meet these requirements – and to what extent do these programs instead support other, less praiseworthy goals?<<
None! Signing requirements does not meet the goals you described in yesterday's post. I am repeating it that user experience is derived from platform support and developer intention.
If developer wants user to avoid unexpected roaming charges they can not detect scenario because Symbian platform does not provide support for that. I don't understand how symbian signed can save user from unexpected roaming charges
Take hypothetical scenario, if my application does not use any capability but consume battery for doing genuine mathematical calculations with poor algorithm. How symbian signed can force to change algorithm to save battery life?
Comment by Rick — 16 December 2008 @ 11:22 am
>>To what extent actual do application signing programs meet these requirements – and to what extent do these programs instead support other, less praiseworthy goals?<<
None! Signing requirements does not meet the goals you described in yesterday's post. I am repeating it that user experience is derived from platform support and developer intention.
If developer wants user to avoid unexpected roaming charges they can not detect scenario because Symbian platform does not provide support for that. I don't understand how symbian signed can save user from unexpected roaming charges
Take hypothetical scenario, if my application does not use any capability but consume battery for doing genuine mathematical calculations with poor algorithm. How symbian signed can force to change algorithm to save battery life?
Comment by Rick — 16 December 2008 @ 11:22 am
Hi,
It’s almost impossible to come up with a signing scheme that defends against malware via some test criteria that can be implemented in practice. Symbian Signed certainly doesn’t, as I’ve written in the past.
I think if users had to do something that switched them into an “open” mode of installation (still not completely open, just much more so), and that fact could be queried instantly by the network operator or device manufacturer, then it should work. I think it needs to be possible, not necessarily easy. This is a facility that should be targeted at prosumers, not the mass market.
However, it would be a great help if the phone could be returned to a state where the warranty was valid, even if that essentially requires a re-format. Even in an “open” state, the security system needs to protect the integrity of the hardware.
Mark
Comment by m_p_wilcox — 16 December 2008 @ 12:02 pm
Hi,
It’s almost impossible to come up with a signing scheme that defends against malware via some test criteria that can be implemented in practice. Symbian Signed certainly doesn’t, as I’ve written in the past.
I think if users had to do something that switched them into an “open” mode of installation (still not completely open, just much more so), and that fact could be queried instantly by the network operator or device manufacturer, then it should work. I think it needs to be possible, not necessarily easy. This is a facility that should be targeted at prosumers, not the mass market.
However, it would be a great help if the phone could be returned to a state where the warranty was valid, even if that essentially requires a re-format. Even in an “open” state, the security system needs to protect the integrity of the hardware.
Mark
Comment by m_p_wilcox — 16 December 2008 @ 12:02 pm
I’m impressed that Symbian chose to try to do something about these (perceived) problems, and parts of the Platform Security framework are well thought through and well implemented, both on a theoretical and practical level. But the burden it puts on developers and users just isn’t worth it. And as others have pointed out, Symbian Signed doesn’t protect you from malware, nor is it intended to. Unfortunately, the whole Platform Security things is also just too complicated for developers that aren’t actually interested in anything than getting their apps to run, as evident in eg. the capabilities used in the pre-release of Nokia’s own N-Gage application. I mean, if Nokia can’t handle it, who can?
Comment by puterman — 16 December 2008 @ 5:49 pm
I’m impressed that Symbian chose to try to do something about these (perceived) problems, and parts of the Platform Security framework are well thought through and well implemented, both on a theoretical and practical level. But the burden it puts on developers and users just isn’t worth it. And as others have pointed out, Symbian Signed doesn’t protect you from malware, nor is it intended to. Unfortunately, the whole Platform Security things is also just too complicated for developers that aren’t actually interested in anything than getting their apps to run, as evident in eg. the capabilities used in the pre-release of Nokia’s own N-Gage application. I mean, if Nokia can’t handle it, who can?
Comment by puterman — 16 December 2008 @ 5:49 pm
First, I would like to point out that this is not a technical problem, it’s a political problem: the architecture of a computer system is politics (http://blog.kapor.com/?p=29). Therefore, there are multiple perfectly valid points of view: those who want absolute and full freedom and those who desire an intervened and patrolled market. But in this debate, there is an objective part you are failing to grasp, and I’ll start with it.
By your defense of the status quo, it’s quite clear that you are facing a conflict of interest: we know you were a developer, so you must understand that any properly motivated malware developer is able to bypass all protections Symbian Signed could offer (self-modifying + auto-updating code and/or runtime/code interpretation). What is more, it’s a priori undecidable to check whether a computer program is a virus, a VOIP program, or for any other property (http://vx.netlux.org/lib/afc01.html), so this battle against malware using checks against “test criterias” is always lost from the very beginning. QED. Period.
By the previous irrefutable reasoning, it happens that the only way to always guarantee that the user doesn’t execute some programs (for whatever reason) is by mandating a centralized signing process, forbidding the execution of unsigned programs and checking that programs in a black list do not execute: the famous kill-switch in the iPhone. And it’s not that Symbian engineers are computer illiterates and Apple engineers are the brightest: Symbian planned an Online Certificate Service with online revocation of applications (http://www.symbianone.com/content/view/358/), a nonexistent functionality nowadays, since most Symbian phones don’t have data plans. To sum up, there’s only one way to carry out the aim of Symbian Signed, and it isn’t implemented and could not be implemented without data plans.
That was the objective part that you, as a developer and math-loving person, can’t disagree with. Another thing is that you don’t want to bite the hand that feeds you. The non-objective and political part follows:
There is a fundamental difference between Apple Store and Symbian Signed regarding the party who bears the costs of “criteria checking”: in the Apple ecosystem, Apple pays; in the Symbian ecosystem, the developer pays. Since it’s the platform company who benefits more with an intervened and controlled market, it should be the party who pays. Otherwise, you are creating a strong barrier to entry and limiting the number of applications: this is basic platform economics (http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1094820)
Continuing with political arguments, this is a case of Soft Paternalism (http://en.wikipedia.org/wiki/Soft_paternalism), in which Symbian is intervening to protect the network operator and/or the user with their mandatory check criteria. But even within soft paternalism, every measure has to be preceded with data that supports that the threat is for real and not the product of imagination. Fortunately, we have the Windows Mobile ecosystem to check for this: there are Windows Mobile viruses and other malware, so this is a real problem; there aren’t many programs consuming vast amounts of memory and background applications running down batteries, so I would say this is not a very real problem; and for the programs collapsing and ruining the network operator, there has never been such a thing, so I claim that they are a dark sci-fi conspiracy.
—
“I would rather be exposed to the inconveniencies attending too much liberty than to those attending too small a degree of it.”
Thomas Jefferson
Comment by Anonymous — 16 December 2008 @ 5:57 pm
First, I would like to point out that this is not a technical problem, it’s a political problem: the architecture of a computer system is politics (http://blog.kapor.com/?p=29). Therefore, there are multiple perfectly valid points of view: those who want absolute and full freedom and those who desire an intervened and patrolled market. But in this debate, there is an objective part you are failing to grasp, and I’ll start with it.
By your defense of the status quo, it’s quite clear that you are facing a conflict of interest: we know you were a developer, so you must understand that any properly motivated malware developer is able to bypass all protections Symbian Signed could offer (self-modifying + auto-updating code and/or runtime/code interpretation). What is more, it’s a priori undecidable to check whether a computer program is a virus, a VOIP program, or for any other property (http://vx.netlux.org/lib/afc01.html), so this battle against malware using checks against “test criterias” is always lost from the very beginning. QED. Period.
By the previous irrefutable reasoning, it happens that the only way to always guarantee that the user doesn’t execute some programs (for whatever reason) is by mandating a centralized signing process, forbidding the execution of unsigned programs and checking that programs in a black list do not execute: the famous kill-switch in the iPhone. And it’s not that Symbian engineers are computer illiterates and Apple engineers are the brightest: Symbian planned an Online Certificate Service with online revocation of applications (http://www.symbianone.com/content/view/358/), a nonexistent functionality nowadays, since most Symbian phones don’t have data plans. To sum up, there’s only one way to carry out the aim of Symbian Signed, and it isn’t implemented and could not be implemented without data plans.
That was the objective part that you, as a developer and math-loving person, can’t disagree with. Another thing is that you don’t want to bite the hand that feeds you. The non-objective and political part follows:
There is a fundamental difference between Apple Store and Symbian Signed regarding the party who bears the costs of “criteria checking”: in the Apple ecosystem, Apple pays; in the Symbian ecosystem, the developer pays. Since it’s the platform company who benefits more with an intervened and controlled market, it should be the party who pays. Otherwise, you are creating a strong barrier to entry and limiting the number of applications: this is basic platform economics (http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1094820)
Continuing with political arguments, this is a case of Soft Paternalism (http://en.wikipedia.org/wiki/Soft_paternalism), in which Symbian is intervening to protect the network operator and/or the user with their mandatory check criteria. But even within soft paternalism, every measure has to be preceded with data that supports that the threat is for real and not the product of imagination. Fortunately, we have the Windows Mobile ecosystem to check for this: there are Windows Mobile viruses and other malware, so this is a real problem; there aren’t many programs consuming vast amounts of memory and background applications running down batteries, so I would say this is not a very real problem; and for the programs collapsing and ruining the network operator, there has never been such a thing, so I claim that they are a dark sci-fi conspiracy.
—
“I would rather be exposed to the inconveniencies attending too much liberty than to those attending too small a degree of it.”
Thomas Jefferson
Comment by Anonymous — 16 December 2008 @ 5:57 pm
“There is no need for signing to ensure safety from malware. That’s what (platform) security is for.”
Platform Security does not exist without a certification authority that can grant (or deny) your right of using the capabilities through signing.
One word is however used here (and in the previous post/comments) abusively: signing.
Symbian Signed is not a signing program. Symbian Signed is a certification program.
Now, I would argue that for enforcing the Platform Security certification should not be mandatory but instead Symbian Signed as a certification authority can provide traceability to an application and that can be done through simple means (a bank payment that can be traced back to the developer for example). All this with minimal testing and/or pair review. Signing without certification.
Then, for a limited number of sensitive capabilities or in order to be included in manufacturer’s or operator’s catalogs (or simply for the marketing benefit) developers may go through the certification process which implies testing.
This way a student can develop and release a decently powerful application without being limited by the fact that it does not have (and can not get) a PublisherID. And a company can offer the same application for 5 euros more than that of the student while attaching the Symbian Signed logo next to the price as a promise of quality.
Comment by Lucian — 16 December 2008 @ 9:24 pm
“There is no need for signing to ensure safety from malware. That’s what (platform) security is for.”
Platform Security does not exist without a certification authority that can grant (or deny) your right of using the capabilities through signing.
One word is however used here (and in the previous post/comments) abusively: signing.
Symbian Signed is not a signing program. Symbian Signed is a certification program.
Now, I would argue that for enforcing the Platform Security certification should not be mandatory but instead Symbian Signed as a certification authority can provide traceability to an application and that can be done through simple means (a bank payment that can be traced back to the developer for example). All this with minimal testing and/or pair review. Signing without certification.
Then, for a limited number of sensitive capabilities or in order to be included in manufacturer’s or operator’s catalogs (or simply for the marketing benefit) developers may go through the certification process which implies testing.
This way a student can develop and release a decently powerful application without being limited by the fact that it does not have (and can not get) a PublisherID. And a company can offer the same application for 5 euros more than that of the student while attaching the Symbian Signed logo next to the price as a promise of quality.
Comment by Lucian — 16 December 2008 @ 9:24 pm
Radio interference and application signing are two totally unrelated things. In Finland, carriers cannot do “nasty” things as mentioned in the text. In fact, it would be illegal for them. After the SIM card is put into a device which has passed network tests, the operator has zero control over what consumer can do with the connection he/she gets.
People mainly hate the control because it is used to cripple their phones and strip them from useful capabilities. I am not sure if mobile networking is the only industry where vendors get away by making the user experience worse and make money from it. The classical example is blocking Bluetooth/infrared so that the consumer must use carriers (bad) service and data rates to transfer his/her music and images. It all boils down to the fact that the carriers prefer to sell “plans” which are all about obfuscating how much money the consumer will spend in the end – get the rid of subsidizing and there is no longer need to cripple phones.
Google is all about user experience and innovation. I though one of Android goals was pushing innovation to the consumers bypassing the carriers. I still have hope left and I believe Google will gain enough bargaining power to stop carrier nonsense.
Back to Symbian – I prefer symbiansigned.com model over Apple-like distribution channel monopoly + killswitch solution. Symbian cannot block you to release Skype, Flash or Java ME for Series 60, unlike what Appple does. The limitations are technical, not business model related. Also, there have been zero serious virus since the platform security kicked in, so we have learnt about Windows history lessons here. Though platform security can be hacked it is big enough obstacle to keep the malware in minimum.
But this does not change fact that symbiansigned.com user experience is not very good and there are dozens of places where things could be streamlined. The people who directly deal with symbiansigned.com are not happy with it. Charging 200$ for a developer certificate for which you need to fill in forms worth of one man day must come to end, since other parties (Android, iPhones, Windows Mobile) don’t do this either.
Also if the user wants to mess up his phone he/she should have change to do it. Currently some Symbian/Series 60 APIs are available for premium partners and operators only. This prevents some innovation – e.g. third party developers cannot make active idle screen applications. Upstream video streaming is hard to implement, because there is no suitable public way to access video encoder. etc. etc. Open sourcing Symbian will change this – riight?
Comment by Mikko Ohtamaa — 17 December 2008 @ 1:33 am
Radio interference and application signing are two totally unrelated things. In Finland, carriers cannot do “nasty” things as mentioned in the text. In fact, it would be illegal for them. After the SIM card is put into a device which has passed network tests, the operator has zero control over what consumer can do with the connection he/she gets.
People mainly hate the control because it is used to cripple their phones and strip them from useful capabilities. I am not sure if mobile networking is the only industry where vendors get away by making the user experience worse and make money from it. The classical example is blocking Bluetooth/infrared so that the consumer must use carriers (bad) service and data rates to transfer his/her music and images. It all boils down to the fact that the carriers prefer to sell “plans” which are all about obfuscating how much money the consumer will spend in the end – get the rid of subsidizing and there is no longer need to cripple phones.
Google is all about user experience and innovation. I though one of Android goals was pushing innovation to the consumers bypassing the carriers. I still have hope left and I believe Google will gain enough bargaining power to stop carrier nonsense.
Back to Symbian – I prefer symbiansigned.com model over Apple-like distribution channel monopoly + killswitch solution. Symbian cannot block you to release Skype, Flash or Java ME for Series 60, unlike what Appple does. The limitations are technical, not business model related. Also, there have been zero serious virus since the platform security kicked in, so we have learnt about Windows history lessons here. Though platform security can be hacked it is big enough obstacle to keep the malware in minimum.
But this does not change fact that symbiansigned.com user experience is not very good and there are dozens of places where things could be streamlined. The people who directly deal with symbiansigned.com are not happy with it. Charging 200$ for a developer certificate for which you need to fill in forms worth of one man day must come to end, since other parties (Android, iPhones, Windows Mobile) don’t do this either.
Also if the user wants to mess up his phone he/she should have change to do it. Currently some Symbian/Series 60 APIs are available for premium partners and operators only. This prevents some innovation – e.g. third party developers cannot make active idle screen applications. Upstream video streaming is hard to implement, because there is no suitable public way to access video encoder. etc. etc. Open sourcing Symbian will change this – riight?
Comment by Mikko Ohtamaa — 17 December 2008 @ 1:33 am
Symbian Signed and restriction to private APIs are a big barrier for startups. few In March this year we evaluated the most promising platform for us to make an entry in app development and met with obstacles of symbian signed and more importantly not having access to private APIs. Yes for private API there is partnership program but it costs us. If company is making money they can adjust that cost easily but for a startup it is not that easy. We couldn’t find iPhone too that easy for making an entry so decided for Android. Initially it was difficult with Android because there were not enough sample code/wiki etc and SDK was also buggy. Over a period SDK is improved a lot and lots of sample code as well without any API usage restriction.
When Symbian’s existing developer base is migrating I hope they will consider opening door for new comers before its too late.
Comment by Unknown — 17 December 2008 @ 12:01 pm
Symbian Signed and restriction to private APIs are a big barrier for startups. few In March this year we evaluated the most promising platform for us to make an entry in app development and met with obstacles of symbian signed and more importantly not having access to private APIs. Yes for private API there is partnership program but it costs us. If company is making money they can adjust that cost easily but for a startup it is not that easy. We couldn’t find iPhone too that easy for making an entry so decided for Android. Initially it was difficult with Android because there were not enough sample code/wiki etc and SDK was also buggy. Over a period SDK is improved a lot and lots of sample code as well without any API usage restriction.
When Symbian’s existing developer base is migrating I hope they will consider opening door for new comers before its too late.
Comment by Unknown — 17 December 2008 @ 12:01 pm
Hi David,
could you please spend few words on how TMO and Google could prevent VoIP on Android, given the fact that it’s an open source platform?
I also found this, but given I’m not a developer and I don’t own a G1, I’m not sure if this a real application or something else:
http://blog.roychowdhury.org/2008/04/29/sip-ua-for-android-stack-rtp-released/
cheers,
alfonso
Comment by alfonso — 29 December 2008 @ 11:36 pm
Hi Alfonso,
>“could you please spend few words on how TMO and Google could prevent VoIP on Android, given the fact that it’s an open source platform?”
Even though it's an open source platform, it doesn't necessarily mean that all the source code to recreate an entire phone will be available.
>“I also found this, but given I’m not a developer and I don’t own a G1, I’m not sure if this a real application or something else.”
One of the comments on that blog seems to make it clear that voice functionality is not supported (yet):
“Registration and all non-voice related functions will work (IM included)”.
// dw2-0
Comment by David Wood — 30 December 2008 @ 3:31 pm