S60 Open to new features

Why companies? Give it to individuals, after verifying their indentity!

I agree with Alexander. You should either grant the phone owner the right to disable the Symbian Signed verification or at least offer individuals the possibility to use Symbian Signed (by adding cert.-authorities that accept individuals or non-registered companies.)

I was so shocked to come back to S60 from my Treo 650 (I tried a 6680 for a month or so before then) only to find this nightmare we call Symbian Signed.

Personally, I find it infuriating that I can't do what I want with a device that I own. Perhaps it's a revenue stream. Perhaps it's truly a well intended security feature. Anyway you cut it, it's NOT what the number 3 player in the smart phone market should be doing!!! (number 3 in regards to amount of 3rd party apps)

Kill it I say! Or at least allow advanced users to disable it.

Posted by: Jay | October 12, 2006 03:20 PM

Perhaps not killed, but changed to be similar to the J2ME signing model.

The funny thing is that this program had been in use for a while even before Platform Security came into play. It was just used only a few people/companies, I guess. Now that everybody "has to" use it, it's a scandal!

I have read couple of posts regarding this topic and heard it from "more" experienced people that most of the applications didn't need to be signed at all as they were working, simply, _normally_. I mean, not so "exceptionally" that they would require extra capabilities that force them to sign their applications. We all know that SIS files don't _have to be_ signed as long as they're using certain capabilies that can be granted by the user upon installation. I'm under the impression that _most_ applications fall into this category. And there is only a small portion of existing/new apps that make use of such restricted APIs/features that impose that they have to hold stronger capabilities. In my interpretation it's just the price we have to pay for running our applications in a more secure environment.

I agree, though, that prices could be lower. And rules could be less strict, taking new and unexperienced developers into account.

Finally, don't forget about the deal between Symbian and CellMania (https://www.symbiansigned.com/app/page/overview/freeware) that enables developers of freeware apps to sign their product free of charge! Ok, it's freeware, but at least we can see some signs that Symbian is trying to do something to make development (and more importantly deployment) more convenient.

Cheers,

Tote

To Tote, the symbian apoligist :),

the capabilities that are restricted are actually one the most interesting and unique ones: access to the phone's GPS location unit and access to microphone and speaker for example. You could do amazing things with them. Open capabilities are limited to more or less bluetooth and GPRS connectivity, which is something a myriad other gadgets can do.

In so far as S60 Python development is concerned, the 3rd edition signing process has effectively poisoned the well.

None of the scripts I've written for 2nd edition phones work due to permissions issues despite the fact that the (3rd edition) interpreter itself is signed with access to all of the APIs in question. Even then, my understanding is that access to the calendar API has been removed from the spec altogether.

I may get around to requesting a certificate and going through the process of having each app signed but I might as well also start writing everything in C++ or Java. The "killer app" in the Python application is the ability to brainstorm and prototype tools that can actually do something *with* the phone : the calendar, the address book, the camera, cell tower information, etc.

I haven't really tested Raccoon for the 3rd edition yet but I can only assume that the same (signing) restrictions apply to mod_python scripts. I love the fact that I can run a web browser locally on my phone (BTW, browser-app people : requests to http://127.0.0.1 do not need to connect to the Internets). The ability to use the browser's rendering engine to handle all the boring UI stuff combined with JavaScript and Python to manage and manipulate the information on my phone is in a word : Awesome!

Sadly, I don't think it's a realistic prospect on 3rd edition phones given the burdensome nature of the signing process. There are some people for whom the cost of signing their scripts won't be an issue. For some people it will be. For most people, it will just be a barrier too high for people to want to care.

Perhaps a signed certificate for SIS files is prudent (I remain unconvinced) but to extend the same policy to scripts whose interpreter already has a complete permissions set shuts down an avenue of possibilities that was only just beginning to open up.

In my interpretation it's just the price we have to pay for running our applications in a more secure environment.

In my interpretation, signing seems more like a way to control 3rd party applications, so no operator-revenue damaging apps are released, for example.

My proposal would be moving more extended capabilities to basic capabilities so that third party developers can still use self-signed certificate. As Sampo said in his blog, there are some capabilities that doesn't make sense to be in extended set.
About freeware, I have been using a service from CellManis, but don't really satisfied. It takes too long to sign a freeware application (2-3 weeks). They should do something to make it shorter (

Symbian signed is slowing down Symbian development when it should be accelerating. Smartphones software sales are not shining at the moment and this only further delays (besides data charges outside the U.S.) any significant revenues from happening. Thanks Nokia!

Obviously the litany of cons against Symbian Signing can be better talked about by folks like Antony; instead let me present it from the end user perspective. You know, those of us buying the phones and getting all our coworkers and friends to buy them.

Where are some of my favourite apps, which are mainly freeware? By those I mean: CellTrack, AFTrack, FExplorer, and TaskSpy (amongst others). I don't know many users who don't use/like these on their older S60v2 devices - they are apps to have in your arsenal of phone software for sure.

I've emailed some of the authors, others have statements on their websites, and so forth. The answer is universal: it's the new 'Security Platform' and Symbian Signing that has effectively knocked them out of the game.

And me, the lowly user? All I want is to vew my stinkin cell IDs. Or geotag screenshots with a little python code. Or kill an errant process gone wild on my handset. But no, I'm left bearing the brunt of this new security setup.

Go visit some cell forums - the dislike of Symbian Signing is universal around the world, we all got screwed.

> Go visit some cell forums - the dislike of Symbian Signing is universal around the world

I can believe that, if you talk about cell forums. After all, they are full of people like you and me: developers and technology enthusiasts. But if you ran an universal gallup of all mobile users, you might hear different opinions. Most people wouldn't install add-on apps anyway, especially if there would be a (perceived) risk of viruses causing $1000 bills...

Don't get me wrong, I think this is a very important question - but a tricky one with no easy answers. But that's why I asked your thoughts :)

Alexander, I know what capabilities are for and to be honest it had taken some time for me to fully understand how they were supposed to work. I agree with you that they are different to what most people have got used to on Windows, Linux, etc. But what about Java (Java ME)? They are a bit like JME permissions, where you have to specify which permission your application will be using and those permissions are only granted if your app is properly signed! Is what Symbian has found out _that_ different to what has already been used for a while in J2ME? Don't think so ... don't know, though, how it has been worked out for developers to get their applications certified in Java world: how much does it cost, how long does it take to get it?

To David M: exactly and that's what I've already noted on one of the other blogs Tommi has cited. Platform Security was born thanks to the high demand of operators, screaming for more secure apps, environment and more importantly control over the whole.

Finally, I share Antony's opinion as well about that Symbian could "re-rank" currently stronger capabilities so that users could grant them upon installation (is that what you said, Antony, btw?:) besides those 5 (or 6?) that she can for the moment. OR basically the user could grant _any_ capabilities to a program, but the permissions for the most critical capabilities would be only one-shot: the user would be asked for confirmation each time, when your app is about to use the capability. It wouldn't be too convenient for the user, I admit, but it would be secure at least and your app could still work.

Nice discussion. I'm also very critical about the 3rd edition signing stuff.
The problem I see: You have to pay too much money to test if you can make money with your new cool application. No poor innovative student will develop for symbian now. Why not test it for windows first.
Therefore symbian will loose the leading edge.
It was always possible to get a cheap development environment for the microsoft world. They know why. ;)

>> But if you ran an universal gallup of all mobile users, you might hear different opinions. Most people wouldn't install add-on apps anyway,

A very good point - if it were to actually work out that way. :) I live in San Francisco - probably 1.1 million people here on a working day (random guess), and people here *love* cellphones (and iPods, and other tech gadgets). Being a cell nerd who rides public transit a lot and walks around town, I watch and see what people use as sort of a hobby.

What (PDA-esque) devices do I see? Treos. Blackberrys. Some iPaq style thingies. What do I not see? Nokia S60 devices. SE UIQ devices. The main factor is out here in USA-land, Nokia S60s and SE UIQ devices are not sold over-the-counter (a lot) like they are in Europe and Asia, you have to go looking for them on purpose.

So who buys S60 devices? Those of us who hit them up on eBay (or other online merchants) or if you're lucky a local import store in Chinatown (sic). We're already aware of what we're buying; I don't think there are "unaware" S60 users in this part of the world, they're intentionally buying the device. Or they heard about it from someone like you or I (I show off my E50 to everyone I can :) ) and want to try one themselves.

These same users are the ones who are going to install third party apps, are kind of geeky, and aren't afraid of "some virus" in an unsigned app. They're the ones on the forums. :)

My $0.02 USD.

PS: in my office of 40-ish I own the only S60 device(s). There are maybe 10-12 Treos, one or two Blackberry things, and the rest are normal handsets of all variety. I have not seen other S60 devices in public use around town in a long time.

@Tote: You're absolutely right. That's what I mean, "reranking" Symbian capabilities.

How many Symbian developers out there in the wild; 1K, 10K, 100K, 500K?

How many users who don't know and don't care about 3rd party apps? A few 10s of millions?

How much money power do opeators have? Quite a few billions?

The writing's on the wall; SS is here to stay and if a few 100s of developers give up the platform who gives a damn? Not Symbian, not any manufacturer and certainly not an operator.

I don't even see it changing in the next 5 years.

Boom

To Tote re: freeware apps: basically a good idea, but when you look at the market situation for commercial Symbian development, this offer is almost cynical. A commercial developer has to pay for Symbian Signed, but the revenues aren't so shiny for this platform. At the same time a freeware developer can publish a competing product for free. That's fine for the customer of course, but bad for the commercial developer base in the long run.

To Tommi re: $1000 bills: a self-signed ("unsigned") application can still send SMS messages without a problem, so Symbian Signed doesn't really help here. You could compare this with the PC situation a couple of years ago where people were using dial-up connections and "dialers" (malware/viruses) were switching to high-priced ISPs. A solution would have been to ask Microsoft to introduce "Microsoft Signed" ... well ;-)

There are so many inconsistencies within Symbian Signed, and I am not convinced the main reason was a more secure phone.

(For example, an unsigned app cannot open a URL in the S60 webbrowser once the browser is running. However, the same app can just kill the browser process and then start the browser with any URL. Doesn't make a lot of sense in terms of security.)

To akBoom re: bad luck: unfortunately, you could be right.

I checked my Technorati links, and found a comment that I quote now in full, because our security code seemed not to work. Here it goes:

I've tried to post a reply to this post three times now, but Movable Type has cranked the suck knob and keeps asking me to re-enter my security code without providing any input field for doing so. By the time you read this my comments may have been added thrice-fold but on the assumption that they haven't, this is what I said :

In so far as S60 Python development is concerned, the 3rd edition signing process has effectively poisoned the well.

None of the scripts I've written for 2nd edition phones work due to permissions issues despite the fact that the (3rd edition) interpreter itself is signed with access to all of the APIs in question. Even then, my understanding is that access to the calendar API has been removed from the spec altogether.

I may get around to requesting a certificate and going through the process of having each app signed but I might as well also start writing everything in C++ or Java. The "killer app" in the Python application is the ability to brainstorm and prototype tools that can actually do something *with* the phone : the calendar, the address book, the camera, cell tower information, etc.

I haven't really tested Raccoon for the 3rd edition yet but I can only assume that the same (signing) restrictions apply to mod_python scripts. I love the fact that I can run a web browser locally on my phone (BTW, browser-app people : requests to http://127.0.0.1 do not need to connect to the Internets). The ability to use the browser's rendering engine to handle all the boring UI stuff combined with JavaScript and Python to manage and manipulate the information on my phone is in a word : Awesome!

Sadly, I don't think it's a realistic prospect on 3rd edition phones given the burdensome nature of the signing process. There are some people for whom the cost of signing their scripts won't be an issue. For some people it will be. For most people, it will just be a barrier too high for people to want to care.

Perhaps a signed certificate for SIS files is prudent (I remain unconvinced) but to extend the same policy to scripts whose interpreter already has a complete permissions set shuts down an avenue of possibilities that was only just beginning to open up.

I dont actually mind the signing process , but would like to see a few changes .

1. The cost for signing should be reduced.

2. Instead of a different sign for ever variant of the same product , how about giving a sign to the professional or the premier or the premium version of the product , and then the features can be cut down after the signing process but not increased. this way , they can get the signing for all the actions of a product so that safety is assured.

Personally, I dislike Symbian Signed a lot!

With S60 2nd edition, I used a lot of warez/cracked software, and now with my brand new E70 I am rather limited in choise of software. Fuck it, fuck it!
Hope for the "security" to be broken one time.

After 2 weeks of Symbian programming

(homemade obsolete exceptions - C++
used as assembler, or Forth language
push stack, pop stack ;-)

strange strings, bad
documentation, DOS like enviroment)

I don't want now buy phone with Symbian OS
Only with Linux ;-)

Returning to Symbian development after doing some Windows Mobile development is like returning to the stone ages. The emulator for Symbian 9 still doesn't emulate an ARM cpu and is distant to devices for anything other than HelloWorlds.
Installing an SDK and compiling a HelloWorld may involve some luck. Carbide is very nice but a time -waster and years behind Visual Studio.
Documentation?... Don't get me started.
And the cherry on top is this certification process which guarantees that innovation will migrate elsewhere (guess where to?), while current large Symbian development companies will share the spoils. Innovation should migrate to devices where innovators can do it without bureaucratic "certifications".

Will the 100M++ devices carrot be enough to make developers endure this mess? Let's see...