Patent Publication Number: US-2009228704-A1

Title: Providing developer access in secure operating environments

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application claims the benefit of U.S. Provisional Patent Application No. 61/033,727, filed on Mar. 4, 2008, which is hereby incorporated by reference in its entirety. 
    
    
     BACKGROUND 
     1. Field 
     This application relates to security in development environments. 
     2. Description of the Related Technology 
     Currently, computer systems may be configured to require that code executed on the computer system be authorized by a trusted party, such as the computer system&#39;s manufacturer. These types of requirements are typically implemented in order to ensure that the integrity of the computing device is not compromised by malicious or unauthorized code. In some cases, computer systems may be configured to require that code be digitally signed by the trusted party and verified before being allowed to execute on the computing device. Verification of the digital signature ensures that the underlying application code has not been modified since it was digitally signed by the trusted authority. 
     However, this security scheme presents a challenge to a software developer. During development, a software developer will frequently modify their code on a computer system and may attempt to test it on that system. Each time the code may be modified, the digital signature becomes invalid. Therefore, in order to execute any new or modified code, the software developer must have that code signed again by the trusted authority. This process can be cumbersome and time consuming. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows a block diagram providing an example of a computing environment suitable for the distribution of software code to computing devices. 
         FIG. 2  shows a block diagram providing one example of how a developer computing device from  FIG. 1  may be configured to utilize developer access profiles. 
         FIG. 3  shows a more detailed view of the developer access profile shown in  FIG. 2 . 
         FIG. 4  shows a more detailed view of the developer identifier data shown in  FIG. 3 . 
         FIG. 5  shows more detailed view of the device identifier data shown in  FIG. 3 . 
         FIG. 6  shows a more detailed view of showing examples of the entitlement data from  FIG. 3 . 
         FIG. 7  shows a flowchart which provides an illustration of how a computing device may be configured to verify and authenticate software. 
         FIG. 8  shows a flowchart illustrating a general process by which third party software developers may be granted developer access using developer access profiles. 
         FIG. 9  shows a flowchart providing an alternative example of how a developer computing device may utilize a developer access profile to execute code. 
         FIG. 10A  illustrates an example mobile device. 
         FIG. 10B  illustrates another example of configurable top-level graphical user interface of a device. 
         FIG. 11  is a block diagram of an example implementation of a mobile device. 
     
    
    
     DETAILED DESCRIPTION 
     Embodiments are disclosed herein that allow for efficient development of software, especially software that may need to be signed in order to execute on a computing platform. With embodiments of the systems and methods described herein, persons and organizations (such as software developers) can install, execute, test, modify, and/or debug code on computing devices without needing to receive specific authorization from a trusted authority or other entity each time the code may be modified. For illustrative purposes, the present disclosure describes some embodiments related to software development for a mobile computing device or platform in which only signed applications and code are allowed to execute, such as a mobile telephone or other handheld device. However, one skilled in the art will recognize that embodiments of the present invention may be implemented on any type of computing device or platform. 
     In some embodiments, software developers may obtain development access to a computing device. For example, development access may include privileges or entitlements that allow software developers to modify code on specific devices, sign at least some of the code on a device as one of the authorized signers, and execute/test the code. For the convenience of the software developer, these devices may be a typical production device that they have purchased or been provided. 
     A software developer may request development access from one or more trusted authorities, such as a manufacturer of the devices, an operating system provider, etc. This request may be communicated in a variety of ways, such as an email, or over a network like the Internet. The request may be approved by a single trusted authority, by at least one of a plurality of trusted authorities, or a combination of several trusted authorities. 
     In order to enable developer access, a trusted authority may create a digital certificate that may be specific to the software developer and the devices and generate a profile that specifies the access rights of the developer on those devices. In addition, the digital certificate may enable the software developer to sign their applications or code so that it may execute on the device in accordance with their profile. Therefore, with developer access, the software developer may develop software on a device, even if the device will only execute signed code or applications. 
     In order to illustrate embodiments of the present invention,  FIGS. 1-9  will now be presented below.  FIG. 1  may be an overview of how software for computing devices can be developed on a developer computing device and eventually distributed.  FIGS. 2-3  illustrate further detail of a developer computing device and a developer access profile.  FIGS. 4-6  illustrate various components of the developer access profile, which may include one or more public keys of the developer, one or more device identifiers, and a set of entitlements that have been assigned to the developer.  FIGS. 7-9  are then provided to illustrate various process flows that are related to obtaining developer access profile and how code or applications on a developer computing device can be executed based on the developer&#39;s profile and signature. 
       FIG. 1  may be one example of a computing environment, which allows for the distribution of authorized software code to computing devices that are configured to execute only authorized code. As shown, the computing environment may include a set of computing devices  100 , a trusted authority  102 , and a software developer  104 . These entities will now be further described. 
     Computing devices  100  may be any number of different types of computing devices, including desktop computers, laptop computers, handheld computers, personal digital assistant (PDA) devices, mobile telephone devices, media player devices, and the like. For example, in some embodiments, computing devices may be an iPhone™, iPod™, or other device from Apple Computer Inc. Computing devices  100  may be configured to require that some or all of the code be authorized by trusted authority  102 . 
     For example, an operating system of computing device  100  may be configured to verify that all code has been authorized by trusted authority  102 . For example, operating systems, such as MacOS, Windows, Linux, Unix, and Symbian, can be configured to control execution of a code or applications based on whether it has been signed by an authorized entity. If the code is authorized and verified, it may be generally executed without any further system or user interaction; if the code has not been authorized, its ability to be executed on computing device  100  may be restricted. In some embodiments, the computing device may alert the user that the code may be not authorized and ask the user if they still wish to execute the unauthorized code. In other embodiments, computing devices  100  may be configured to prevent unauthorized code from being executed at all, regardless of the user&#39;s preference. 
     In some embodiments, trusted authority  102  may be any entity that has the authority to determine whether software, such as software  106 , can be executed on computing devices  100 . For example, trusted authority  102  may indicate its authorization of software by digitally signing it. As may be known in the art, a digital signature uses public key cryptography to help ensure the integrity of data. A digital signature can be used to identify the source of the data, and can be further used to detect any modifications to the data subsequent to the application of the digital signature. 
     Although  FIG. 1  shows a single trusted authority  102 , embodiments of the present invention may employ any number of trusted authorities alone or in combination. For example, each of several trusted authorities may have the unilateral authority to allow code to be executed on computing devices  100 . As another example, authorization from a combination of trusted authorities, such as both a manufacturer and an operating system provider, can be required. 
     Software developer  104  may be any entity that develops, distributes, tests, installs, etc. applications and code on computing devices  100 . In order to distribute its code to computing devices  100 , software developer  104  may provide trusted authority  102  with compiled object code in the form that it may be intended for distribution to computing devices  100 . During deployment of software from developer  104 , trusted authority  102  may digitally sign the object code of the software  106 , and can then make the code available to computing devices  100  with its digital signature. Subsequently, when a request to execute the software is made on computing device  100 , computing device  100  can check the digital signature of the software  106  to verify its authenticity and/or authorization. If the software can be verified as being signed by trusted authority  102 , software  106  is allowed to execute on computing device  100 . There are various well known ways for computing device  100  to check the digital signature of the software  106  prior to execution. 
     In order to develop software, software developer  104  may coordinate with trusted authority  102  to obtain access to one or more of computing devices  100  that allows it to develop software. Because software developer  104  may wish to test its software on deployed computing devices  100 , software developer  104  may obtain or purchase computing devices  100 . 
     However, during the software development process, the code in a software application may change frequently. In order to alleviate the need for trusted authority  102  to digitally sign code repeatedly, trusted authority  102  may instead provide a digital certificate and a developer access profile, which may be installed on computing devices  100 (D). With the digital certificate and access profile installed, computing devices  100 (D) may thus be converted into developer computing devices. 
     The developer access profile may allow software developer  104  to modify, recompile, and test their software on these developer computing devices  100 (D) without the need to request additional code signing services from trusted authority  102 . In particular, a developer access profile may be installed on developer computing devices  100 (D), which configures it to accept digital signatures from software developer  104  and execute code signed by software developer  104 . In some embodiments, developer computing devices  100 (D) may also, in addition to receiving developer access profiles, include development and test related software such as a debugging, tracing, or profiling software as part of a standard distribution installed on developer computing devices  100 , as part of a pre-provisioning process, or at any other time. In some embodiments, developer computing devices  100 (D) are pre-provisioned with such additional development related software. In other embodiments, development related software may be installed on the device with, or in conjunction with, the developer access profile. Further details of one embodiment of such a developer access profile and how it may be implemented on developer computing device  100 (D) will now be described with reference to  FIGS. 2 and 3  below. 
       FIG. 2  shows a block diagram providing one example of how the developer computing device  100 (D) may be configured to utilize developer access profiles to execute software signed by software developer  104 . As noted above, developer computer device  100 (D) may be the same type of device as computing devices  100  for which the software  106  created by software developer  104  may be intended. For example, if the software  106  can be developed to run on a certain mobile phone platform, computing devices  100  and  100 (D) may both operate on the same platform with the only difference being that the developer computing devices  100 (D) are utilized by software developer  104  (for testing and quality assurance purposes, for example), whereas the other computing devices  100  are used by end users. 
     Developer computing device  100 (D) may typically include an operating system  202 . The operating system may be well-known operating system such as MacOS, Windows, Linux, Unix, Symbian, or the like. As discussed briefly above, operating system  202  may be configured to require that some or all code executed on the device  100 (D) be authorized prior allowing it to be executed. In some embodiments, trusted authority  102  or software developer  104  may utilize a code signing certificate, which may be used to verify the source and integrity of the signed computer code. 
     The developer computing device  100 (D) may also include a device identifier  204 . The device identifier  204  may take various forms. In one embodiment, the device identifier may be a serial number that uniquely identifies the developer computing device  100 (D). In other embodiments, the device identifier may be a unique identifier generated by the operating system  202 . 
     Furthermore, the developer computing device  100 (D) can include software storage  206 . The software storage  206  may be a location on the device where software  106  may be stored for use by the operating system  202  of the device. The software storage  206  may take the form of volatile and/or non-volatile memory on the computing device. The software  106  may be stored temporarily in the device  100 (D) or permanently in the device  100 (D). 
     In some embodiments, on developer computing device  100 (D), digital signatures can be created by performing a hash function on the software in order to create a message digest, which may then be signed using a private key of software developers  104  or trusted authority  102 . A digital signature may include a digest that may be created, for example, by performing a hash function on the software in order to create a message digest. In some embodiments, incremental code signing may be used. The hash value may be a hash value generated for all or a particular portion of the software. For example, in some embodiments, the software is divided into one or more units such as one or more pages. A hash value is generated for each unit or page of the software. The digest for the software in such embodiments includes a hash value that is generated for an array or table of the hash values of each code or page. The message digest may be then encrypted using a private encryption key associated with trusted authority  102 . In one embodiment, the well known SHA-1 function may be used to generate the message digest. The encrypted message digest (also referred to as the signature) may be then appended to the one or more of the software modules  206 . Thus, when executing software code, the operating system  202  on developer computing device  100 (D) may process the request by verifying the source and integrity of the software code by validating the digital signature was signed by either trusted authority  102  or software developers  104  using the public keys of trusted authority  102  or software developers  104 . 
     In order to manage the developer access of software developer  104 , developer computing device  100 (D) may also have a developer access profile  208 . Profile  208  may be created by trusted authority  102 , which may then be installed on the developer computing devices  100 (D). Developer access profile  208  can be a set of data that permits execution of software signed by entities other than trusted authority  102 . In particular, developer access profile  208  can allow software developers  104  to modify and recompile source code for their software  106 , and then test the software  106  on the developer computing device  100 (D) without needing to request additional code signing services from trusted authority  102 . Instead, software developer  104  may be permitted to digitally sign their software  106 , and run the software on those developer computing devices  100 (D) which have developer access profiles  208  that specify that code signed by the developer  104  may be executed on the device  100 (D). In some embodiments developer access profile  208  may also specify certain operations that the developer  104  may perform in testing the software  106 . For example, developer access profile  208  may specify that software  106  digitally signed by the developer  104  may be debugged on the developer computing devices  100 (D) included in developer access profile  208 . Developer computing device  100 (D) may have more than one developer access profile  208  installed. 
     In some embodiments, developer access profile  208  may operate in conjunction with policy process  210 . Policy process  210  may take the form of a daemon process that is trusted by operating system  202 . Alternatively, policy process  210  may be a portion of the operating system kernel  202 . For example, access profile  208  may be a file having attribute/value pairs that are read by policy process  210 . 
     In some embodiments, policy process  210  may be installed on computing devices  100  along with developer access profile  208 . Alternatively, policy process  210  may be included with the device when originally shipped. In still other implementations, policy process  210  may be added to the device via an operating system update process as may be known in the art. 
     Policy process  210  may be typically used to enforce policies specified in developer access profile  208 . In certain embodiments, policy process  210  may be configured to detect code execution requests and determine whether the request should be permitted. For example, when a request to execute code is detected, policy process  210  may be configured to check the digital signature of the code to ensure that it is valid. If the digital signature is not from trusted authority  102 , policy process  210  may access the developer identifier data  302  of developer access profile  208  on the device  100 (D) to determine if the signature may be from any of software developers  104  authorized in the profile  208  to sign software  106 . 
     In some embodiments, if developer access profile  208  specifies that a developer can trace the operation of the software on the development device, but does not allow debugging, the policies process  210  will allow trace operations, but allow running applications in debug mode. 
       FIG. 3  shows a more detailed view of developer access profile  208 . As noted above, developer access profile  208  may be a set of data stored on device  100 (D). As shown, developer access profile  208  may include, among other things, device identifier data  302 , developer identifier data  304 , and entitlement data  306 . These items will now be further described. 
     Device identifier data  302  specifies one or more device identifiers  204  to which developer access profile  208  apply. For example, in embodiments where the devices  100  are mobile telephone devices, device identifier data  302  may include an array of mobile telephone device serial numbers. Developer access profile  208  may further include developer identifier data  304 , which specifies software developers  104  to whom developer access profile  208  applies. 
     Developer identifier data  304  may take various forms. In some embodiments, developer identifier data  304  may include a name or identifier of software developer  104  and one or more public keys associated with software developers  104  covered by developer access profile  208 . Other types of information may also be used. 
     Entitlement data  306  may include data, which indicates the types of operations that are allowed for software  106  signed by developers  104 . In general, entitlement data  306  may be highly granular and specify entitlements at a high level of specificity. In this manner, developer access profile  208  can be highly customized for each of software developers  104  and, if needed, for each of devices  100 (D).  FIGS. 4-6  will now be described to illustrate further detail regarding developer identifier data  304  and entitlement data  306 . 
       FIG. 4  shows a more detailed block diagram of the developer identifier data  304 . As discussed above, developer access profile  208  may specify more than one developer  104  as being authorized to digitally sign code. In the example provided in  FIG. 4 , four developer identifiers  402 (A)- 402 (D) are specified, with four different public keys stored in the developer identifier data  304 . In some embodiments, developer identifier data  304  may be stored in an array data structure stored within the developer access profile. Other types of data structures may also be used. 
       FIG. 5  shows a more detailed block diagram of the device identifier data  302 . Device identifier data  302  for a developer access profile  208  may include one or more device identifiers  204 . In the example provided in  FIG. 5 , four different device identifiers  204 (A)- 204 (D) (which are related to four different developer devices  100 (D)) are included in the profile  208 . Although the example provided includes specific device identifiers, in some embodiments, more generalized device identifying data may be utilized. For example, some device vendors and/or manufacturers may provide devices having device identifiers which are specific to an organization. For example, a device vendor and/or manufacturer may customize certain aspects of device identifiers  204  associated with devices based on the organization to which they are delivered. In these instances, the device identifier data  302  may include ranges of device identifiers, rather than listing each individual device identifier value. In still other embodiments, wild card characters may be used to specify that the developer access profile applies to all devices having specified identifier characteristics. In still other embodiments, the device identifier data could specify developer access profile  208  applies to all devices. In these instances, software signed by one or more of the developers identified in developer identifier data  302  could be authorized to run on any device  100  upon which developer access profile  208  may be installed. 
       FIG. 6  provides a more detailed view of an example of the types of data that may be included in entitlement data  306 . As discussed above, developer access profile  208  may specify the types of access that are permitted for applications signed by the developers  104 . On developer computing device  100 (D), software developers  104  may be required to be listed in developer identifier data  304  and may be limited to the entitlements described in entitlement data  306 . 
     Entitlement data  306  may take the form of predefined Boolean variables which are indicative of various entitlements. The example provided in  FIG. 6  shows four possible entitlements  602 (A)- 602 (D). 
     If entitlement  602 (A) is set to “TRUE”, code signed by developers  104  associated with developer access profile  208  are permitted to build their software  106  in a debug mode and then run the software  106  on the device  100 (D) in a debug mode. If the debug mode allowed entitlement  602 (A) is not set to “TRUE”, and the developer  104  attempts to run the software in debug mode on the device  100 (D), policy process  210  may be configured to not allow the execution of the code. 
     Trace allowed entitlement  602 (B) allows software  106  digitally signed by the developer  104  to be compiled and executed in trace mode on the devices  100 (D) covered by developer access profile  208 . Entitlement data  306  may further specify entitlements which relate to the degree and/or types of access that software  106  signed by the developer  104  may have to certain data stored in the file system on the device  100 (D). In some embodiments, these areas may include data that is typically off limits to applications. For example, in a mobile phone device, the address book data may include sensitive data that would not ordinarily be accessible by a third party application program, access to network connectivity of a mobile phone device may also be restricted. However, if software developer  104  wishes to develop an application that needs access to the address book data, an access address book data entitlement  602 (C) may be defined that allows this access. 
     Entitlement data  306  may also specify entitlements which relate to the degree and/or type of access to operating system application programming interfaces (APIs) that are available to the software  106 . For example, software developer  104  may wish to write a software application that plays multimedia files on computing device  100 (D) via calls to the multimedia API in the operating system. Operating system  202  on the device  100 (D) may be configured to not expose the multimedia API to applications unless signed by trusted authority  102 . In order to provide software developer  104  with an ability to test the software  106  on computing device  100 (D), an access to multimedia API entitlement  602 (D) may need to be provided, which exposes this API to the software  106 . 
     Various process flows for executing and developing code on computing device  100  will now be explained with reference to  FIGS. 7-9 . First,  FIG. 7  is presented to illustrate how computing device  100  generally verifies software that it executes.  FIG. 8  is then presented to illustrate the process of how software developer obtains developer access on a computing device. And finally,  FIG. 9  illustrates a general process of how a software developer can develop and execute code on a computing device with their developer access. These figures will now be described. 
     As noted,  FIG. 7  is a flowchart which provides an illustration of how a computing device  100  may be generally configured to verify software  106  prior to executing the software  106  on the device  100 . The process begins at block  702  where a request to execute software code may be received at the device. Typically, this request may be received in the operating system  202 , and the request includes a request to execute software code by a processor on computing device  100 . The request may be generated by a user launching an application program that may be stored in the application storage  206  of the computing device. 
     The process then moves to decision block  704 , where the computing device determines if the code has been digitally signed. If the code has not been digitally signed, the process moves to block  710  where the code may be not permitted to be executed on the device  100 . If, however, the code may be digitally signed, the process moves to decision block  706 , where the system authenticates and verifies the digital signature. In some embodiments, the verification and authentication may be provided by calculating a hash value (also called a message digest) for the digitally signed code and then decrypting the digital signature of the code using the public key of trusted authority  102  which purports to have signed the code. If the value of the message digest and the decrypted digital signature match, then the code may be verified and authenticated. If at decision block  706 , the code is not authenticated and/or verified, the process moves to block  710  and the code execution may be not permitted on the device  100 . If the code is authenticated and verified, the process instead moves to block  708 , where the device  100  may be allowed, typically by the operating system, to execute the signed code. 
       FIG. 8  may be a flowchart illustrating the general process by which third party software developers (such as software developer  104 ) are granted developer access to developer computing devices  100 (D) according to one or more embodiments described herein. The process may begin at block  802 , where software developer  104  recognizes a need for development access to a computing device  100 . As discussed above, in certain embodiments, the developer  104  writes software  106  intended to be executed on the device  100 . Device  100  may, however, require that some or all code executed on the device be digitally signed. 
     Having recognized a need for developer access to the device  100 , the process then moves to block  804 , with developer  104  sending to trusted authority  102  a request for development access. In some embodiments, this request may include identifiers  204  of computing devices  100 (D) for which the developer  104  desires developer access. As discussed above, the device identifiers  204  may take the form of device serial numbers or some other type of identifying data that may be specific to a particular device (or group of devices). In addition, software developer  104  may provide other information and data, such as identification of development personnel, an address, the types of access needed in their developer access, etc. 
     Next, at block  806 , trusted authority  102  generates a developer access profile  208  based on the device identifiers  204  sent by software developer  104 . In various embodiments, trusted authority  102  may implement one or more policies when generating developer access profile  208 . These policies may vary based on several factors that, for example, may include: the type of software being developed by software developer  104 ; one or more other parties that are related to the computing devices  100 , such as a telecommunications carrier or enterprise that owns computing devices  100 ; a geographic location of computing devices  100 (D); hardware, software, or firmware versions installed on computing devices  100 (D); and the like. In other words, developer access profile  208  may be highly specific to computing devices  100 (D) and software developer  104 . 
     In some embodiments, trusted authority  102  may also generate a developer identifier for software developer  104  making the request. This developer identifier may also be used for a digital certificate issued by trusted authority  102 . In some embodiments, trusted authority  102  may be a certificate authority, or may utilize another entity as the certificate authority. 
     The digital certificate may include information about software developer  104  as well as a public key of software developer  104  that may be signed using the private key of trusted authority  102  or a certificate authority. The digital certificate may also include other information and data, such as a validity period for the digital certificate, one or more revocation authorities, etc. 
     As discussed above, a generated developer access profile  208  may include device identifier data  302  in the form of device identifiers  204  for those devices which are covered by developer access profile  208 . The developer access profile also may include developer identifier data  304  as well as the digital certificate. Developer access profile  208  may also include various files and other information that indicates the specific privileges and entitlements that have been granted to software developer  104  on the specific devices identified. Once developer access profile  208  has been generated, it may be then sent by trusted authority  102  to software developer  104  at block  808 . 
     For example, software developer  104  may obtain the digital certificate and developer access profile  208  by accessing a server over a network (such as a secure website on the Internet), via encrypted communications (such as email or file transfer), via an integrated development environment, or via delivery of a computer readable medium (such as disk, flash memory, or optical disk). In addition, software developer  104  may obtain the digital certificate and developer access profile together or separately. 
     Upon receiving developer access profile  208 , software developer  104  may then store and install the digital certificate and developer access profile  208  on the devices  100 (D) which are specified in the profile  208 . For example, software developer  104  may employ an integrated developer environment application to install these items on computing devices  100 (D). Alternatively, trusted authority  102  (or some other authorized entity) may install or push these items onto computing devices  100 (D) on behalf of software developer  104 . For example, software developer  104  may couple or connect computing devices  100 (D) to a network or server. In response, after some preliminary authentication and other processing, the digital certificate and developer access profile  208  may be downloaded onto computing devices  100 (D). 
       FIG. 9  may be a flowchart illustrating one example of how a developer computing device  100 (D) handles executing digitally signed code according to developer access profile  208 . The process may begin at block  902  where operating system  202  receives a request to execute code on developer computing device  100 (D). Typically, this request may be generated by the user launching a software application. However it may also be a system process that it launched automatically without user input. Operating system  202  may be configured to check first if the code has been signed by trusted authority  102 , and if not, check if the code is within development access. 
     In particular, when the request to execute code has been received by operating system  202 , it may check if the code has been digitally signed at decision block  904 . If the code has not digitally signed, the process may jump to block  910 , and the code may be not permitted to execute on the device  100 (D). 
     If the code has been digitally signed, the process then moves to decision block  906 , where the system checks to determine whether the software code has been signed by a trusted authority  102  or software developer  104 . 
     As discussed above, in some embodiments, the digital signature of the code may be authenticated and verified by decrypting the digital signature into a message digest using a public key associated with trusted authority  102  or software developer  104 , and then validating the message digest against a message digest created by hashing the code itself. If the code has been verifiably signed by trusted authority  102  and has not been modified, in some instances, the process moves to block  916  and the code may be allowed to be executed. 
     If, however, at decision block  906  the code was not signed by trusted authority  102 , the process may move to decision block  908  where the system then checks to determine whether a developer access profile  208  is present on the device  100 (D). If no developer access profile  208  is present on the device  100 (D), the process moves to block  910 , and the requested code may be prevented from executing on the device  100 (D). 
     If, however, a developer access profile  208  is present on the device, the process then moves to decision block  912 . At decision block  912 , the system checks the code to determine whether it has been signed by software developer  104  listed in developer access profile  208  on the device  100 (D). If not, the execution process moves to block  910 , and execution of the requested code is blocked. 
     If the code has been digitally signed by software developer  104  having at least one of developer identifiers  402 , then the process may proceed to decision block  914 . At block  914 , operating system may check device access profile  208  to determine if the requested code execution is consistent with developer access profile  208 . For example, operating system  202  may check whether device identifier  502  is listed in the device identifier data  302  of profile  208 . Of course other checks may be performed regarding the requested code execution, such as APIs called, and may be permitted or blocked based on developer access profile  208 . 
     If device identifier  204  is not listed in profile  208 , then processing may return to block  910  and the code execution may be blocked. If, however, the device identifier  204  is listed in developer access profile  208 , then the process may move to block  916 , where the execution of the requested code may be permitted. 
       FIG. 10A  illustrates an example mobile device  1000 . The mobile device  1000  can be, for example, a handheld computer, a personal digital assistant, a cellular telephone, a network appliance, a camera, a smart phone, an enhanced general packet radio service (EGPRS) mobile phone, a network base station, a media player, a navigation device, an email device, a game console, or a combination of any two or more of these data processing devices or other data processing devices. 
     Mobile Device Overview 
     In some implementations, the mobile device  1000  includes a touch-sensitive display  1002 . The touch-sensitive display  1002  can be implemented with liquid crystal display (LCD) technology, light emitting polymer display (LPD) technology, or some other display technology. The touch sensitive display  1002  can be sensitive to haptic and/or tactile contact with a user. 
     In some implementations, the touch-sensitive display  1002  can comprise a multi-touch-sensitive display  1002 . A multi-touch-sensitive display  1002  can, for example, process multiple simultaneous touch points, including processing data related to the pressure, degree, and/or position of each touch point. Such processing facilitates gestures and interactions with multiple fingers, chording, and other interactions. Other touch-sensitive display technologies can also be used, e.g., a display in which contact is made using a stylus or other pointing device. Some examples of multi-touch-sensitive display technology are described in U.S. Pat. Nos. 6,323,846, 6,570,557, 6,677,932, and 6,888,536, each of which is incorporated by reference herein in its entirety. 
     In some implementations, the mobile device  1000  can display one or more graphical user interfaces on the touch-sensitive display  1002  for providing the user access to various system objects and for conveying information to the user. In some implementations, the graphical user interface can include one or more display objects  1004 ,  1006 . In the example shown, the display objects  1004 ,  1006 , are graphic representations of system objects. Some examples of system objects include device functions, applications, windows, files, alerts, events, or other identifiable system objects. 
     Example Mobile Device Functionality 
     In some implementations, the mobile device  1000  can implement multiple device functionalities, such as a telephony device, as indicated by a Phone object  1010 ; an e-mail device, as indicated by the Mail object  1012 ; a map devices, as indicated by the Maps object  1014 ; a Wi-Fi base station device (not shown); and a network video transmission and display device, as indicated by the Web Video object  1016 . In some implementations, particular display objects  1004 , e.g., the Phone object  1010 , the Mail object  1012 , the Maps object  1014 , and the Web Video object  1016 , can be displayed in a menu bar  1018 . In some implementations device functionalities can be accessed from a top-level graphical user interface, such as the graphical user interface illustrated in  FIG. 10A . Touching one of the objects  1010 ,  1012 ,  1014 , or  1016  can, for example, invoke a corresponding functionality. 
     In some implementations, the mobile device  1000  can implement a network distribution functionality. For example, the functionality can enable the user to take the mobile device  1000  and provide access to its associated network while traveling. In particular, the mobile device  1000  can extend Internet access (e.g., Wi-Fi) to other wireless devices in the vicinity. For example, mobile device  1000  can be configured as a base station for one or more devices. As such, mobile device  1000  can grant or deny network access to other wireless devices. 
     In some implementations, upon invocation of a device functionality, the graphical user interface of the mobile device  1000  changes, or is augmented or replaced with another user interface or user interface elements, to facilitate user access to particular functions associated with the corresponding device functionality. For example, in response to a user touching the Phone object  1010 , the graphical user interface of the touch-sensitive display  1002  may present display objects related to various phone functions; likewise, touching of the Mail object  1012  may cause the graphical user interface to present display objects related to various e-mail functions; touching the Maps object  1014  may cause the graphical user interface to present display objects related to various maps functions; and touching the Web Video object  1016  may cause the graphical user interface to present display objects related to various web video functions. 
     In some implementations, the top-level graphical user interface environment or state of  FIG. 10A  can be restored by pressing a button  1020  located near the bottom of the mobile device  1000 . In some implementations, each corresponding device functionality may have corresponding “home” display objects displayed on the touch-sensitive display  1002 , and the graphical user interface environment of  FIG. 10A  can be restored by pressing the “home” display object. 
     In some implementations, the top-level graphical user interface can include additional display objects  1006 , such as a short messaging service (SMS) object  1030 , a Calendar object  1032 , a Photos object  1034 , a Camera object  1036 , a Calculator object  1038 , a Stocks object  1040 , a Address Book object  1042 , a Media object  1044 , a Web object  1046 , a Video object  1048 , a Settings object  1050 , and a Notes object (not shown). Touching the SMS display object  1030  can, for example, invoke an SMS messaging environment and supporting functionality; likewise, each selection of a display object  1032 ,  1034 ,  1036 ,  1038 ,  1040 ,  1042 ,  1044 ,  1046 ,  1048 , and  1050  can invoke a corresponding object environment and functionality. 
     Additional and/or different display objects can also be displayed in the graphical user interface of  FIG. 10A . For example, if the device  1000  is functioning as a base station for other devices, one or more “connection” objects may appear in the graphical user interface to indicate the connection. In some implementations, the display objects  1006  can be configured by a user, e.g., a user may specify which display objects  1006  are displayed, and/or may download additional applications or other software that provides other functionalities and corresponding display objects. 
     In some implementations, the mobile device  1000  can include one or more input/output (I/O) devices and/or sensor devices. For example, a speaker  1060  and a microphone  1062  can be included to facilitate voice-enabled functionalities, such as phone and voice mail functions. In some implementations, an up/down button  1084  for volume control of the speaker  1060  and the microphone  1062  can be included. The mobile device  1000  can also include an on/off button  1082  for a ring indicator of incoming phone calls. In some implementations, a loud speaker  1064  can be included to facilitate hands-free voice functionalities, such as speaker phone functions. An audio jack  1066  can also be included for use of headphones and/or a microphone. 
     In some implementations, a proximity sensor  1068  can be included to facilitate the detection of the user positioning the mobile device  1000  proximate to the user&#39;s ear and, in response, to disengage the touch-sensitive display  1002  to prevent accidental function invocations. In some implementations, the touch-sensitive display  1002  can be turned off to conserve additional power when the mobile device  1000  is proximate to the user&#39;s ear. 
     Other sensors can also be used. For example, in some implementations, an ambient light sensor  1070  can be utilized to facilitate adjusting the brightness of the touch-sensitive display  1002 . In some implementations, an accelerometer  1072  can be utilized to detect movement of the mobile device  1000 , as indicated by the directional arrow  1074 . Accordingly, display objects and/or media can be presented according to a detected orientation, e.g., portrait or landscape. In some implementations, the mobile device  1000  may include circuitry and sensors for supporting a location determining capability, such as that provided by the global positioning system (GPS) or other positioning systems (e.g., systems using Wi-Fi access points, television signals, cellular grids, Uniform Resource Locators (URLs)). In some implementations, a positioning system (e.g., a GPS receiver) can be integrated into the mobile device  1000  or provided as a separate device that can be coupled to the mobile device  1000  through an interface (e.g., port device  1090 ) to provide access to location-based services. 
     In some implementations, a port device  1090 , e.g., a Universal Serial Bus (USB) port, or a docking port, or some other wired port connection, can be included. The port device  1090  can, for example, be utilized to establish a wired connection to other computing devices, such as other communication devices  1000 , network access devices, a personal computer, a printer, a display screen, or other processing devices capable of receiving and/or transmitting data. In some implementations, the port device  1090  allows the mobile device  1000  to synchronize with a host device using one or more protocols, such as, for example, the TCP/IP, HTTP, UDP and any other known protocol. 
     The mobile device  1000  can also include a camera lens and sensor  1080 . In some implementations, the camera lens and sensor  1080  can be located on the back surface of the mobile device  1000 . The camera can capture still images and/or video. 
     The mobile device  1000  can also include one or more wireless communication subsystems, such as an 802.11b/g communication device  1086 , and/or a Bluetooth™ communication device  1088 . Other communication protocols can also be supported, including other 802.x communication protocols (e.g., WiMax, Wi-Fi, 3G), code division multiple access (CDMA), global system for mobile communications (GSM), Enhanced Data GSM Environment (EDGE), etc. 
     Example Configurable Top-Level Graphical User Interface 
       FIG. 10B  illustrates another example of configurable top-level graphical user interface of device  1000 . The device  1000  can be configured to display a different set of display objects. 
     In some implementations, each of one or more system objects of device  1000  has a set of system object attributes associated with it; and one of the attributes determines whether a display object for the system object will be rendered in the top-level graphical user interface. This attribute can be set by the system automatically, or by a user through certain programs or system functionalities as described below.  FIG. 10B  shows an example of how the Notes object  1052  (not shown in  FIG. 10A ) is added to and the Web Video object  1016  is removed from the top graphical user interface of device  1000  (e.g. such as when the attributes of the Notes system object and the Web Video system object are modified). 
     Example Mobile Device Architecture 
       FIG. 11  is a block diagram  1100  of an example implementation of a mobile device (e.g., mobile device  1000 ). The mobile device can include a memory interface  1102 , one or more data processors, image processors and/or central processing units  1104 , and a peripherals interface  1106 . The memory interface  1102 , the one or more processors  1104  and/or the peripherals interface  1106  can be separate components or can be integrated in one or more integrated circuits. The various components in the mobile device can be coupled by one or more communication buses or signal lines. 
     Sensors, devices, and subsystems can be coupled to the peripherals interface  1106  to facilitate multiple functionalities. For example, a motion sensor  1110 , a light sensor  1112 , and a proximity sensor  1114  can be coupled to the peripherals interface  1106  to facilitate the orientation, lighting, and proximity functions described with respect to  FIG. 10A . Other sensors  1116  can also be connected to the peripherals interface  1106 , such as a positioning system (e.g., GPS receiver), a temperature sensor, a biometric sensor, or other sensing device, to facilitate related functionalities. 
     A camera subsystem  1120  and an optical sensor  1122 , e.g., a charged coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS) optical sensor, can be utilized to facilitate camera functions, such as recording photographs and video clips. 
     Communication functions can be facilitated through one or more wireless communication subsystems  1124 , which can include radio frequency receivers and transmitters and/or optical (e.g., infrared) receivers and transmitters. The specific design and implementation of the communication subsystem  1124  can depend on the communication network(s) over which the mobile device is intended to operate. For example, a mobile device can include communication subsystems  1124  designed to operate over a GSM network, a GPRS network, an EDGE network, a Wi-Fi or WiMax network, and a Bluetooth™ network. In particular, the wireless communication subsystems  1124  may include hosting protocols such that the mobile device may be configured as a base station for other wireless devices. 
     An audio subsystem  1126  can be coupled to a speaker  1128  and a microphone  1130  to facilitate voice-enabled functions, such as voice recognition, voice replication, digital recording, and telephony functions. 
     The I/O subsystem  1140  can include a touch screen controller  1142  and/or other input controller(s)  1144 . The touch-screen controller  1142  can be coupled to a touch screen  1146 . The touch screen  1146  and touch screen controller  1142  can, for example, detect contact and movement or break thereof using any of a plurality of touch sensitivity technologies, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with the touch screen  1146 . 
     The other input controller(s)  1144  can be coupled to other input/control devices  1148 , such as one or more buttons, rocker switches, thumb-wheel, infrared port, USB port, and/or a pointer device such as a stylus. The one or more buttons (not shown) can include an up/down button for volume control of the speaker  1128  and/or the microphone  1130 . 
     In one implementation, a pressing of the button for a first duration may disengage a lock of the touch screen  1146 ; and a pressing of the button for a second duration that is longer than the first duration may turn power to the mobile device on or off. The user may be able to customize a functionality of one or more of the buttons. The touch screen  1146  can, for example, also be used to implement virtual or soft buttons and/or a keyboard. 
     In some implementations, the mobile device can present recorded audio and/or video files, such as MP3, AAC, and MPEG files. In some implementations, the mobile device can include the functionality of an MP3 player, such as an iPod™. The mobile device may, therefore, include a 32-pin connector that is compatible with the iPod™. Other input/output and control devices can also be used. 
     The memory interface  1102  can be coupled to memory  1150 . The memory  1150  can include high-speed random access memory and/or non-volatile memory, such as one or more magnetic disk storage devices, one or more optical storage devices, and/or flash memory (e.g., NAND, NOR). The memory  1150  can store an operating system  1152 , such as Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS, or an embedded operating system such as VxWorks. The operating system  1152  may include instructions for handling basic system services and for performing hardware dependent tasks. In some implementations, the operating system  1152  can be a kernel (e.g., UNIX kernel). 
     The memory  1150  may also store communication instructions  1154  to facilitate communicating with one or more additional devices, one or more computers and/or one or more servers. The memory  1150  may include graphical user interface instructions  1156  to facilitate graphic user interface processing; sensor processing instructions  1158  to facilitate sensor-related processing and functions; phone instructions  1160  to facilitate phone-related processes and functions; electronic messaging instructions  1162  to facilitate electronic-messaging related processes and functions; web browsing instructions  1164  to facilitate web browsing-related processes and functions; media processing instructions  1166  to facilitate media processing-related processes and functions; GPS/Navigation instructions  1168  to facilitate GPS and navigation-related processes and instructions; camera instructions  1170  to facilitate camera-related processes and functions; and/or other software instructions  1172  to facilitate other processes and functions, e.g., access control management functions. The memory  1150  may also store other software instructions (not shown), such as web video instructions to facilitate web video-related processes and functions; and/or web shopping instructions to facilitate web shopping-related processes and functions. In some implementations, the media processing instructions  1166  are divided into audio processing instructions and video processing instructions to facilitate audio processing-related processes and functions and video processing-related processes and functions, respectively. An activation record and International Mobile Equipment Identity (IMEI)  1174  or similar hardware identifier can also be stored in memory  1150 . 
     Each of the above identified instructions and applications can correspond to a set of instructions for performing one or more functions described above. These instructions need not be implemented as separate software programs, procedures, or modules. The memory  1150  can include additional instructions or fewer instructions. Furthermore, various functions of the mobile device may be implemented in hardware and/or in software, including in one or more signal processing and/or application specific integrated circuits. 
     It will be understood by those of skill in the art that numerous and various modifications can be made without departing from the spirit of the present invention. Therefore, it should be clearly understood that the forms of the invention are illustrative only and are not intended to limit the scope of the invention. While the above detailed description has shown, described, and pointed out novel features of the invention as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the device or process illustrated may be made by those skilled in the art without departing from the spirit of the invention.