FAQ-1306 How are automatic 'Over The Air' updates handled within the Symbian Signed framework?


FAQ-1306 How are automatic 'Over The Air' updates handled within the Symbian Signed framework?

» Symbian OS » Developer Knowledgebase » FAQ-1306

Classification:	General	Category:	Symbian Signed
Created:	09/14/2005	Modified:	10/24/2005
Number:	FAQ-1306
Platform:	Symbian OS v6.1, Symbian OS v7.0, Symbian OS v7.0s, Symbian OS v8.0, Symbian OS v8.0a, Symbian OS v8.0b, Symbian OS v8.1a, Symbian OS v8.1b, Symbian OS v9, Symbian OS v9.0

Question:
How are automatic 'Over The Air' updates handled within the Symbian Signed framework?

Answer:
Symbian Signed takes the position that an application providing OTA update functionality should conform to the same "good phone citizen" criteria as other applications.

These criteria are captured in the Symbian Signed Test Criteria, and also the "Guidelines" listed below.

What is OTA updating?
"Over-the-air" (OTA) mechanisms can be used to update executable files (.exes, .dlls) and to update/add additional passive content - e.g. configuration information, game levels, e-books etc.

OTA updates can be:

User-initiated or automatic/scheduled
Installed as standard SIS files, individual files, or other package types
Downloaded using standard protocols or custom protocol

OTA updates can be an effective mechanism for upgrading applications, but can also be abused. Common abuse cases include:

Large and costly downloads without notifying the user
Sending out user information without permission
Overwriting other application's files

Symbian Signed Guidelines for OTA updating
An application should consider these specific guidelines in addition to the normal test criteria:

1. Notify the user of any chargeable connections.
2. Notify the user of any connections initiated by the application. Minimally this should be done until the user chooses to turn off the notification functionality.
3. Update executable and resource files by bundling them in a SIS file and using the installer (rather than placing them directly into locations on the file system).
See below for a brief discussion of the issues with respect to phones based on Symbian OS versions before and after Symbian OS v9.

Pre-Symbian OS v9
The security model prior to Symbian OS v9 allows the developer to have full flexibility in handling OTA updates, connections, notifications etc. This includes the ability to harm the user/phone as described in the abuse cases listed above.

Symbian Signed applications are expected to follow the guidelines given above. As for all Symbian Signed validation, a significant value comes with the fact that the application is signed, so the vendor of poor or malicious applications can be identified.

Symbian OS v9 and later
The Symbian OS v9 enhanced security model supports capability mediated access to functions and data caging. These enable
enforcement of the recommended guidelines:

** Guidelines related to network connections (1, 2)
These are enforced for unsigned applications - these are given only one-shot user-granted access for making network connections.
Symbian Signed applications will be expected to comply with the usual test criteria/guidelines in order to pass - they may however be granted exceptions/waivers for alternative behaviour at the manufacturer discretion.

** Guideline 3 related to executable packaging in SIS files
Executable files must be packaged in a SIS file and installed using the normal installer; it is not possible to download and run executable files directly.

Executable files can only be run from \sys\bin\ and can only be copied to that location using the standard installer. Application resource files and other private data must be stored in \private\\ - again, the only way to access these directories on Symbian OS is through the installer.
Non-executable and public files do not need to be installed using the standard installer. So if there is no need to protect the files, then OTA methods as prior to Symbian OS v9 may be used.

Theoretically an application might bypass the standard installer by getting the manufacturer-granted "TCB" capability. In practise, it is unlikely that a manufacturer will grant this capability.