Symbian Signed AllFiles and TCB
My adventure into writing Symbian 9.1 Signed freeware has unearthed more problems and questions… and a few answers.
If you are following my progress, you will know I needed a ACS publisher ID to obtain a devcert for a manufacturer capability. Up to now, I haven’t needed one as apps have been signed in the name of companies I have worked for.
You need to apply for a certificate in the name of a company. Luckily, I work freelance through my own UK Ltd company so this wasn’t a problem - but could be a problem for lone developers.
Anyway, I stumped up the $350 to Verisign. The next problem was because I don’t have a telephone bill in the name of my company (I forward a 0870 number to home during work hours), Verisign needed the paperwork to be notarised by a Solicitor… costing me a further £60. I finally got my Verisign cert last week and applied (via Symbian Signed) for a DevCert.
Now more about capabilities. The latest Symbian Platform Security FAQ explains how I need not just AllFiles but TCB to be able to write to the sys and resource directories. This is more serious as it requires that the application be signed by Nokia.
I emailed Symbian Signed to ask for a contact at Nokia. I was told that I may not need TCB and they asked for the APIs I am using. I sent the information and they emailed back saying the query has been passed on to the Symbian technical support department. A week later, after chasing my query, I got a reply saying I would need Allfiles and TCB and also asking what kind of application I was writing.
The above demonstrates a problem. There’s no one place that describes what capabilities are used for what APIs. Even the Symbian Signed team don’t know. The SDK only has an incomplete and confusing list. In fact, the way you use an API (e.g. What particular directory you access in an RFile call) affects what capabilities you need. The only way to determine what capabilities you need is to experiment in the emulator and look for platform security debug trace messages. Not very clever. In fact, it might even be possible to produce a program and get it Symbian Signed, only to find an end-user uses it (results in different data into an API) in a particular way that violates platform security. i.e. It’s often not possible to do exhaustive scenario testing.
Meanwhile, my DevCert request was processed by Nokia and I got the following answer…
"As the whole Platform Security is based on the idea that nobody gets access to those data caged directories, we cannot accept the request for TCB and AllFiles. Moving/copying files to those directories is not very permanent anyway, since the application installer is the only application that can modify the content of those directories. For example, if you’re copying some files to some of the data caged directories directly, those files will be removed in the next device boot."
This last bit is news to me and isn’t documented anywhere. The people Symbian Signed people obviously didn’t know this. I have been wasting my time (and money).
Since then, several developers of existing pre-9.1 applications have emailed me. Some interesting things have come up. Is a manufacturer capability granted based on the fact that it’s known (tested) that the application doesn’t do anything ‘naughty’ (e.g. behaves badly/does things not documented) or are there policy decisions based on types of application that Nokia doesn’t want on the phone?
Some of the more interesting pre-9.1 applications do things that change the default behaviour of the phone. How favourably will these be assessed? (I know… on a case by case basis). Another problem area is interpretors such as OPL, Appforge and Python. These could be used to write rogue programs. How will this be policed?
On thing’s for sure. The Symbian Signed department must be very busy and will have to improve their processes and clarify what’s possible if they are not to be over-run with (case by case basis) questions.
Related Articles: