>"The vast majority of users today don't have a problem with malware (as I type, there still hasn't been any on Symbian OS v9)."

True, but the situation might change in the future, if the testing and other hurdles before apps can be signed are reduced (as many developers request).

If that change occurs, then a service such as I described in the main posting becomes more desirable:

“In principle, users would be willing to pay money for a premium service from application stores, as follows:

“*) If an application is subsequently deemed to be problematic (on, say, particular phones), then relevant users would be sent messages alerting them of this situation.”

As you say, the interesting question is, who should pay for such a service?

This question applies more generally. It seems that, either way, there are costs to keeping networks and phones free from malware. Costs have to be borne, whether malware is policed by up-front testing or by retrospective revocation.

In the present setup, these costs are largely incurred by developers. I like your idea of exploring alternatives!

// dw2-0

Why? The vast majority of users today don't have a problem with malware (as I type, there still hasn't been any on Symbian OS v9). This seems like asking users to pay for making developers' lives easier (either directly with this app store surcharge, or indirectly by suffering malware) and that isn't a very attractive sales pitch!

I do think economics might provide an answer though, it's basic supply and demand – stakeholders who want more security should pay more for it, and stakeholders who want less security should pay less for it. Right now most users don't care about security; most developers actively want less; so who wants more?

>“…an interesting way to exploit Symbian vulnerabilities is presented, so ingenious that not even a perfect revocation infrastructure could ever stop the malware that could be created with it…”

Wouldn’t this mechanism be defeated if the Publisher ID certificate being used to sign such malware was revoked (and if the personal credentials used to obtain this Publisher ID were barred from being used to obtain another ID)?

Here, I’m using the word “revoked” in the loose general sense of point 5 in my original posting:

“In yet other cases, the developer who signed the application could be barred from signing any more applications”.

// dw2-0

>"I have long believed that revocation handling is a role that the AV vendors are perfectly placed to fulfill in the Symbian environment…

>"Anyway, there is an ecosystem here waiting to be developed…"

Interesting thought!

I look forward to the ecosystem itself stepping forward to implement this kind of solution.

However, I suspect that such solutions will require some centralised changes too – changes that can only be made at the heart of the ecosystem (such as alterations to some core parts of Symbian Signed).

// dw2-0

In some ways, this premium service would be akin to the anti-virus monitoring solutions that are already available from some security specialist companies.

I have long believed that revocation handling is a role that the AV vendors are perfectly placed to fulfill in the Symbian environment.

There has always been a certain amount of ridicule on why there are probably more AV solutions for Symbian 9.x than viable viruses, but if the role of AV vendors could be extended to deal with revocations, this might give more legitimacy to their products, while at the same time requiring exactly the types of judgment calls that security firms are used to making on a daily basis.

This could probably be extended to policing different definitions of “malware” – e.g. company phones may be more restrictive about certain types of software than phones managed by an individual.

Anyway, there is an ecosystem here waiting to be developed…