Join Now

Hi, I'm Paul, but you can also call me Todd and I won't get upset.

Symbian signed and openess

Paul.Todd | 08 July, 2008 12:11

I hav'nt posted for a while, primarily becuase I am behind in whitepaper writing and partially due to work commitments.

Anyway I am working on a new set of posts explaining the OMA-DM adapters and how to access them so this will be starting in a few days as I have realized the existing documentation for this is woefully inadequate for something so powerful.

However, onto the cheese as people say... David Woods has an excellent article on Symbian Signed over at his blog

 However there  are some fundemental issues I disgree with.

1. As he was part of the Symbian Signed  design team he knows it inside and out. Most developers do not know or understand the nuances of capabilities and how they apply to which dll is loaded with what capabilities and it even goes as far as signing a sis file. Even the documentation is far from clear. One only needs to look a the rule for dynmically loading a dll vs statically loading a dll. Whilst David may know it as he designed Symbian, a Windows or j2me developer will not.
In the past I have had  more than my fair share of problems explaining to other dev's why it is a bad idea to run services with the TCB priviledge on Windows and its orders of magnitude more complex to explain capabilities on Symbian.

2. how the hell can someone rewrite an OS and forget to document which API's have have what capabilities. Enough said really (whilst ROFL)

2.1 How can someone rewrite an OS and forget to put in decent logging and helpful error messages when an application fails to run or install (still ROFL'ing)

3. Getting decerts for other competing products is a piece of cake compared to Symbian. MS, RIM and Apple are simple and it just works.(Not ROFL anymore)

4. If anything I see device manufacturers using capabiltiies to prevent people distributing applications that can compete with other solutions or preferred suppliers. Lets say I write an antivirus application with the new Symbian Foundation API's, I am still beholden to the device manufacturer to grant the capabiltities to install and run my product.No where does it say Symbian Signed will be the point at which an application will be rejected for quality concerns. The way I see this playing out is that manufacturer will still stop developers getting devcerts with all capabilities (eg TCB) under the guise that they only work with "partners" and not with ISV's so developing for example an antivirus solution will never happen because of manufacturer lockout. Whereas Symbian Signed should be the gatekeeper for applications to be run on the phone it is much more likely that capabilties will still be the paper work nightmare they currently are.

For these issues, I unfortunatly I still see Symbian Signed as a revenue black hole for ISV's in the moribund ISV app market.

So enough with the "open source" washing PR and more with concrete support for developers because ultimately we are the people going to deliver the applications that sell the phones and lets make sure they are Symbian and not Android or Limo phones.

 If you really want to impress me, say that the Symbian Foundation and Nokia are adopting the principals and practises of Maemo and not Microsoft.

General, Symbian C++ | Next | Previous | Comments (4) | Trackbacks (0)

Comments

What's your #1 suggestions for improving Symbian Signed?

dw2cco | 08/07/2008, 19:59

Hi Paul,

I'm keen to learn from the principles and practice of Maemo. Absolutely!

I'm sorry to hear that you've had a rough time with Symbian Signed. Could I ask you: What is the single most important improvement you recommend should happen with Symbian Signed?

As you know, Symbian Signed went through a number of changes recently. As it says in "A guide to Symbian Signed":

"Symbian Signed has changed recently, introducing new and simplified signing options
for applications, and a new lower cost Certificate Authority (CA). No matter what kind of application you are developing for Symbian OS, whether it is commercial or non-commercial, the changes should make it easier for you to get your software signed and deployed. The following three signing options are now available:

"(*) Open Signed, Developer Certificate based signing, including a completely new online-only signing option for developers without a Publisher ID;

"(*) Express Signed, a streamlined signing option that does not require independent testing;

"(*) Certified Signed, the mainstream signing option based on independent testing by a Symbian-accredited Test House."

"The number of Capabilities requiring Device Manufacturer approval has been minimized, and a simpler, unified process has been created for applications that do still require manufacturer approval. Independent testing is now only required for Certified Signed. However, all applications are still expected to satisfy any test cases relevant to them."

// David Wood, Symbian

symbian signed

safaltechnical | 09/07/2008, 07:16

hi Paul,

i do not have publisher id
but i want to install a sis which requires capabilities like TCB,NETWORK CONTROL ,ALLFILES
but the capabilities is not accessed through open signed

Yes and no

Sorcery-ltd | 09/07/2008, 12:42

Sorcery-ltd

Hi Paul,

I have to say I agree with some points and disagree with others.

1) Yes, PlatSec is complex and not helped at all by the very poor information that Symbian publishes about it. The new PlatSec booklet from Symbian Press is particularly poor - I'll post my constructive criticism on that separately.

2) Well yes, inexcusable really. Although they didn't rewrite the OS, they retro-fitted PlatSec constraints to existing APIs which is where a lot of the problems come from. I expect that most of the PlatSec checks were documented at the point of the check, but another API that uses an API internally that requires a certain capability...

2.1) Yes, but that's business as usual in most software development in my experience. :-(

3) Once you're signed up to the program - which is the problem most people have with Symbian Signed at the moment. I've already given my suggestions for how this could be improved for freeware and open source projects. How should it be improved for commercial ISVs?

4) I'm not sure where your distrust comes from here, particularly since you've been granted TCB capability for an application. There is already an anti-virus product for Symbian (http://www.f-secure.com/products/fsmav.html). If someone else writes one that is both good and secure I'm sure they'll have no trouble getting the necessary capabilities granted.

TCB really does need to be protected very carefully though, otherwise you might as well just throw away PlatSec altogether. If I were in charge of handing out the TCB DevCerts I'd only be giving them to sensible sized companies with a reputation to lose or start-ups where the people involved were already known in the industry (not how things should work in a free and fair world but the core concept for PlatSec is TRUST!).

If Norton turns up saying they want a TCB devcert to develop an anti-virus product for Symbian they'll have no problem. If J. Smith from the newly created MobiVirus.com makes the same request then he's going to have a lot more work to do to get it granted. That's how it should be! However, if it was P. Todd rather than J. Smith he should have a rather easier time of it. :-)

Mark

TCB

Rippe | 09/07/2008, 15:13

Rippe

As I'm (with my team) partially in charge of giving out DevCerts with TCB, DRM and AllFiles I just have to comment. What Mark described is exactly what we do. We have to be careful when granting any of the three. Because:

1. AllFiles just to make sure your secrets are not thrown away too easily.
2. DRM because Nokia licensed DRM technology and we are liable on holding that part together. In other words a DRM protected application must not leak out from our devices unprotected.
3. TCB because there is Platform Security and because of #1 and #2.

The main pain is that all of the three capabilities are still needed. May it be design flaws in S60 (Server Side MTMs, changing a theme background, etc.) or due to a good reason (Device encryption, Antivirus, FEPs, etc.).

That requires a process which is bit painful, but doable if the reason is technically justified and (like I say) the company requesting them has a direction in life. Unfortunately there is a legal agreement needed...

Risto

You must login to post comments. Login
 
 
Powered by LifeType 
     
     RDF Facets:
     
     
     qfnZtopicQUqfnBlogTopicZgeneralQ
     qfnZtopicQUqfnTopicZcppQ
     qfnZtypeQUqfnTypeZBlogContentQ
     qfnZtypeQUqfnTypeZBlogE45ntryQ
     qfnZtypeQUqfnTypeZCommunityContentQ
     qfnZtypeQUqfnTypeZWebpageQ
     qmarsZlanguageQUxhttpE3aE2fE2fswE2enokiaE2ecomE2flanguageE2d1E2fenX