Continuing Symbian Signed Conversation

One of the points I was harping on at and around the Symbian Partner conf were my perceived issued with the Symbian Signed effort. As a developer I get no benefit out of the initiative, but I’ve commonly felt some pained incurred by it. David Wood also just posted about the basic principles of software signing, so apparently it’s on his mind too.

I’ve already put down a bunch of my gripes about the current system. But if we want to break it down to basics, there are a few questions that I think we need to answer about a signing process. I was going to try to lay then down in some form of coherent order, but I have a rapidly evolving situation that needs some tending to. So here they are in jumbled rough form:

• Signing is trusting. In the SSL world that’s trusting that the server at the end of the connection is owned by the people who are supposed to own it. Who are we trusting in signing a Symbian app?
• There’s trusting that the app provider isn’t going to do anything nefarious.
• There’s trusting that the OS will only allow the app to do things it was signed to do (nice bit of work there, I like this part of the signing process actually)
• There’s trusting that is something goes wrong with the app you can get help.. which is unaddressed.
• Part of what the carriers/operators really want is a reduction in support calls/cost. This doesn’t help that. Actually, there’s a mistaken perception on the part of users that their carrier/operator is the person to call when an app goes wrong. I don’t call Comcast when a virus screws up my PC
• Why are these things really important in the mobile world when they’re left to sort themselves out (internet style) in the PC realm? Is it constrained devices and bandwidth really? Or is carrier/operator cost the principal driver?
• If it’s really constrained devices and bandwidth, why can’t I – the user – manage rights outside of the signing infrastructure? Why doesn’t signing set default rights and let me choose what I want to grant or remove manually after the install?
• Signing shouldn’t be the only mechanism of trust extension. Look at the Maemo installer for an example of well done application installation process. Installing a package brings in a feed of updates, repository for apt installs actually, that brings in updates. Build the trust mechanism into that, I should be able to trust the people I want to trust. It’s great that the operating system can enforce some set of restrictions for a set of applications signed by an “official source”. But if I want to trust Google directly, let me trust Google.

Damnit, gotta run. Give David some feedback if you can, I think he’s headed in a good direction with this conversation.