Audials Mobile - Free music from social radios

This is the first time I review a mobile software by the request of the authors. I've been contacted by the creators of Audials Mobile to check out their latest product, which I really enjoyed to do. Here goes my analysis.

Audials Mobile is a cell phone software that you can use to download free music in MP3 format from the newest generation of social radio stations. You can pick-up your choice from over 70,000 artists and 80 genres that are really compelling numbers for an average user like me. I also received my license key so that I could soon get rid of the limitation of the trial software (free to download up to 2 songs) and use the full-blown version.

Installation

The product can be downloaded from Audials' web page and installed without any problems. The user's attention is drawn politely to the used phone features so that no-one shall be surprised about any hidden functionality. The number of tweaks the user can do is kept at a minimum (which is good!): network connection, recording path and checks for software update are among the options.

Main features

The product offers the following core features:

• Search & download based on artist. The user can choose from an auto-complete list of artists, most populars are starred and listed at the beginning for more efficient searching. Having picked-up the artist, the available records are listed in the next view also indicating which social site the given track can be downloaded from.
• Search  & download based on genre. One can find the same records, but via a different route.
• Browse own song collection. Already downloaded songs are here + those that are currently being downloaded.

I used this application via a WiFi connection at home. Thus, songs were downloaded fast and although the downloads always took a bit more on mobile than in my desktop browser the difference was insignificant. The product uses the platform's built-in music player to play music, which is good for stability and user experience + it nicely integrates to Idle screen, too.

In addition, Audials Mobile has a plug-in framework, too. Anyone can extend the functionality of the software by adding one or more sources that users can download music from.

Bugs

There's not really too much I disliked about this software. There's only one thing that was very annoying and it had to do with Flash Video (.flv files). Yes, Audio Mobile offers the feature of grabbing music out of a video file, however, it - for some reason - fails to do it properly. I can download the music and the resulting file is in MP3 format, however, the only thing I can hear is some crappy sound.

Suggestions

My hints for improvement are as follows:

• I was missing the ability of going 'back' to the application during music playback: when I press 'Back' the playback always gets interrupted.
• Always-on network connection drains battery and is not necessary anyway - connect to network only when it's really required.
• Would be great if I could suspend/resume recording, i.e. downloading songs from the Net. Now you can either let it finish or stop the download entirely.
• Might be only my narrow-minded preference, but searching by genre/film I expected a list of movie titles, too, not only composers.
• Parallel download: even though it is possible to make a list of downloadable contents, the files are still downloaded sequentially one after the other. This might eventually result in that a long download holds back the download of other smaller files that would potentially finish sooner.

Conclusion

Audials Mobile is a great application that I really enjoyed to play with. It almost always delivered what I expected from it and did it with good performance. The application is easy to use, I could not discover any fancy or unnecessary features.

It's another question if/how long will it remain legal to download content this way. I mean I'm keen to download free MP3s, even albums with this app, however, if you look at the Swedish court decision in BitTorrent's case I'm a bit sceptic about the future of such a solution.

But as long as it's not explicitly forbidden by law I'm happy to use it. :)

Tote

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

MicroWeather for S60 goes Open Source

I usually don't write about specific mobile software, but this time it's a bit different. You know, it's one thing that one of my colleagues, Jouni Miettunen, became a Forum Nokia Champion last time thanks to his active participation in Python for S60 community. I'm really proud of him, he really deserved the honour.

But it seems that the spirit of open source software has "infected" another colleague of mine. Gabor Fetter, author of MicroPool (a bestseller in its category), MicroPinball and MicroWeather has now decided to make his last piece of software open source. I'm not going into praising MicroWeather, let it be enough that I use it daily. For more information, you can check out the official page at http://sourceforge.net/projects/microweathers60/. But you can do more than being in read-only mode: why not contribute to it? Any ideas, contribution are welcome!

I'm happy to see that we're that agile! ;-)

Tote

The diversity of Symbian development

When talking about mobile software development lots of people forget about the fact that it's not only the native programming language that can be used on a given platform. I've read a lot of comparisons between Symbian/C++, Win32/MFC/.NET of Windows Mobile, Objective-C on iPhone, Android, etc. lately discussing the advantages and disadvantages of these options, maturity and popularity of the underlying platforms, probability of writing successful programs, etc.

The problem with these comparisons (in which Symbian/C++ is typically at the end of the list with its peculiarities and steep learning curve) is that they discuss only half of the picture. The more advanced a mobile platform the more you can do on it - which applies to software development, too. I strongly believe that one of the strengths of software development on Symbian platform is that it's not bound to a single programming language, SDK, etc. A lot of you might not know that for Symbian-powered devices you can write software in

• Java - Mobile Java (JME) has been available since the early days,
• Flash Lite - Adobe's Flash has been added to S60 phones 1-2 years ago,
• Python - Python for S60 is an open source initiative enabling rapid application development,
• Ruby - Ruby for Symbian is one of the newest additions to S60,
• .NET - Red Five Labs's add-on to S60 platform is tempting Windows Mobile developers to use their skills on another platform,
• NS Basic - Powerful development environment and run-time framework for programs written in BASIC (link),
• HTML using other web technologies like CSS, Javascript - Apple's WebKit rendering engine is becoming the de facto standard for mobile browsers making them capable of showing full web pages (i.e. not only WAP or mobile web). This enables widgets development for a range of smartphones like S60-phones, iPhone, Android, etc.

You can see from the list above that Symbian development is much more than native application programming. On the contrary, I dare to claim that native programming is becoming less and less relevant over time. Of course, each option has its strengths and weaknesses (as well as native programming) the point is diversity, the possibility to choose. This (among others) makes Symbian OS's position stronger than its competitors': if you can develop for one mobile platform it's almost sure that you can use THAT knowledge for Symbian development, too. One exception for this might be Objective-C on iPhone, but I wouldn't be surprised if that became a reality on Symbian in the near future, too.

By the way, Simon Judge made a quick comparison between different platform development options - it's worth a read. As well as Andreas Constantinou's  post at Vision Mobile - a well-written article about mobile application runtimes for better understanding this world.

Any comments are welcome,

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

Static vs active application icons

I found an interesting blog about mobile interaction design at Sender 11 (whatever that name means). The point of the article is that in order to make application icons more attractive and provide a better user-experience, the icons should refresh their content from time to time and show "relevant" information to the user instead of being passive and showing only static information.

I like the idea. As one of the comments says with Nokia S60s you can now build interfaces wiht live icons like these in web-run-time and create a whole menu as a widget. Well, I don't know much about widgets, but I can imagine that it would work. For example, the whole Application Shell could make use of Web run-time and show application entry points (i.e. icons) as widgets with their always-changing behavior. Even more, the idea of Active Idle could be replaced by an active Application Shell, too. Some pixels could also be saved from precious screen real-estate (e.g. unread messages) by letting the application icons show information.

What could different applications show to the user? Here's a by far incomplete list out of my mind:

• Calendar: indication about events nearby
• Messaging: unread messages (sms, e-mail, etc.)
• Bluetooth connectivity: enabled vs disabled, transfer in progress
• WLAN connectivity: enabled vs disabled, number of hotspots nearby
• Maps: known (i.e. pre-recorded) locations nearby
• Clock: time
• Music Player: some information about tune being played (with scrolling, for example)
• RSS reader: new, unread items
• etc.
  

Could you add more?

Tote

Browser as an application platform

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

Nokia stirs water with mobile Linux

It seems it's time for another round to discuss about whether Nokia will abandon Symbian OS in favour of (mobile) Linux. All About Symbian has reported that "Nokia's Chief Financial Officer said Nokia is considering manufacturing Linux-based mobile phones". This information is confirmed by Unwired View as well, although in a slightly different tone: they say "Nokia sees increasing role of Linux in handsets". Finally, El Reg is saying that "Nokia says no plan to switch phones to Linux".

Who to believe? Having read the comments carefully, people seems to have the following opinions/see the following options:

• The biggest haters of Symbian say that it's natural that Linux will take over and this is exactly what they've always claimed.
• According to a bit more careful opinion, these two mobile operating systems will co-exist. There are couple of arguments for this scenario:
• Symbian/S60 is undoubtedly the leader in smartphone market
• There's room for both OSes: Symbian excels in high-performance mobile phones, whereas Linux could be successful in mid-range feature phones.
• Nokia has already heavily invested in the development of a mobile OS and is a nearly 50% shareholder of Symbian these days - why would they ruin all this?
• The development of a smartphone running on Linux still takes a LOT of time.
  
• Some more paranoid commenters say that "Linux is not really a threat for Symbian, but rather a motivation" to work & perform even better in today's extremely competing environment (i.e. mobile OSes and smartphone market). They believe that Nokia wants to make pressure on Symbian by announcing new Linux-powered devices from time to time.
  
• Finally, there are those who don't give a sh.t to what OS is running on a phone, they "just" want their Flash/Python/Java/etc. applications (whether they wrote them or not) to run smoothly in the future, too. Some of these people also mention that it's the same if the OS gets replaced, the UI (i.e. S60) is what's important - and if it remains, nothing will change actually.
  

Personally, I think that Nokia is still making experiments with Linux. Don't forget that they already have mobile Linux devices (Internet tablets running on Maemo platform), though, those are not mobile phones, just sort of PDAs. In today's fragmented mobile Linux market, no one mobile manufacturers dare to commit themselves to take Linux as the leading operating system for their products - it would simply be way too risky. It's been also said numerous times that there are lots of factors that manufacturers must consider when selecting a mobile OS and Linux is definitely NOT the ultimate solution today. Nokia might abandon Symbian in the future, however, it's not time for that. Yet.

Any thoughts?

Tote

Mobile software development - Functional testing

Simon Judge's blog made me think, again. He wrote about Mob4Hire, a company offering people for mobile application testing. Testers get paid via PayPal after bidding on projects (i.e. mobile applications/solutions) and developers get testers at a (hopefully) reasonable price. Finding testers might be especially useful if your geographic area is not the one you'd like your software to be tested in.

You know, lots of developers (dare to say: most?) do not recognize the importance of testing. This is the least pleasant part of development, I must admit, yet one of the most important. There are various kinds of testing including (but not limited to) unit-, regression, load, "smoke", etc. testing. The one, Mob4Hire provides solution to is called functional testing, where one can test the whole solution end-to-end. You know, mobile handsets are very-very fragmented in terms of platforms: applications can be developed in many programming languages like Java, Symbian C++, Windows Mobile Win32/C#, iPhone Obj-C, Linux C/C++, etc. And even when sticking to the same platform and programming environment, JME for example, the supported features vary very much from device to device. This, along with the complexity of what operators allow 3rd-party programs to do, makes it very difficult for a new application to be thoroughly tested.

Nokia already provides a free service for developers wishing to test their mobile applications written for Nokia S60 platform: it's called Nokia RDA (short for Remote Device Access). It is an Internet-based solution, where you can remote control a real mobile phone. You can request, for example, that SIM- and/or memory card be inserted in the test device as well as more than one phone be reserved for your test session to test peer-to-peer communications.

DeviceAnywhere provides a similar solution to Nokia RDA, however, it's not limited to a particular platform, nor to only 1-2 network operators. According to their web site, their service is "a revolutionary online service that provides access to hundreds of real handsets, on live worldwide networks, remotely over the Internet". Unfortunately, it is not free of charge.

Note that you cannot test everything with these solutions. For example, applications that use camera, GPS, accelerometer are basically out of question as well as ones using external accessories.

Another option for functional testing is making use of the services of Test Houses. Professional testers verify the quality of your software (compared to Mob4Hire, for example, see Simon's opinion) so that you can be sure you get the most what you paid for. Sometimes it's even required for your application to pass certain tests in order to get certified by some authorities. However, you may need to pay a lot for this service, see the list & pricing of Test Houses that Symbian Signed accepts, for example.

Finally, let's talk about community-driven testing. Once your application is in such a shape that it is ready for external people to play with it, you can ask them to go and use it extensively. You can offer free copies of the software to them, for example, or they may do it just for their own gratification - it's the same. This way of testing works extremely well in solutions based on client-server architecture with a mobile front-end and a server back-end. It's quite common in these scenarios that the mobile-end is just a light-weight client software that can be freely distributed, thus it doesn't cause any inconvenience if software distrubition is not strictly controlled. The point is that you may get lots of people playing with your software, because it's their passion. And passion drives people to do their job well, simply because they enjoy it, they love your program and they'd like it to be even better. I'm really a great supporter of this kind of testing. :)

Can you recommend any other way for performing functional mobile software testing? Please let me (us) know!

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

Android SDK is out - first impressions

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

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?

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 development - An alternative to embedding applications

I usually don't write articles about actual Symbian development issues, but this time I think I make an exception, if you don't mind. If you don't speak "Symbianish" or simply are not interested, then please skip the rest of my post. Nevertheless, I hope that the majority of you will just keep on.

I was in London on last Sunday for Nokia Developer Day. I was invited, because I'm a Forum Nokia Champion. There was an interesting presentation about Location Based Services and some technical details were revealed as to what Nokia would come out with as part of their upcoming SDK, namely S60 3rd Edition Feature Pack 2. It's not secret that they're going publish Map and Navigation API and an important feature of that API is the ability of launching Maps application stand-alone or embedded.

If you speak Symbianish, then you should know what launching an application in embedded mode means: your application loses focus and hands it over to the embedded application so that you have no control over it as long as that application owns the focus. It's worth noting, though, that albeit your application has lost focus it's still the main (hosting in other words) application that just makes use of services provided by another application. This can be seen by having a look at the list of currently running applications, where it's the name of your application that is in the list and not the one you have embedded.

The advantage of launching an application embedded in your application is that you don't have to bother with how it works internally, you just start it up and basically rely on that it works properly. On the other hand, this way of using other applications' services has disadvantages, too: one is that you have no influence on the menu structure of the embedded application.

Why is that important? Well, a real use case that we had to implement recently is that an application 1: shall be able to show some points-of-interest (POIs) on a map and 2:
shall have its own menu structure. We were happy to hear that Map and Navigation API would be available for public use, however, launching Maps application to satisfy our first requirement would mean that we would not be able to satisfy the second.

Then I started wondering how it could be done. Since I was deeply involved in the development of S60 Browser application some time ago, I know quite a lot about the application and the ecosystem around it. For example, I knew that a new approach had been introduced as part of the "Browser-offering" ~2 years ago that allows an application developer to use a (CCoeControl-based) control in her application. That control is called Browser Control (its API is BrowserControl API) and basically it is capable of showing & handling a web page just as the built-in Browser application does. So essentially your application can have its own menu structure, whilst also being able to show a web page. It gives you more flexibility and freedom if you use this API in favor of launching Browser in embedded mode, however, it's also more complex - sometimes unnecessarily.

Finally, we reached the point of my article: wouldn't it make more sense for applications that can be embedded (since not each application can be embedded) to offer such a (CCoe)control-based solution as well? For example, if the newly announced Maps and Navigation framework published such a service, then I shouldn't be worried about how to solve my problem. But this question is more general than to narrow it down to this special use case. I think, if some architects and/or lead designers from Nokia read my article, then I suggest them to think about it.

As a last thought, you might be wondering how I'm gonna work out this problem eventually. Well, there happened to be another presentation on that very day (i.e. Sunday) about Web Widget development on S60. I'm just thinking about writing an S60 widget that makes use of Google Maps API so that everyone is happy. :)

Any comments are welcome!

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

Cost monitoring

I've started wondering just recently why there is no support at all for cost monitoring on our phones? Okay, on S60 phones there are two applications where you can monitor
- how much time you've spent with speaking on the phone,
- how much data you've up/downloaded.

You've spotted that neither tells how much money you'll have to pay at the end of the month, right?

Obviously, one of the main reasons why there is no such an application on your phone is that there is no such application on the market. Neither built in your phone. Is it that simple, huh? Not really. Let's think about it how our application should work:
- it either keeps track of how much time you've spent with speaking (you called someone or someone called you while you're abroad) and also monitors how much data you've exchanged (up/download, SMS, MMS, etc.).
- or connects to your operator's site and download data from there.

Let's examine these two options in more depth:
- Keeping track of everything on client side: it makes sense to do it as most of the required features are already present. I guess, at least as I presume here that the APIs Logs and Connection Manager applications make use of are publicly available. What is missing, though, the information that could be used to figure out the actual costs. Okay, the tariff could be retrieved from various places and eventually could be typed in into our fictitious Cost Monitor application as well, but first users are usually pretty much lazy to do that, second it's not even trivial to find out which rate we should apply when. For example, how do you know what rate to apply when you're abroad? You can't expect that the user will do all these operations as it's pretty much laborious. Even I would not do that. :-\ Not to mention the fact that even though it's kept track of e.g. how much data you've downloaded, but I doubt that I could figure out which bearer (e.g. 3G, WLAN) I used each time. As usually we use public WLAN service free of charge or pay for it when we're there, I wouldn't like to see those figures in my calculations. And I'm sure that there are other issues as well that we would need to tackle to get a correct end result.

Briefly: it would be pretty much challenging, if not impossible, to write such an application and even if it was possible it would put a big burden on users' shoulders to manage the application.

- On the other hand, if Cost Monitor application was only a thin client that could connect to the operator's site, then we could put all the burden of implementing the calculation logic on operators' shoulders (can you imagine an operator with shoulders?:). Which, in fact, has already been implemented as operators always know it pretty well how much money they can pull out from your pocket. I guess, some of you have already found it out that there is a little problem with this approach. Not implementation-wise, but from strategic point of view. And well, the problem is not only little, but HUGE: operators will never make such a service (e.g. a Web Services API) available publicly. It's simply not in their interest as it might inspire their clients (i.e. us) to have better control over their costs.

Finally, I did not go into details as to the features of our Cost Monitor application. The obvious one would be to give visual representation of the user's costs. A non-obvious, but very useful, one would be to be notified upon reaching/approaching a pre-set limit. I'm sure that everyone can immediately see why this feature would be opposed by operators - whose help we would rely on, btw.

Looking forward to your comments!

Migrated from Forum Nokia Blogs.

Tote

Carbide.C++ - How to purchase it?

We had to purchase a few Carbide.C++ licenses for our company - the first ones, actually. Therefore, I visited Forum
Nokia/Tools/SDK section in order to find the right link that I can click on to purchase the licenses. The problem that there wasn't
any such link. :( I could have downloaded the IDE, but I had already done it by then. I've also opened up the IDE (with a temporary
license) to see if it contains any menu items that reveal anything with regards to ordering licenses. Even though there is a
submenu under Help/Carbide licenses, which contains some menu items for installing, viewing and even borrowing licenses, but
nothing mentioned about buying them. So, after failing to find out how to buy this software, I decided to search for it on the Web!

First, I searched for "order buy Carbide.C++", again, on Forum Nokia - without any success. Okay, there was a bunch of links that I
could have chosen from, but it was not intuitive to pick up the right one.

Then I decided to use the ultimate tool with the same seach query: Google. It was the second link that worked (the first was NewLC - Hi, Eric, how are you doing?:). Surprise, what kind of link was it? A link to a FN Discussion Board topic! Hey, isn't it in the
interest of Nokia to sell their product?! Then, imho, it shouldn't be a *discussion board topic* that advertises it the best (i.e.
being the most popular link) the way of purchasing Carbide.C++, no? Reaching the end of the discussion it finally turned out that
there was a link that anybody can use. Btw, the links mentioned above are as follows:
- Buying Carbide Dev
- Forum Nokia PRO - Company Registration

Another interesting thing is that you have to be a Forum Nokia PRO member for buying the product. That's good, but I was afraid of
the same thing than a few poster were, too: FN PRO registration costs thousands of euros. Per year. Well, I haven't yet completed
the process of purchasing our licenses, however, I'm just hoping that Mike Trujillo (from Forum Nokia) is right: "There is no charge for setting up the account".

Any comments?

Migrated from Forum Nokia Blogs.

Tote

Random thoughts on web browsing in S60

As I was involved in the development of S60 browser for years, I think I have a good overview on how a mobile browser works. Therefore I'm particularly interested in the "mobile browser war" taking place in S60. First of all, I'm surprised that there's a _war_ at all.

Of course, I'm talking about Opera and the new S60 (or OSS) Browser. You know, I'm a big fan of the latter (for reasons, see above) and I think it's a fantastic piece of software. I see that there are lots of other people around the world who share my opinion. Nevertheless, I still don't decline using other similar software, like Opera, just because it's not my favourite. Even more, I don't understand why supporters of either browser hate the other software and argue endlessly protecting their favourite. Hey, it's a free world, anybody can like anything and no need/place for hate.

It's just because both browsers are good. Extremely good in a not-so-easy environment! Whilst OSS Browser (any official name of this software?) is strong in showing web pages in their original layout, it's often found as a weakness, too, when the user has to scroll sometimes a lot in order to navigate to the relevant part she's interested in. Opera solves this problem by rendering the web page smartly (I mean, knowing that it's going to be displayed on a smartphone) so that it always fits on to the screen horizontally and even if the user has to scroll she has to do it only vertically. However, small screen rendering ™ has a drawback: the layout of the web page is changed and it's sometimes not what the author of the page wants and/or the users like. I think this is the main difference between these two fantastic browsers and it's really up to the users which one they prefer knowing the pros and cons. I personally bow to scrolling a bit more, but expect to see the page in its original layout, thus vote for the OSS browser.

But as to Opera Mini, Opera Software's free browser: I bow before them! To those who still don't know, Opera Software has written two different browsers for mobile phones: Opera and Opera Mini. So far I've been talking about the first, but I must tell some words about the latter, too. You know, I have visited Opera's boot on Smartphone Show and had a short chat with one the guys there. Besides that they share my opinion on the opposition of these two browsers, I heard some technical details about Opera Mini from them. First, it's not written in Symbian C++, but Java programming language. I was surprised to hear that as browsing requires as much resources (memory, CPU, I/O, network) as possible and the Java run-time environment is not famous of providing this as it would be desirable. But to my biggest surprise, it turned out that Opera Mini turns to an Opera server first asking it for downloading and rendering the web page in question on behalf of the mobile phone. I guess, the second step for Opera Mini is to download and show the "pre-digested" page information (not confirmed, though). That's fantastic! I mean, I'm amazed of how they could come out with such a brilliant idea. They can even apply compression techniques on the pre-digested data so that they reduce the amount of data to be transmitted to the minimum. Very cool! It's unnecessary to tell you that I've already downloaded and taken Opera Mini into use on my Nokia 6630. To my biggest pleasure - also unnecessary to say. What? - I hear. Yes, I'm using Opera Mini on my Nokia phone as the built-in browser is not good enough to my needs (OSS Browser has not been backported to older S60 versions).

Finally, as I've already written, I have attended Google's Q&A session on Tuesday. I was not surprised when they applied the common formula and said that "we're going to port/write as much software for Symbian in as short period as possible". I mean that's natural, it's certainly in their interest, too. Nevertheless, I started to think whether it's really worth for them to write software for S60 at all. Provided that the built-in browser is already close to perfection (just close, though), users of advanced S60 phones can enjoy almost(*) desktop browsing experience. Thus, no need to write anything for this platform! However, in the (*) section I wrote "almost" and I did it on purpose. You know, a mobile phone with such a small screen, never-enough memory, slow(er) CPU will never be able to beat desktop browsers, in my opinion.
Side-note: interestingly enough, I was not there when Nokia had announced their vision on the Smartphone Show that new mobile phones would slowly replace even desktop computers in the not-too-far future. Having mobile phones used for almost a decade, I would never have predicted it to happen. Tell me, when will you want to stare at a small display 1/20 (or less) in size of a desktop display? Or type in long documents with an ITU-T keypad?
So, it's Google's interest to make their services available on Symbian, too. Fortunately (and due to the fact that they're smart enough), their APIs enable anybody, not only them, to make this happen in a relativel short period. I can hardly wait until they announce their LBS-supported Froogle! :)

Any comments?

Migrated from Forum Nokia Blogs.

Tote

Update: I was wrong when I wrote that it had been Nokia announcing mobile phones replacing PC in the near future. Mentioned in Michael Mace's great article, it turns out that it was Symbian. And don't forget to read the comments, too: I also share Steve Litchfield's opinion that we don't have to over-react this announcement. :)