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

Smartphone OS market share in 2006

An article on smartphone OS market share by region (between 2004 and 2006) made me think. Since I'm an analytical mind and also interested in this topic I've automatically started to compare the two figures. And as the author of the aforementioned article has left the analysis part to us (or was he just too lazy?:), I've taken the effort to draw some conclusions from the figures.



So, let's take the regions one by one as shown on the figures!
- European, Middle-East and Africa (EMEA): Symbian still rules smartphone OS market here.
- In Japan almost the whole market was ruled by Symbian in 2004. This has significantly changed by 2006 since Linux has appeared on the horizon with its ~40%! I bet Symbian is not too happy about it, even if they have shipped lots of new phones in Japan recently.
- China: first, let's start with that Microsoft was present on the market in 2004. In contrast, their market share has dramatically shrunk almost to non-existent by 2006. Second, Linux is yet again an important factor that analysts and more importantly phone manufacturers must take into account in 2006. Its roughly 40% market share is very considerable. Third, the strange thing is that Symbian's market share has remained intact during these two years - it's still around 60%.
- North-America: one of the strangest markets - at least from our analysis' point of view! In 2004, Palm phones were dominating the smartphone market (~50%). Their market share, though, has dramatically shrunk to less than half of their previous share (now ~20%). The same pattern can be observed with regards to the popularity of Symbian OS - but with different numbers. In 2004, Symbian was the second smartphone OS vendor dominating 30% of the market - in contrast they're now the fourth with their ~10%! Who won then? Surprise-surprise: Microsoft! They were the third most popular OS vendor in 2004 (~10%) and now they're the #1 with ~30%! The last observation is that RIM has pretty much gained position - they're the second now.
- Finally, the rest of the world (ROW): well, similarly to EMEA market Symbian phones are in monopoly.

As a brief summary my findings are as follows. Symbian's hegemony is noticable all around the world. In most places more than half of the smartphone OS market is in their hand(held)s. :) With one exception, though: North-America. There are couple of interesting articles (on SymbianGuru, Darla Mack's and Tommi's blogs) as to why Symbian, most notably S60 phones are not present in North-America so it wasn't surprising for me to see the trend. It came as no surprise, either, that Microsoft is just there in North-America - what I found interesting, though, that basically this is the only market where they are taken into account at all. Finally, it's already a cliche that Linux phones are coming. LiMo, MontaVista's Mobilinux and TrollTech are just a few keywords everybody blessed with a little foresight might want to memorize. Japan and China are two countries where experiments are being made with mobile linux - and their success seems to be tangible. But let's not continue the debate on which mobile platform is the best and more importantly who will win in the long run. On the one hand, that's impossible to predict, on the other hand it's worth another article. :)

Anything to add?

Migrated from Forum Nokia Blogs.

Tote

Symbian vs iPhone

I've found a link (thanks, Peter, for sharing) to an interesting article that details why iPhone's (and Apple's) OSX is better than Symbian OS and how it's going to beat it. I have some thoughts about the author's arguments, let me share them.

In most regards, Symbian's reputation as a modern, robust, stable and advanced OS for smartphones is not well deserved. Sure, Symbian works, it has a very long feature list, and it's probably even the best smartphone OS available today. But it's mostly because the competition is pathetic than anything else.

I must disagree with this statement. You might argue that the OS is not modern as lots of "not-so-new" features, such as STL, is not included, but this does not necessarily mean that it's not modern at all. How can you claim that the system is not robust, stable or advanced? How do you measure it? I don't think Symbian OS is worse in general than its competitors. On the contrary, I believe it's very robust and stable. Just an evidence: it can run for days, weeks without having to reboot it. Just show me another (preferably open) mobile OS that can do the same. And you mentioned that it had a very long feature list and the OS was the best today. Based upon all of this why do you say that the OS has not deserved to be the #1 OS for mobile phones?

The Three Symbians
From one point of view, there are no ‘Symbian’ phones in the market, but rather three incompatible and diverging OSs: NTT DoCoMo's Symbian MOAP for Asia, Nokia’s Symbian S60, and Sony Ericsson’s Symbian UIQ.

You're right and wrong. You're right that there is a very thick layer (S60, UIQ and MOAP) on top of the core Symbian OS that makes the three platforms incompatible at some extent. But you're wrong, because you can minimize the difference between these variants with some clever effort. For example, most engine components can be written with a common codebase. Which is not true if you compare different OSes like Windows, Palm, etc.

On the other hand, there's no better solution, I'm afraid. Neither Java nor Linux brings us the *ultimate solution*. And I'm sure it's clear for everyone why I'm not talking about WinCE here. Unfortunately, mobile OS market seems to be heading to divergence rather than convergence.

Finally, variation for iPhone and OSX is not an issue here as there is nothing to variate yet.

To make it even worse from a third party developer's point of view, Nokia and Symbian made the new S60 version 3 binary incompatible to previous versions of S60. So none of your old Symbian apps will work on any new phones (i.e. if you actually bought any :-).

You shouldn't be so cynical. Actually lots of phones have already been sold that are based on S60 3rd Edition. It's just one thing that you do not know it.

Symbian Signed
So much for independently third-party software development on Symbian compared to the ‘closed’ model used on iPhone. In practice the difference is not that big. Apple will, of course, allow close partners to develop apps like they do with iPod Games today.

"In practice", the difference is HUGE imho. In case you have not noticed, Symbian phones are not closed as opposed to (the almost) closed iPhone. I presume that to be a close partner of Apple will be much more difficult than to have your application Symbian Signed. And in lots of cases your application doesn't even have to be Symbian Signed - it all depends on what you want to use on the phone. You know, most applications are able to run smoothly with the most basic capabilities (or even without them) that do not require your application to be signed. I suggest you to take some lessons on how Symbian Signed works before judging it.

And you know, this is the price phone manufacturers have to pay to operators in order for their device to be sold. I believe it's still better than not being chosen as a 'close partner'.

Symbian Design Issues
... entire section ...

While I agree with you with regards to most of the technical issues you listed, I have one question: what do you expect from Symbian to do? Do you expect them to withdraw all those design decisions that they've made during those days when it was reasonable to make those decisions? You know, it's easy to criticize, but very hard to offer alternatives ... Not to mention the fact that it would most probably introduce another bunch of source/binary breaks in most programs. Obiously, it would be especially painful these days since we have not yet recovered from the shock of Platform Security. Instead, Symbian should make a smooth transition from old design to new (if it's reasonable), which will naturally take some time.

Analysts Wrong on Symbian
Most media in Sweden (and elsewhere) have reported that the iPhone is nothing new at all. It's mainly a nice package with limited/bad hardware and nothing particularly new on the software side.

Isn't that true?

However, if you look at the speed and effort needed to make new applications on iPhone compared with other platforms it's two completely different worlds.

I'm a little bit confused: does it make sense to make new applications for iPhone? Most probably you won't be able to install them at all.

Existing Mobile Platforms vs OS X
With Symbian (as well as WinCE, Palm OS, and I suppose also the Linux phones because they probably have a very limited number of Linux frameworks installed because of memory restrictions etc) you have a big problem to deliver on the marketing hype and media expectations because of all limitations. This is one of the reasons all mobile services are failing to badly—it's simply to hard and complicated to deliver the market expectations with today's platforms.

At this point I must admit that I have never used OSX (consequently never programmed for it, either). But regardless of that still wondering how OSX and iPhone overrule the rest of the mobile platforms?

Five Years Ahead
... entire section ...

Well, here I again must admit that I have never used Objective-C in my life. Thus, I can't make my own decision about this issue based on my own experience. What I have heard, though, from people who had used it is that it was very uncomfortable for them to use that language. And they felt sort of a freedom when they had changed from ObjC to C++. There weas no-one who told me that ObjC was (a) better (experience) than C++. Knowing that, is it really the language, the foundation, based on which a new mobile OS will rise and overrule the others? I don't think so, but please disprove me.


Nevertheless, I can see that you're right at some point. There're lots of things to improve, only a few examples:
- Documentation ==> developers spend a lot of time with browsing technical documentation. And it's by far not perfece/complete. One of the main (true) complaints about learning Symbian is that it has a very long learning curve. Although I think we're heading to the right direction (good examples in the SDKs, good and thorough books, trainings, forums, etc.) it still takes too much time for a beginner to get used to Symbian. We definitely need more better tools, for example, Carbide.C++'s UI Designer is another good step to the right direction. And Symbian and its stakeholders must realize it and take actions against it (I mean, the long learning process) in order for developers still to be motivated to write programs for Symbian.

- Tools ==> it's a cliche that there's no ultimate tool for Symbian development. What is even more painful that there is no single *free* tool that anybody could use with great benefit. For example, when Nokia made a political decision about not to support MS Visual Studio in their SDKs they should have already come out with a better alternative instead of MS VS. Not with CodeWorrier, of course. I believe that instead of investing so much money and time in CW Nokia should have turned to open source community sooner and then we would have a better, more stable and useful tool (Carbide.C++) by now. In my opinion, if Symbian and "their companion" want to give a boost to Symbian development, then they should provide/use free tools that simply work. Okay, it's easy to say, but still...

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

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

S60 E-phones = ugly phones?

We had to purchase a couple of mobile phones recently. We want to use them for business purposes. For that reason, I had checked out what our Hungarian mobile operators offered and what's available in Nokia stores nearby. First, we specified the criterion that an ideal business phone must fulfill (not in order):
- WLAN,
- VPN,
- Easy to handle (keys, menus, etc.),
- Good battery life,
- Has memory card,
- Pre-installed apps.

As a mobile geek and big fan of S60 phones, I have made the drastical step of excluding non-S60 phones. Even more, I wanted to deal only with S60 3rd Edition phones. And that limited the list to E- and N-series phones.

As I wrote, we were originally thinking of business phones, that is, devices from the E-series. Well, I checked them out and found that although each supports most of the features we were looking for, there were NONE that fulfilled each criteria. Okay, that's a natural thing, but what was even more interesting (and sad, indeed) that we found basically ALL of them bad-looking, ugly. Which phones am I talking about? Let me list them along with our arguments:
- E50: conservative shape, relatively big display (at least compared to the keyboard size), but small keys and more importantly small fonts on the display. It was very difficult to find out what is on the display.
- E60: this phone has an even more conservative shape. A bit bigger than E50 and both the display and the size of the keys were okay. However, it was not fancy _in any way_ and the keys were so close to each other that it would have been easy to press more than one button at a time. I did not like it at all, at least.
- E61: very big. It's said that the display and the qwerty-style keyboard is big enough and it's easy to use it. However, the size of this phone is so big (even though it's thin), that it wouldn't have fit into my pocket or belt-bag. And I don't want to talk to a phone of half a brick size.
- E70: fold form phone, which I do not really like even though I used it during development. Perhaps that's the reason why I don't like it? :) Also note that, for some reason, it's not available here in Hungary. I was told that there were issues with the software stability, which I couldn't verify. I don't believe rumours, but there must be some reason for not being available in the country.

So, there were 4 E-series phones, which I (and one of my colleagues) disliked. And it was not neccessarily due to the features they do/don't support (2 of 4 did not have camera, for example), but to their shape, form! You know, I wouldn't like to use a phone that I don't like to hold in my hands, even if it supports each and every feature on Earth.

Who told Nokia phone designers that business users don't prefer better looking phones? I think the shape and layout of these phones is overly simple, so simple that it scares some possible users from them. Like us, who finally decided to purchase a few N73. It also has most of the features we wanted to use and you know what? We've changed our mind and re-prioritized the features that we thought it was essential. Now we have a good phone, which we can use for almost everything. Business purposes included.

Migrated from Forum Nokia Blogs.

Tote

Sony Ericsson to acquire UIQ Technology

Interestingly enough, this post is neither about Nokia nor any of their products as you would expect from a Forum Nokia blog post. It's about Sony Ericsson and their press release regarding acquiring UIQ Technology. Many popular mobile blogs (e.g. here, here and here) have already drawn our attention to this piece of great news, but it seems they have all missed to point out a very important consequence of this step.

Or it might be only me who's a little bit worried about Symbian's future? Not that much, but still. You know, I have read couple of articles about the future of mobile operating systems and was a bit worried about that lots of them predict the fall of Symbian in contrast with the rise of Linux. For example, the last report I've read on this topic was made by ARCchart and can be freely downloaded from here: http://www.arcchart.com/reports/mos.asp. They say that one of Symbian's biggest disadvantage is that Nokia owns too much shares in it, which might scare off other manufacturers, mobile companies from licensing it. In contrast with Linux (as they say), which is not suffering from a similar effect, thus might look more desirable for mobile companies. Oddly enough, even Nokia is making experiments in the area of producing mobile devices (Nokia 770, Nokia 330 - not confirmed that latter runs on Linux) with Linux operating system, which might be a base for rumours, too.

So the point in my opinion is that Sony Ericsson's commitment to UIQ might significantly strengthen the position of Symbian OS in the market of mobile operating systems. Not as if Symbian wasn't already in a strong position for the moment, but hopefully it will have positive effects in mid- and long-term plans, too.

Finally note that as I've already written I was in London on the Smartphone Show, where I picked up a booklet from Symbian's booth. The title of the booklet is "The Insight Series with David Wood" (check it out at http://www.symbian.com/symbianos/insight/index.html) and it's about the thoughts of Symbian's EVP for research about basically anything that has something to do with mobility and of course concerns Symbian. What has really captured my attention is a chapter about The hidden value of the mobile operating system. In this chapter, David Wood explains why he thinks that even though Linux is a real alternative on the market of mobile OSs, Symbian doesn't (yet) have to worry about it.

Comments are warmly welcome!

Migrated from Forum Nokia Blogs.

Cheers,

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

Smartphone Show, London, 2006

The Smartphone Show in London. I have already heard lots of things about it, but never been there thus far, so I was glad to have the chance to visit it. I've decided to be there for both days (Tuesday and Wednesday) so that I would have enough time to talk to everybody, try out/listen to everything. I mean, everybody and everything I'm interested in.

My feelings? Mixed. The good thing is that everybody was there who really counts in the Symbian world. Okay, I mean those that I'm aware of. :) Symbian, Nokia, Sony Ericsson, SysOpen Digia, ARM, Wiley (Symbian Press), BlackBerry, etc. Hey first: sorry for not mentioning everybody, but it's most probably thanks to my limited memory. Second: I have not mentioned Google on purpose. They have not yet contributed to Symbian so significantly that I should mention them, imho. Nevertheless, their cookies (I mean, the real ones, not the digital) were good. :)

Why are my feelings mixed then? Well, even though I'm from Hungary, a small country, I've already seen a few big shows, let them be trade or technical ones. This one was not one of them, at least not in my opinion. To my disappointment, I could wander through the area of the show in the first half an hour and pick up those boots that I decided to pay my attention to. Then I spent the first day with visiting those boots, talking to people, listening to others talking, etc. I've even attended a few seminars on Tuesday. Briefly: it was smaller than I had originally expected.

Okay then, what made me stay there for Wednesday? Well, besides the fact that I could have cancelled my hotel reservation and changed my flight schedule only for a horribly high amount of money, it was definetely the party that followed the first "working day". I mean, that was GREAT! Very good music (does anyone know the name of the band?), drink, food. The place had been a secret until we got transported there: it was called "The Container City", not too far away from ExCel London, where the show took place. At the end of the party, we got even taken near to the city center so that didn't have to think too much of how to go and where.

To my biggest surprise, there were even more people visiting the show on Wednesday. At least it seemed to me so. As I had already seen what I wanted to by that time, I decided to listen to keynote presentations in the morning and attend some technical seminars in the early afternoon (my plane left in the evening, so I had to leave early). It turned out to be a good plan and I could do what I had originally scheduled. For example, I was wondering what the heck BlackBerry could be looking for on the show, but after listening to their keynote speech (the lady was _very_ convincing) I could hardly stand to go to their boot and ask for a quote for my company. I was also interested in David Wood's speech, his vision of the next few years in mobile space was very impressive.

All in all, I'm so glad that I have visited the Smartphone Show. I've enjoyed it very much and I think I've gained much experience of it, too. Nevertheless, I might opt for a one-day trip in the future - that will be enough. Including the party, of course. :)

Migrated from Forum Nokia Blogs.

Tote

Forum Nokia Champion Day, London, 2006

As a Forum Nokia Champion, I was invited to attend the aforementioned event on 16 October in London. In addition, Symbian arranged their annual Smartphone Show so that it took place on the upcoming days, Tuesday and Wednesday so that I could stay in London for a few more days. This posting is about the first day, Monday, but I'm going to write another one with my remarks about the show.

Here you are. I'm so grateful that I could attend this event and meet other fellow champions. We were accomodated in Hotel Le Meridien (wow!) for two nights, Sunday and Monday. After having an excellent breakfast, we walked across Regent Street to Cafe Royal, a venue perfectly fitted to host meetings and events - like ours. First, we all had a brief introduction of ourselves and I can tell you that it was very nice to meet all of you and associate the faces, voices with most of the names I've already read here and there. There came some technical seminars, where we were presented some insights about the new Carbide.C++ Dev & Pro versions, Python for S60, got some hints on documentation and S60 3rd Edition update, etc. By the way, we had a traditional English pub lunch at noon - it was excellent not only because the food was good, but we could get to know each other, have a chat with anybody.

After the seminars, we were invited to build the team (i.e. teambuilding :). It turned out that we were spies (I knew that Tom Cruise was kicked out from Mission Impossible, but was surprised to see that we're gonna replace him:) and we had to accomplish a spy mission. We were split into 5 teams, each had to do the same tasks: explore places nearby, answer tricky questions, scavenge items from various places in a fixed amount of time. Khhm, we were so much filled with empathy that we thought it would be nice to be the fifth among the five teams and let others feel a little bit better. None seemed to be effusive in their gratitude. :) By the way, the winner team got Nokia 9500 Communicators, one per each member.

Finally, the last event on Monday was a coctail party held in Albannach, UK's second biggest whisky bar (as I learned). It was not only us, FN Champions, who were invited, but PRO members were also there. It was good to see so many people filled with enthusiasm about mobility - unfortunately, the place was so small that it was basically overcrowded. Nevertheless, the food was excellent as well as the drinks so we (at least I) enjoyed the whole party.

In fact, the whole day! So I'd like to thank Sanna, Elina and the rest of the team who arranged the whole thing so that I was (and still am) both proud and grateful that I'm a champ. Besides that I'd like to encourage other fellows, you, mobile geeks, do your best in the mobile community and become a FN Champion. It's worth, believe me!

Migrated from Forum Nokia Blogs.

Tote

Ps.: one of my colleagues has also flew to London to attend the Smartphone Show. As he is not a champion, he couldn't attend those events that I could, but what he could do, however, was that he went to the pub event arranged by Symbian on Monday evening. There was a draw during the event and he won an N93. Simply just because he was there. I'm so jealous. Everyone could win a mobile phone, except me? :)

New communications protocol from NRC

Nokia Research Center has just published a new communications protocol for "battery-seriously-constrained" devices, like watches, wireless sensors, etc. According to their research, Bluetooth requires way too much power that it hasn't been worth integrating it into these devices. Now I really wonder how this newborn will co-exist with already accepted & widely used standards.

And the link, where I found this info.

Migrated from Forum Nokia Blogs.

Tote

New naming scheme for Nokia phones

At last! To be honest, I've been lost in the jungle of code numbers Nokia uses for their phones lately. Although I'm focusing only on Symbian, more precisely S60 phones, I was still confused which model knows what, what their basic characteristics are, etc. I've even misused these numbers for S40 and S60 phones (cardinal sin! :) and then was wondering why I was looked stupid by people.

Actually, I also wanted to write a posting about this topic, but now I'm late. Nevertheless, I'm so glad that people at Nokia have also noticed this problem and more importantly decided to solve it!

Good decision, can hardly wait for the new names!

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

Let's kick it off

Hi there,

This is Gabor Torok's (aka 'Tote') weblog about mobility in general. I'm a technical guy having spent more than 7 years in this rapidly evolving area. You can find more information about my background in the About me box.

Having been selected for Forum Nokia Champion in 2006, re-selected in 2007, I had the chance to share my thoughts with others about technical and non-technical issues alike on a popular blogging forum, Forum Nokia Blogs. It was a great opportunity to exchange ideas with smart guys out there. However, my Forum Nokia Champion membership will end sooner or later and as I want to continue blogging I decided to start a new blog that I have some sort of control over - this one.

So this is where we are for the moment. I will migrate my old posts from FN Blogs and will be doing this double-work as long as I'm a Champ. After that, I'm planning to write only here.

Hope that you will enjoy reading my blog!

Cheers,

Tote