Mobile worm, Yxes.A - an analysis

F-Secure and FortiGruard both reported that a new worm, Yxes.A, is spreading on Nokia smartphones based on S60 3rd Edition platform (and probably higher, too). According to FortiGuard:

• "It gathers phone numbers from the infected device's file system, and repeatedly attempts to send SMS messages to those. The messages feature a malicious Web address (URL); upon "clicking" on the address in the received message, the recipients will download a copy of the worm (provided their phones/subscriptions allow for internet browsing)." That is, it's a Trojan.
  
• Beyond propagating to as many users as possible via the strategy mentioned above, the worm's aim is to gather intelligence on the infected victim (such as serial number of the phone, subscription number) and post it to a remote server likely controlled by cyber criminals.
  
• It's also noted that  worm can mutate easily: "As far as our analysis goes, the worm currently does not take commands from the remote servers it contacts. However, since the copies hosted on the malicious servers are controlled by the cyber criminals, they may update them whenever they want, thereby effectively mutating the worm, adding or removing functionality." It's not that simple, though. It's not like download a new EXE from the Net and it will just work. No new EXE or DLL (a plug-in, for example) can be installed without the assistance of Application Installer, which will eventually require user's attention and approval. Some files that don't have to be installed can be downloaded, though, containing instructions for the worm to execute, however, it's becoming a science fiction if we think that any malware author will put THAT much effort in developing such a system. I'm highly sceptical on that it would be a real threat and refuse to be threatened by that.
• It's also reported that "On launch, the worm executes as the process 'EConServer.exe', which is likely meant to camouflage alongside the existing legitimate system process 'EComServer.exe'". This simply doesn't mean anything: if a process name is only similar to another (system) process name then it doesn't imply anything. And anyway, EComServer.exe is never launched by hand (but by the system upon device start), consequently it's not a valid scenario that the malicious EXE gets launched instead.
• It's a very agressive application, since it "will also automatically run every time the device is rebooted / power cycled. Further, it bears a destructive nature and will kill certain processes such as the application manager (AppMgr)." If that's true then the program must hold very strong capabilities that cannot be granted by a self-signed certificate.

You can see from the list above that the worm can be malicious, indeed. Following from the last point we can conclude even more:

• The program couldn't be self-signed, since the program requires such strong capabilities that the Application Installer will never grant to a self-signed installable.
• It couldn't be signed via Open Signed Offline*, either, since that would limit the spread only to max 1000 devices with given IMEI numbers.
• It couldn't be Certified Signed*, either, since that requires a thorough test done by an official Test House. Even if they hadn't done a thorough test, such a behavior must have turned out very soon.
• All that means that it was Express Signed*. You know, one characteristic of Express Signed is that they do occasional testing, which means that there might be some malicious apps that can go through this filter.

What counter-measures can be taken? First, the certificate of the malware author must be revoked. That means that whenever they will try to publish another application, whatever it will do it will not be allowed to be distributed, but will be filtered out automatically. This doesn't comfort any victims of this virus, though (hmm, are there any?).

Second, it would be just great if OCSP-checking was enabled on every phone by default. OCSP is a protocol that allows the Installer to check it in a database that a certificate is revoked or not. Although it is available on each S60 phones, it is disabled by default. But I go even further: it's not only the Installer that should use it, but other components of the system, too. In fact, the system itself should perform such a cross-check at regular intervals if any of the installed applications have become undesirable for the user (i.e. the certificate used to sign that application has got revoked) in the mean time. I'm unsure as to why this mechanism can be disabled at all, probably because it requires a network connection and data exchange with a remote server. But I think this should be something that operators shouldn't charge for - isn't it in their best interest, too, that the devices using their network wouldn't get infected?

* For more information on various signing schemes, please visit Symbian Signed.

Any thoughts are welcome,

Tote

Malware on Android: It has begun

No, it's not going to be yet-another I told you so post. Though I did. :) You might have heard of the spreading of MemoryUp virus on Android-powered devices. There are numerous articles mentioning it (like this one ;), let me cite one of them from phoneArena:

"As strange as it may seem, a lot of users have complained of the MemorUp app..."

What is so strange in this? Android's security model is an open invitation to malware authors: anyone can write an application and distribute it freely on Android Market. The secret is that although every application must be signed, it's not mandatory that the certificate used for signing be certified by a Certificate Authority. In other words, you can self-sign your own application. Accountability is lost.

"We’re more worried about the fact that such a harmful application has found its way to Android Market and has stayed unnoticed until now."

That's exactly how Android Market works. I'm surprised that you're surprised. Anyone can write and freely distribute their own programs that may even be a malware. Signing ought to prevent from mass virus distribution - as long as signing certificates are certified by CAs (authors can be traced back and prevented from continuing malicious activity). Which is sadly not the case, see above.

"If it has managed to creep inside, wouldn’t there be a chance for others?"

It's not a question, I'm sure there will be more. Even though self-signed applications are limited as to what they're allowed to do, MemoryUp has showed us that this restriction is not enough.

The question is rather what could be done against this phenomenon? One option is that Google leaves it untouched: it will turn out very quickly if a program is malware or not (well, unless if it's a timed bomb). Another alternative is be stricter on what a self-signed app can do and allow only properly (i.e. CA) signed programs to act freely (after user's confirmation, of course). The strictest option would, of course, be if self-signing was not allowed at all. I'm sure you've noticed that the last two options mean that developers would need to pay for (CA) signing. Which is against the principles of Android development.

Looking forward to Google's reaction,

Tote

Random thoughts on recent news

Hi,

So many things have happened in mobile world recently that I can hardly cope with their sheer volume. This time I would just add my quick thoughts to some of them, one-line comments that I would like you to comment, too.

Let's start with VirusGuard Coming to Android Market in 2009: yeah, a clear disadvantage of full openness coupled with user-controlled security policy is that such a software is necessary. Remember that famous anti-virus software vendors also tried to gain a foothold on mobile phones based on Symbian OS, too? Unfortunately, Symbian's security mechanism works so well that there is no real demand for such software on these phones. Note: since Android Market is  only for free software (yet), this commercial software can be purchased from Handango.

I've read two interesting reviews on the user experience of T-Mobile G1 and Nokia S60. In fact, these two were compared to each other. It was funny to read how two people with different needs could come up with contradictory results. Whilst Matthew from Darla Mack's blog found Contacts, Syncing, E-mail support and a "lot of other things" being superior on G1 he confirmed it too that there are many things that need improvement in upcoming Android-powered devices as well. Chris Walters from TheNokiaBlog, on the other hand, found just the opposite: he thought he could at last forget about S60 and can enjoy all the things Android can provide, but realized that S60 is still superior to Android in many aspects: build quality of device, camera, not being locked to any carriers, etc. There are two immediate conclusions I drew from these (and other) reviews:

• Don't believe to any reviews, but make your own decision based on your own needs. For example, how would you decide based on these two reviews cited above when they both claimed that G1/S60 was superior to the other platform in Syncing?
• Nokia had been the king of user experience on mobile phones until iPhone and G1 appeared on the horizon. The structure of menus, applications, settings, etc. were logical, consistent and compatible across a wide range of devices. It was engineering-driven so it couldn't be in any other way. Following an engineering-driven approach, however, is not enough anymore. In my opinion these companies could learn a lot from each other. It's not a sin (well, generally) to copy one's idea if that has proven whereas ours has not stood the test of time. The point is better user experience, which is better both for users and vendors.

The third thing I found worth being mentioned is Nokia Friend View. This beta software is similar to IYOUIT (for example) that I've already given a try to and liked much. I can see this kind of software being useful from another point of view (than what they advertise), too: I'm a family man and although my kids are small I know that the time will come quickly when I will let them hang around but still would like to know where they are. The wide-spread of such a software (and hardware!) will hopefully keep me relaxed in those times.

Finally, Nokia has made a very important announcement in the past week: they introduced Nokia Life Tools along with 7 new models under €100 price range. According to the press release, Nokia Life Tools is a range of innovative agriculture information and education services designed especially for rural and small town communities in emerging markets. Knowing that the opportunity at the bottom of the pyramid is huge, and handset manufacturers and network providers alike are working hard to fill it with phones (this time cited from PCWorld) it's no wonder why these new models can be purchased at never-seen prices. Nokia has finally entered the war fought for phone owners with thin wallets with the introduction of Ultra Cheap Phones.

Tote

Another hack for Symbian Platform Security

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

Symbian Platform Security - hacked?

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. :)

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

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. :-\

Just my two cents,

Tote

Protecting APIs - a different approach

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!

Tote

Here is my program, sign it yourself!

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. :)

Migrated from Forum Nokia Blogs.

Tote

Do you think that PlatSec signing process is a nightmare?

Well, then let me share the following article with you about midlet signing. It describes how painful a Java midlet signing process can be. In addition to that, it also contains some basic information about how signing works (e.g. chain of certificates) and what it costs. Shocking experience. :-\

From signing and capabilities/permissions point of view I would say they're the same. You know, it's one thing that you've got to be familiar with a security system that sometimes simply doesn't work (unless you invest much-much money in it), the bigger problem that most developers suffer from is that you even have to pay for it. As security is our common concern wouldn't it make sense to introduce such a system in which nobody pays to nobody? You know, not only is the concern common, but the benefit would also be mutual. I know I'm so naive. :-\

Migrated from Forum Nokia Blogs.

Tote

Let's use DRM!

I've seen *lots* of questions on various S60 forums, where developers were asking for advices on how to implement THE ideal security technique that protects their application from cracking, stealing and in general: using without the permission of the author.
I'm not sure if they're aware of that they're not alone with their problem and in fact Nokia (and Symbian, of course) has already made a framework for them that's sitting on *every* S60 phone and just waiting for being used.

This framework is called DRM and it's a short for Digital Rights Management. You might have heard about it lately, as there's a quite hot topic, namely the "war" between Apple and France. So, without dwelving into techniqual details regarding the capabilities of aforementioned framework, let me point out its two most important features:
- forward-lock: it does NOT allow to send a DRM-protected content from one phone to another (i.e. forward).
- preventing the user from consuming the content (listening to music, watching video, playing a game, etc.) more than she's paid for. It's possible to set up this limit specifying how many times or for how long can the content be used without having to pay again.
Note that there is an exception for forward-lock, called Super Distribution, where the content *can* be forwarded, but under complete control.

So, what does a developer have to do if she wants to DRM-protect her application? There are two things she has to tackle:
- first, she must make the application (i.e. the SIS file) DRM-protected: the freely downloadable NMIT makes that possible, for example.
- second, publish the protected content so that others can download it. An important point here is that ideally publishing happens so that asking for new permission (as user rights usually expire from time to time) by users is convenient.

And this is the point where I'm uncertain as to whether there is enough support for developers. You know, they have to
- either set up their own delivery server that takes care of content as well as rights management. I'm sure you all see that one can hardly find free tools for it.
- or make use of the DRM support service their mobile content provider provides them. If it does provide. For example, I've already seen that Handango (one of the most popular S60 content providers) provides similar support for its *partners*. I call it "DRM hosting", hope that I use this term right, and am really wondering how much it costs for average developers. I mean, I'm sure that some developers/companies can afford it, but what about "the masses"?

I'm eager to hear your opinion!

Migrated from Forum Nokia Blogs.

Tote