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:
- Unexpectedly high telephone bills
- Unexpectedly low battery life
- Inability to make or receive phone calls
- Leakage without approval of personal information such as contacts, agenda, or location
- Corruption of personal information such as contacts, agenda, or location
- Leaving garbage or clutter behind on the handset, when the software is uninstalled
- 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:
- Having to allocate support personnel for users who encounter malware on their handsets
- The network being overwhelmed as a result of data-intensive applications
- 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
- 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
- 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.
dw2 
Hi David,
Problem is not with what Symbian Signed is designed for. Problem is with *HOW* Symbian signed is trying to achieve its goal.
Of course the goals you described are bases for any good application and make perfect sense. However you completely ignoring other half of the story. See some points below
1) TC trust certificate is a big mess both in terms of time and money. It is a big barrier for new entrants. I am not saying that it is bad, all I am saying that Symbian could come up with simple solution. When Apple can do it why not Symbian.
2) It increases development time dramatically in ensuring each symbian signed requirement is met.
A tool could have been developed by symbian signed that ensures those requirement and result in to pass/fail. Basically Symbian signed pushed pushed cost of ensuring symbian signed requirements to the developers. Which is inefficient because every developer has to repeat same testing steps that a single tool could do for all developers.
3) Procedures are so complex and not documented even at symbian signed websites. The documents are ages old and not updated with the changes done to Symbian Signed. This leads to psoting your query on forums and wish to God that someone will reply. Pathetic
The amount of development time (and of course cost associated with that) Symbian Signed takes does not justify the goals it is trying to achieve. Symbian signed is a bureaucratic mess and is mainly responsible for developers to force them to move to new platforms.
Comment by Vipin — 15 December 2008 @ 11:10 am
Hi David,
Problem is not with what Symbian Signed is designed for. Problem is with *HOW* Symbian signed is trying to achieve its goal.
Of course the goals you described are bases for any good application and make perfect sense. However you completely ignoring other half of the story. See some points below
1) TC trust certificate is a big mess both in terms of time and money. It is a big barrier for new entrants. I am not saying that it is bad, all I am saying that Symbian could come up with simple solution. When Apple can do it why not Symbian.
2) It increases development time dramatically in ensuring each symbian signed requirement is met.
A tool could have been developed by symbian signed that ensures those requirement and result in to pass/fail. Basically Symbian signed pushed pushed cost of ensuring symbian signed requirements to the developers. Which is inefficient because every developer has to repeat same testing steps that a single tool could do for all developers.
3) Procedures are so complex and not documented even at symbian signed websites. The documents are ages old and not updated with the changes done to Symbian Signed. This leads to psoting your query on forums and wish to God that someone will reply. Pathetic
The amount of development time (and of course cost associated with that) Symbian Signed takes does not justify the goals it is trying to achieve. Symbian signed is a bureaucratic mess and is mainly responsible for developers to force them to move to new platforms.
Comment by Vipin — 15 December 2008 @ 11:10 am
A very insightful post, but I agree with all the points raised on the previous comment. What is more worrying it is giving Symbian a very bad reputation to develop for as Symbians platform is considered very difficult to develop on at the best of times and Symbian Signed is another nail in the coffin by adding more development time and significant cost into the bottom line. To many people Symbian signed has all the halmarks of a DRM scheme. Its expensive to ship product and annoys end users and is easily defeated by bad guys.
One thing that would impress me would be if Symbian and Nokia actually developed in house using the same techniques (eg restricted devcerts and capabilties) that 3rd party developers do, rather than just having certs with All-TCB and not following Symbian signed testing criteria. If they did that I bet it would be a month before Symbian signed was consigned to the dustbin of history. You want to build a better Symbian signed: make the same process mandatory in house first….
More importantly: why has Apple gone from 0 to 16.5% marketshare and 10000 apps in the space of a year when they do it in a manner much less intrusivly than Symbian does.
These are my own views, its needless to say and not the corporate entity I work for.
Comment by pault — 15 December 2008 @ 12:38 pm
A very insightful post, but I agree with all the points raised on the previous comment. What is more worrying it is giving Symbian a very bad reputation to develop for as Symbians platform is considered very difficult to develop on at the best of times and Symbian Signed is another nail in the coffin by adding more development time and significant cost into the bottom line. To many people Symbian signed has all the halmarks of a DRM scheme. Its expensive to ship product and annoys end users and is easily defeated by bad guys.
One thing that would impress me would be if Symbian and Nokia actually developed in house using the same techniques (eg restricted devcerts and capabilties) that 3rd party developers do, rather than just having certs with All-TCB and not following Symbian signed testing criteria. If they did that I bet it would be a month before Symbian signed was consigned to the dustbin of history. You want to build a better Symbian signed: make the same process mandatory in house first….
More importantly: why has Apple gone from 0 to 16.5% marketshare and 10000 apps in the space of a year when they do it in a manner much less intrusivly than Symbian does.
These are my own views, its needless to say and not the corporate entity I work for.
Comment by pault — 15 December 2008 @ 12:38 pm
I read Android article and unexpected roaming charges. I am not sure about roaming APIs in Android; however I would like to highlight a fact on Symbian that in Public SDK there is no way to know if a user is in Roaming or Not.
Application developers wants to give option not trigger data connection/call answer etc automatically and should prompt user or may be shut off the operation in roaming. But since Symbian does not provide public API to do that so developers have no way to detect scenario.
If you expect developer to go for partnership (spend money) for this purpose, it is illogical.
I have an application that can answer call on user behalf but in roaming I would like to prompt user because there are charges for incoming call too in roaming; but after searching I couldn’t find any API to do that in S60 3rd ed.
I would request a plugin in all S60 3rd ed SDKs to detect the scenario. if you really want good user experience. Symbian signed does not stop such things it requires APIs from platform.
Comment by Rick — 15 December 2008 @ 12:45 pm
I read Android article and unexpected roaming charges. I am not sure about roaming APIs in Android; however I would like to highlight a fact on Symbian that in Public SDK there is no way to know if a user is in Roaming or Not.
Application developers wants to give option not trigger data connection/call answer etc automatically and should prompt user or may be shut off the operation in roaming. But since Symbian does not provide public API to do that so developers have no way to detect scenario.
If you expect developer to go for partnership (spend money) for this purpose, it is illogical.
I have an application that can answer call on user behalf but in roaming I would like to prompt user because there are charges for incoming call too in roaming; but after searching I couldn’t find any API to do that in S60 3rd ed.
I would request a plugin in all S60 3rd ed SDKs to detect the scenario. if you really want good user experience. Symbian signed does not stop such things it requires APIs from platform.
Comment by Rick — 15 December 2008 @ 12:45 pm
Hi Vipin,
>“Problem is not with what Symbian Signed is designed for. Problem is with *HOW* Symbian signed is trying to achieve its goal…”
I'm very keen to discuss the implementation issues too. But first I do want to check the level of agreement people have with the underlying requirements. Before we re-engineer the solution, we do need clarity on what are the really key requirements.
>“Of course the goals you described are bases for any good application and make perfect sense.”
I’m not sure everyone would agree with you. I hear people taking issue, not just with the implementation, but also with the underlying goals.
// dw2-0
Comment by David Wood — 15 December 2008 @ 12:49 pm
Hi Vipin,
>“Problem is not with what Symbian Signed is designed for. Problem is with *HOW* Symbian signed is trying to achieve its goal…”
I'm very keen to discuss the implementation issues too. But first I do want to check the level of agreement people have with the underlying requirements. Before we re-engineer the solution, we do need clarity on what are the really key requirements.
>“Of course the goals you described are bases for any good application and make perfect sense.”
I’m not sure everyone would agree with you. I hear people taking issue, not just with the implementation, but also with the underlying goals.
// dw2-0
Comment by David Wood — 15 December 2008 @ 12:49 pm
Hi all,
My view is there are both issues with what is being attempted and how the its implemented.
For example some of the criteria appear to be trying to resolve issues in Symbian OS. E.g. if you dont want 100’s of spam SMS per sec being delivered by rogue apps can I suggest the SMS stack simply does not allow such activity.
Or what about not filling the internal disk too much. There is clearly a fundamental issue in Symbian OS if you cant switch the phone on when the internal disk is full – why not fix that ??
In other cases the criteria try to dictate sales + marketing policies – in particular the Scalable UI compliance tests. Here you are obliged to support obsolete devices e.g. 3250, 5500 (which didnt even have any SDK support in the first place). Even when you do support these devices you get failed if the UI you present on one device is slightly diffeent to another – and yes I have the test reports for this. What has supporting an obsolute device got to do with ensuing the app works properly on those devices the developer is targetting?.
Its odd that for exmaple – Nokias apps dont often work on many devices. None of the N-Gage apps work on say E series devices etc – yet these are signed. The One rule for e.g. Nokia + their chums, one for smaller 3rd parties really really annoys people.
Other things:
Symbian Signed has little to zero benefit that we have observed.
Operators want/have their own test regimes so they clearly dont trust Symbian Signed testing.
I dont know of any worthwhile channel where Symbian Signed is mandatory. Those channels where this used to be required now accept all apps – so Symbian Signing is actually detrimental.
If apps have to be Symbian Signed, why is it not mandatory for apps to be Java verified. E.g. its trivial in Java to run up a huge bill — simply do HTTP!.
Consumer have little/no idea what it means.
Several comments to the above:
If fixing bugs in your app before you release it increases development time ‘dramatically’ – which is the fundamental driver behind most of the test criteria, then I have little sympathy. Yes it adds some overhead, but no more than a few percent. For reference, we have over 100 different apps though Symbian Signed, S60 + UIQ + S80.
I would also suggest that Apple’s soln is not as easy as you claim, We had to wait 4 months to become ‘approved’. Obtaining TC Trust cert + becoming approved took less than 1 week – so both have issues.
Apples SDK is also somewhat restricted, e.g. a number of the things Symbian Signed is epxlicity designed to guard against simply are not possible e.g. VOIP is banned, background running apps banned, Bluetooth not availalbe, dont think access to SMS is avail etc etc
Apple manually validate all apps that are submittd to the AppStore – and they effectively charge you 30% of net receipts (yes you do get other services in that 30% such as billing) they just happen to have chosen to hide the testing/signing costs – which is not unreasonable given they can re-coup the costs being the only route to market.
I agree the Symbian Signed site never seems to be working – obtaining new DevCert for new phone IMEI is a real drag, the procedures are complex, poorly documented and are interpreted quite differently by different people – e.g. developers + test house. This is particularly frustrating if their interpretation differs slightly + they choose to fail your app.
Totally agree with the ‘make the process mandatory within symbian/licencess’ – including only allowed to use the ‘released SDK’ and tools.
Comment by bbj — 15 December 2008 @ 1:51 pm
Hi all,
My view is there are both issues with what is being attempted and how the its implemented.
For example some of the criteria appear to be trying to resolve issues in Symbian OS. E.g. if you dont want 100’s of spam SMS per sec being delivered by rogue apps can I suggest the SMS stack simply does not allow such activity.
Or what about not filling the internal disk too much. There is clearly a fundamental issue in Symbian OS if you cant switch the phone on when the internal disk is full – why not fix that ??
In other cases the criteria try to dictate sales + marketing policies – in particular the Scalable UI compliance tests. Here you are obliged to support obsolete devices e.g. 3250, 5500 (which didnt even have any SDK support in the first place). Even when you do support these devices you get failed if the UI you present on one device is slightly diffeent to another – and yes I have the test reports for this. What has supporting an obsolute device got to do with ensuing the app works properly on those devices the developer is targetting?.
Its odd that for exmaple – Nokias apps dont often work on many devices. None of the N-Gage apps work on say E series devices etc – yet these are signed. The One rule for e.g. Nokia + their chums, one for smaller 3rd parties really really annoys people.
Other things:
Symbian Signed has little to zero benefit that we have observed.
Operators want/have their own test regimes so they clearly dont trust Symbian Signed testing.
I dont know of any worthwhile channel where Symbian Signed is mandatory. Those channels where this used to be required now accept all apps – so Symbian Signing is actually detrimental.
If apps have to be Symbian Signed, why is it not mandatory for apps to be Java verified. E.g. its trivial in Java to run up a huge bill — simply do HTTP!.
Consumer have little/no idea what it means.
Several comments to the above:
If fixing bugs in your app before you release it increases development time ‘dramatically’ – which is the fundamental driver behind most of the test criteria, then I have little sympathy. Yes it adds some overhead, but no more than a few percent. For reference, we have over 100 different apps though Symbian Signed, S60 + UIQ + S80.
I would also suggest that Apple’s soln is not as easy as you claim, We had to wait 4 months to become ‘approved’. Obtaining TC Trust cert + becoming approved took less than 1 week – so both have issues.
Apples SDK is also somewhat restricted, e.g. a number of the things Symbian Signed is epxlicity designed to guard against simply are not possible e.g. VOIP is banned, background running apps banned, Bluetooth not availalbe, dont think access to SMS is avail etc etc
Apple manually validate all apps that are submittd to the AppStore – and they effectively charge you 30% of net receipts (yes you do get other services in that 30% such as billing) they just happen to have chosen to hide the testing/signing costs – which is not unreasonable given they can re-coup the costs being the only route to market.
I agree the Symbian Signed site never seems to be working – obtaining new DevCert for new phone IMEI is a real drag, the procedures are complex, poorly documented and are interpreted quite differently by different people – e.g. developers + test house. This is particularly frustrating if their interpretation differs slightly + they choose to fail your app.
Totally agree with the ‘make the process mandatory within symbian/licencess’ – including only allowed to use the ‘released SDK’ and tools.
Comment by bbj — 15 December 2008 @ 1:51 pm
Thinking a bit more about this perhaps what Symbian really need to do is go back to what Symbian Signed is actually trying to achieve
In my view its
i) tracability
ii) kill switch
and thats really it.
App quality is mostly resolved by market forces + distribution channels. However hard Nokia want to make it to produce crap apps, crap apps will be produced and a route to market found. If they are truely crap few people will actually download/purchase. If they are wonderful this news will spread quickly.
Perhaps a radically alternate plan is required e.g. much more along the lines of the AppStore:
Symbian/Nokia run an application repository.
Only applications in the repository can be distributed = tracablity, e.g. via some certificate. As far as I can tell, currently the vast majority of Symbian apps are not signed, and not traceable so the scheme is failing one of its core objectives.
There should not be many reasons why apps cannot be put in the repository = dont apply one set of ethics to other industries/countries. Some limited QA can be done here if required.
Distributors are ‘licenced’ and obliged to report back on rogue apps. Only licenced distributors can distribute the apps. Should reduce the number of craked sites (usually where the malware is anyway) + much easier for the industry to spot such sites.
Each distribution channel decides on whether the app needs to pass the equivalent to Symbian Signed testing, nothing or their own regime.
About 99.999999% dont require anything, the other %age have their own regime anyway – so why deny this reality?. Symbian just provide the default test doc.
Any half sensible distributor would want to block rogue apps anyway, even if blocking = dont allow this app to be presented on my distribution storefront.
It should be reasonably easy to be a distributor – until such time as shown to be irresponsible etc + they can choose what material they want to distribute at some level. E.g. Devleopers obliged to do something about rating the apps – via some form of submission form.
Perhaps look at Digital River + what they do ?
Kill switch is pretty much same as currently implemented.
Realize that Operators are simply dumb pipes, (in more ways than one) and bypass them totally if required. All they do is get in the way of any form of progress. If they want to have rigorous tests on apps they sell on their webstores, thats upto them, for the rest of the world….
Apple has done this very sucessfully.
Yes above only works for online distrib, but given some thought I am sure it can be figured out how to support various offline plans.
And NO I am not advotating a single AppStore – that is very very undesirable – in just about all respects….
Comment by bbj — 15 December 2008 @ 2:51 pm
Thinking a bit more about this perhaps what Symbian really need to do is go back to what Symbian Signed is actually trying to achieve
In my view its
i) tracability
ii) kill switch
and thats really it.
App quality is mostly resolved by market forces + distribution channels. However hard Nokia want to make it to produce crap apps, crap apps will be produced and a route to market found. If they are truely crap few people will actually download/purchase. If they are wonderful this news will spread quickly.
Perhaps a radically alternate plan is required e.g. much more along the lines of the AppStore:
Symbian/Nokia run an application repository.
Only applications in the repository can be distributed = tracablity, e.g. via some certificate. As far as I can tell, currently the vast majority of Symbian apps are not signed, and not traceable so the scheme is failing one of its core objectives.
There should not be many reasons why apps cannot be put in the repository = dont apply one set of ethics to other industries/countries. Some limited QA can be done here if required.
Distributors are ‘licenced’ and obliged to report back on rogue apps. Only licenced distributors can distribute the apps. Should reduce the number of craked sites (usually where the malware is anyway) + much easier for the industry to spot such sites.
Each distribution channel decides on whether the app needs to pass the equivalent to Symbian Signed testing, nothing or their own regime.
About 99.999999% dont require anything, the other %age have their own regime anyway – so why deny this reality?. Symbian just provide the default test doc.
Any half sensible distributor would want to block rogue apps anyway, even if blocking = dont allow this app to be presented on my distribution storefront.
It should be reasonably easy to be a distributor – until such time as shown to be irresponsible etc + they can choose what material they want to distribute at some level. E.g. Devleopers obliged to do something about rating the apps – via some form of submission form.
Perhaps look at Digital River + what they do ?
Kill switch is pretty much same as currently implemented.
Realize that Operators are simply dumb pipes, (in more ways than one) and bypass them totally if required. All they do is get in the way of any form of progress. If they want to have rigorous tests on apps they sell on their webstores, thats upto them, for the rest of the world….
Apple has done this very sucessfully.
Yes above only works for online distrib, but given some thought I am sure it can be figured out how to support various offline plans.
And NO I am not advotating a single AppStore – that is very very undesirable – in just about all respects….
Comment by bbj — 15 December 2008 @ 2:51 pm
All you really need to do is a look at the way a symbian signed website is designed and that’s answers all the questions really, totally unusable, not intuitive, buggy and doesn’t even have a proper channels of support (symbian forums ?? joke).
enough said.
Comment by Romkin — 15 December 2008 @ 4:49 pm
All you really need to do is a look at the way a symbian signed website is designed and that’s answers all the questions really, totally unusable, not intuitive, buggy and doesn’t even have a proper channels of support (symbian forums ?? joke).
enough said.
Comment by Romkin — 15 December 2008 @ 4:49 pm
Slightly off topic, but an observation nonetheless, is that operator customisation of handsets often (usually) matches most of your definitions of malware. From random observations over a few years, Orange are perhaps most notorious with their bastardisation of S60 based handsets, leading to huge drops in performance, and other random problems. I am about to return an N82 because of Orange malware I can’t get rid of (despite using quite sophisticated techniques and specialist software). This issue cannot be easily dismissed under the misguided idea that because it’s an operator it must be fine. The user owns the phone, and Symbian (and Nokia) must allow a complete and easy removal of operator branding and other software. Orange especially have proven an inability not to affect handset performance drastically.
Alex
CEO
phonething.com
Comment by Alex — 15 December 2008 @ 6:31 pm
Slightly off topic, but an observation nonetheless, is that operator customisation of handsets often (usually) matches most of your definitions of malware. From random observations over a few years, Orange are perhaps most notorious with their bastardisation of S60 based handsets, leading to huge drops in performance, and other random problems. I am about to return an N82 because of Orange malware I can’t get rid of (despite using quite sophisticated techniques and specialist software). This issue cannot be easily dismissed under the misguided idea that because it’s an operator it must be fine. The user owns the phone, and Symbian (and Nokia) must allow a complete and easy removal of operator branding and other software. Orange especially have proven an inability not to affect handset performance drastically.
Alex
CEO
phonething.com
Comment by Alex — 15 December 2008 @ 6:31 pm
Hi Alex,
>“Slightly off topic, but an observation nonetheless, is that operator customisation of handsets often (usually) matches most of your definitions of malware… leading to huge drops in performance, and other random problems…”
Continuing down this off-topic line of thought, there is in theory an option for the Symbian Foundation to include a wide set of performance criteria in the acceptance test suite applicable before a handset can be branded as "Symbian Foundation compatible" (NB actual brand mark TBD).
I can see, however, that this could become contentious. Just as developers sometimes today complain that the set of tests for Symbian Signed app accreditation is too restrictive, a network operator in this situation could complain that the performance criteria are too restrictive – and that they stand in the way of other benefits from the customisation layer.
Incidentally, current thinking is that any device compatibility test suite will be optional. Device manafacturers will be able to ship phones, even though they fail some of the compatibility tests. However, in such cases, the non-compatibilities would need to be publicised. In such cases, wider community opinion will ideally put pressure on the manufacturer in question to conform in the future.
>The user owns the phone, and Symbian (and Nokia) must allow a complete and easy removal of operator branding and other software.
It depends on the nature of the contract you enter into, with the network operator. If you are receiving a subsidy, you lose some of your bargaining power. But ideally, users will have the option of paying the full price, in which case they should have greater freedom to customise the software on the device they have bought.
// dw2-0
Comment by David Wood — 15 December 2008 @ 10:11 pm
Hi Alex,
>“Slightly off topic, but an observation nonetheless, is that operator customisation of handsets often (usually) matches most of your definitions of malware… leading to huge drops in performance, and other random problems…”
Continuing down this off-topic line of thought, there is in theory an option for the Symbian Foundation to include a wide set of performance criteria in the acceptance test suite applicable before a handset can be branded as "Symbian Foundation compatible" (NB actual brand mark TBD).
I can see, however, that this could become contentious. Just as developers sometimes today complain that the set of tests for Symbian Signed app accreditation is too restrictive, a network operator in this situation could complain that the performance criteria are too restrictive – and that they stand in the way of other benefits from the customisation layer.
Incidentally, current thinking is that any device compatibility test suite will be optional. Device manafacturers will be able to ship phones, even though they fail some of the compatibility tests. However, in such cases, the non-compatibilities would need to be publicised. In such cases, wider community opinion will ideally put pressure on the manufacturer in question to conform in the future.
>The user owns the phone, and Symbian (and Nokia) must allow a complete and easy removal of operator branding and other software.
It depends on the nature of the contract you enter into, with the network operator. If you are receiving a subsidy, you lose some of your bargaining power. But ideally, users will have the option of paying the full price, in which case they should have greater freedom to customise the software on the device they have bought.
// dw2-0
Comment by David Wood — 15 December 2008 @ 10:11 pm
h) Control
David, 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?
Ian
Comment by idij — 16 December 2008 @ 12:08 am
h) Control
David, 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?
Ian
Comment by idij — 16 December 2008 @ 12:08 am
Hi,
I agree on the general criteria except:
(whether the software is intentionally or unintentionally badly behaved)
If the software is not intentionally malware, and just buggy then it should be down to market forces to determine its fate. Trying to police the quality of applications with a central signing scheme in a mandatory way is a bad idea (there’s no reason such a scheme shouldn’t exist for unproven developers to have an option of building trust in their apps, it just shouldn’t be mandatory to get the application onto the phone).
I agree with most of what bbj has said. Although we don’t really want a proliferation of quality approval schemes, we’ve got them anyway, Symbian Signed hasn’t eliminated them. If there’s a central app store (also NOT the only possible distribution channel, but a highlly visible one) that network operators don’t block applications from then it should allow a route to market for all developers. Then, if networks want to lock down their devices they have to actively block downloads from the store and this is clear to the consumers. That way, if people really want to be able to install 3rd party apps then they can vote with their wallets and switch operators or pay for an unlocked device.
Mark
Comment by m_p_wilcox — 16 December 2008 @ 11:32 am
Hi,
I agree on the general criteria except:
(whether the software is intentionally or unintentionally badly behaved)
If the software is not intentionally malware, and just buggy then it should be down to market forces to determine its fate. Trying to police the quality of applications with a central signing scheme in a mandatory way is a bad idea (there’s no reason such a scheme shouldn’t exist for unproven developers to have an option of building trust in their apps, it just shouldn’t be mandatory to get the application onto the phone).
I agree with most of what bbj has said. Although we don’t really want a proliferation of quality approval schemes, we’ve got them anyway, Symbian Signed hasn’t eliminated them. If there’s a central app store (also NOT the only possible distribution channel, but a highlly visible one) that network operators don’t block applications from then it should allow a route to market for all developers. Then, if networks want to lock down their devices they have to actively block downloads from the store and this is clear to the consumers. That way, if people really want to be able to install 3rd party apps then they can vote with their wallets and switch operators or pay for an unlocked device.
Mark
Comment by m_p_wilcox — 16 December 2008 @ 11:32 am
Symbian has a basic problem of defending their stupidity that they did in the past, continuing with same mistakes and ignoring market reality. Symbian always see what they want to see. If Android is so bad why manufacturer like Sony Ericsson who was with Symbian for a long time and very well understand the market is joining OHA announcing that their Android device will touch market in summer 2009.
The simple reason comes to my mind is that Symbian will never learn from its mistakes and continue defending them.
Comment by Unknown — 16 December 2008 @ 11:46 am
Symbian has a basic problem of defending their stupidity that they did in the past, continuing with same mistakes and ignoring market reality. Symbian always see what they want to see. If Android is so bad why manufacturer like Sony Ericsson who was with Symbian for a long time and very well understand the market is joining OHA announcing that their Android device will touch market in summer 2009.
The simple reason comes to my mind is that Symbian will never learn from its mistakes and continue defending them.
Comment by Unknown — 16 December 2008 @ 11:46 am
Hi David,
thanks for addressing this controversial topic once again. 🙂
Requiring signing without the option of user override is about control, pure and simple.
I believe that there is some truth to this, and in my view this shows that the officially stated goals of Symbian Signed have become somewhat muddled in a few respects:
Compared to the headline goal of keeping malware out, I find that the goal of restricting access to DRM falls into a completely different category, because it is actually intended to protect the content/device against the user in certain ways – only this explains some design choices in Symbian Signed (no overrides of specific settings even for very advanced users). In my view this requirement should be honestly stated as such.
On the other hand, making cracked applications more difficult to distribute has (to my knowledge) not featured in the original list of Symbian Signed goals, and appears a bit “tacked on” – as a result, the protection against this is only partial, and really helps only applications that fundamentally require Extended or Manufacturer Approved capabilities for function properly (and thus can’t be re-signed by end users easily). It is a nice side-effect for some developers that makes their efforts to pass Symbian Signed a bit more worthwhile, but in my view it is currently no more than that.
And finally I agree with everything said in the comments above about http://www.symbiansigned.com – in my view, outsourcing such a vital piece of API to an external company, rather than treating it as a distributed part of the overall system, was a big mistake. If you want to see Symbian running molasses, this is the place to look. 😉
ciao marcus
Comment by Marcus Groeber — 16 December 2008 @ 1:42 pm
Hi David,
thanks for addressing this controversial topic once again. 🙂
Requiring signing without the option of user override is about control, pure and simple.
I believe that there is some truth to this, and in my view this shows that the officially stated goals of Symbian Signed have become somewhat muddled in a few respects:
Compared to the headline goal of keeping malware out, I find that the goal of restricting access to DRM falls into a completely different category, because it is actually intended to protect the content/device against the user in certain ways – only this explains some design choices in Symbian Signed (no overrides of specific settings even for very advanced users). In my view this requirement should be honestly stated as such.
On the other hand, making cracked applications more difficult to distribute has (to my knowledge) not featured in the original list of Symbian Signed goals, and appears a bit “tacked on” – as a result, the protection against this is only partial, and really helps only applications that fundamentally require Extended or Manufacturer Approved capabilities for function properly (and thus can’t be re-signed by end users easily). It is a nice side-effect for some developers that makes their efforts to pass Symbian Signed a bit more worthwhile, but in my view it is currently no more than that.
And finally I agree with everything said in the comments above about http://www.symbiansigned.com – in my view, outsourcing such a vital piece of API to an external company, rather than treating it as a distributed part of the overall system, was a big mistake. If you want to see Symbian running molasses, this is the place to look. 😉
ciao marcus
Comment by Marcus Groeber — 16 December 2008 @ 1:42 pm
Hi Rick,
>"I read Android article and unexpected roaming charges. I am not sure about roaming APIs in Android; however I would like to highlight a fact on Symbian that in Public SDK there is no way to know if a user is in Roaming or Not.
>"Application developers wants to give option not trigger data connection/call answer etc automatically and should prompt user or may be shut off the operation in roaming. But since Symbian does not provide public API to do that so developers have no way to detect scenario."
Actually I understand that Symbian’s ETEL library does provide this functionality, via the functions
CTelephony::GetNetworkRegistrationStatus
and
CTelephony::NotifyChange(…ENetworkRegistrationStatusChange…)
// dw2-0
Comment by David Wood — 16 December 2008 @ 4:53 pm
Hi Rick,
>"I read Android article and unexpected roaming charges. I am not sure about roaming APIs in Android; however I would like to highlight a fact on Symbian that in Public SDK there is no way to know if a user is in Roaming or Not.
>"Application developers wants to give option not trigger data connection/call answer etc automatically and should prompt user or may be shut off the operation in roaming. But since Symbian does not provide public API to do that so developers have no way to detect scenario."
Actually I understand that Symbian’s ETEL library does provide this functionality, via the functions
CTelephony::GetNetworkRegistrationStatus
and
CTelephony::NotifyChange(…ENetworkRegistrationStatusChange…)
// dw2-0
Comment by David Wood — 16 December 2008 @ 4:53 pm
Hi Unknown,
>“Symbian has a basic problem of defending their stupidity that they did in the past, continuing with same mistakes and ignoring market reality…”
Symbian has changed aspects of its OS and ecosystem management many times in the past, and we'll change them many times in the future too!
However, I want to avoid throwing out the baby with the bathwater.
One thing that did happen when Symbian Signed and PlatSec were put in place was that a mushrooming set of scare stories about wireless malware ramped back down again. I don't want to let that particular genie out of the bag again, by making over-hasty changes to Symbian Signed and PlatSec now.
>Symbian always see what they want to see. If Android is so bad…”
I hope that I’ve never said (or implied) that “Android is bad”. If so, I sincerely apologise. Both Android and Symbian clearly have a mixture of strong points and weaker points. I do think that Android will face challenges – just as Symbian faces challenges.
// dw2-0
Comment by David Wood — 16 December 2008 @ 4:59 pm
Hi Unknown,
>“Symbian has a basic problem of defending their stupidity that they did in the past, continuing with same mistakes and ignoring market reality…”
Symbian has changed aspects of its OS and ecosystem management many times in the past, and we'll change them many times in the future too!
However, I want to avoid throwing out the baby with the bathwater.
One thing that did happen when Symbian Signed and PlatSec were put in place was that a mushrooming set of scare stories about wireless malware ramped back down again. I don't want to let that particular genie out of the bag again, by making over-hasty changes to Symbian Signed and PlatSec now.
>Symbian always see what they want to see. If Android is so bad…”
I hope that I’ve never said (or implied) that “Android is bad”. If so, I sincerely apologise. Both Android and Symbian clearly have a mixture of strong points and weaker points. I do think that Android will face challenges – just as Symbian faces challenges.
// dw2-0
Comment by David Wood — 16 December 2008 @ 4:59 pm
Thanks David,
We were using RTel APIs and API for this purpose was removed in 3rd ed. Our mistake that we didn’t rewrite our code when moved to 3rd ed to avoid additional efforts. Sorry to bother you. We have to reconsider our decision.
Thanks Again.
BTW symbian signed doesn’t help in ensuring these practical scenarios. It has to come from developers.
Comment by Rick — 16 December 2008 @ 5:06 pm
Thanks David,
We were using RTel APIs and API for this purpose was removed in 3rd ed. Our mistake that we didn’t rewrite our code when moved to 3rd ed to avoid additional efforts. Sorry to bother you. We have to reconsider our decision.
Thanks Again.
BTW symbian signed doesn’t help in ensuring these practical scenarios. It has to come from developers.
Comment by Rick — 16 December 2008 @ 5:06 pm
First @David:
a) it is easy to justify that Symbian Signed saves users from malware but in fact out of the possible attacks you list there only the latest two are covered by the testing criteria. It is as easy (if not easier) to make a call/sms to a 1-900- number than to make an emergency call.
b) user’s confidence has to be won and that requires marketing efforts which Symbian Signed has not done. Open Signed Online open to users does not attract confidence.
c) Symbian Signed does not protect for cracked software except to the extend of forcing a software signer to authenticate itself when requesting restricted capabilities
d) Check your Download! application and tell me how many anti-virus apps you have there for download – at least one is always available. And that good since at least one signed application has been lately classified as malware
e) Google’s G1 is now available in a hardware unlocked version that can be flashed with an malware OS if so wished, yet nobody seem to have a problem with that (ok, it is not a mass market option but still)
f) same as above
g) fragmentation is bad but at the same time you cannot really have a one fit all kind of solution in which to throw hobbyists and enterprise developers.
So, I agree with the intent although I’m not so sure that PlatSec and Symbian Signed are really addressing the issues. Maybe an open discussion on what is malware and how to fight it would have been relevant (maybe still is).
Now, regarding the comments: Application quality is one thing, security is another. Obviously it takes more time to develop and test a good quality application but that is not a good enough reason to complain.
I love Paul’s idea about Nokia and Symbian using their own medicine, that would be indeed something to watch. I would also recommend them to train their employees and to ask them to work using the public SDK and the public documentation too. 🙂
A couple of other comments are simply lacking the technical understanding of the problem so they are slightly amusing. And sad at the same time when we’re now 4 years past the adoption of PlatSec. Btw, does anyone here remember that Symbian Signed existed even before that (although not mandatory)?
Comment by Tom — 16 December 2008 @ 8:55 pm
First @David:
a) it is easy to justify that Symbian Signed saves users from malware but in fact out of the possible attacks you list there only the latest two are covered by the testing criteria. It is as easy (if not easier) to make a call/sms to a 1-900- number than to make an emergency call.
b) user’s confidence has to be won and that requires marketing efforts which Symbian Signed has not done. Open Signed Online open to users does not attract confidence.
c) Symbian Signed does not protect for cracked software except to the extend of forcing a software signer to authenticate itself when requesting restricted capabilities
d) Check your Download! application and tell me how many anti-virus apps you have there for download – at least one is always available. And that good since at least one signed application has been lately classified as malware
e) Google’s G1 is now available in a hardware unlocked version that can be flashed with an malware OS if so wished, yet nobody seem to have a problem with that (ok, it is not a mass market option but still)
f) same as above
g) fragmentation is bad but at the same time you cannot really have a one fit all kind of solution in which to throw hobbyists and enterprise developers.
So, I agree with the intent although I’m not so sure that PlatSec and Symbian Signed are really addressing the issues. Maybe an open discussion on what is malware and how to fight it would have been relevant (maybe still is).
Now, regarding the comments: Application quality is one thing, security is another. Obviously it takes more time to develop and test a good quality application but that is not a good enough reason to complain.
I love Paul’s idea about Nokia and Symbian using their own medicine, that would be indeed something to watch. I would also recommend them to train their employees and to ask them to work using the public SDK and the public documentation too. 🙂
A couple of other comments are simply lacking the technical understanding of the problem so they are slightly amusing. And sad at the same time when we’re now 4 years past the adoption of PlatSec. Btw, does anyone here remember that Symbian Signed existed even before that (although not mandatory)?
Comment by Tom — 16 December 2008 @ 8:55 pm
I think signing should not be mandatory. Instead we should have a global security preferences which let us choose for each privilege between the following:
– Ask always
– Ask first time
– Deny
– Allow
And then the same settings for each application, signed or not (maybe accessible from context menu).
Of course there should be profiles for grouping options with whatever name one decides to use (i.e.: trusted, not trusted, testing, whatever…) and assigning them to apps at user discretion.
That would give the user the power and control, which, I’m not sure about others, but that’s what I want when I decide to go for a smart phone and suffer slower GUI, shorter battery duration and a bigger price.
From a user’s perspective, the advantage symbian currently has is the physical format of their phones, you can choose between keyboard, monoblock, slider, etc.. with winmo you are more restricted to pda like phones. If you could install any SO to any phone I seriously doubt I will be running S60.
Comment by Carlos — 18 December 2008 @ 9:07 am
I think signing should not be mandatory. Instead we should have a global security preferences which let us choose for each privilege between the following:
– Ask always
– Ask first time
– Deny
– Allow
And then the same settings for each application, signed or not (maybe accessible from context menu).
Of course there should be profiles for grouping options with whatever name one decides to use (i.e.: trusted, not trusted, testing, whatever…) and assigning them to apps at user discretion.
That would give the user the power and control, which, I’m not sure about others, but that’s what I want when I decide to go for a smart phone and suffer slower GUI, shorter battery duration and a bigger price.
From a user’s perspective, the advantage symbian currently has is the physical format of their phones, you can choose between keyboard, monoblock, slider, etc.. with winmo you are more restricted to pda like phones. If you could install any SO to any phone I seriously doubt I will be running S60.
Comment by Carlos — 18 December 2008 @ 9:07 am