It's autumn, it's time for the Symbian Smartphone Show, which means it must be time to wheel Symbian Signed back out in the open! Developer Sampo Suvisaari has been writing about why Symbian Signed means less choice for end users and proposes a simple and brilliant change to the system.
Read on in the full article.
The prosed change is a good idea in theory. However in practise I'm not sure it would work. I don't think operators would go for it. Moreover even established companies are failing Symbian Signed tests on newly submitted proucts at times. I would assume Symbian would wish to maintain the current levels of requirements and there's no way to do this without testing every application.
That said I would agree that the multiple version thing does need to be addressed as do small upgrades or bug fixes.
Correct me if I'm wrong but isn't it possible to run unsigned software by altering the settings on your 3rd Edition device? I thought that's what I'd been doing when running application beta versions etc.
I'm not sure what the fuss is about, so I assume I'm missing something?
As I understand it, unsigned apps both show up the security warning (which as, you say, isn't THAT a big deal) and also have restrictions on which device functionality can be accessed (like sending emails and SMS silently, the sort of propagation stuff that malware would want to do)....
Any experts/developers in here?
Steve
I'm not a specialist but from what i've read, warning dialogs are not the only problem that self-signed applications encounter. Self-signed application simply can not access some of the phone's functionality at all. The article mentions the problem with the IMEI: self-signed application can not apparently access the phone's IMEI. Manufacturer's capabilties are also not accessible from self-signed application. See Simon's post here http://mobilephonedevelopment.com/archives/191 about that for example (in this post, he also discovers that it's actually Symbian that decides what your application can do and cannot do. If they don't like what your application does for whatever reason, they won't sign it so you can scrap it and write off all the time and money you spent developing it).
Does anyone actually know what functions unsigned applications can't use? Sending SMSes or emails silently seem relatively unimportant functions, is there something else?
I'm just wondering how much of a problem this really is for developers.
IMEI access is clearly important in selling software I suppose, but I don't understand why that would be restricted, surely there's no way malware could use IMEI for dangerous purposes?
And is there an alternative way of preventing malware without a central body vetting applications?
The SDK states for each class which capabilities are used. Unsigned apps cannot use API's that need capabilities. As it happens in Avkon the CSendUI class, which is meant for sending SMS, emails and such from a menu can only be used when the app is signed.
A phone's IMEI can be reporgrammed, so by stealing somebody's IMEI and reprogramming your phone, your phone can pretend to be somebody else's phone. This might sound unimportant, but in Holland there was a murder case where the position of the suspects phone in relation to GSM masts was used as evidence for the suspects location close to the time of the murder.
The IMEI being used for copy protection is bevause nothing better is available, not because the IMEI itself is important.
Sander van der Wal
mBrain Software
krisse wrote:Correct me if I'm wrong but isn't it possible to run unsigned software by altering the settings on your 3rd Edition device? I thought that's what I'd been doing when running application beta versions etc.I'm not sure what the fuss is about, so I assume I'm missing something?
No you can't install unsigned applications on your phone under S60 3rd Edition. What you can do (but you have to enable that in the App. Manager settings: Software Installation -> All) is install self-signed applications but, as we were saying, self signed application have a somewhat limited access to the phone functionalities. Granted though, the settings are a bit confusing since it says "All" when it should really say: "Symbian signed and self-signed".
Hi,
Yes you can install non Symbian Signed apps on your phone if you change the installer settings. Such apps may well fulfill all your requirements in the area in which they are providing a solution, however thats not true of many classes of apps.
It really depends on what type of app you want to write as to whether capabilities are required. Its then a somewhat different issues as to whether you need to be Symbian Signed.
E.g.
Want a real file manager - not the pretend one shipped on numerous devices - well you need Symbian Signed, sell your company to Nokia/Symbian/SE, kidnap the big chief of any of these companies + promise to only ever list the directory contents, sell the dog, cat, house children, and your soul to demand AllFiles capability.....
Want to write a file recogniser so your app gets lauched e.g. when web browser gets to some content it otherwise does not know about - Symbian Signed
Want to write a location based app - e.g. Treasure Hunt game - Symbian Signed. I imagine pretty much any mapping app needs this as well.
Want to write an app that looks at the Contacts DB - e.g .a replacement Contacts app - Symbian Signed.
Almost certainly true of the Message stores and Agenda as well. (new email client and replacement Diary apps)
Games:
Want to play games via Bluetooth. Dont need to be Symbian Signed.
Want to be able to send say an SMS to post the high score - Symbian Signed required.
Want to have in-game chat e.g. via SMS - Symbian Signed
Want to have SIP based multiplayer gaming - Symbian Signed
Just want to write a plain single user game - probably dont need to be Symbian Signed.
etc
In theory the Symbian SDK's document what functions require what capabilities in order to function correctly. However, if you've ever actually attempted to use the SDK docs + believe whats in them you havnt done much Symbian programming 😊
E.g. an example at random (well alright pseudo random with a very poor generator):
The Rfs::Att() function to obtian the file attributes is defined in the SDK to require 'AllFiles' capability. Apart from being insane this is just plain wrong. You dont need 'AllFiles' UNLESS you are attempting to read file attributes of files in the restricted parts of the file store - in which case attempting to read the file attributes is the least of the problems.
There is also the fantastic note in the SDK where it lists the capabilites stating
"Note: Implementation may vary between devices"
- so just because Capability X is user grantable at install time on your test device it may or may not be user grantable on the customer device. Well thats really useful.
Is it a real problem... Yes and no. Its a pain in the rrrr's, can become expensive and definatly slows development. It hits large and small companies in totally different ways. E,g, individuals cant actually get a Verisign ACS publisher cert despite the fact that their entire vetting procedure appears to be phoning you up once a year. On the other hand large companies have serious procedural issues actually giving mere mortal progammers the private (top secret) key files + pass words needs to actually sign the files - just incase they compromise the privacy of the private key. Having a publically available private key sort of defeats the point !!
A classic example of other sort of issue that dont get considered:
Due to a change in the Nokia firmware concerning how keyboards work on E61 - in particular what keys are deliverd to apps - one of our apps suddently became unusable - 0 to 9 were no longer delivered to the app at all !.
Because Nokia have either fixed a bug or introduced one in the firmware release (depending on your view) we had to change the app and get it re-signed (with all the associated costs). So thats several hundred sales worth of reveune gone up in smoke.
PS
IMEI access is restricted primarily due to a BUG which is supposed to be fixed in later phone versions, most real world devices you need NetworkServices and ReadDeviceData irrespective of what you may read in any SDK.
bbj wrote:
Want a real file manager - not the pretend one shipped on numerous devices - well you need Symbian Signed, sell your company to Nokia/Symbian/SE, kidnap the big chief of any of these companies + promise to only ever list the directory contents, sell the dog, cat, house children, and your soul to demand AllFiles capability.....
Want to write a file recogniser so your app gets lauched e.g. when web browser gets to some content it otherwise does not know about - Symbian Signed
Want to write a location based app - e.g. Treasure Hunt game - Symbian Signed. I imagine pretty much any mapping app needs this as well.
Want to write an app that looks at the Contacts DB - e.g .a replacement Contacts app - Symbian Signed.Almost certainly true of the Message stores and Agenda as well. (new email client and replacement Diary apps)
Games:
Want to play games via Bluetooth. Dont need to be Symbian Signed.Want to be able to send say an SMS to post the high score - Symbian Signed required.
Want to have in-game chat e.g. via SMS - Symbian Signed
Want to have SIP based multiplayer gaming - Symbian Signed
Just want to write a plain single user game - probably dont need to be Symbian Signed.
In theory the Symbian SDK's document what functions require what capabilities in order to function correctly. However, if you've ever actually attempted to use the SDK docs + believe whats in them you havnt done much Symbian programming 😊E.g. an example at random (well alright pseudo random with a very poor generator):
The Rfs::Att() function to obtian the file attributes is defined in the SDK to require 'AllFiles' capability. Apart from being insane this is just plain wrong. You dont need 'AllFiles' UNLESS you are attempting to read file attributes of files in the restricted parts of the file store - in which case attempting to read the file attributes is the least of the problems.There is also the fantastic note in the SDK where it lists the capabilites stating
"Note: Implementation may vary between devices"
- so just because Capability X is user grantable at install time on your test device it may or may not be user grantable on the customer device. Well thats really useful.
Is it a real problem... Yes and no. Its a pain in the rrrr's, can become expensive and definatly slows development. It hits large and small companies in totally different ways. E,g, individuals cant actually get a Verisign ACS publisher cert despite the fact that their entire vetting procedure appears to be phoning you up once a year. On the other hand large companies have serious procedural issues actually giving mere mortal progammers the private (top secret) key files + pass words needs to actually sign the files - just incase they compromise the privacy of the private key. Having a publically available private key sort of defeats the point !!A classic example of other sort of issue that dont get considered:
Due to a change in the Nokia firmware concerning how keyboards work on E61 - in particular what keys are deliverd to apps - one of our apps suddently became unusable - 0 to 9 were no longer delivered to the app at all !.
Because Nokia have either fixed a bug or introduced one in the firmware release (depending on your view) we had to change the app and get it re-signed (with all the associated costs). So thats several hundred sales worth of reveune gone up in smoke.PS
IMEI access is restricted primarily due to a BUG which is supposed to be fixed in later phone versions, most real world devices you need NetworkServices and ReadDeviceData irrespective of what you may read in any SDK.
Unfortunately, this is the way this industry behaves. It's always after the next big money spinner, and software usability is not the most important thing on it's mind. Propably there right about the software too, because, ATM, software isn't selling mobiles.
Sander van der Wal
mBrain Software