Software architect working in Symbian/S60 area since 2000 and still being enthusiastic about mobility. Please visit my introduction page on Forum Nokia Champions web page.
Here is my program, sign it yourself!
tote_b5 | 01 March, 2007 16:22
I've bumped into the following blog today. This is exactly what I was thinking about a few weeks ago! I asked myself if developers could distribute their apps freely? Of course, the bottleneck is that they have to sign their apps properly, which is time-consuming and costly. But if one publishes his unsigned SIS file (it can be signed as well, since a file can be re-signed), then it can be freely signed by anybody else. So that the author can get rid of the burden of having to have his application SymbianSigned before distribution takes place.
One issue, though, that this workaround raises is trust. Why would I sign a SIS if it's from somebody whom I don't know? Why would I trust the program and presume that it will make no damage, generate extra cost, etc.? Of course, it's such an issue that must be carefully considered, case by case, program by program. But still there are programs whose authors are well-known and respected: they haven't all had time/money to bother with signing. Or let's take open source projects: unless they have good funding they will never spend money on content signing, which cost will never be returned. Not as if I was aware of such an open source project, but still. :)
So let's have a closer look at how it would work in practice! The classification of capabilities is as follows:
Group #1: User-grantable capabilities that can be granted by the user upon installation.
Capabilities: LocalServices, UserEnvironment, NetworkServices, Location, ReadUserData and WriteUserData.
Group #2: Powerful capabilities that cannot be granted by the user, but do not require any manufacturers' approval.
Capabilities: PowerMgmt, ReadDeviceData, WriteDeviceData, TrustedUI, ProtServ, SwEvent, SurroundingsDD.
Group #3: The most sensitive capabilities that only device manufacturers (i.e. not SymbianSigned or any other authority) can grant.
Capabilities: AllFiles, CommDD, DiskAdmin, MultimediaDD, NetworkControl, TCB, DRM.
If one writes a program that requires capabilities from groups #1-2 then it can be easily signed by anybody even if it demands some sort of technical mindedness. The steps for being able to install such a SIS file on our phone are as follows:
And what about those programs that use APIs protected by capabilities from group #3? For them, one must have an ACS Publisher ID even for a single phone. And not only is it the cost that might prevent most people from requesting a publisher ID from VeriSign. If you'd like to be able to sign programs with the most sensitive capabilities, then getting a publisher ID is the easier task. The second step is to issue a request to the device manufacturer in which you detail which capability you need and why. On API level (e.g. I need RFormat::Open() to use and for that I have to have DiskAdmin capability) and for each capability one by one. And believe me it's tough! It's time and energy consuming and sometimes doesn't lack unnecessary conversation with the manufacturer ('we don't think you need that capability' ... arghh).
As a brief summary I still think that it's worth going on this path. For a well-isolated target group, namely mobile geeks, but for them it's really worth. Yes, it's you who reads this blog. :)
Tote
One issue, though, that this workaround raises is trust. Why would I sign a SIS if it's from somebody whom I don't know? Why would I trust the program and presume that it will make no damage, generate extra cost, etc.? Of course, it's such an issue that must be carefully considered, case by case, program by program. But still there are programs whose authors are well-known and respected: they haven't all had time/money to bother with signing. Or let's take open source projects: unless they have good funding they will never spend money on content signing, which cost will never be returned. Not as if I was aware of such an open source project, but still. :)
So let's have a closer look at how it would work in practice! The classification of capabilities is as follows:
Group #1: User-grantable capabilities that can be granted by the user upon installation.
Capabilities: LocalServices, UserEnvironment, NetworkServices, Location, ReadUserData and WriteUserData.
Group #2: Powerful capabilities that cannot be granted by the user, but do not require any manufacturers' approval.
Capabilities: PowerMgmt, ReadDeviceData, WriteDeviceData, TrustedUI, ProtServ, SwEvent, SurroundingsDD.
Group #3: The most sensitive capabilities that only device manufacturers (i.e. not SymbianSigned or any other authority) can grant.
Capabilities: AllFiles, CommDD, DiskAdmin, MultimediaDD, NetworkControl, TCB, DRM.
If one writes a program that requires capabilities from groups #1-2 then it can be easily signed by anybody even if it demands some sort of technical mindedness. The steps for being able to install such a SIS file on our phone are as follows:
- Registration on SymbianSigned.com.
- Requesting a developer certificate for a given IMEI (i.e. the person's own mobile phone).
- Once having the DevCert, sign the program with it.
And what about those programs that use APIs protected by capabilities from group #3? For them, one must have an ACS Publisher ID even for a single phone. And not only is it the cost that might prevent most people from requesting a publisher ID from VeriSign. If you'd like to be able to sign programs with the most sensitive capabilities, then getting a publisher ID is the easier task. The second step is to issue a request to the device manufacturer in which you detail which capability you need and why. On API level (e.g. I need RFormat::Open() to use and for that I have to have DiskAdmin capability) and for each capability one by one. And believe me it's tough! It's time and energy consuming and sometimes doesn't lack unnecessary conversation with the manufacturer ('we don't think you need that capability' ... arghh).
As a brief summary I still think that it's worth going on this path. For a well-isolated target group, namely mobile geeks, but for them it's really worth. Yes, it's you who reads this blog. :)
Tote
General, Symbian C++ |
Next | 
Previous |
Comments (4) | 
Trackbacks (0)
Comments
Re: Here is my program, sign it yourself!
tote_b5 | 04/03/2007, 17:59
Hey David,Your TaskSpy is a great tool! Btw is it open source or something? Or "just" the source code is available to everyone?
Tote
Re: Here is my program, sign it yourself!
PushL | 04/03/2007, 23:07
Gábor,
The source code was released without any specific license in mind. Personally, I consider it to be in the public domain.
Regards,
David.-
The source code was released without any specific license in mind. Personally, I consider it to be in the public domain.
Regards,
David.-
Re: Here is my program, sign it yourself!
feenix | 06/03/2007, 14:32
I also have thought about this, at least for beta testing. The more technically adept people could sign the app themselves and get the full functionality.
But, IIRC, if I state in the MMP that I want ReadDeviceData and sign it without any IMEIs, the app won't even install. This is very frustrating. The correct way would be to allow the installation and since the functions already return an error if the SW doesn't have the needed caps, there would be no problem. So we could say "I want ReadDeviceData but if it's not available, then give me an error" and one SIS could be signed for self-signed and per-device.
Now we have to have two binaries built (which is not nice), one with #1 caps, second with #2 caps and then distribute them separately. ARGH!
But, IIRC, if I state in the MMP that I want ReadDeviceData and sign it without any IMEIs, the app won't even install. This is very frustrating. The correct way would be to allow the installation and since the functions already return an error if the SW doesn't have the needed caps, there would be no problem. So we could say "I want ReadDeviceData but if it's not available, then give me an error" and one SIS could be signed for self-signed and per-device.
Now we have to have two binaries built (which is not nice), one with #1 caps, second with #2 caps and then distribute them separately. ARGH!
Who am I?
Software architect working in Symbian/S60 area since 2000 and still being enthusiastic about mobility. Please visit my introduction page on Forum Nokia Champions web page.
Calendar
Recently...
- Random thoughts on recent news
- Ridiculous strict control in Apple AppStore
- Transforming mobile industry
- Samsung Mobile Innovator - Yet another Symbian developer site
- Silicon Valley doesn't respect Nokia
- Brief status report about smartphone market, mid-2008
- Symbian and Nokia wrestling about voting rights?
- Static vs active application icons
- Cross-platform development
- Collection of great materials on Symbian going open-source
Categories
- Symbian Foundation [5]
- Nokia [5]
- Android [6]
- Linux [6]
- Development [8]
- Innovation [1]
- Symbian [10]
- Windows Mobile [7]
- Platform Security [2]
- iPhone [10]
- UI [2]
- Mobile OS [12]
- Testing [3]
- Symbian C++ [11]
- Series 80 [0]
- Series 40 [0]
- S60 [13]
- Python [0]
- Open C [1]
- Messaging [0]
- Location Based Services [1]
- Java [3]
- General [16]
- Games [0]
- Flash [1]
- Event [5]
- Entertainment [0]
- Enterprise [3]
- Connectivity [2]
- CDMA [0]
- Business Opportunities/Services [17]
- Browsing [5]
Re: Here is my program, sign it yourself!
PushL | 04/03/2007, 11:57
Unfortunately I don't have enough time at this moment to continue its development, make it pass the criteria, etc. so the easiest way I figured out was releasing an unsigned sis file. I do get some emails from time to time from people who's clueless and don't know what this is all about, but I presume (and expect) that most people won't have problems getting it working.. And if there is any trust issue, you have the source code there :)
Unfortunately, this is still not enough for AllFiles & file browsers...
Regards,
David.-