Gabor Torok's Forum Nokia Blog

Browser as an application platform

Thu, 19 Jun 2008 01:10:10 +0200

I've read the following analysis from ARCchart with great interest. I'm already familiar with the idea of writing applications for mobile browsers and that it can be considered as a real alternative for mobile software development. WidSets and Widgets are all around us, not to mention Flash Lite, Silverlight, two cross-platform solutions used for delivering (multimedia) content to more and more people.

The main point of ARCchart's article was to point out that the whole problem of fragmented mobile development could be solved by developing to a single run-time environment: the browser. The browser, which is today's most widely used applications on desktop and mobile computing devices alike.

What is this fragmentation thing, one could ask? Well, let's have a quick look at various mobile platforms, development environments:

It's a known fact that Symbian/C++ opens the door to the wide variety of native features of S60 and UIQ devices, however, it still has a steep learning curve and its programming environment is not too developer-friendly, either, compared to e.g. Java. The vast majority of smartphones are running on Symbian operating system (whether iPhone-fans admit it or not), however, development is often more (cost-)efficient for other platforms. Portability is a serious issue in Symbian.
Windows Mobile devices are very popular in North-America, especially among business users. However, its popularity is way behind Symbian phones' anywhere else in the world and don't forget the fact that there are much more consumers than prosumers. On this platform, you can write native applications in Win32/MFC/.Net, however, these applications are rarely portable across other platforms.
Java? Hell, it's the king of fragmentation in terms of supported (or rather unsupported) features, so-called JSRs. Even though it was supposed to bring the Paradise to mobile software developers, it's still suffering from severe problems.
What else? Linux? Show me some popular Linux-powered phones first and how people are making cross-platform, backward compatible programs for them.
iPhone? Mac OS X with its Objective C just increases variation. Even though C++ can also be used for programming and there are, for example, attempts to port JME programs to Obj-C, as I said: it just increases variation, which is the nightmare of programers.
Android? Although the whole system is based on mobile Linux, the primary development language will be Java. But which Java? Google's own. And although it's said to be a solid foundation for Google OHA members, it's still only a recommendation for them to choose whether various features will be supported in their devices or not. You can imagine how it affects fragmentation in the Java world - it will just make it even more complex.

Now how does a browser come into play? I'm sure that most readers of this blog have already heard of WebKit, an open source browser engine enabling mobile browsers to show and handle full-web content. It is used in Mac OS X's Safari (iPhone browser), Nokia's S60 browser, the built-in browser of Google's Android will also be WebKit-based, not to mention Digia's @Web, a recently announced port of WebKit for UIQ phones. Although there are other good browsers, too, such as Opera Mobile and IE in Windows Mobile, WebKit seems to be becoming the de facto standard in mobile devices (which is not necessarily a bad thing). It's also worth mentioning Opera Mini and TeaShark at this point, two Java-based browsers, both using remote back-end servers for pre-processing full-web content and showing only the digested content formatted for resource-constrained devices. Side-note: it's also WebKit that is running on TeaShark's back-end servers. :)

So is ARCchart right or not? Is the browser the ultimate solution for mobile software development? In my opinion yes and no. They're right that mobile browsers and complementing technologies (such as Flash Lite) are becoming more and more powerful, capable of rendering extremely complex web pages, performing surprisingly smart functions, letting the user interact with active content, exchanging data with remote servers, etc. However, whilst "older" web technologies (e.g. JavaScript) are not powerful enough to compete with the power of real programming languages, newer ones (e.g. Flash Lite) have not been widely adopted yet. For example, for a quick and very brief reference as to what the different versions of Flash Lite can and cannot do, visit this link. And even though there's not too much variation here yet, there will be: newer versions of Flash Lite will require developers to keep track of which mobile phone supports which version, how to distinguish between Silverlight and Flash Lite applications, etc. I'm afraid it won't be any different in the end.

In my opinion, web-based technologies will open up new alternatives (they've already done so, actually) for mobile software: not necessarily too complex ones, but at least enjoyable. And this is exactly what most people are looking for: they'd like to enjoy using these programs. These new kind of programs that complete the whole picture, add to it, but will NOT replace yet older but still powerful technologies.

Can hardly wait for your comments,

Tote

True emulation for Symbian development - when?

Fri, 11 Apr 2008 16:24:17 +0200

Though I've already heard that Windows Mobile SDK offers true phone emulation, however, only now have I got to the point that I ask for your opinion: why cannot we do the same during Symbian software development?

Note that you might have also heard that iPhone developers can also rely on this useful service. Nevertheless, don't forget to bear in mind that they must be working on the same platform, i.e. MacIntosh OSX. That is, there's not too much to emulate there.

But Windows Mobile is different: you develop on Windows presumably on an x86 architecture and produce binary code for another processor architecture (ARM) that you can even debug on. How? Why on Earth cannot we do the same?

Tote

Another hack for Symbian Platform Security

Sun, 09 Mar 2008 23:35:04 +0100

One of my articles that has gained lots of attention was written about hacking Symbian Platform Security. Although it turned out that reproducing the workaround found by Symbiaali is laborous, requires strong technical knowledge and its wide-spread use is very unlikely, it clearly showed me that people were interested in this topic.

Today I found another post at Symbian Freak that describes just another way to turn Symbian operating system's well-known permission checking feature off. Although I don't agree with the title of the article (good-bye?? S60??), I think at least it's worth a few words.

What is this crack about? How can we cheat Platform Security capability checking so that it does not care if our program really has the capability being checked or not? Well, in a very special way:

Take a development environment for Symbian, like CodeWarrior Pro or Carbide.C++ Pro. Please note that you will need the ability of on-device debugging, that's why CodeWarrior Personal/Carbide.C++ Express is not enough. I'm unsure if Carbide.C++ Developer Edition was enough (this is between Express and Professional), but I doubt that. More on this later.
Prepare everything for on-device debugging (connect phone to PC, install MetroTRK to phone, etc.).
Start any program from within the development environment (aka IDE) in debug mode.
Change some bits in the kernel stack responsible for security enforcement. This is the most critical place, where you can really turn everything upside-down. And since you can do that, I believe it's Carbide.C++ Professional Edition that you need and not Developer - latter is less expensive, but in turn it provides only on-device application debugging in contrast with Pro's system debugging.
Voilà, we're done - we have access basically to anything.

Disadvantages

The crack is temporary, since everything is done in RAM.
Required tools are expensive: CW Pro was available at ~$1.700 (the product is discontinued and cannot be bought officially), Carbide.C++ Pro can be purchased for $1.300.
Break is limited to one device.
Proved to work only on Nokia N80, on other "hotter" devices (like the N95) it does not work or at least nobody has been able to make it work so far.

What kind of damage can a cracker still do?

Explore file system, discover what is stored where and how (as if you had AllFiles and/or TCB capability) and exploit it.
Access to DRM-protected content (as if you had DRM capability). This might be more dangerous as you can download e.g. DRMed music once and sell it multiple times later on.

To sum up this post, this new way of cheating Platform Security is the traditional way of cracking. I'm not surprised that it had been discovered and published, I just wonder why it has taken so long? And finally, I don't think that it would cause major problems in Symbian ecosystem.

What do you think?

Tote

Update: Corrected the name of Carbide.C++ edition to Express. Thanks Lucian!

Tilt-O-Mania, also known as Nokmote

Thu, 15 Nov 2007 15:09:37 +0100

Have you ever felt that your idea is stolen and "Damn, I wish I had been faster in doing it"? Now I feel exactly that way.

The first time I heard that another Nokia phone, N95, has a built-in accelerometer I started wondering why on Earth? Why on Earth is it worth for Nokia to put such a device in their phone? Has Nokia 5500 Sport (first Nokia device with built-in accelerometer) proven that it's worth making further experiments with? I haven't seen any analysis telling so, although I admit that it doesn't mean anything. Why on Earth has Nokia kept it secret that there was such a gadget in their hottest device? Is it a secret? Isn't it something that makes the device even cooler?

Then I started to think about what we could do with it? First, I thought RotateMe was a great software, I really liked the idea. But I felt something was missing. Then I found it: why not simulate joystick key presses (i.e. left, right, up, down + press) by tilting the device to the right direction? Since it's fairly easy to simulate key events in Symbian C++ just as if they had really occured, I thought it was easy to implement. The good thing in this idea that it works with existing software, no need to re-write or adapt anything: applications will not notice the difference between real keystroke and simulated.

Tilt-O-Mania

That would have been the name of my software. R.I.P. Now it's called Nokmote and it's not mine at all. :( Sorry guys behind the "sad smiley", I'm happy that you'll come out with an implementation, but I must tell you that I'm unhappy that you'll come out with it. :)

To be honest, I was always wondering why nobody had ever discovered the opportunity in writing such a software. As more and more S60 devices will come out with built-in accelerometer this feature could become such an integral part of user experience that even Nokia might want to use it. I dare to claim that even the joystick could be replaced by the accelerometer + this solution in the future. Not only could Nokia save some money by removing some existing hardware (i.e. the joystick), but they might even be able to use the new spare space for other purposes. Isn't it so cool?

And you know what? The solution is not Nokia/Symbian specific: any (mobile) device having a motion sensor could do on-screen navigation like this. Another Symbian phone, iPhone, gPhone even a laptop, though it would be funny to see a businessman tilting his computer at the airport just for the sake of navigation. :)

On the other hand, I was shocked to find that my(?) idea was not original at all. I mean not that now somebody has come out with an implementation for S60, but this idea was implemented years(!) ago on another mobile phone. You know, some of my colleagues have worked with a MyOrigo device and when I told them my idea they enlightened me that it had already been implemented. Check out this article from The Register and you'll see that such a device is already on the market. Okay, it is a not-really-famous mobile phone and perhaps it doesn't even make use of accelerometer data, but still the idea is theirs: user tilts software navigates.

Never mind, although I'm sorry to see that I can't be THE pioneer in this area, I'm happy to see that it'll be available to us soon. Good luck for writing the software!

Originally from mobile-thoughts.blogspot.com.

Tote

Android SDK is out - first impressions

Tue, 13 Nov 2007 03:15:17 +0100

After watching the video about the introduction of Android for developers, I'm convinced that the new phone will generally be as useful and user-friendly as e.g. the-also-newcomer iPhone. Well, it came as no surprise to me, I'm just expecting a lot of innovation from the new player in mobile space. I don't expect that the new platform will offer as many features as traditional Symbian-powered devices and I can even dare to say that it's not going to be as stable, either ... yet. However, I'm pretty sure that they will catch up soon and offer real alternatives for users, phone manufacturers, operators, etc.

What has totally escaped my attention, though, was that the programming language for this platform would be Java. Based on the fact that it's going to be a Linux-based OS I kind of anticipated that the programming language would be C/C++. I don't know the rationale behind this decision, but it will definitely give a boost to the otherwise stagnating JME programming environment.

I wonder, though, how Google is planning to solve the infamous Java fragmantation problem for mobile phones. What is that? Well, even though Java is a very popular and platform-independent (aka portable) programming language, it's just the set of Java core services that is available on every mobile device. The presence of additional features, such as advanced mobile graphics, security, etc. depend on phone manufacturers' decision, whether it's worth adding them. Which makes Java mobile applications market very fragmanted (some features are available, some are not) and development very frustrating. You know, I have heard an example that a mobile Java game programmer had to make 100(!) variants of his game "just" to be able to distribute it to as many phones as possible.

Another thing about mobile Java development is that most mobile phones are running on another operating system than Java. In fact, Java is not an operating system at all, even though there have been attempts to make Java-based mobile platforms, see e.g. SaveJe for more details. But Symbian OS is similar to Android platform in that they both have their native platform (Symbian OS and Linux, respectively) meaning that platform features are usually available in native programming language first and then some JNI layer added on the top and there you are, it's ready for Java programmers. So far so good. However, it introduces some latency in the equation as it requires some time to write features in native environment first and wrap it in the second round. Will Android suffer from the same problem?

My regular readers already know that I was involved in S60 Browser development and it was very challenging and I really liked it. For that reason, I'm happy to see that Google chose WebKit for their mobile browser (S60 Browser is also based on this rendering engine) and in the demonstration it worked well. I was wondering which display method they would choose for web pages:

S60 approach that displays the web page in its entirety without scaling
or iPhone approach that scales down the web page to so that it fits to display dimensions, though it's hardly readable, but lets the user zoom it very conveniently (e.g. by double-tapping on screen)

They actually chose both: they first display the page without scaling and then user can scale it down for better navigation. I'm pretty sure that Nokia has their own IPR on MiniMap (i.e. the zooming interface) so that might be one of the reasons why Google didn't choose that option. However, what surprised me that they use the same visual history for page navigation as in S60 Browser.

So these are my first impressions after spending half an hour with Android after midnight. I'm really keen to hear your comments - just as usual! :)

Originally from mobile-thoughts.blogspot.com.

Tote

[Update]: I'm shocked, check this out: Dalvik: how Google routed around Sun's IP-based licensing restrictions on Java ME. It basically says that Android phones will NOT be JME-powered, but you can write JSE programs to them. With Android, Google has introduced their own VM, Dalvik, which eventually does not make use of Java bytecode, but their own Dalvik format. It's all to get rid of Sun being involved in licensing.
It's another question how good or bad will it be to the community. It means a new variant on the horizon, a VM incapable of running so-far-standard Java bytecode, thus your midlets will have to be re-compiled. I can see why Google is happy to have their own solution to this problem, but I can also see why developers would be unhappy due to that they'll have to take just another Java variant into consideration. Even if their pockets will be full with (Google's) money.

Symbian Platform Security - hacked?

Sat, 27 Oct 2007 03:48:18 +0200

Well, 3:00am has already passed and I'm tired and sleepy. One thing doesn't let me sleep, though. I've just stumbled upon these articles (Exploring S60 with AllFiles and Goodbye S60 Platform Security, Hello CAPABILITIES!) and I can't believe my eyes: Platform Security hacked?!

Briefly, the solution is as follows:

Take a firmware update package (currently supported only by Nokia for their S60 phones).
Edit a well-isolated part of it, where all those capabilities (i.e. rights) are listed that a user can grant to a 3^rd party application upon installation. Remove existing capabilities, add new ones, whatever.
Flash it.

Now you have such a phone (software) that allows you to give so powerful rights to any 3^rd party application that they can do basically anything on the device. For example, your program can access DRM-protected content (you've downloaded it once and share it with others), browse other applications' secret folders, etc. You just need to

Extract a signed SIS (Symbian Installation) file
Add rights to it (whatever gives them more power)
Re-pack & sign it again
And install it
Although the Software Installer will notice that the application was not properly signed (== acquires for more capabilities than it can normally have), the user will be in such a position that he can grant those extra rights.

Actually, this is the approach that the author of the aforementioned articles followed with regards to a very popular file browser application: he added AllFiles capability to the program so that he could explore the entire file system, which he hadn't been able to do until then.

Unfortunately, I can't prove or disprove whether this solution really works, since I haven't even updated my N95's firmware yet (shame on me!). However, this guy seems to know what he was talking about and I sort of a believe him.

In any case, if what he wrote happens to be true, then I have a few questions:

Why on earth did Symbian publish such a confidential information that is useful solely for phone manufacturers? You know, the documentation of Software Installation Policy is a very internal thing, not anyone's business. You can see that it's enough if one talented person stumbles upon that documentation and uses it.
Why is a firmware package in such a format that anyone can edit it? I mean, locally on their machine. Okay, with such a low-level tool that very few people are familiar with, but it's still possible. Wouldn't it have made more sense to encrypt and sign the package so that
- it cannot be decrypted by 3^rd parties (well, easily at least)
- it gets decrypted only on the target device right before flashing?

You know, I'm not a security expert, so I might easily be suggesting a stupid thing, but if there's any chance to do it that way, I think it's definitely worth the effort.

But even if it's not viable, then why does the firmware package update the whole system including the most critical parts? You could see that one can change the software installation policy this way. Why not make a process consisting of two steps:
- User can download and flash a firmware package that updates the (vast) majority of the system, but it doesn't allow him to touch the critical parts
- Those critical parts can either NOT be updated at all or only at service points.

I just really don't know what I've expected from Platform Security, but I have a feeling that in my secret dreams I thought it was unbreakable (I know, I'm naive). Again, I'm still looking for confirmation as to whether this solution really works, but I'm afraid that I already feel the bitter taste in my mouth. You know, a system that Symbian is proud of, operators love (some developers hate:) and even competitors acknowledge shall not be attackable and even if a security hole is discovered it shall be closed quickly without any major impacts. Nevertheless, I think this problem can be solved - hopefully very easily. But as to injecting the fixed version on to old phones, it will just take another firmware update. :)

Originally from mobile-thoughts.blogspot.com

Tote

Update: another fellow Forum Nokia Champion of mine, Antony Pranata, wrote an article about the very same topic. I think it completes my post in addition to confirming that the solution works. Worth reading.

Symbian Signed is not an anti-virus software

Wed, 23 May 2007 16:35:10 +0200

The Register reported today that a new spyware for mobile phones had appeared on the horizon. It's harmful for S60 phones, too, 3^rd Edition devices included. And what causes the stir in the water is that it's a Symbian Signed application.

There's a general misconception here, I'm afraid. I think the biggest problem most people don't understand that signing has not much to do with protection against malicious programs. These people don't understand that the process is about signing (surprisingly), i.e. certifying that the application comes from a well-known source. Additionally, in order for an application to be Symbian Signed it must undergo thorough testing being done by independent test houses. Since this application is Symbian Signed, it must have passed those tests.

The problem is that it's impossible to test everything an application can do. It's even possible to acquire for a capability (and get it!) just by saying that the application needs it for a different purpose. As this example shows: I can ask for e.g. NetworkServices capability and say that I need it for remote backup. And then make no mention on the fact that I will use it for other reasons, too. You know, it can be done since no-one checks the source code, it's not part of the approval process for Symbian Signed certification. And it will never be, I suppose, as no-one will ever share their best kept secret (i.e. the source code) with outsiders.

What Symbian (Signed) could do better, though, is that they shouldn't advertise these signed applications as "trusted". Because they aren't. What you can trust, though, is that the author of a Symbian Signed application is accountable. If he/she/they produce a software that proves to contain some malicious code, then they can be "caught" and counter-measures can be taken. What counter-measures? For example, the author's certificate can be revoked and added to a list, called Certificate Revocation List or CRL for short. This list can be always checked upon on-line. For example, when a user is just about to install a 3^rd party software whose author is not known (or at least not trusted), the Application Installer can do this cross-verification as part of the installation process. Pretty useful info, isn't it? Worth noting that most users are not aware of this and they have this feature disabled on their phones. Including me, but that's on purpose. :-

Original from mobile-thoughts.blogspot.com.

Just my two cents,

Tote

Design patterns in Symbian

Wed, 25 Apr 2007 12:34:31 +0200

This time my post will be a short one. :)

You know, I've been thinking about writing some posts on various design patterns applied in Symbian OS core components. My motivation is first that I enjoy reading/using code that has been carefully and nicely designed. Second, I wanted (and I still do) to encourage each developer to always think before starting to implement any solution for a given task/problem. It may sound as a cliche, but I found it a very common pattern that people (i.e. developers) had not considered how others will use their module (niceness of interface, readability of source code, etc.), how it fits into the big picture, how future-proof it is, etc. You know, ideally you shouldn't just code something, but rather do it nicely. That's the difficult part.

Even though I found this idea pretty challenging I've kept postponing my first article on this topic for various reasons. Now I'm late - at least with the first article. :) I've just noticed that rensijie from NewLC.com had posted two article about design patterns:

Good posts, Rensijie! I'm really looking forward to the next article on the topic. Or even I might add some. :)

Tote

Protecting APIs - a different approach

Mon, 19 Mar 2007 13:47:43 +0100

I have been wondering lately if the current is the most optimal way of protecting APIs in the S60 (or Symbian in general) C++ SDKs. It must not come as a surprise to any programmers that there are far more features in these SDKs than what we can use with the publicly available functions. But they are usually hidden.

How? Before answering this question, some technical details. In order to use a certain feature in C++ the following two conditions must be met:

The header file including the function to be called must be publicly available in the SDK,
The component, typically a DLL and its associated LIB file, must be publicly available in the SDK.

The first condition ensures that the code compiles, the second that the link process will succeed. The most common practice that Nokia applies when they want to protect an API (i.e. not let 3rd party use it) is that they remove the header file in question. I would call it as a lazy protection as it does not protect against reverse engineering. For example, as soon as the API becomes publicly available there is nothing that can prevent a developer from making use of that functionality. Okay, Nokia clearly forbids reverse engineering in their license agreement, but there might be people who think it in a different way.

The second type of protection, let's call it hard protection, is to remove both the header and the LIB (that we import in our MMP) from the SDK so that neither compilation nor linking succeeds. Naturally, the DLL must remain in the SDK as usually it already has clients that use the provided functionality. This workaround is also applied by Nokia and Symbian alike. Sometimes they make it so that the LIB file is missing only under emulator platform (i.e. WINSCW), but not from the target platform (e.g. ARMv5). This makes it more difficult for developers to test their software - but not impossible. Since if you cannot link against a DLL statically, then you can still do it dynamically. You just need to use RLibrary class for that purpose and call the exported methods based on their ordinals. Okay, it's by far not trivial and now we're knee-deep in sensitive and confidential data, but it IS possible.

Let's just stop here for a minute to think about why Nokia (probably) follows the above-described practice! If I wanted to protect some data and not let others use it, then I would do everything in order to impede people to make use of it. Not just invent some hackish solutions that can be relatively easily bypassed, but make it really hard for others to hack. But it might not be in Nokia's interest to do so. You know, they have partners to whom they open up some - non-published, but available - APIs every now and then. And if they can choose from simply giving access to a header file OR sharing e.g. a LIB file, too, then they naturally vote for the first option. In my opinion it's much easier to do due to e.g. traceability reasons.

We have now finally reached the point where I can talk about my idea on a (probably) better way to protect APIs. You know, there's a rule of thumb in Symbian C++ programming as of the introduction of Platform Security: if you have sensitive information (I mean, data) to protect, then you're suggested to write a server and let it guard that data. This solution also enables you to smoothly control who and how can access the protected resource. I believe that Nokia has already re-factored their code according to this pattern so that all sensitive data is taken care of by various servers. These servers may then check against capabilities, secure and/or vendor IDs. Ideally, there is no sensitive data by now that is not protected by a server.

And this is the point where I ask: why not make every API public so that everyone can use it? Following from all above, security must not be a concern here, since access to sensitive data is already under control. On the other hand, developers could greatly benefit from having access to DLLs that have been hidden from them so far. You know, I'm talking about a big bunch of features that have been written by some talented developers at Nokia, Symbian, etc. and hidden unnecessarily. Why not let others make use of those features if it doesn't harm?

There's an exception, though. If the piece of information to be protected is not data, but an algorithm, for example. If it's not of big importance what data we work on, but how. Garnished possibly with some IPR issues. If this is an issue and the executing code is in a DLL (i.e. not behind a server), then we can't expect too much from Platform Security. We can assign some strong capability to the DLL so that using it would not be trivial for anyone, but we'd have no option for fine-tuned secure/vendor ID check, for example. Perhaps even capability constraints would not be sufficient, either. I think that we (err, I mean Nokia, Symbian and others) could re-use the existing approach in this case, that is, not publishing header and/or LIB files in the public SDKs. You know, I don't think we should fully get rid of the current solution, but at least suggest to use it moderately.

Wishing to read your comments!

Original from mobile-thoughts.blogspot.com.

Tote

Here is my program, sign it yourself!

Thu, 01 Mar 2007 16:22:27 +0100

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:

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.

Following these steps enables anyone to sign any (Symbian) programs that can eventually be installed on a (Symbian) smartphone. On any programs, I meant those that do not require capabilities from the third group. Another constraint of a single DevCert is the inability to sign a program for more than one phone. That requires an ACS Publisher ID from VeriSign - costs 350 bucks, btw.

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