Method and system for registration of dynamically created packed applications

Abstract

The invention relates to a method and system for registering dynamically created packed applications with an operating system. The dynamically created packed application may not include a way to authenticate the packed application, but may declare slave attributes to the host package. The host packet may include a validated signature and be registered with an operating system. The host package may include a host runtime that references an executable file included in the host package. The packed application may not include an executable file, but may reference host runtime. The operating system may register the packed application based in part on its slave attributes to the host package. When the packed application is activated, the packed application may invoke the host runtime and executable file, but use the application identification of the packed application to do so. The application identification may be different from a host runtime identification at the host runtime.

Description

[0001] Explanation of Divisional Application This application is a divisional application of application number 202080070010.6, filed on August 18, 2020, entitled "Method and System for Registering Dynamically Created Packaged Applications". Background Technology

[0002] A Progressive Web App (PWA) is a type of application delivered over the internet. One goal of PWAs is to help developers build cross-platform applications, potentially more easily than using native applications. PWAs can be built using languages ​​associated with websites. Such languages ​​can include Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript. PWAs can run on any platform or operating system using a standard-compliant browser.

[0003] Progressive web apps can have features—such as offline access, push notifications, home screen installation, and device hardware access—that allow users to experience the app much like they would a native app. Progressive web apps can be used on any type of device (desktop, mobile, or tablet) and do not require re-downloading of content upon initial loading. A progressive web app can be considered a type of web page. Therefore, developers do not need to distribute progressive web apps through platform-specific stores or controlled distribution channels. Summary of the Invention

[0004] According to one aspect of this disclosure, a computer-readable medium is disclosed. The computer-readable medium includes instructions executable by one or more processors to cause a computing system to receive a request to register a client package. The client package is unsigned and specifies subordination to a host package. The host package is signed and includes an executable file. The host package registers with an operating system. The host package has access to the functions of the operating system. The computer-readable medium also includes instructions executable by one or more processors to register the client package with the operating system. The computer-readable medium further includes instructions executable by one or more processors to receive a request to activate an application included in the client package, and, upon receiving the request, to cause execution of the executable file. The computer-readable medium also includes instructions executable by one or more processors to grant the application access to the functions of the operating system.

[0005] An application can have an application identifier, and the execution of an executable file can be accomplished using that application identifier.

[0006] The application identifier may not conflict with the host identifier of the host packet.

[0007] The computer-readable medium may also include additional instructions executable by one or more processors to enable a computing system to use application identifiers to track the activity of the application and the executable after execution of the executable.

[0008] The client package may include an unsigned tag, and this unsigned tag is required for the operating system to register the unsigned package.

[0009] The computer-readable medium may also include additional instructions executable by one or more processors to cause the computing system to receive a second request from the application for access to a second function of the operating system. The host packet may not have access to the second function. The computer-readable medium may also include additional instructions executable by one or more processors to deny the application access to the second function.

[0010] The computer-readable medium may also include additional instructions executable by one or more processors to cause the computing system to unload the host package from the operating system. The computer-readable medium may also include additional instructions executable by one or more processors to cause the computing system to unload the client package after unloading the host package.

[0011] The client package can be created by a second application included in the host package.

[0012] The host package may include host capabilities, and these host capabilities are required for the operating system to register the client package.

[0013] Client packages can be created by developers or system administrators after the host package has been signed.

[0014] The computer-readable medium may also include additional instructions executable by one or more processors to enable a computing system to determine that the host package meets a standard. This standard may be included in a dependency specified in the client package.

[0015] The client package may not contain an executable file or references to binaries or classes outside the host package.

[0016] According to another aspect of this disclosure, a computer-readable medium is disclosed. The computer-readable medium may include instructions executable by one or more processors to cause a computing system, upon activation of an application, to request execution of an executable file having an application identifier of the application. The executable file is included in a host package, and the application is included in a client package. The host package is signed and includes a host identifier. The host package registers with an operating system and includes the ability to access functions of the operating system. The client package is unsigned and declares subordination to the host package. The application identifier is distinct from the host identifier. The computer-readable medium may also include instructions executable by one or more processors to cause the computing system to receive access to functions of the operating system during runtime of the application.

[0017] The computer-readable medium may also include additional instructions executable by one or more processors to cause the computing system to request registration of the client package with the operating system. The host package may include host capabilities. These host capabilities are required to register the client package with the operating system.

[0018] The client package may include an unsigned tag. This unsigned tag is required to register the client package with the operating system.

[0019] Computer-readable media may also include additional instructions executable by one or more processors to prevent the computing system from receiving secondary functionality of the operating system. The host package may not have access to secondary functionality of the operating system.

[0020] The host package can cause the client package to be unloaded.

[0021] According to another aspect of this disclosure, a computer-readable medium is disclosed. The computer-readable medium includes instructions executable by one or more processors to cause a computing system to receive a request to activate a client application. The client application does not include a signature used by the operating system to verify the authenticity of the client application. The client application has a client identifier. The client application declares subordination to a host application. The host application includes a signature used by the operating system to verify the authenticity of the host application, and the host application has a host identifier different from the client identifier. The computer-readable medium also includes instructions executable by one or more processors to cause the computing system, upon receiving the request, to activate the host application under the client identifier. The computer-readable medium also includes instructions executable by one or more processors to cause the computing system to grant the client application access to functions of the operating system. The host application may have access to those functions.

[0022] The computer-readable medium may also include additional instructions executable by one or more processors to cause the computing system to deny client applications access to secondary functions of the operating system. The host application may not have access to these secondary functions.

[0023] The client application can be generated by the main application after the host application has been signed.

[0024] This summary is provided to introduce a set of concepts in a simplified form, which will be further described in the detailed embodiments below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0025] Other features and advantages will be set forth in the description below. The features and advantages of the invention can be realized and obtained by means of the systems and methods particularly pointed out in the appended claims. The features of this disclosure will become more apparent from the following description and the appended claims, or may be learned by practice of the subject matter disclosed below. Attached Figure Description

[0026] To describe in detail the manner in which the foregoing and other features of this disclosure can be obtained, a more specific description will be provided with reference to the specific embodiments shown in the accompanying drawings. For better understanding, the same reference numerals denote the same elements throughout the various drawings. It should be understood that the drawings depict some exemplary embodiments, and the embodiments will be described and explained with additional specificity and detail using the drawings, wherein:

[0027] Figure 1 An example system for registering unsigned client packages according to this disclosure is shown.

[0028] Figure 2 An example client package according to this disclosure is shown.

[0029] Figure 3 An example host package according to this disclosure is shown.

[0030] Figure 4 An example system for generating and registering client packages according to this disclosure is shown.

[0031] Figure 5 An example method for registering a client package with an operating system, according to this disclosure, is shown.

[0032] Figure 6 An example method for processing requests to register unsigned packages, according to this disclosure, is shown.

[0033] Figure 7 An example method for processing requests for access functions according to this disclosure is shown.

[0034] Figure 8 An example method for accessing operating system functions according to this disclosure is shown.

[0035] Figure 9 An example method for generating a client package according to this disclosure is shown.

[0036] Figure 10 This shows some components that can be included in a computing system. Detailed Implementation

[0037] The operating system can control what packages (which can contain zero or more applications) are registered with it and which applications are allowed to run on the system. Registering packages with the operating system can include logging information about the packages and can be a way for the operating system to track what programs and executables are on the system and what they are doing. Applications not associated with registered packages can be prevented from running on the system. Once a package is registered with the system, the operating system can grant the applications included in the package access to certain system functions. System functions can include providing notifications to users, accessing system applications (such as the photo library), or accessing device hardware components (such as the camera). Granting applications access to operating system functions can enrich application functionality and improve the user experience of the applications and the operating system or platform on which they run. However, at the same time, allowing applications to run on the system and granting them access to operating system functions can create security problems. Giving applications access to the system can create the potential for applications to harm the system.

[0038] One way a system attempts to protect itself from malicious programs and file attacks is through signing. Signing is a method used to verify that a package is authentic (as it claims to be or from a trusted source) and has integrity (has not been altered). Signing can involve using two keys or certificates. Certificates can be created by the operating system or platform developer. The first certificate can be a private certificate that is not publicly shared. The operating system developer may receive a package from a third-party developer and, after evaluating the package, sign it using the private certificate. Alternatively, the operating system developer may share the private certificate with a trusted third-party developer, who can then use the private certificate to sign their packages. The second certificate can be publicly available and can be distributed on machines running the operating system developed by the operating system developer. Before installing the package, the operating system can use the public certificate to verify the package's authenticity. If the package has been modified after being signed with the private certificate, the public key will not be used to verify its authenticity. Signing provides a mechanism for verifying the authenticity and integrity of a package before it is installed on the system and granted access to the operating system's functions.

[0039] While signing improves security, it presents challenges when working with dynamically created content, such as content generated while the system is running. As mentioned above, signing requires a certificate that must remain private and cannot be present on the runtime machine. But consider a scenario where a signed application running on the machine generates a new application package during runtime. For example, consider an internet browser running on the machine generating an application package based on a website accessible via the internet. The internet browser can generate the application package to allow users to experience the website without needing to use an internet browser or be connected to the internet. However, obtaining a signature for the new application package requires sharing that application package with someone who owns the private certificate of the signed application. This significantly delays user access to the new application.

[0040] One way to provide dynamically created packaged applications with access to system and operating system functions without requiring signatures (while still protecting the system) is through the use of host packages. A host package can be a trusted package acting as a gateway, through which client packages (which can be dynamically created) can register with the operating system and gain access to operating system functions. Both host and client packages can possess certain characteristics that facilitate the use of dynamically created packaged applications while still protecting the system.

[0041] Because client packages can be dynamically created, they may not include a signature. The lack of a signature can mean the operating system lacks a way to verify the client package's identity. Therefore, the operating system can require the client package to declare a dependency on the host package. This dependency can be used to link the client package to the host package. The dependency can also include criteria. Criteria can include the host package's name and minimum version. Criteria can include other defined characteristics. For example, a host package can be identified by its name, version, publisher / author, resource (language, region, etc.), bitness, or architecture or central processing unit support. Criteria can require the host package's content to be encrypted, compressed, or physically residing on a specific volume or device. Criteria can require the host package to have certain claimed capabilities, specific functionality, or include specific keys, tags, or identifiers. If the host package identified in the dependency does not contain a certified signature, is not registered with the operating system, or does not meet the criteria included in the dependency, the operating system can refuse to install the client package or allow any of its applications to run on the system. In this way, the operating system at least knows that the gateway through which the client package will access the system is legitimate.

[0042] The operating system may allow client packages to include content files, but may not allow those content files to include any executable files. Alternatively, the client package may not be allowed to reference or execute any executable files contained within it. The operating system may also require that client packages not contain extensions that reference binaries or classes other than those included in the host package. These restrictions can mitigate some security issues related to allowing unsigned packages on the system. The operating system may require applications in the client package to reference the host runtime contained in the host package. Applications can use the host runtime identifier of the host runtime to reference the host runtime. The host runtime in the host package may include activation information. When an application invokes the host runtime, the activation information can tell the operating system what to do. The activation information may include a reference to an executable included in the host package. When an application in the client package is activated, the operating system can use the activation information contained in the host runtime and invoke the executable of the host runtime. The executable can then use the content files of the client package. In this way, the client package acts as an extension of the host package. The client package may include new content, but is limited to using executables included in the host package.

[0043] Once registered with the operating system, a host package can receive access to certain operating system functions. The capabilities included in a host package determine what functions the host package can access. The operating system can require user consent before an application included in the host package can use those capabilities. For example, if a host package includes the ability to access a device's camera, the operating system can require user consent to grant that application access when it attempts to access the camera. A host package can also have a specific trust level with respect to the operating system. The trust level indicates the level of access the host package has to operating system functions. Operating system developers can control what capabilities third-party developers can include in host packages. The capabilities and trust level of a host package can be applied to and restrict any client packages subordinate to it. For example, the operating system can deny a client package access to functions that the host package cannot access. Furthermore, client packages may not be able to override restrictions imposed by the host package.

[0044] Each client package and any application within it can have a unique identifier, unlike other entities and objects on the system. Furthermore, when an application in a client package is activated, it can cause the operating system to invoke the executable file in the host package, but using the application's identifier. Therefore, even if an application included in a client package uses an executable file included in the host package, the operating system can track the activity of applications included in the client package separately from the host package and its applications.

[0045] A host package may include granting it host capabilities to client packages subordinate to it. The operating system may refuse to register client packages subordinate to packages that do not possess host capabilities. Alternatively, the operating system may register client packages subordinate to packages that do not possess host capabilities, provided the package has a specific trust level with the operating system. Operating system developers can control which developers receive access to host capabilities and trust levels that allow host packages to have subordinate client packages. Therefore, customizing capabilities and trust levels provides a mechanism to protect the operating system while opening the door to dynamically created content for gaining access to the system.

[0046] Client packages can include unsigned tags. Unsigned tags indicate that the client package does not include a signature. The operating system can refuse to install unsigned packages that do not include unsigned tags. Operating system developers can control access to unsigned tags. In this way, operating system developers can restrict who and what can create unsigned packages that can gain access to the system.

[0047] The operating system may require the host package to unload all client packages belonging to it. The operating system may also require that, when unloading the host package, all client packages belonging to it be unloaded. Furthermore, the operating system may require the host package to clean up the artifacts of the client packages during the unloading process.

[0048] The use of host and client packages described in this article facilitates the use of dynamically created applications in a way that still protects the system from harmful packages and files. The operating system delegates certain powers and responsibilities for protecting system metrics to the host package. However, it can only do so if the host and client packages meet certain criteria. The host package can also handle remediation for misbehaving client packages. Even if a client package does not need to be signed, it must still be subordinate to an authorized host package and may be limited to the functionality of the host package.

[0049] Figure 1 An example of a system 100 in which the techniques disclosed herein can be utilized is shown. According to this disclosure, system 100 may include device 102, which includes client package 110 and host package 140. Device 102 may be any type of computing device or system. For example, device 102 may be a desktop computer, a mobile phone, or a distributed computing system consisting of multiple nodes. The device may have one or more users. Device 102 may be managed by a system administrator. Device 102 may also include operating system 170.

[0050] Client package 110 may be a collection of files and data created for installation on a computing device such as device 102. Client package 110 may have been generated during operation of device 102. Client package 110 may have been generated by host package 140 or operating system 170. Alternatively, client package 110 may be generated by a developer (who may be the same or different from the developer of host package 140). The developer may have generated client package 110 after generating host package 140. Alternatively, client package 110 may be generated by a system administrator. The system administrator may be a person with some level of administrative control or access to device 102. Alternatively, client package may have been generated by a user of device 102. The system administrator or user may have generated client package 110 after host package 140 was generated and after host package 140 was installed on device 102.

[0051] Client package 110 may include client manifest 112, content file 128, and application 120. Client package 110 may not include a signature or any other object that would allow operating system 170 to authenticate client package 110. Client package 110 may not include any executable file. Although Figure 1 The client package 110 shown only includes application 120, but other client packages may include multiple applications.

[0052] While client package 110 may not include a signature, dynamically created client packages may include a signature or authentication object. For example, an application included in a host package may dynamically create a client package, request temporary access to a private certificate for signing the client package, and then install the client package as a signed package. The application may require the user to insert a USB flash drive key containing the private certificate. The application may require the user to provide a certificate to access a remote machine containing the private certificate. The user may authorize their phone or mobile device to provide the private certificate.

[0053] Client manifest 112 may include metadata about client package 110 and information contained in client package 110. Client manifest 112 may describe application 120. Operating system 170 or its developer may specify the types of information that should or may be included in client manifest 112. Operating system 170 or its developer may specify the format of the information included in client manifest 112. Operating system 170 may use client manifest 112 and the information contained in client manifest 112 to determine whether to install client package 110, and to use client manifest 112 and the information contained in client manifest 112 during the installation of client package 110. When application 120 is activated, operating system 170 may use client manifest 112 or the information contained in client manifest 112.

[0054] Client listing 112 may include a dependent attribute 116. Dependent attribute 116 may indicate the delimited package (such as host package 140) to which client listing 112 belongs. Dependent attribute 116 may include sufficient information about host package 140 to allow operating system 170 to determine whether the package is the host package 140 indicated in dependent attribute 116. Client package 110 may belong to host package 140 for the purpose of registering with operating system 170. Client package 110 may also belong to host package 140 for accessing one or more executable files. Dependent attribute 116 may identify host package 140.

[0055] Although client list 112 only includes attribute 116, in other designs, the client list may include multiple attributes. In cases involving multiple attributes, operating system 170 may first determine if there exists a package registered with operating system 170 that satisfies the attributes listed first. If not, operating system 170 may proceed to the attributes listed second. Operating system 170 may continue until the attributes are satisfied or operating system 170 has exhausted all attributes included in the client list.

[0056] In some designs, the client manifest of a client package may not include dependent attributes. In these cases, the client package may not have access to the functionality and capabilities of the host package.

[0057] Application 120 may describe, reference, or include a collection of files and information that work together for a specific purpose or to perform certain functions, tasks, or activities. Application 120 may include an application identifier that uniquely identifies application 120. Application 120 may not include or reference the executable included in client package 110. Instead, application 120 may include a reference to host runtime 154 included in host package 140. The reference to host runtime 154 can be used when application 120 is activated. This reference may indicate that operating system 170 should invoke host runtime 154 when application 120 is activated. Application 120 may indicate that operating system 170 should use the application identifier to invoke host runtime 154 when application 120 is activated.

[0058] Application 120 may reference content file 128. Content file 128 can be used during the runtime of application 120. Therefore, host runtime 154 and any executables referenced in host runtime 154 can use content file 128 contained in application 120. For example, host runtime 154 can use content file 128 to create a user interface. Such a user interface may differ from the application created using content contained in host package 140.

[0059] Host package 140 may be a collection of files and data created for distribution to and installation on a computing device such as device 102. Host package 140 may have been generated by a developer (who may be the same as or different from the developer of operating system 170). Host package 140 may include zero or more applications. An application may be a collection of files and information that work together for a specific purpose or to perform certain functions, tasks, or activities.

[0060] Host package 140 may include metadata files and content files. The metadata file may include information about host package 140, its identifier, contents, and functionality. The metadata file may include bookkeeping files. Operating system 170 can use the metadata file to understand what is included in host package 140 and what to do with host package 140 when it is installed and applications included in host package 140 are activated. The content files in host package 140 can be used during the runtime of applications included in host package 140.

[0061] Host package 140 may include host manifest 146. Host package 140 may include only a single manifest, such as host manifest 146. Host manifest 146 may include metadata about host package 140 and the information and files contained in host package 140. Host manifest 146 may describe zero or more applications. Host manifest 146 may include host runtime 154. Host runtime 154 may be accessed by packages other than host package 140 and by applications other than those included in host package 140.

[0062] Host runtime 154 may include activation information. The activation information may reference an executable file. When host runtime 154 is invoked, operating system 170 can use the activation information. Therefore, when host runtime 154 is invoked, operating system 170 can run the executable file. Host runtime 154 may include a host runtime identifier that uniquely identifies host runtime 154. Application 120 included in client package 110 may reference the host runtime identifier so that operating system 170 invokes host runtime 154 when application 120 is activated.

[0063] Host list 146 may indicate that host package 140 or host runtime 154 has certain capabilities. These capabilities may include access to certain functions of operating system 170, such as function 174a and function 174b.

[0064] Host packet 140 may include signature 142. The developer of host packet 140 may have generated signature 142 after creating host packet 140 but before distributing it to device 102 (this may also be referred to as signing host packet 140). Signature 142 may have been created using a key or certificate. The key or certificate used to create signature 142 may be a private key or certificate. The operating system developer may have already generated the private key. The operating system developer may share the key or certificate used to sign host packet 140 only with trusted developers. Furthermore, the key or certificate used to sign the host packet may not reside on device 102. Signature 142 can be created by providing host packet 140 and the private key to the signing algorithm. Operating system 170 can use signature 142 to verify the authenticity and integrity of host packet 140. Operating system 170 may have a public key that verifies that signature 142 was generated using the private key and that host packet 140 has not been modified since it was signed.

[0065] Operating system 170 may be a program or platform that manages hardware (such as hardware component 104) and software on a computing device such as device 102. Operating system 170 may include registry 172. Operating system 170 may use the registry to track and manage packages, applications, and processes on device 102. When operating system 170 installs a package or application on device 102, operating system 170 may place information about the package or application in registry 172. Operating system 170 may not invoke or execute applications that have not been registered with operating system 170 or whose associated packages have not been registered with operating system 170.

[0066] Operating system 170 may include verification module 176. Verification module 176 may allow operating system 170 to verify the authenticity of a packet's claim. Verification module 176 may use a signature (such as signature 142) included in the packet to determine that the packet is authentic. Verification module 176 may include a public key or certificate. Verification module 176 may include a signature verification algorithm that receives a packet (such as host packet 140), a public key, and a signature (such as signature 142), and determines whether the packet is authentic.

[0067] Operating system 170 can receive requests to install packages. Installing a package may include an index, stages, and registration. The index may include operating system 170 analyzing a list of packages and recording information about them. Stages may include operating system 170 creating a directory for the package's contents, placing the package's contents in that directory, and recording the location of that directory. Registration may include operating system 170 associating the package with a specific user. Registering a package can also more broadly refer to the process by which operating system 170 learns about the package's attributes and records those attributes. Registering a package can also refer to operating system 170 verifying the package and allowing the packages and applications included in it to exist and run on the system. Operating system 170 can receive requests to register client package 110 from client package 110. Alternatively, operating system 170 can receive requests to register client package 110 from host package 140. Operating system 170 may refuse to invoke or run applications and files not associated with the registered package.

[0068] Operating system 170 may refuse to register a package that does not include a verifiable signature, unless operating system 170 can register an unsigned package that indicates a dependency on a registered package that includes a verifiable signature. For example, suppose client package 110's dependency 116 indicates that client package 110 is dependent on host package 140. Further suppose host package 140 has not yet registered with operating system 170. In this case, operating system 170 may refuse the request to register client package 110 with operating system 170. Alternatively, suppose host package 140 registers with operating system 170, and operating system 170 verifies signature 142 (which may be part of the process of registering host package 140). In this case, operating system 170 can register client package 110. Operating system 170 may also require that the identifier of client package 110 does not conflict with the identifier of host package 140 in order to register client package 110. Operating system 170 may also require that the application identifier of application 120 and the identifier of host runtime 154 do not conflict in order to register client package 110.

[0069] If the user confirms that they want to install an unsigned package, operating system 170 can also register the unsigned package. The user can respond to a prompt created when the user requests to install an unsigned package to indicate that they want to install it. The user can also indicate that they want to install an unsigned package by changing system settings that allow the installation of unsigned packages. Before installing an unsigned package, operating system 170 may require user authentication. For example, operating system 170 may require the user to enter a password or perform two-factor authentication.

[0070] Operating system 170 can uninstall packages. Uninstalling packages can include a list of unregistered packages. For example, uninstalling client package 110 can include unregistering client package 110 from registry 172. Uninstalling host package 140 can cause operating system 170 to also uninstall client package 110. When operating system 170 only uninstalls client package 110, it can instruct host package 140 to remove any artifacts from client package 110.

[0071] Operating system 170 may include function 174. Calling one or more functions 174 may allow an application to access certain capabilities or functions of device 102. For example, function 174 may allow an application to access hardware component 104a (which may be a camera) or hardware component 104b (which may be a microphone) of device 102. Calling function 174 may also allow an application to access or modify files existing outside of the application or its associated packages. For example, function 174 may allow an application to access a photo library stored on device 102, or to place an icon on the home screen of device 102. Function 174 may also allow an application to access the memory of device 102 or other applications.

[0072] Operating system 170 may receive a request to access a function (such as function 174a) within function 174. If the requesting application does not have the capability to grant access to function 174a (or the application's associated package does not have the capability), operating system 170 may deny the request. Conversely, if the requesting application (or its associated package) has the capability to grant access to function 174a, operating system 170 may grant the request. For example, suppose host package 140 includes the capability to grant host package 140 access to function 174a, but host package 140 does not include the capability to grant host package 140 access to function 174c. If an application included in host package 140 requests access to function 174a, operating system 170 may grant the application access to function 174a. However, if an application included in host package 140 requests access to function 174c, operating system 170 may deny the application access to function 174c.

[0073] Operating system 170 can receive a request to access function 174a from client packet 110. Operating system 170 can use rules to determine whether client packet 110 can access function 174a. One possible rule is that operating system 170 can require each of client packet 110 and host packet 140 to include the capability for function 174a so that application 120 can access function 174a (intersection rule). Another possible rule is that if either host packet 140 or client packet 110 includes the capability for function 174a (combination rule), then operating system 170 can grant either client packet 110 or application 120 access to function 174a. Yet another possible rule is that operating system 170 can allow host packet 140 to determine whether client packet 110 or application 120 can access function 174a (host-restricted rule). Another possible rule is that operating system 170 may grant client package 110 access to function 174a as long as client package 110 includes the capability for function 174a, regardless of whether host package 140 includes that capability (client declaration rule). These rules do not have to be mutually exclusive. For example, host package 140 may include multiple sets of capabilities. Host package 140 may include a first set of capabilities used when an application included in host package 140 is running with an identity included in host package 140, a second set of capabilities required by client package 110 when an application included in host package 140 is running with an identity included in client package 110, and a third set of capabilities that may optionally be available to client package 110 when an application included in host package 140 is running with an identity included in client package 110. The third set of capabilities may include fast capabilities, or may allow client package 110 to declare capabilities not declared in host package 140.

[0074] System 100 may include a remote device 180. Remote device 180 may be physically separate from device 102. Remote device 180 may include a file 182. File 182 may include an executable file and content files. Remote device 180 may be connected to a network 184. Device 102 may be connected to network 184 and can access file 182 on remote device 180 via network 184. Host runtime 154 or an executable file referenced by host runtime 154 may include instructions for accessing file 182 during runtime. In this way, application 120 included in client package 110 can invoke a program stored on remote device 180. For example, remote device 180 may include a word processing program, and host runtime 154 or an executable file referenced by host runtime 154 may include instructions for invoking a word processing program stored on remote device 180. Activating application 120 included in client package 110 can invoke a word processing program included on remote device 180.

[0075] Figure 2 An example of client package 210 according to this disclosure is shown.

[0076] Client package 210 may be a collection of files and data intended to be installed on a computing device, such as a cellular phone, desktop computer, or access terminal. Client package 210 may not include executable files or extensions that reference binary or class files other than those contained in the host package to which the client package belongs. Client package 210 may be generated at runtime on the computing device, such as by an application on the computing device. In this way, client package 210 can be generated dynamically. Client package 210 may also be generated by a developer, system administrator, user, or operating system.

[0077] Client package 210 may include content file 228. Content file 228 may be any type of file other than an executable file that a computing device can process. Executable files may include dynamic link library files. Content file 228 may include images (such as JPG and TIFF), sound files (such as MP3 files), video files, data files, text files, HTML files, scripts, and documents. Content file 228 may be used by an application or executable file. For example, an application or executable file may use content file 228 to create a user interface.

[0078] Client package 210 may include client manifest 212. Client manifest 212 may be a metadata file containing information about client package 210 and the files included in client package 210. The type and format of the information included in client manifest 212 may be specified by the operating system or platform or the developer of the operating system or platform.

[0079] Client list 212 may include client identifier 214. Client identifier 214 may be information that the operating system can use to identify and track client package 210. Client identifier 214 may include name, publisher, and version. Client identifier 214 may include object identifier (OID). Object identifier may be a unique name for client package 210. Client identifier 214 may be unique compared to other OIDs of objects and entities associated with or installed on the device on which client package 210 is located. The operating system can use client identifier 214 to track and manage client package 210 and any applications associated with client package 210.

[0080] Client list 212 may include a dependent attribute 216. Dependent attribute 216 may specify the package or application to which client package 210 belongs or depends. Dependent attribute 216 may use the package's OID or other information about the package to specify the package. The package to which client package 210 belongs may be referred to as the host package. Dependent attribute 216 may include a standard 232. Standard 232 may describe the requirements that the package or application must meet so that the operating system resolves dependent attribute 216 and installs client package 210 on the device. For example, dependent attribute 216 may designate a specific package as the host package of client package 210. Standard 232 may specify the minimum version of the host package that client package 210 is willing to accept or is compatible with.

[0081] Client manifest 212 may include an unsigned flag 226. The unsigned flag 226 may be a string. The unsigned flag 226 may indicate that client package 210 is unsigned. The operating system may refuse to install unsigned packages, such as client package 210, that do not include the unsigned flag 226. The operating system or its developers may define the value of the unsigned flag 226.

[0082] Client manifest 212 may define application 220. Although client manifest 212 is shown as defining only application 220, in other designs, the client manifest may define multiple applications. Application 220 may not include executables or references to executables included in client package 210. Instead, application 220 may include host runtime reference 224, which specifies a host runtime included in the host package. Host runtime reference 224 may use a host runtime identifier to specify the host runtime. The host runtime may include activation information and reference executables included in the host package. Activating application 220 may invoke the host runtime specified in application 220, and thus invoke the executable referenced in the host runtime. Application 220 may reference content file 228.

[0083] Application 220 may include application identifier 222. Application identifier 222 may be information identifying application 220. Application identifier 222 may include the OID of application 220. Application identifier 222 may be different from all other OIDs of objects and entities existing on the device on which application 220 resides. The operating system can use application identifier 222 to invoke the host runtime identified in application 220. In other words, activating application 220 can invoke the host runtime and any executables referenced in the host runtime, but it does so using application identifier 222. In this way, the operating system is able to track the activities of the host runtime and any executables referenced in the host runtime as activities of application 220 and client package 210.

[0084] Client package 210 may request registration with the operating system. The operating system may refuse to register client package 210 unless client package 210 and the host package meet certain criteria (some of which are described above). For example, if client package 210, as an unsigned package, does not belong to the host package, the operating system may refuse to install client package 210. As another example, if client package 210 belongs to a host package that does not have a verified signature or has not yet been registered with the operating system, the operating system may refuse to install client package 210. As another example, if client package 210 includes any executable file, the operating system may refuse to install client package 210. Alternatively, if client package 210 includes an executable file, the operating system may refuse to install client package 210 solely based on the inclusion of the executable file. Conversely, if client manifest 212 or application 220 references any executable file included in client package 210, the operating system may refuse to install client package 210. Alternatively, the operating system may still install client package 210 but refuse to execute any executable file included in client package 210. In an alternative, the host runtime referenced in application 220 may refuse to run or invoke the executable included in client package 210. The operating system may require any activatable extension in client package 210 or application 220 to reference the host package or host runtime.

[0085] When a user uninstalls client package 210, the operating system can unregister client inventory 212. The operating system can also instruct the host package to clean up artifacts from client package 210.

[0086] When changes are made to client package 210 (such as updating client package 210, remediating client package 210, disabling client package 210, enabling client package 210, or uninstalling client package 210), the operating system can notify the host package.

[0087] Figure 3 An example of host package 340 according to this disclosure is shown.

[0088] Host package 340 can be a collection of files and data intended to be distributed to and installed on computing devices such as cellular phones, desktop computers, or access terminals. Host package 340 can be generated by the developer.

[0089] Host packet 340 may include a signature 342. Signature 342 may be created using a private key. The private key may not reside on the device where host packet 340 resides. Signature 342 allows the device or operating system to determine that host packet 340 is authentic and has not been modified. For example, the device where host packet 340 resides may include a public key. The public key allows the device to verify that signature 342 was generated using the private key and that host packet 340 is authentic and has not been modified since it was signed. Signature 342 is one way the operating system can verify the authenticity of host packet 340. The operating system and host packet 340 may use other methods to verify authenticity in other designs.

[0090] Host package 340 may include executable files 344a and 344b. Executable file 344 may be a file that can be executed on a computing device. Executable file 344 may reference and use content file 328 included in host package 340. Executable file 344 may use files not included in host package 340.

[0091] Host package 340 may include host manifest 346. The host manifest may be a metadata file containing information about host package 340 and the files included in host package 340. The type and format of the information included in host manifest 346 may be specified by the operating system or platform or by the developers of the operating system or platform.

[0092] Host list 346 may include host identifier 348. Host identifier 348 may be information identifying host package 340. Host identifier 348 may include name, publisher, and version. Host identifier 348 may include OID. Host identifier 348 may be different from the client identifier of a client package belonging to host package 340. Host identifier 348 may be unique compared to all other OIDs identifying objects and entities on the device where host package 340 resides. The operating system can use host identifier 348 to manage and track host package 340.

[0093] Host list 346 may specify capabilities 350 of host package 340. Capability 350 may indicate that host package 340 has access to certain functions of an operating system, platform, or device (such as device 102). For example, suppose executable file 344b attempts to access a function of the operating system. The operating system may only grant executable file 344b access to a function if capability 350 indicates that host package 340 has access to that function. These functions may include placing an icon on the home screen, providing notifications, or accessing the camera. The operating system developer may control access to capability 350. Capability 350 may be a custom hash that the developer of host package 340 must obtain from the operating system developer and include in host list 346. Use of capability 350 may require user consent.

[0094] Capability 350 may include host capability 352. Host capability 352 may indicate that host package 340 can generate client packages. Host capability 352 may indicate that client packages are dependent on host package 340. The system may require host capability 352 to register client packages that claim dependency on host package 340. Host capability 352 may be a custom hash that the developer of host package 340 must obtain from the operating system developer in order to include it in the host manifest 346. The operating system developer may share host capability 352 only with trusted developers. Requiring host capability 352 may be a way for the operating system developer to address security concerns about allowing unsigned client packages to access operating system functions through host package 340.

[0095] Capability 350 may also include the ability to install and uninstall (or cause the operating system to install or uninstall) all packages and applications belonging to host package 340. When a client package or application belonging to host package 340 is uninstalled, host package 340 may be responsible for removing the artifacts of the client package or application.

[0096] Host manifest 346 may include host runtime 354. Host runtime 354 may be information and functionality accessible to applications other than those included in host package 340. Host runtime 354 may be an extension. Host runtime 354 may include activation information 360. Activation information 360 may describe what the system should do when host runtime 354 is invoked. Activation information 360 may reference executables, such as executable 344b. Activation information may also reference multiple executables. Activation information 360 may specify that executable 344b should be executed after host runtime 354 is invoked. Although host manifest 346 includes only host runtime 354, in other designs, host manifest may include multiple host runtimes. Each host runtime may have a unique identifier.

[0097] Host runtime 354 may have a host runtime identifier 356. Host runtime identifier 356 may include information identifying host runtime 354. Host runtime identifier 356 may be a way of referencing host runtime 354. Host runtime identifier 356 may include the OID of host runtime 354. Host runtime identifier 356 may be different from the application identifier of an application included in a client package belonging to host package 340. Host runtime identifier 356 may be unique compared to all other OIDs identifying objects and entities on the device where host package 340 resides. Client packages may use host runtime identifier 356 to reference host runtime 354.

[0098] Host runtime 354 can have a trust level 358. Trust level 358 indicates the level of trust the operating system has relative to host package 340 or host runtime 354. If the trust level 358 of host package 340 is not equal to or greater than a predefined level, the operating system may refuse to register client packages belonging to host package 340.

[0099] Updating host package 340 can involve terminating all applications dependent on host package 340. Updating host package 340 can also involve preventing the execution of all applications dependent on host package 340 during the update process. These requirements can be applied when host package 340 is managed lifetimely.

[0100] Figure 4 An example of a system 400 according to this disclosure is shown. System 400 may include an operating system developer 478, a developer 462, a system administrator 486, a device 402, a user 492, a network 484, and a website 488.

[0101] Device 402 may include hardware and software. Device 402 may include operating system 470, host package 440, and client package 410. Operating system developer 478 may have already generated operating system 470. Operating system 470 may be software that manages the hardware and software of device 402. Operating system developer 478 may be the source of device 402.

[0102] Host package 440 may be a collection of files and data. Host package 440 may be registered with operating system 470. Host package 440 may be signed, and operating system 470 may have authenticated host package 440 before registering it. After user 492 acquires device 402, host package 440 may be downloaded to device 402. Alternatively, host package 440 may reside on device 402 when user 492 acquires it. Operating system developer 478 may generate host package 440. Alternatively, developer 462 may have already generated host package 440. In either case, operating system developer 478 and developer 462 may sign host package 440 before distributing it and before it resides on device 402.

[0103] Host package 440 may include one or more applications. These applications enable user 492 of device 402 to perform tasks. Host package 440 may interact with operating system 470 during runtime to perform tasks. Host package 440 may include a host runtime that can be accessed and used by applications not included in host package 440. The host runtime may reference executables included in the host package.

[0104] Client package 410 may be unsigned and subordinate to host package 440. Client package 410 may not include any executable files. Client package 410 may include client applications. When activated, the client application may invoke the host runtime. The client application may be limited to the functionality of the host runtime and host package 440. However, client package 410 may include content files not included in host package 440. The client application may use its client application identifier to invoke the host runtime. And the executable file referenced by the host runtime may use the content files included in client package 410 during runtime. Therefore, the client application may provide the user with access to different content and allow the user to perform tasks different from those that the user can access and perform using one or more applications included in host package 440.

[0105] System administrator 486 may have already generated client package 410. After host package 440 registers with device 402, system administrator 486 may have already generated client package 410. System administrator 486 may have generated client package 410 based on the specific needs of user 492 of device 402. Client package 410 can be used to customize the experience of user 492 using one or more applications included in host package 440 or device 402. System administrator 486 may not have access to a certificate to sign client package 410.

[0106] In the alternative, developer 462 can generate client package 410. Developer 462 can generate client package 410 after host package 440 has been signed. Developer 462, who may not have developed host package 440, may not have access to the certificate to sign client package 410.

[0107] Alternatively, the host application included in host package 440 may have already generated client package 410. The host application may generate client package 410 during its runtime. For example, the host application could be a web browser. During the runtime of the web browser, a user can use the web browser to access website 488. Website 488 may include content 490. When device 402 does not have access to network 484, user 492 may want access to content 490 of website 488. The web browser can generate client package 410 based on website 488 and content 490.

[0108] In the alternative, user 492 may have already generated client package 410.

[0109] Figure 5 A method 500 for registering an unsigned package with an operating system is shown. For clarity, the method will be described in conjunction with the systems, devices, components, and data described above.

[0110] Method 500 may include receiving a first request to register a host package (502). The host package may make the first request to an operating system, such as operating system 170. The host package may be host package 140 or host package 340. The developer may have already generated the host package. The first request to register the host package may be a request for the operating system to recognize the host package, record information about the host package, and allow applications included in the host package to run on the device where the operating system resides. The first request to register the host package may be a request to link the host package to a specific user.

[0111] Method 500 may include verifying the signature of the 504 host packet. The signature may be signature 142 or signature 342. The signature may have been generated using a private key, which is typically unavailable and not included in the host packet. The private key may have been generated by the operating system developer. The operating system developer may share the private key only with trusted developers. The operating system may use the public key to verify the signature of the 504 host packet. Verifying the signature of the 504 host packet indicates that the host packet is authentic and has not been modified since the signature was generated. Verifying the signature of the 504 host packet provides some assurance that the host packet was created by a trusted developer and is not malicious.

[0112] Method 500 may include registering a 506 host package with an operating system. The operating system may be operating system 170. Registering a 506 host package with the operating system may include recording information about the host package. Registering a 506 host package with the operating system may include granting the host package permission to run on the device. Registering a 506 host package with the operating system may include associating the host package with a specific user.

[0113] Method 500 may include receiving a second request, 508, to register a client package. The client package may be client package 110 or client package 210. The operating system may receive the second request, 508. The operating system may receive the second request, 508, from a host package or from the client package. The client package may not include a signature. The client package may not provide a method for authenticating the client package. The second request to register the client package may be a request for the operating system to identify the client package, record information about the client package, and allow applications included in the client package to run on the device. The second request to register the client package may be a request to link the client package to a specific user.

[0114] Method 500 may include determining that the client package 510 does not contain an executable file. Determining that the client package 510 does not contain an executable file may further include determining that the client package does not contain extensions that reference binaries or classes other than the host package or host runtime. The executable file may include a dynamic link library file.

[0115] Method 500 may include determining that client packet 512 has an unsigned tag. The unsigned tag may be unsigned tag 226. Determining that client packet 512 has an unsigned tag may include determining that the client packet includes a constant having a value set by the operating system developer.

[0116] Method 500 may include a dependency attribute that identifies the client packet to the host packet. The dependency attribute may be dependency attribute 116 or dependency attribute 216. The dependency attribute may identify the host packet. The dependency attribute may include standards such as Standard 232.

[0117] Method 500 may include parsing the dependent attributes of a 516 client packet. Parsing the dependent attributes of a 516 client packet may include identifying a host packet. Parsing the dependent attributes of a 516 client packet may include determining that the host packet meets the criteria for being included in a host packet.

[0118] Method 500 may include determining that host package 518 has registered with the operating system 518. Registering with the operating system could mean recording information about the host package. It could also mean that the host package has been linked to a specific user. It could also mean that the host package is allowed to run on the device.

[0119] Method 500 may include determining 520 that the host packet includes host capabilities. Host capabilities may be host capability 352. Host capabilities may indicate that the host packet has a host licensed from the operating system to act as a client packet. The operating system developer may provide host capabilities only to trusted developers. Alternatively, method 500 may include determining that the host packet has a trust level equal to or greater than a predetermined trust level.

[0120] Method 500 may include registering the 522 client package with the operating system. Registering the 522 client package with the operating system may include recording information about the client package. Registering the 522 client package with the operating system may include granting the client package permission to run on the device. Registering the 522 client package with the operating system may include associating the client package with a specific user.

[0121] Method 500 may include receiving 524 activation requests for applications included in a client package. The application may be application 120 or application 220. The activation request may be generated directly by the user initiating the application. The activation request may also be generated indirectly by the user, such as by opening a file type that cannot be viewed without the application.

[0122] Method 500 may include invoking the host runtime of the main package 526 using the application's application identifier. The application may include a reference to the host runtime. The host runtime may be host runtime 154 or host runtime 354. The host runtime may include activation information. The host runtime may reference an executable included in the host package. Invoking the host runtime of the host package 526 may include executing the executable referenced in the host runtime.

[0123] Method 500 may include tracking the activity of application 528 using an application identifier. The operating system may use the application identifier to track the activity of application 528. Tracking the activity of application 528 using an application identifier may include tracking the activity of an executable file. Even if the executable file is included in a host package (rather than a client package), the operating system may be able to associate the activity of the executable file with the application because the host runtime is invoked using the application identifier.

[0124] Method 500 may include receiving 530 a first function request to access a first function of the operating system. The first function may be one of functions 174. The operating system may receive 530 the first function request. The operating system may receive 530 the first function request from an application. The first function may involve accessing hardware components of the device where the operating system resides (such as a camera or microphone). The first function may involve accessing system files (such as files that control images appearing on the device's home screen) or system functions (such as sending notifications). The operating system may restrict access to the first function.

[0125] Method 500 may include determining that host packet 532 has the capability to access the first function. This capability may be one of the capabilities of capability 350. The operating system may determine that host packet 532 has the capability to access the first function.

[0126] Method 500 may include granting application 534 access to the first function. The operating system may grant application 534 access to the first function.

[0127] Method 500 may include receiving 536 a second function request to access a second function of the operating system. The second function may be one of the functions in function 174. The operating system may receive 536 the second function request. The second function request may originate from an application. The second function may be different from the first function.

[0128] Method 500 may include determining that host packet 538 does not have the ability to access the second function.

[0129] Method 500 may include rejecting the second function request of 540.

[0130] Method 500 may include uninstalling host package 542. Uninstalling host package 542 may include unregistering host package.

[0131] Method 500 may include uninstalling client package 544 after uninstalling the host package. Uninstalling client package 544 may include unregistering the client package. Uninstalling 544 may include uninstalling all client packages that are dependent on the host package. In other designs, the client package may not be uninstalled when the host package is uninstalled. Instead, the client package may remain on the system, but its status may change to corrupted, disabled, inoperable, or requiring attention.

[0132] Figure 6 A method 600 for registering an unsigned package is shown. For clarity, the method will be described in conjunction with the systems, devices, components, and data described above.

[0133] Method 600 may include receiving a request to register an unsigned package (602). An operating system (such as operating system 170) may receive this request (602). The unsigned package may be client package 110 or client package 210. The unsigned package may request registration. Alternatively, a host package (such as host package 140 or host package 340) may make the request.

[0134] Method 600 may include determining whether the unsigned packet (604) declares a dependency attribute to the host packet. The dependency attribute may identify the host packet. The dependency attribute may be dependency attribute 116 or dependency attribute 216. If the unsigned packet does not declare a dependency attribute to the host packet, method 600 may include rejecting the request (622).

[0135] Method 600 may include determining whether host packet 606 is registered. Determining whether host packet 606 is registered may include determining whether host packet 606 has registered with the operating system. If host packet is not registered, method 600 may include rejecting the request 622.

[0136] Method 600 may include determining, at 608, whether the host packet meets the criteria included in the dependent attribute. The criterion may be criterion 232. If the host packet does not meet the criterion, method 600 may include rejecting, at 622, the request.

[0137] Method 600 may include determining 610 whether the host packet includes a signature. The signature may be signature 142 or signature 342. If the host packet does not include a signature, method 600 may include rejecting 622 the request.

[0138] Method 600 may include determining whether the signature of the host packet has been verified (612). If the signature of the host packet has not been verified or cannot be verified, method 600 may include rejecting the request (622).

[0139] Method 600 may include determining whether the unsigned package contains an unsigned tag. If the unsigned package does not contain an unsigned tag, method 600 may include rejecting the request.

[0140] Method 600 may include determining 616 whether the host packet includes host capabilities or has a trust level equal to or greater than a predefined level. If the host packet does not include host capabilities or does not have a trust level equal to or greater than a predefined level, method 600 may include rejecting 622 the request.

[0141] Method 600 may include determining whether the unsigned package contains any executable files. If the unsigned package contains any executable files, method 600 may include rejecting the request.

[0142] Method 600 may include granting 620 the request. The operating system may grant 620 the request. Although granting 620 the request is shown to occur only if all the conditions shown are met, method 600 may include granting 620 the request when fewer than all the conditions shown are met. For example, in some designs, method 600 may grant a request to register a client package even if the client package does not declare a dependency or declares an unresolved dependency. In these cases, the client package may be able to register with the operating system but may not be able to use the functionality and capabilities of the host package. In other designs, granting 620 the request may also require additional conditions to be met. For example, method 600 may require that there be no conflict between the unsigned package, any application described in the unsigned package, the host package, and the identifier of any application or host runtime described in the host package.

[0143] Method 600 may include rejecting 622 the request. The operating system may reject 622 the request. Although rejecting 622 the request is shown to occur when any of the conditions shown are not met, rejecting 622 the request may require two or more conditions shown to be not met.

[0144] Figure 7 A method 700 for granting access to a function is shown. For clarity, the method will be described in conjunction with the systems, devices, components, and data described above.

[0145] Method 700 may include receiving a request for access to a function (702). The operating system may receive the request for access to the function (702). The operating system may receive the request for access to the function (702) from an unsigned package or an application contained in an unsigned package. The operating system may receive the request (702) from a host runtime or an executable file included in a host package, the host package operating with the application identifier of an application contained in an unsigned package. The function may be one of the functions in function 174. The function may involve accessing the hardware components of the device where the operating system resides.

[0146] Method 700 may include determining whether the client packet (704) includes the ability to access the functionality. The client packet may be an unsigned packet such as client packet 110 or client packet 210. If the client packet does not include the ability to access the functionality, method 700 may include rejecting the request (710).

[0147] Method 700 may include determining whether the host packet includes the ability to access the functionality. The host packet may include a signature such as signature 142 or signature 342. The host packet may be host packet 140 or host packet 340. The client packet may include a dependency on the host packet. If the host packet does not include the ability to access the functionality, method 700 may include rejecting the request at 710.

[0148] Method 700 may include granting request 708. The operating system may grant request 708. Although granting request 708 is shown to occur only if all the conditions shown are met, method 700 may include granting request 708 if less than all or even if not all the conditions shown are met. In other designs, granting request 708 may also require additional conditions to be met. As previously stated, the operating system may use various rules to determine whether a client packet has access to the capability of that functionality. These rules include intersection rules, union rules, host restriction rules, and client claim rules. As previously stated, these rules may be used together. A request to grant access to a function may involve the use of those rules or any one or more other rules known in the art.

[0149] Method 700 may include rejecting request 710. The operating system may reject request 710. Although rejection of request 710 is shown to occur when none of the conditions shown are met, rejection of request 710 may require all of the conditions shown to be unmet.

[0150] Figure 8 A method 800 for requesting access to operating system functions is illustrated. For clarity, this method will be described in conjunction with the systems, devices, components, and data described above.

[0151] Method 800 may include a subordinate attribute of the host packet as declared in 802. The subordinate attribute may be subordinate attribute 116 or subordinate attribute 216. The host packet may be host packet 140 or host packet 340.

[0152] Method 800 may include defining an 804 application using an application identifier and a reference to a host runtime. The application may be application 120 or application 220. The application identifier may be application identifier 222. The host runtime may be host runtime 154 or host runtime 354.

[0153] Method 800 may include specifying an unsigned tag 806. The unsigned tag may be unsigned tag 226.

[0154] Method 800 may include request 808 to register with the operating system without a signature. Request 808 may be performed by client packet 110 or client packet 210. Request 808 may be performed by a host packet on behalf of the client packet. The operating system may be operating system 170.

[0155] Method 800 may include receiving 810 registration with the operating system.

[0156] Method 800 may include requesting the execution of host runtime 812 after the application is activated. Request 812 may be performed by the application. Host runtime may be included in a host package.

[0157] Method 800 may include request 814 for access to functionality of the operating system or device. Request 814 may be performed by an application included in a client package. The operating system may receive the request for access to functionality.

[0158] Method 800 may include receiving 816 access to a function. Receiving 816 may be performed by an application included in a client package.

[0159] Method 800 may include a request 818 for access to a second function of the operating system or device. Request 818 may be performed by an application included in a client package. The operating system may receive the request for access to the second function.

[0160] Method 800 may include a failure to access the second function 820. The operating system may refuse the request to access the second function.

[0161] Figure 9 A method 900 for generating client packages is illustrated. For clarity, this will be described in conjunction with the systems, devices, components, and data described above.

[0162] Method 900 may include generating a 902 client packet during the runtime of the host packet. The host packet may be host packet 140 or host packet 340. The client packet may be client packet 110 or client packet 210. The host packet may include a signature. The client packet may not include a signature. The host packet may generate a 902 client packet.

[0163] Method 900 may include declaring a 904 dependent attribute to the host packet in the client packet. The dependent attribute may be dependent attribute 116 or dependent attribute 216.

[0164] Method 900 may include an application defined in the client package 906, which has an application identifier and a reference to the host runtime. The application may be application 120 or application 220. The host runtime may be host runtime 154 or host runtime 354.

[0165] Method 900 may include specifying an unsigned flag (908) in the client packet. The unsigned flag may be unsigned flag 226.

[0166] Method 900 may include, after activating the application, providing 910 access to the host runtime under the application identifier. The host package may provide access to the host runtime.

[0167] Figure 10 Certain components that may be included within computer system 1000 are shown. One or more computer systems 1000 may be used to implement the various devices, components, and systems described herein. For example, device 102 may be implemented using computer system 1000.

[0168] Computer system 1000 includes processor 1001. Processor 1001 can be a general-purpose single-chip or multi-chip microprocessor (e.g., an advanced RISC (Reduced Instruction Set Computer) machine (ARM)), a special-purpose microprocessor (e.g., a digital signal processor (DSP)), a microcontroller, a programmable gate array, etc. Processor 1001 can be referred to as a central processing unit (CPU). Although in Figure 10 The computer system 1000 shows only a single processor 1001, but in alternative configurations, a combination of processors (e.g., ARM and DSP) can be used.

[0169] The computer system 1000 also includes a memory 1003 that communicates electronically with the processor 1001. The memory 1003 can be any electronic component capable of storing electronic information, such as client packet 110, host packet 140, and operating system 170. For example, the memory 1003 can be implemented as random access memory (RAM), read-only memory (ROM), disk storage media, optical storage media, flash memory devices within RAM, on-board memory including the processor, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, and combinations thereof.

[0170] Instruction 1005 and data 1007 may be stored in memory 1003. Instruction 1005 may be executed by processor 1001 to implement some or all of the functions disclosed herein. Executing instruction 1005 may involve using data 1007 stored in memory 1003. Any of the various examples of modules, components, packages, applications, and operating systems described herein may be implemented in whole or in part as instruction 1005 stored in memory 1003 and executed by processor 1001. Any of the various examples of data described herein may be in data 1007 stored in memory 1003 and used during the execution of instruction 1005 by processor 1001.

[0171] The computer system 1000 may also include one or more communication interfaces 1009 for communicating with other electronic devices. The communication interfaces 1009 may be based on wired communication technology, wireless communication technology, or both. Some examples of communication interfaces 1009 include Universal Serial Bus (USB), Ethernet adapters, wireless adapters operating according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 wireless communication protocol, Bluetooth® wireless communication adapters, and infrared (IR) communication ports.

[0172] Computer system 1000 may also include one or more input devices 1011 and one or more output devices 1013. Some examples of input devices 1011 include keyboards, mice, microphones, remote controls, buttons, joysticks, trackballs, touchpads, and light pens. Some examples of output devices 1013 include speakers and printers. A particular type of output device typically included in computer system 1000 is a display device 1015. Display device 1015 used with the embodiments disclosed herein may utilize any suitable image projection technology, such as liquid crystal displays (LCDs), light-emitting diodes (LEDs), gas plasma, electroluminescence, etc. A display controller 1017 may also be provided for converting data 1007 stored in memory 1003 into text, graphics, and / or moving images (as applicable) displayed on display device 1015.

[0173] Various components of the computer system 1000 can be coupled together via one or more buses, which may include power buses, control signal buses, status signal buses, data buses, etc. For clarity, in... Figure 10 The various buses are referred to as Bus System 1019.

[0174] The techniques described herein can be implemented in hardware, software, firmware, or any combination thereof, unless specifically described as being implemented in a particular manner. Any features described as modules, components, etc., can also be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. If implemented in software, these techniques can be implemented at least in part by a non-transient computer-readable medium on which computer-executable instructions are stored, which, when executed by at least one processor, perform some or all of the steps, operations, actions, or other functions disclosed herein. The instructions can be organized into routines, programs, objects, components, data structures, etc., which can perform specific tasks and / or implement specific data types, and can be combined or distributed as needed in various embodiments.

[0175] The steps, operations, and / or actions of the methods described herein may be interchanged with each other without departing from the scope of the claims. In other words, unless the correct operation of the described methods requires a specific order of steps, operations, and / or actions, the order and / or use of a particular step, operation, and / or action may be modified without departing from the scope of the claims.

[0176] In the example, the term "determine" (and its grammatical variations) encompasses a variety of actions; therefore, "determine" can include operations, calculations, processing, derivation, investigation, searching (e.g., looking in a table, database, or other data structure), confirmation, etc. Furthermore, "determine" can include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), etc. Additionally, "determine" can include parsing, selecting, picking, building, etc.

[0177] The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that additional elements may exist in addition to those listed. Furthermore, it should be understood that references to “one embodiment” or “embodiment” in this disclosure are not intended to exclude the existence of additional embodiments that also incorporate the described features. For example, where compatible, any element or feature described herein with respect to an embodiment may be combined with any element or feature of any other embodiment described herein.

[0178] This disclosure may be practiced in other specific forms without departing from its spirit or characteristics. The described embodiments are to be considered illustrative rather than restrictive. Therefore, the scope of this disclosure is indicated by the appended claims, not by the foregoing description. Changes within the meaning and equivalents of the claims should be included within its scope.

Claims

1. A system comprising: a processor; and a memory including computer-executable instructions that, when executed, perform operations comprising: generating a client package during execution of a host runtime of a host package; declaring a dependency on the host package in the client package; defining an application with an application identity and a reference to the host runtime in the client package; specifying an unsigned marker in the client package; and providing access to the host runtime under the application identity upon activation of the application.

2. The system of claim 1, wherein the host package comprises a first set of data for distribution to a computing device and installation on the computing device to create.

3. The system of claim 2, wherein the client package comprises a second set of data for installation on the computing device to create, the client package generated by the host package.

4. The system of claim 1, wherein the client comprises: a client manifest including the dependency and metadata describing the application; and a content file used during runtime of the application.

5. The system of claim 1, wherein the unsigned marker indicates that the client package is unsigned.

6. The system of claim 1, wherein the application does not include or reference an executable program included in the client package.

7. The system of claim 1, wherein the host runtime includes activation information referencing an executable program used to activate the application.

8. The system of claim 1, wherein the host package includes a verifiable signature, and the host package is registered with an operating system based on verification of the verifiable signature.

9. The system of claim 8, wherein the verifiable signature: is generated using a private key not included in the host package; and is verified using a public key corresponding to the private key prior to or as part of starting the host runtime.

10. The system of claim 8, wherein the activation of the application comprises: registering the client package with the operating system based on the verification of the verifiable signature.

11. The system of claim 10, wherein registering the client package with the operating system comprises: determining that an identity of the client package does not conflict with an identity of the host package.

12. The system of claim 11, the operations further comprising: receiving a request from the application to access a function of the system; and enabling the application to access the function using the host runtime.

13. The system of claim 12, wherein enabling the application to access the function comprises: evaluating, by an operating system executing the host runtime, a rule indicating that at least one of the client package or the host package includes a capability for the function is satisfied; and determining that the rule is satisfied.

14. A method comprising: ​ ​ ​ ​ generating a client package during execution of a host runtime of a host package by an operating system of a device; defining in the client package: a dependency on the host package; an application with an application identification; a reference to the host runtime; and an unsigned marker; and providing access to the host runtime using the application identification in response to activation of the application.

15. The method of claim 14, wherein the application identification is a unique object identifier for the application.

16. The method of claim 14, wherein the application identification enables the operating system to track activity of the host runtime and executable programs referenced in the host runtime as activity of the application.

17. The method of claim 14, wherein the client package does not include an object that allows the operating system to authenticate the client package.

18. The method of claim 14, wherein the host package includes a trust level relative to the operating system, the trust level indicating a level of access the host package has to functionality of the operating system.

19. The method of claim 14, wherein the host package includes at least two of: a name of the host package; a version of the host package; a publisher of the host package; or an author of the host package.

20. A device comprising: a processor; and a memory including computer-executable instructions that, when executed, perform operations comprising: generating a client package during execution of a host runtime by an operating system of the device, the host runtime being included in a host package; defining in the client package: a dependency on the host package; an application with an application identification; and a reference to the host runtime; and providing access to the host runtime to the application based on the application identification in response to activation of the application. ​ ​ ​

Images