Mark Wilcox's Forum Nokia Blog

Yes do agree with Mark. with One point missing it show also show a dialog saying you should not have paid for this application or like that ...

Hi, yes, the current (no longer available?) freeware signing system enforces a notice that says you shouldn't have paid. However, open source licenses usually state that anyone is free to sell the application (of course hardly anyone ever does because it can be obtained free elsewhere) so that could make things difficult again.

Hi,

I think that most of the basic principles here are reasonable and that with a few slight tweaks this could work.

Creating a new "Free Signed" category would be difficult for a few technical reasons and more importantly I think it'd be difficult to get all the stakeholders (i.e. operators and phone vendors) to agree to it. The developer programs (e.g. FN, SDN, SEMC DevWorld) would all love it of course, but alot of the other teams would be scared and not like it. This is especially those people who are most concerned with more mid-range devices where the users are unlikely to install freeware anyway and are also not likely to pay much attention to text files in the SIS before calling the operator's support team.

This is one of the key challenges we face with Symbian Signed, it's trying to cater to several very different audiences. On the one hand are developers who basically want to treat their phones like they treat their PCs and are happy to take the responsibility if it all goes wrong. On the other hand are people using phones that came free on their contract, have no idea about malware and alpha software, and will get very very annoyed if they end up with an unstable phone even if they did click "yes" to a dialog with a skull-and-cross-bones on it. BTW - the other audience is enterprise which is different again but not relevant here.

Anyway, getting back to the point, although I think "Free Signed" would be challenging, what's wrong with "Express Signed" as it is today? You say that there are two problems:
-- It needs to be free.
-- There needs to be no test criteria.

On the first point I have a simple solution. We'd need to look at the volume, but Symbian would pay for the publisher ID and the content IDs for a group of people willing to act as a "publisher certifier" for freeware. We'd probably be happy to have about 3 or so such groups.

In terms of liability on the publisher certifier it'd be the same as anyone else with a publisher ID -- i.e. if something goes wrong (found either by audit or through consumer complaint) Symbian looks into the situation. If it's malicious then we revoke the publisher ID. If it's carelessness we'd give a warning and if it continued then we'd revoke.

We once had an idea of having a freeware community website where applications could be uploaded, people could use them (via open signed), and then vote on them. Once an application got sufficient votes it would be signed. Unfortunately we haven't found anyone to do it yet.

So then there's the test criteria. To be honest I don't really understand why freeware signed properly in this way shouldn't be subject to the test criteria. If the tests aren't sensible then commercial software shouldn't be subject to them either and we should remove them (as we have done on quite a few in the latest revisions). If the tests are sensible then signed freeware should follow the rules same as other software. Otherwise that's what open signed is for.

Apart from anything else -- I don't like the idea of another level from a consumer's perspective. When I'm installing an app I'm happy to see "signed" or "not signed", but "this is freeware" is starting to get a bit complicated.

So...
(1) What do you think?
(2) Next step is finding a group willing to act as a publisher certifier. Interested?

The other option we once considered was to give people with publisher IDs the right to use non-IMEI restricted developer certificates. This is actually closer to what you are suggesting since:
(A) The user would get a "dragons be here" dialog on installation.
(B) There isn't the expectation of meeting with the test criteria.

The biggest concern about this is that it would be abused for cracked software and we'd end up having to stop it again a few weeks later.

Cheers,
Antony

After reading your posting on the N800 I realise that I forgot to mention what I think is the real solution here. Rather than trying to deal with mid-range phone users, pro-sumers/developers, and enterprises in the same way just separate them.

(1) For mid-range phone users I think Symbian Signed as it is now is quite reasonable. A freeware path would be good. Some improvements to the submission process on the website would be good. But otherwise it's decent.

(2) For developers/pro-sumers just add a setting to the phone that allows the user to install any application they want (not including device-manufacturer capabilities). With over-the-air settings any operator could detect that you'd turned this off when you rang up for support and could tell you that you're on your own.

(3) For enterprise do the above but also allow them to install they own additional certificates (since enterprises often want to stop apps going on to device other than their own).

Personally I think that this is the right solution.

Cheers,
Antony

Hi Antony,

Thanks very much for reading and responding.

This is a really difficult area and I very much appreciate the attempts to find a compromise.

I don't think the "Even better solution" above will work. I agree that what's needed is to treat the different classes of end user separately. However, if you effectively allow people to make all but the device manufacturer capabilities user grantable via a setting then I think it will get massively abused - for cracked software again.

I think that everything widely installable needs official signing of some sort to maintain the identity/trust chain.

If you allowed users to change a setting or install another certificate that enabled them to use officially signed (but not certified) freeware (which is a combination of the solutions discussed) then it could work. It could be made clear that your warranty was void after you change the setting/install the certificate at least unless/until you re-flash with the latest official firmware (disabling the setting or removing the certificate) then would that keep the other stakeholders happy?

Other than that I think we're in broad agreement.

Cheers,
Mark

I'm interested in the question of whether "Free Signed" software should comply with the test criteria. You suggested that it shouldn't need to in your original post, but I think it should (see my first post).

Thoughts?

I think that is the absolutely critical point if you want this to work for freeware and open source software.

There needs to be a way to distribute easily installable alpha and beta versions of a project. Many projects will never go beyond this stage but none will if you can't generate a decent following to provide feedback and encourage the developers.

UNI-01 is about final released projects. If developers want to get their freeware or open source projects distributed widely via major portals like Handango, or in the Nokia Download client for example then I think they should be in this state and go through the full signing process.

UNI-02 is actually pretty hard to fail by blocking the incoming events - you'd have to do it on purpose. If the application state is messed up by an incoming call in a beta version you just live with it.

UNI-03 an open source based project is likely to have large ported components that come with their own memory leaks - a developer isn't going to want to fix all of these before getting to the interesting bits that made them want to start the project in the first place. Also, failing this case isn't at all serious - you're likely either to see the app not open at all or get a nasty system error. Quite likely though the phone will close something else and everything will be fine. I actually think this one isn't really necessary for the full signing case.

UNI-04 with modern storage sizes is unlikely to ever occur and again the failure isn't really significant. The kind of advanced user that's going to be playing with beta versions can quite comfortably fix things with a file manager.

UNI-05 has to be deliberately prevented not to work in general. Nothing a reboot won't fix for the advanced user anyway.

UNI-06 is pointless in my opinion. If you deliberately remove the battery during a file system write then you can corrupt the files and quite possibly break many applications that have passed the test. The chances of doing this by accident are incredibly small. Can be fixed by a re-install (plus clean up with file manager in the worst case).

UNI-07 again for a beta, who cares? Backup and restore isn't the first feature you're going to add.

UNI-08 is almost out of date paranoia about resource usage. Should still be there for full signing but the N96 has 16GB for goodness sake - I don't have that much installed on my laptop.

UNI-09 is likely to work anyway post v9. Where it doesn't the project is likely to die as future versions are unlikely to install either. Developers have quite an incentive to ensure this works anyway.

UNI-10 again developers have quite an incentive to support as many resolutions as possible. Where they don't there's likely to be either a mess on the screen, a cropped screen or a blank border. The user will probably just give up and uninstall the app. Doesn't seem like a big deal.

UNI-11 finally a test case I agree with! Will not apply to most applications and for the advanced users targeted here will probably result in the removing the application if they don't have the option.

The capability specific tests should almost certainly remain valid for any widely distributable release of freeware or open source software but if "Free Signed" only includes the capabilities for Express Signed then this isn't an issue.

As such you could just use Express Signed via specific freeware and open source publisher certifiers and waive all fees and test audits for those publisher IDs. The thing you've lost then is the posibility for the software installer or application distributors to tell the difference.

Cheers,
Mark