[mitts]

In an attempt to improve developer experience around S60/Symbian Signing and certification, this is your chance to give us some input!

We hear from developers that some APIs might require "too high" capability compared to the functionality of the API. If you think that this is the case for some specific S60 API, pls respond to this thread providing the following information:

a) What API?
b) Why do you think that the capability required to use this API should be relaxed?
c) What in your view would be a reasonable capability for the API?

While I understand that some of you would like to respond that no API should require any capability, pls help us pinpoint APIs that you think should be considered for fixing within the framework of the current platform security mechanism.

[mgroeber9110]

Originally Posted by mitts

We hear from developers that some APIs might require "too high" capability compared to the functionality of the API. If you think that this is the case for some specific S60 API, pls respond to this thread providing the following information:

Thank you for getting this discussion started - a few thread references from past discussions that I remember taking part in. I think each of these is fairly self-explanatory in why the capabilities requested there are not appropriate.

• CSendUi - backwards-compatible UI that has not been fully migrated to "sensible" capabilities
• CPbkAddressSelect - requires Extended capabilities Read/WriteDevice data even for read-only access to individual records, and apparently the same data could be retrieved with lower capabilities
• CTelephony creation - varies between phones, needs NetworkServices even for non-network-related tasks such as getting IMEI

I know that the following is more difficult than the above items, but I would still like to make a more advanced suggestion as well, for a longer-term project:

Attempt to remove the need for the DRM capability from ECom plugins (e.g. FEPs) and MTMs. I see no ultimate design reason why most of this code should ever come into contact with decrypted DRM data, so because of the strict liability implications for anyone getting this capability, in my view the long term approach should be to factor out code that needs to have this level of access into a small number of servers, instead of spreading it across a wide variety of unrelated modules "by guilt of association".

[mike_brock]

1. Location should be made user grantable - at least for the case where the requestor is local to the device and ERequestorService/EFormatApplication.

The capabilites allowing developers to connect with an RSocket to a Bluetooth GPS and receive the raw NMEA and thus determine location without using the Location API are all user grantable, so a developer can self-sign. But to use the GPS built in to the N95/6110/E90 one must use the location API, which is declarative, so requires symbian signing.

The user could be asked to confirm the first connection to the location server to provide the same level of protection as for data or Bluetooth connections.


2. To open a web URL if the web browser is not already running requires no capability. If the web browser is already running it requires the SWEvent capability. (TSS000340 in technical library.)

To open a web URL when the web browser is not running, you use RApaLsSession::StartDocument which requires no capabilities. But if a web browser is running, you need to use TApaTask::SendMessage, which requires SWEvent - even if your program started the web browser with a previous call to RApaLsSession::StartDocument.

SWEvent requires symbian signing, which seems excessive just for opening a URL.

[ltomuta]

Hi guys,

To keep this thread interactive here is how I see some of the issues:

Originally Posted by mgroeber9110

• CTelephony creation - varies between phones, needs NetworkServices even for non-network-related tasks such as getting IMEI

This issues is about to be documented in the Technical Library: only one S60 3rd Edition device is affected by this defect which btw. was fixed and the updated firmware is already available.

Originally Posted by mike_brock

1. Location should be made user grantable - at least for the case where the requestor is local to the device and ERequestorService/EFormatApplication.

The capabilities allowing developers to connect with an RSocket to a Bluetooth GPS and receive the raw NMEA and thus determine location without using the Location API are all user grantable, so a developer can self-sign. But to use the GPS built in to the N95/6110/E90 one must use the location API, which is declarative, so requires Symbian signing.

The user could be asked to confirm the first connection to the location server to provide the same level of protection as for data or Bluetooth connections.

When a user caries an external GPS device it is presumably very clear for him/her what that device is used for and when the device is on or off. With an internal GPS device or with the location acquired from the network the user may feel that he/she is not in control of what the phone "says" about him/her location. It is therefore understandable that the phone or service provider want to have a certain level of quality and liability control.

As a general note: I think is more important to see reports of situations where the application development is slowed down (e.g. by the fact that one is not able to test basic functionalities on device until the manufacturer approves a certain capability for the devcert) rather than complaints about capabilities that can be easily obtainable during the application testing phase (e.g. Location) but which at the end will require certification.

[mgroeber9110]

Originally Posted by ltomuta

When a user caries an external GPS device it is presumably very clear for him/her what that device is used for and when the device is on or off. With an internal GPS device or with the location acquired from the network the user may feel that he/she is not in control of what the phone "says" about him/her location. It is therefore understandable that the phone or service provider want to have a certain level of quality and liability control.

I agree on the difference between internal and external GPS - but this is still somewhat contradictory in my mind, in that for an external GPS you are happy to let the user make the choice whether location is available to an application or not, while for an internal GPS you argue for this to be controlled by the service provider. On the other hand, no such liability issues seem to exist for NetworkServices, which can easily lead to the user clocking up a few thousand Euros on their phone bill...

For this reason, I would tend to support the idea of making location a user-grantable right as well, on a par with NetworkServices and UserEnvironment. At least its implications can be more easily communicated than, say, MultimediaDD.

Originally Posted by ltomuta

I think is more important to see reports of situations where the application development is slowed down (e.g. by the fact that one is not able to test basic functionalities on device until the manufacturer approves a certain capability for the devcert) rather than complaints about capabilities that can be easily obtainable during the application testing phase (e.g. Location) but which at the end will require certification.

In my view, this misunderestimates the amount of complexity and schedule risk that mandatory signing introduces for an organization that has no prior Symbian experience - I have met several people who did not even know about the ability to self-sign certain apps, and consider the need for external testing of a semi-public demo app as a major obstacle. For them, even "easily obtainable" capabilities actually do slow down development.

In terms of sensitive capabilities providing a real barrier to entry for new developers, my first candidate would be the need for ALL -TCB on some parts of MTMs.

[ltomuta]

Well, different developers will face different problems and this is why we need to make sure that the overhead is minimal and that all the featuers are controlled by minimal capability requirements.

[jan_ole]

Originally Posted by mike_brock

2. To open a web URL if [...] SWEvent requires symbian signing [...]

SWEvent should generally be made user-grantable. At least for sending keystrokes and events with functions like TApaTask.SendKey, UserSvr::AddEvent(), etc.

Ole

[svdwal]

Recognizers needing the ProtServ capability. A recognizer only looks at the contents of a system-supplied buffer, and not much else. As ProtServ is not user-grantable, is is now not possible to create an application for viewing or editng Non-Symbian formats that is self-signed.

Printer drivers needing the capabilities of the loading application, which can be All -TCB.
A printer driver prints information on paper, or does something that is equivalent to printing on paper. If this is a problem for apps, it is much easier not to implement the printing functionality in the first place.

[feenix]

I have made this suggestion before and will make it again: make most of the caps user grantable runtime.

What I mean is this:

When an application wants to determine the location of the user, it will use Location API. The user is presented a query "Do you allow the SW to find out your location?" and selections: No, This time, Through this SW use, Always.

This way the USER is in control. THEY will decide if they want to allow the SW to get the information.

And naturally this woul be extended to all areas: reading/writing SMS's, contact information, email, network, camera etc etc etc.

Platform security is a good idea, but the security should come fom the user. Not from some third party testing house that doesn't really know what the SW will do after a month, year, 100 executions etc. And this way you wouldn't have hundreds of disgusted developers screaming at you.

This has already been done for JVM's in many phones and it is not a hard thing to implement.

Also another thing: it is stupid that we must declare the caps in the MMP file when compiling. Think about this:

I compile a SW. I want to test it with a devcert in my device but I also want to give it out. I use e.g. Location API. Now I must compile two versions: one that has one set of caps in the MMP, sign it with devcert, then another version that has another set of caps and sign it with another cert.

Since the functions can already have return values that say "no no, you are not allowed to do this", why should we tell the caps in MMP? Just so that the user can be presented with the list in application install? Not if you did it the way I described above.

Also, it's not nice to see the list when installing. The SW can "make calls or use network." So, which is it going to do? I want to allow it to use network, but not make calls naturally. The user is quite unsure at this point. Also other caps are too broad for the user to grasp, this is why more fine separation and runtime querying would be nice.

But if you're only going to relax APIs, I too vote for at least Location and Cell ID queries to be allowed without devcert/symbian signed testing.

[ltomuta]

Originally Posted by feenix

Also another thing: it is stupid that we must declare the caps in the MMP file when compiling. Think about this:

I compile a SW. I want to test it with a devcert in my device but I also want to give it out. I use e.g. Location API. Now I must compile two versions: one that has one set of caps in the MMP, sign it with devcert, then another version that has another set of caps and sign it with another cert.

Since the functions can already have return values that say "no no, you are not allowed to do this", why should we tell the caps in MMP? Just so that the user can be presented with the list in application install? Not if you did it the way I described above.

The capabilities listed in the MMP file are embedded in the produced binary and will tell what an EXE can do (if trusted) or what a DLL can be trusted to do (by the EXE who loads it). From this point of view the capability definition fits as well with the MMP as anything else. Then, the capability check is done at run time and the process is queried for needed/available capabilities by functions that otherwise have no ideas who your process is. It is the server side method that has a security validation policy and not your client side function call.

Also, capabilities can be changed post-build so you do not need to rebuild your project if the only thing changed is the capability set. Plus, a small extension makefile can generate as many "versions" of your application as you need in one build session.

But if you are going to deliver an application without the Location capability then providing proper error handling is not enough. You should really rebuild your application and remove the bloating location related code, it is going to be useless anyway.

[Aarkham]

Originally Posted by feenix

I have made this suggestion before and will make it again: make most of the caps user grantable runtime.

What I mean is this:

When an application wants to determine the location of the user, it will use Location API. The user is presented a query "Do you allow the SW to find out your location?" and selections: No, This time, Through this SW use, Always.

This way the USER is in control. THEY will decide if they want to allow the SW to get the information.

And naturally this woul be extended to all areas: reading/writing SMS's, contact information, email, network, camera etc etc etc.

Platform security is a good idea, but the security should come fom the user. Not from some third party testing house that doesn't really know what the SW will do after a month, year, 100 executions etc. And this way you wouldn't have hundreds of disgusted developers screaming at you.

This has already been done for JVM's in many phones and it is not a hard thing to implement.

Also another thing: it is stupid that we must declare the caps in the MMP file when compiling. Think about this:

I compile a SW. I want to test it with a devcert in my device but I also want to give it out. I use e.g. Location API. Now I must compile two versions: one that has one set of caps in the MMP, sign it with devcert, then another version that has another set of caps and sign it with another cert.

Since the functions can already have return values that say "no no, you are not allowed to do this", why should we tell the caps in MMP? Just so that the user can be presented with the list in application install? Not if you did it the way I described above.

Also, it's not nice to see the list when installing. The SW can "make calls or use network." So, which is it going to do? I want to allow it to use network, but not make calls naturally. The user is quite unsure at this point. Also other caps are too broad for the user to grasp, this is why more fine separation and runtime querying would be nice.

But if you're only going to relax APIs, I too vote for at least Location and Cell ID queries to be allowed without devcert/symbian signed testing.

I fully support what you have said. It's a shame that the power to decide what can be done in a phone is not in the hands of the people that have bought it and pays the carrier bills.

I also vote for the Location API. I work in a LBS company and it's going to be very strange that the worst version of our phone application is going to be the one for the Symbian phones that have a built-in GPS.

[mitts]

Good feedback, keep them coming!

[Aarkham]

Also in line with the user being able to grant permissions. What happens if a serious bug is discovered in an application? maybe that application is signed with full rights and the bug compromises the security of all the data in the phone. But the company can not provide a quick bugfix because they have to sign it, and that takes time...

In the case of my company, we have valuable data in our servers, if the user trust us and pays monthly for our service, I can not understand why we need a third company to make our clients feel more safe.

Thanks

[ajsanchez]

Hello everybody,

I'll give my opinion about BIO parsing and the capabilities needed for it.

This technique is ussed to manage message types arriving to the phone, such as ringtones, configuration files and so on.

The normal way will be to have two components, one dll parser telling that the message belonges to a certain type and one application (or a control) that manages the message (The two components will be linked by a BIF file).

In most cases the dll parser will do nothing but tell the OS that the message belonges to the type defined for that BIO parser (in other cases it may save the contents of the message to a file). So the application will be launched and manage the message.
This application will be signed and tested and supposed to be reliable for the user and the phone and it will have the capabilities granted either by the user or the certificate when it was installed.

What I don't understand is the set of capabilities needed by the dll parser: ReadDeviceData WriteDeviceData DiskAdmin NetworkControl SwEvent NetworkServices LocalServices ReadUserData WriteUserData Location UserEnvironment what includes two sensitive capabilities (DiskAdmin and NetworkControl). This implies getting those capabilities at development time just for testing the dll and app on target phone (with all the problematic associated to that).
I don't know why this is so complicated, though that the application can do exactly the same if it is running all the time (adding it to startup list) and looking the inbox (CMsvSession).

Bye

[unikande]

Hi!

LOCATION CAPABILITY USER GRANTABLE, PLEASE!

I have developed a navigation program for S60/S80 for boaters. It only works with Finnish nautical charts which are especially adapted for the program. As you can imagine the market is not very big for this kind of application. I'm working on the program on my spare time so it has taken several years to complete. There are now about 300 programs out there working in S60 version 1 and 2 phones and Nokia Communicators. Being a one man/one product company there is no way I can go through the testing/signing process if I want to make any profit at all with the application.

It's really a pity that my application will not work on the coming Nokia devices with built in GPS. Well actually it can work, using an external GPS but it will not be able to use the integrated GPS because Location capability is not user grantable.