The present application claims priority from application No.61/067,872 entitled "Browser-based applications and Interfaces Having Secure Access to Native Operating systems features" filed on 3/2 of 2008, which is hereby incorporated by reference in its entirety.
Detailed Description
The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Furthermore, in the following description, numerous details are set forth for the purpose of explanation. However, it will be recognized by one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order not to obscure the description of the invention with unnecessary detail. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
While the present invention has been described in terms of particular embodiments and figures, those of ordinary skill in the art will recognize that the invention is not limited to the embodiments or figures described. Those skilled in the art will recognize that the operations of the various embodiments may be suitably implemented in hardware, software, firmware, or suitable combinations thereof. For example, some processes may be performed using processors or other digital circuitry under the control of software, firmware, or hardwired logic. (the term "logic" herein refers to fixed hardware, programmable logic, and/or suitable combinations thereof, as would be recognized by one of ordinary skill in the art to carry out the recited functions). The software and firmware may be stored on a computer readable medium. Some other processing may be implemented using analog circuitry known to those skilled in the art. Additionally, memory or other storage devices and communication components may also be used in embodiments of the invention.
1A-1E are illustrative diagrams of platforms for executing components 148 in a web browser 104 in accordance with embodiments of the invention. FIG. 1A shows an overall view of the functional units of the platform, and FIGS. 1B-1E show more detailed views of specific functional units. The component 148 may be, for example, a component providing a generic toSuch as JavaScript in the web browser 104TMSuch as computer program code modules for services for which network-based code is not available. These services include, for example, drag and drop (drag and drop) operations, text to speech (text to speech) operations, and other restricted or native system operations and resources 130. The software developer may add additional components 148 by defining an interface 162 that specifies one or more operations provided by the components and an implementation 164 of those operations. Examples of components include a Flickr uploader component, which provides a drag and drop user interface for uploading images to a user interface area set in the web browser 104 by dragging and dropping files from the user's computer to the user interface area set by the Flickr uploader componentAn online photo sharing service. Other example components include a text-to-speech component and an image processing component (called ImageAlter). The component 148 can be used for browser-based program code 107 provided by a user, such as JavaScript code downloaded from a web server as part of a web page. The example platform of FIG. 1A, including the plug-in interface 108 and the bootstrap program (daemon)140, enables such browser-based program code to use the components 148. Since component 148 provides features that are not available in web browser 104, component 148 extends the set of features of end-user machine 102 that are available for use by web page 106. Because the features provided by the components often use restricted system operations and resources that are potentially harmfully abused, effective security measures are needed to ensure that the components use the restricted operations and resources in a manner that is explicitly or implicitly approved by the user.
System 102 includes component execution logic 140 that provides core services 142 and component provider interfaces 146, such as C provider interface and RubyTMInterpreted programming language provider interface. Although C and Ruby are described herein, the component provider interface 146 may support other languages, such as C + +, Java, and so forth. The component execution logic 140 includes logic toThe component set 148 of one less component 160. Each component includes implementation function(s) 164 and interface definition(s) 162 that describe implementation function(s) 164. The interface definition may be, for example, a JSON description file that describes the name and parameters of the operation(s) provided by the component 160 and implemented by the implementation 164. In one example, implementation function(s) 164 perform restricted system operation(s) on browser host computer 102 if permission for the operation(s) is received from a user of the browser host computer. That is, the implementation function prompts the user to approve certain restricted or security sensitive operations that will be performed when the function is executed, such as opening a file or network connection, communicating via a network connection, or accessing system resources such as a printer, voice synthesizer, or storage device, etc. Each implementation function may select an appropriate level of granularity for the security prompt. For example, the implementation function may prompt the user for each file access (file access), for all file accesses, or for file accesses during a web browser session, and so forth. At least a portion of the implementation function(s) may be implemented using native code, as known to those skilled in the art.
The restricted system operation may be, for example, a native function (i.e., a function that is callable from a language such as C or C + + and is not generally directly available to the component 148 because the component 148 may be implemented in a language such as Ruby that does not directly access the native function). Native functionality may access system resources by establishing the identity and access permissions of a user by providing login credentials or digital certificates for the user or for a user associated with the end user machine 102. Native functions may, for example, display information on an output device and/or receive information from an input device, or perform operating system specific functions such as drag and drop, text-to-speech, file browsing, and so forth. The native functions may access data stored on magnetic disks, optical disks, semiconductor-based memories, and the like.
These restricted system operations are only accessible by native code, e.g., code written in a language such as C or C + +, that is compiled into machine-level instructions. Programming languages such as Java, JavaScript, and Ruby that are typically supported in web browsers do not have features that access certain native operating system or hardware features, or even if the languages do have these features, these features are typically disabled by web browser 104 due to security risks posed by unrestricted access to these features. The plug-in interface 108 allows the browser-based code 107 (e.g., user-provided JavaScript code downloaded from the web server 100) to access these restricted features by providing component execution logic 140, wherein the component execution logic 140 allows a developer to implement components 148 that access these features via native code portions of the developer-provided component implementation 164 or via built-in native code for certain frequently used features. In one example, the plug-in interface 108 is a browser plug-in that interfaces with the web browser 104 via a browser plug-in Application Programming Interface (API), such as ActiveX or NPAPI. The unauthorized use of restricted system operations by browser-based program code 107 and components 148 (including native and non-native code portions) is prevented by including a security check in the component implementation 164, such as a secure user prompt (secure user prompting) that verifies that the end user approves invocation of the restricted operation, or by requiring the component implementation 164 and/or the plug-in community library 117 that makes certain types of permissions (e.g., permissions to open IRC connections) available to the end user before invoking the restricted feature.
The core interface 144 includes native implementations for accessing hardware features or operating systems such as user interface drag and drop, file access, secure user prompts, text-to-speech, and GPS interfaces. Built-in or predefined components are provided for accessing these predefined native implementations from common languages such as JavaScript and Ruby. The components 148 include predefined components, such as components for drag and drop, file access, secure user prompts, text to speech conversion, GPS, and the like.
In one example, the system modules, including plug-in interface 108, core services 142, and components 148, are installed on (i.e., made executable on) end user machine 102 by installing bootstrap program 170, wherein bootstrap program 170 receives the modules from distribution server 150 via a computer network such as the Internet. The installation bootstrap program 170 is installed by the user and inherits (inherit) the user's access credentials, which the installation bootstrap program 170 uses to install the system module on the user machine 102. The system module inherits the user's access credentials and uses these credentials to execute native code and access restricted system operations.
Web browser 104 includes web page 106 received from web server 100. The web page may include or reference JavaScript code 107 provided by the user. JavaScript code 107 is an example of browser-based code, which can be computer program code that can be invoked by web browser 104. The web browser 104 also includes a plug-in interface 108, the plug-in interface 108 interfacing with a browser specific plug-in API116 using a generic browser plug-in API 114, and the browser specific plug-in API116 in turn interfacing with a browser core 118 to interface the generic browser plug-in API 114 to the browser 104. The plug-in adapter layer 112 provides an interface between user-provided scripting code 107 (e.g., JavaScript) and a generic browser plug-in API (e.g., also JavaScript) that interfaces with a native code common plug-in library 117 (e.g., C or C + +), which native code common plug-in library 117 is capable of invoking restricted system operations that are not available in the scripting speech code execution environment that is typically provided to the web page 106 by the web browser 104. The plug-in adapter 112 is invoked, for example, in response to a component call instruction from the browser-based program code 107. The plug-in adapter 112 may, for example, be called in return by a generic browser plug-in API 114 in the form of a callback (callback invocation) that provides results or notifications to the user's JavaScript 107.
Core logic 140 includes one or more language specific component provider interfaces 146 as introduced above. The component execution logic 140 may be implemented as a bootstrap program, i.e., a process that runs in the background and/or independent of a particular user, and communicates with one or more plug-in interfaces 108. The core logic boot program 140 loads the interfaces and implementations for each component 148, for example, when the boot program is initialized or when a request for the component 160 is received. The component implementation is loaded with a dynamic load or link process appropriate for the language for the component 164 (e.g., a dynamic library open call for a C voice component, or an appropriate Ruby load operation for a Ruby component). Each component provider interface 146 receives component invocation requests from the plug-in adapters 112. In one example, the component invocation request is a serialized version of the component invocation instruction, suitable for transmission via inter-process communication from the plug-in adapter 112 (which is part of the browser process) to the core interface 144 of the core service 142 (which is part of the core logic bootstrap process 140). The core interface 144 forwards the serialized call instruction to the component provider interface 146, and the component provider interface 146 calls the appropriate implementation function of the corresponding component 160, where the function and component are specified in the component call request. In one example, provider interface logic 146 may revoke the permission from the user of the browser host computer in response to completion of the operation. In another example, the provider interface logic can revoke the permission from the user of the browser host computer in response to termination of a network session associated with the browser-based program code.
The provider interface 146 may deliver the interface definition to the plug-in adapter logic. In languages such as Ruby that provide introspection of types, the interface definition can be derived automatically from the component implementation provided by the user. The plug-in adapter 112 may receive interface definitions from components.
The provider interface 146 can load the component(s) 148 from a distribution server 150, a storage device, or other data source. The component(s) 148 may be, for example, a shared library and may be a package of information including interface definitions, implementation of interfaces, and documentation of interfaces. Component(s) 148 may be provided by any trusted entity. If the implementation ensures that user permissions are requested and received before any operations are performed on the system resources, the operation of each component 148 is substantially secure (i.e., does not access any system resources that may cause a security violation). Once the user is prompted, the user-provided JavaScript will not be able to perform malicious actions on the computer 102 because the user-provided JavaScript generally cannot provide a reply to the prompt.
The implementation function may provide results, where the provider interface logic and the plug-in adapter logic deliver, i.e., forward, the results to the browser-based program code. That is, a response can be returned from the component(s) 148 to the user-provided JavaScript.
From the certificate that endorses a particular component and all associated information about that component, an end user can be provided with a meaningful understanding of the risks that the component is allowed to execute. When a component is needed by a web page, the system obtains a component description. These descriptions may be endorsed or not endorsed. The non-annotated components are "anonymous" and are executed as "sandboxed" (sand-boxed) components. The risk of endorsed components is dynamically and securely determined based on the certificate that endorses them. This hierarchical approach allows for decentralized development of security components. A prompt is presented to the user requesting permission to perform the operation provided by the component. The type and nature of the prompts presented to the user is based on the component and the risk of operation of the particular component.
As introduced above, a "risk rating" may be generated for a component to allow a user to determine whether the component may be executed on the user's computer. The risk rating is based on a certificate that endorses the component and other information about the component. The certificate that endorses the component identifies the provider of the component as a trusted authorized entity, in which case the component is considered an official component or a third party component, in which case the trusted authorized entity ensures that the identity of the component provider (e.g., the publisher) is correct, or as an independent component, in which case the component provider is known to the trusted authorized entity, or as an anonymous component, in which case the trusted authorized entity alerts of the installation or execution of the component. The risk rating is communicated to the user when the user is required to permit execution of the component. In one example, if one or more operations provided by a component are invoked, the risk rating is displayed to the user in a request to permit execution of a particular restricted system operation that the component will execute. In one example, the request for permission is displayed in response to an initialization of the component, where the initialization may occur in response to the browser receiving a web page that includes script code, and the script code includes statements that invoke operations (e.g., methods, procedures, or functions) of the component. In another example, the request for permission is displayed in response to invocation of a particular operation by the script code prior to execution of the component operation.
In one example, the risk rating corresponds to a level of a plurality of risk levels ranging from low risk to high risk. A hierarchical risk rating system is provided to indicate the level of vigilance a user should give when using a particular component. In one example, each tier of the plurality of tiers corresponds to a risk rating as described above, i.e., the risk is based on the certificate of the endorsement component. The prompt is presented to the user by a component that requires access to a particular resource to perform a restricted operation, such as reading a file. The cues change according to the risk of the component. The risk may be presented to the user as a brief phrase based on risk, such as "very low risk," or as a more detailed phrase based on risk and the operation that the component wishes to invoke, such as "erasing or overwriting a picture stored on your computer has very low risk.
In one example, four risk tiers are provided, and a component may be associated with one of the tiers. A risk rating may be associated with each level in a hierarchy.
The system provides secure external authorization of the component. The trusted authority acts as a "gatekeeper" and issues endorsement certificates to these various entities. Depending on the certificate that endorses a particular component and associated information describing the component, a meaningful description of the component risk may be generated and presented to the user. That is, the risk level is based on the degree of trust in the certificate, with highly trusted certificates having the lowest risk.
In one example, a component description is obtained when the component is used, such as when script code on a web page calls the component. These descriptions may be endorsed or not endorsed. The components that are not endorsed are "anonymous" and are executed in a protected "sandbox" environment. The risk level of endorsed components is dynamically and securely determined based on the certificate that endorses them. This hierarchical approach allows for decentralized component development. Furthermore, execution of high-risk class components may not be permitted by default, thereby minimizing the risk presented to an average user while enabling component developers to use most types of system resources.
In one example, a component permission object is provided to represent a permission to perform a particular operation associated with the permission object. The component license includes a name and a description. For example, a permission connecticttochatserver, which represents permission to connect to a chat server, may have an association description "connect to IRC (chat) host". Component permissions represent operations that are meaningful to the user, for example application specific operations such as connecting to a chat server. Also, the description of component permissions also describes the permissions in terms that are meaningful to the user, e.g., "connect to IRC (chat) host" is more meaningful than "open network connection" or "open network connection on a port in scope 6667-7002". Part of the description "IRC (chat) host" refers to application specific features, such as IRC or chat host. The description listing ports 6667 and 7002 without an application being set forth does not relate to a specific application and therefore does not relate to application specific features.
In one example, the requirements for the permission object may be associated with a security-sensitive component operation, and the component may request the corresponding permission object, such as the ConnectToChatServer permission described above, to be obtained during initialization or initial processing of the component. When a component is to be executed, the component requests permission for the call operation. The user may be prompted by utilizing the secure user prompt described elsewhere herein to obtain the permission objects required for operation. If the user responds with a positive "yes" to the prompt describing the action to occur, permission is granted to the user to invoke the action. In another example, the user may have an associated digital certificate that may replace the secure user prompt, thereby providing the user with permission to invoke the operation. The operation may be associated with a desired maximum risk level such that the operation may be performed by a user having credentials with a risk level equal to or lower than the desired maximum risk level for the operation.
For example, the chat component may include an operation named "connect" to open a network connection to the chat server. The chat component may be implemented in part in one language, such as Ruby, and in part in a second native language, such as C. The native language implementation may include a direct call to an operating system network connection function, in which case the native language implementation checks for the presence of a permission associated with the user, where the permission corresponds to an operation to be performed, such as a network connection function, such as a ConnectToChatServer permission. If permission exists (e.g., associated with the user), the native implementation invokes the operating system network connection function. If the permission does not exist, the implementation invokes a secure user prompt user interface that represents a prompt to the user, such as "give permission to communicate with the chat server over the network? The risk level of the action is low ". The prompt includes a phrase describing the action to be performed, and the action is described in terms of component operations (in the above example, "connect" operations for establishing a network connection to the chat server). The prompt describes the requested permission in terms of component operations, such as communicating with a chat server. The prompt also describes a risk level, e.g., low. In contrast to the meaning of the underlying operating system function that is less meaningful to the component user (e.g., port 7000 connected to server "a.b.com"), the hints describe the operation in terms of the semantic meaning of the component operation.
Fig. 2 is an explanatory diagram of metadata information for components according to an embodiment of the present invention. FIG. 2 illustrates properties of an example component 200, including a name 202(ImageAlter) of the component, a type 204 (independent), a version 206(1.0.1), a corelet (i.e., component) API version 208(3), a description 210 ("A corelet based on ImageMagic to image images localization server over the HTTP"), and an interface specification 212 including an operation specification 214 and a document 216. The interface specification 212 is used by the component execution logic 140 of FIG. 1A to register interfaces (as specified by the interface specification 212) and implementations as components 148. In one example, the component execution logic 140 may determine the interface of the component by extracting the name and parameter type of each operation from the interface specification 212. Implementations may include, for example, program code implemented in a language such as Ruby in the form of source, object, or bytecode, including native implementations (in languages such as C + + or the like) for accessing any portion of native operating system functionality. Once registered, the operations provided by the interface of the component are available for use by browser-based code 107. In this example, the interface 212 is specified in a textual format and includes a single operation named Alter. An example interface specification is: alter (< path > file, < integer > maxwidth, < integer > maxheight, < integer > rotation, < string > quality, < list > effects, < string > format.
Additional operations may be included in the interface by adding additional entries to the metadata in the form of the interface specification 212. Document 214 provides a description of an exemplary Alter operation, namely, "Alter an image and return a localhost URL by which the result may accessed". The documents 214 may be automatically converted for use in a development tool, such as an integrated development environment.
Fig. 3 is an explanatory diagram of a prompt displayed in a web browser to request permission to execute a component according to an embodiment of the present invention. Fig. 3 illustrates a prompt dialog box 300 showing a message indicating that a host computer (in this example, browser. yahoo. com) is requesting permission to use and activate a new service (i.e., component) on the user computer. This prompt requires the user to review the list of requested permissions 302 before approval. Requested permissions 302 include Display desktop notification (Display desktop notifications) permissions 304 and download and Activate service (download and Activate service) permissions 306. The display desktop notifies that the license has been allowed by the user, as indicated by the tick mark adjacent to the description of license 304. Download and activation license 306 includes further details regarding the service to be downloaded and activated, including notification (Notify) service description 308, which indicates that the notification service is a service that delivers desktop notifications. A decline (Deny) button 310 may be selected by the user to decline permission for download and activation. An Allow (low) button 312 may be selected to Allow the download to be performed and the service to be activated. Similar prompts may be displayed for user-defined components when they are called by browser-based code.
Fig. 4 and 5 are explanatory diagrams of a file upload component according to an embodiment of the present invention. The file upload component 400 allows the picture file to be dragged and dropped into area 410. File is subsequently uploaded to by the componentFig. 5 shows a picture 510 uploaded from a picture catalog. The interface also includes a component 520 for applying a transformation and a component 530 for adjusting the picture size. These components invoke local operations (e.g., ImageMagick library) on the user's computer to process the pictures within the web browser.
In one example, if a component is lost, the component execution logic 140 queries any number of distribution servers to find and retrieve the component, including resolving dependencies. The component 148 is versioned, i.e., associated with a version number, and the component version may be required by another component or by the plug-in interface 108 in the hierarchy of the end user machine 102. In one example, the component 148 is associated with a version that includes a major version number, a minor version number, and a micro-segment version number, forming a version, such as 2.0.1. The component has a unique name specified by the component provider's internet domain name, for example, combined with the name describing the component itself. Thus, an example component name is "com. The version designator may include a major number and a minor number, or a major number, a minor number, and a micro-segment number. The component version matches the version designator if all of the numbers appearing in the version designator are the same as the corresponding numbers in the component version. In one example, three lists are considered in determining how to satisfy a request for a component: which updates are available on the end user machine 102 (priority 1), the components that are installed (priority 2), and the components that are available from the network, e.g., from the distribution server 150 (priority 3).
According to an embodiment of the invention, a security mechanism is provided. The security mechanisms include secure user prompts, implicit consent, and secure resource representation. In one aspect, the secure user prompt includes displaying a dialog box with a prompt describing a particular operation to be performed. Hints describe operations using at least one component-specific term that refers to the type of object or service that the component operates on. For example, the prompt "low access to photos" refers to the term "photos," which is the type of object that allows access to the components of the photo to operate on. As another example, the prompt "low access via Instant Messaging" refers to the term "Instant Messaging," which is a type of service that allows access to components of an Instant Messaging operation to operate. In one example, component-specific terms are more specific than a description of the underlying operating system function(s) invoked by the component. For example, the operating system level operations for granting read permissions have a general description related to read permissions that is independent of any particular application or component object or service.
According to embodiments of the present invention, an implicit consent security feature refers to an affirmative consent to a user to perform an operation in response to a user action, where the response is not a response to an explicit request to grant permission to perform the operation. As an example of implicit consent, a user interacts with a computer in order to specify a file that is the starting point for a potentially risky operation. The component may interpret the interaction as a user consent to perform an operation on the file, such as a restricted system operation. Similarly, for other resource types, a component that controls access to the resource type may allow a user to perform operations on the resource type in response to the user interacting with the component's user interface in a particular manner. User interaction, e.g., with a user interface component, indicates that the user implicitly permits the operation to be performed. For example, a user action of dragging a file into a browser application displaying a web page provides such implicit consent: code associated with the web page may operate (e.g., read or write) to the specified file.
In another example, the system may render an in-context dialog (in-context dialog) to provide, for example, a user name and login credentials required by the component. This input is rendered by the plug-in community library 117 which is not under the control of the untrusted web page 106, in which case the user is not prompted for permission to perform an operation, such as "login to Flickr", but rather the acquisition of credentials may be integrated into the flow. In this case, the user may refuse to give the Flickr credential while using a particular website, and the end user will pay less mental effort. However, the end result is that the user is requested to approve the action without being controlled by the web page.
Implicit consent allows multiple user interaction steps to be combined into a single step. With implicit consent, the user is not explicitly requested to grant permission to perform the operation. Rather, the user's permission to perform the operation is inferred from the user's actions. Implicit consent improves security and eases the use of network interactions. In the Flickr upload example, the flow is as follows, for example. Without implicit consent, (1) the user accesses pages uploaded to Flickr but not the Flickr product; (2) the user is redirected to the Flickr page to authorize Flickr; (3) the user completes authorization for Flickr; (4) the user closes the window of the Flikcr page, returns to the original page, and completes authentication by clicking a button.
With implicit consent, the same authentication procedure is performed in fewer steps: (1) the user accesses a page uploaded to Flickr but not the Flickr product; (2) "secure dialog" appears on the page; the secure session handles authorization for Flickr without control of the original page; (3) the user inputs the voucher and clicks ok; and (4) the original page is automatically notified. The last step of the first flow, clicking on a button on the original page to indicate that authentication is complete, is no longer required with implicit consent. Further, subsequent accesses to the Flickr service can automatically provide the user's credentials to Flickr, so that when the login expires, the user need not provide the credentials again. Credentials are securely and trustfully maintained by the Flickr component.
In the Flickr Login example, a component requests permission to perform an operation requiring login credentials, such as logging onto Flickr. The web page calls the functions authorized for Flickr. The prompting for credentials and the transmission of authorization requests is performed by core services 142 under the direction of a Flickr access component (e.g., FlickerUploader shown in component 148) and is not under the control of the page. When the authorization request is completed, the web page receives a return value, which may be "authorized", "user denied authorization", or "authorization failed (poor credentials)". Security is enhanced because the web page does not have access to user credentials (e.g., login name and password) for authenticating the site being executed.
In another example, to interact with a network-accessible camera (webcam), with explicit consent, (1) a user accesses a web page that provides a web cam feature; (2) the user clicks the "take a picture from webcam" button; (3) the user is prompted to permit taking a picture without control of the web page; and (4) the user clicks the "Capture" button to take the picture. With implicit consent, the same webcam interaction is performed in fewer steps: (1) the user accesses the web page; (2) the user is presented with a dialog showing the current webcam view (the dialog is not controlled by the web page); (3) the user clicks the "Capture" button, granting the website implicit consent to use webcam. According to embodiments of the invention, a secure resource representation is generated by this user interaction and may be accessed in JavaScript code as a secure resource identifier. The identifier is tied to a specific resource, such as a file, and cannot be changed by browser-based (e.g., JavaScript) code. In one aspect, the identifier is a random, unique number that can be referenced, but cannot be changed to refer to a different file or other resource. The lifetime of the file selection is based on the lifetime of the page, so the identifier becomes invalid after the page is closed by the browser.
Component implementations prompt the end user independently of browser-based code (e.g., JavaScript) on the web page. Thus, the component code is bound by a response provided by the user, such as granting (positive) or denying (negative) permission. In one aspect, any operation that may be security sensitive, such as any operation that may access or delete stored information or may use a network connection, has a potential security risk and should be protected by a secure user prompt, or in one example by verifying a certified license object corresponding to the operation.
In one example, a white-list (white-list) feature may be provided to enable or disable execution of a particular component or a particular version thereof on a particular website. The white list entries permit the site to use a particular component. Distribution server 150 distributes the endorsed distribution file that includes a white list of domains that are permitted to use the component, a black list of components to be purged (e.g., deleted), and a black list of platform versions to be purged. For example, if the plate of the assemblyIf the version 1.0.1 is known to have defects, then the blacklist feature may be used to prevent future execution of the version 1.0.1. The white list feature may be controlled by the user. For example, a music site may use an Apple to import songs directly to a userA component in a music player catalog. The component may request that the user allow import once, allow each import, or never allow.
In one example, a client using the plugin interface platform 108 of FIG. 1A includes a blacklist feature to clear a component and/or a specified version thereof. The client downloads a digitally signed package containing a license package (permission bundle). The download may occur at a designated time or periodically, in response to a message received from the server, or at other times. The permission package includes a revocation list listing one or more components to be purged and corresponding versions. Any installed components on the revocation list are purged and any subsequent attempts to reinstall the purged components are not successful. The plug-in interface platform 108 itself may be remotely disabled by a designated entity in the clearance list.
New versions of components may be obtained from time to time. Due to the large number of components that may be installed on the end-user machine 102, keeping all components installed up-to-date may adversely affect performance and/or consume resources excessively. When a user visits a site that uses a component, the site expresses the component requirements as requirement statements, such as component name, version, and minimum version triplet code. All the requirements that have been requested recently are stored. The update check periodically clears out-of-date demand statements and checks the distribution server for those components that meet the remaining current demand and are newer versions of components currently installed on the machine 102. Any such newer versions are downloaded in the background, e.g., without stopping any executing components, and stored in the update cache. Then, if web browser 104 accesses a site that expresses a need to be better served by available cached updates, the user is prompted for permission to install the downloaded updates. Expired components may be identified and deleted, for example, by finding components that are not being used to meet current demand and are not being used for an extended period of time. These components may be purged from the machine 102 with minimal negative impact.
FIG. 6 illustrates a typical computing system 600 that may be used to implement processing functionality in embodiments of the invention. Computing systems of this type may be used, for example, in clients and servers. Those skilled in the art will also recognize how to implement the invention using other computer systems or architectures. Computing system 600 may represent, for example, a desktop, laptop or notebook computer, handheld computing device (PDA, cell phone, palmtop, etc.), mainframe, server, client, or any other type of special or general purpose computing device as may be desired or appropriate for a given application or environment. Computing system 600 may include one or more processors, such as a processor 604. Processor 604 can be implemented using a general or special purpose processing engine such as, for example, a microprocessor, microcontroller or other control logic. In this example, processor 604 is connected to a bus 602 or other communication medium.
Computing system 600 may also include a main memory 608, such as Random Access Memory (RAM) or other dynamic memory, for storing information and instructions to be executed by processor 604. Main memory 608 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 604. Computing system 600 may likewise include a read only memory ("ROM") or other static storage device coupled to bus 602 for storing static information and instructions for processor 604.
Computing system 600 may also include information storage system 610, which may include, for example, a media drive 612 and a removable storage interface 620. The media drive 612 may include a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a CD or DVD drive (R or RW), or other removable or fixed media drive. Storage media 618, for example, may comprise a hard disk, floppy disk, magnetic tape, optical disk, CD or DVD, or other fixed or removable medium that is read by and written to by media drive 612. As these examples illustrate, the storage media 618 may include a computer-readable storage medium having stored therein particular computer software or data.
In alternative embodiments, information storage system 610 may include other similar components for allowing computer programs or other instructions or data to be loaded into computing system 600. Such components may include, for example, a removable storage unit 622 and an interface 620, such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units 622 and interfaces 620 that allow software and data to be transferred from the removable storage unit 618 to computing system 600.
Computing system 600 may also include a communications interface 624. Communications interface 624 may be used to allow software and data to be transferred between computing system 600 and external devices. Examples of communications interface 624 include a modem, a network interface (e.g., an ethernet or other NIC card), a communications port (e.g., a USB port), a PCMCIA slot and card, and so forth. Software and data transferred via communications interface 624 are in the form of signals which may be electrical, electromagnetic, optical or other signals that are received by communications interface 624. These signals are provided to communications interface 624 via a channel 628. This channel 628 may carry signals and may be implemented using a wireless medium, wire or cable, fiber optics, or other communications medium. Some examples of a channel include a phone line, a cellular phone link, an RF link, a network interface, a local or wide area network, and other communication channels.
In this document, the terms "computer program product," "computer-readable medium," and the like may be used generally to refer to media such as memory 608, storage device 618, or storage unit 622. These and other forms of computer-readable media may be involved in storing one or more instructions for use by processor 604, to cause the processor to perform specified operations. These instructions, which are generally referred to as "computer program code" (which may be grouped in the form of computer programs or other groupings), when executed, cause the computing system 600 to perform features or functions of embodiments of the present invention. Note that the code may directly cause the processor to perform specified operations, may be compiled to do so, and/or may be combined with other software, hardware, and/or firmware elements (e.g., libraries for performing standard functions) to do so.
In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into computing system 600 using, for example, removable storage drive 614, drive 612 or communications interface 624. The control logic (in this example, software instructions or computer program code), when executed by the processor 604, causes the processor 604 to perform the functions of the invention as described herein.
It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processors or domains may be used without detracting from the invention. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Thus, references to specific functional units are only to be seen as references to suitable means for providing the described functionality rather than indicative of a strict logical or physical structure or organization.
Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the invention is limited only by the claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention.
Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by e.g. a single unit or processor. Furthermore, although individual features may be included in different claims, these may possibly advantageously be combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Furthermore, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather the feature may be equally applicable to other claim categories, as appropriate.
In addition, it will be understood that various modifications and alterations may be made by those skilled in the art without departing from the spirit and scope of the invention. The invention is not to be limited by the foregoing illustrative details, but rather is to be defined according to the claims.
Although only certain exemplary embodiments have been described in detail above, those skilled in the art will readily appreciate that many modifications are possible in the exemplary embodiments without materially departing from the novel teachings and advantages of this invention. Accordingly, all such modifications are intended to be included within the scope of this invention.