Patent Application
20130205385
Different strategies exist for enabling an application to interact with a user-owned resource. As used herein, a user-owned resource refers to any functionality, control setting, or data associated with a user who interacts with a user device. For example, one type of user-owned resource may correspond to a camera resource that is provided by the user device.
On one extreme of the design spectrum, an access strategy may treat all user-owned resources as global resources. This permits any application that is installed on the user device to access any user-owned resource without restriction. A traditional desktop environment that runs on a personal computer uses this type of an access strategy. That is, an application that runs using the desktop system can generally access any of the resources provided by the personal computer by virtue of the fact that the user has permitted the application to be installed on the personal computer. On the opposite extreme of the design spectrum, an access strategy may treat each application as an isolated principal that has no access to any user-owned resource under any circumstance. Some types of traditional browser systems use this type of an access strategy or a variation of this type of access strategy. For instance, a web application that runs using this type of browsing system is generally not allowed to access the user-owned resources installed on the computer device which runs the browsing system.
The first-mentioned access strategy is not optimal because an application may represent a malicious entity which can access and utilize the user's resources in undesirable ways. The second access strategy is not optimal because an application may have a legitimate need to access a user-owned resource. Preventing the application from accessing a resource in this circumstance therefore reduces the utility of the application, or may force the application to rely on less efficient work-around solutions to access the user-owned resource. For example, a browser system may rely on a browser add-on to interact with a user-owned resource. But many browser add-ons enjoy overly broad access rights with respect to certain user-owned resources, and thereby may subject the user to undue security risks.
To address the above shortcomings, the industry has proposed various intermediate access strategies, e.g., for use on smartphones. In one case, an access strategy may treat the applications as isolated entities. When an application requires access to a user-owned resource, a system which runs the application can display a prompt to the user, asking the user whether to grant the application permission to access the user-owned resource. This strategy is not optimal, however, because the user may perceive the prompts as bothersome. In addition, the user may simply answer such prompts in the affirmative in rote fashion, e.g., without fully considering the rights being conferred. In another case, an access strategy involves providing a manifest which describes the access rights conferred to an application. Upon installing an application, the access strategy may ask the user to accept or decline the permission rights described in the manifest. This access strategy, however, is also not optimal because a user may not readily understand the nature of the rights described in the manifest. Further, the manifest may grant the application overly broad access rights.
The above-noted potential shortcomings are set forth by way of illustration, not limitation. Known access strategies may suffer from additional potential drawbacks.
An access system is described herein which allows an application to access a user-owned resource based on a user's interaction with an intent-based access mechanism (IBAM). That is, the access system interprets this interaction as conveying the user's implicit and authentic intent that the application be allowed to access the user-owned resource. The IBAM may be implemented, in part, using a resource monitor which mediates access to the user-owned resource.
According to one implementation, the IBAM corresponds to a gadget that is embedded in an application user interface provided by the application. In another case, the IBAM corresponds to logic for detecting a permission-granting (PG) input sequence that a user may use while interacting with the application.
According to one illustrative feature, the access system accommodates different types of IBAMs and corresponding resource monitors, such as a single-transaction access IBAM, a session-based access IBAM, a permanent access IBAM, a scheduled IBAM (which permits access based on at least one scheduling condition), etc.
According to another illustrative feature, the access system includes a composite IBAM and an associated composite resource monitor that mediates access to two or more user-owned resources.
According to another illustrative feature, the IBAM and its associated resource monitor may represent system-level functionality which mediates access to at least one system-level resource, such as a camera, a printer, a location device, message-sending functionality, a clipboard store, etc. In another case, the IBAM and its associated resource monitor may represent application-specific functionality which mediates access to at least one application-specific resource via an interface provided by a hosting application.
A content-view gadget represents an example of an application-specific IBAM. A first hosting application may expose the content-view gadget to ensure authentic interaction with its application-maintained data, via its exposed application programming interface (API). A second application may embed the content-view gadget in its application user interface to convey the user's authentic intent to grant the second application permission to invoke the API of the first hosting application on the user's behalf.
According to another feature, the access system includes a mechanism for determining whether a specified application permits the IBAM to be embedded (in an active state) in the application user interface provided by the specified application. If the application user interface is nested in one or more ancestor application user interfaces, this determination involves examining the permissions granted by the associated ancestor applications.
According to one possible benefit, the access system allows applications to access user-owned resources in a contextual manner that is not unduly burdensome to users. At the same time, the access system confers access rights that are narrowly tailored (e.g., conforming to a least-privilege paradigm of resource access), thereby not compromising the security of user-owned resources and other functionality associated with the access system.
The above approach can be manifested in various types of systems, components, methods, computer readable media, data structures, articles of manufacture, and so on.
This Summary is provided to introduce a selection of concepts in a simplified form; these concepts are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
The same numbers are used throughout the disclosure and figures to reference like components and features. Series 100 numbers refer to features originally found in
This disclosure is organized as follows. Section A describes an illustrative access system for allowing applications to access user-owned resources based on the user's interaction with intent-based access mechanisms. Section B describes illustrative methods which explain the operation of the access system of Section A. Section C describes illustrative computing functionality that can be used to implement any aspect of the features described in Sections A and B.
As a preliminary matter, some of the figures describe concepts in the context of one or more structural components, variously referred to as functionality, modules, features, elements, etc. The various components shown in the figures can be implemented in any manner by any physical and tangible mechanisms, for instance, by software, hardware (e.g., chip-implemented logic functionality), firmware, etc., and/or any combination thereof. In one case, the illustrated separation of various components in the figures into distinct units may reflect the use of corresponding distinct physical and tangible components in an actual implementation. Alternatively, or in addition, any single component illustrated in the figures may be implemented by plural actual physical components. Alternatively, or in addition, the depiction of any two or more separate components in the figures may reflect different functions performed by a single actual physical component.
Other figures describe the concepts in flowchart form. In this form, certain operations are described as constituting distinct blocks performed in a certain order. Such implementations are illustrative and non-limiting. Certain blocks described herein can be grouped together and performed in a single operation, certain blocks can be broken apart into plural component blocks, and certain blocks can be performed in an order that differs from that which is illustrated herein (including a parallel manner of performing the blocks). The blocks shown in the flowcharts can be implemented in any manner by any physical and tangible mechanisms, for instance, by software, hardware (e.g., chip-implemented logic functionality), firmware, etc., and/or any combination thereof.
As to terminology, the phrase “configured to” encompasses any way that any kind of physical and tangible functionality can be constructed to perform an identified operation. The functionality can be configured to perform an operation using, for instance, software, hardware (e.g., chip-implemented logic functionality), firmware, etc., and/or any combination thereof.
The term “logic” encompasses any physical and tangible functionality for performing a task. For instance, each operation illustrated in the flowcharts corresponds to a logic component for performing that operation. An operation can be performed using, for instance, software, hardware (e.g., chip-implemented logic functionality), firmware, etc., and/or any combination thereof. When implemented by a computing system, a logic component represents an electrical component that is a physical part of the computing system, however implemented.
The phrase “means for” in the claims, if used, is intended to invoke the provisions of 35 U.S.C. §112, sixth paragraph. No other language, other than this specific phrase, is intended to invoke the provisions of that portion of the statute.
The following explanation may identify one or more features as “optional.” This type of statement is not to be interpreted as an exhaustive indication of features that may be considered optional; that is, other features can be considered as optional, although not expressly identified in the text. Finally, the terms “exemplary” or “illustrative” refer to one implementation among potentially many implementations.
A. Illustrative Systems
A.1. Overview of the Access System
As used herein, an application refers to any type of functionality for performing any function. In some cases, an application can perform a high-level task. To name just a few possible high-level tasks, an application can perform a word-processing function, an image editing function, a social networking function, any business-related function, and so on. In another case, an application can perform a lower-level support task. To name just a few possible low-level tasks, an application can perform a file management task, a communication-related task, and so on.
An application can be implemented in any manner. For example, in one case, an application can represent a body of code that executes on any code runtime system. In another case, an application can represent a body of markup language content and/or script content that executes on a browser system, and so on. The functionality of an application can be implemented locally and/or remotely with respect to the user device 106.
A user-owned resource represents any functionality or information that is associated with a particular user and controlled by that user. Some user-owned resources may pertain to system-level resources associated with the user device 106 or other environment in which the applications 102 are executed. These system-level resources can be accessed by different applications, and therefore may be regarded as application-agnostic resources. Without limitation, for instance, system-level resources may encompass physical equipment, such as a camera, a location device (e.g., a GPS device), a motion-sensing device (e.g., an accelerometer), a printer, a microphone, a speaker, a message-transmission mechanism (e.g., an SMS-transmission mechanism), etc. The system-level resources can also encompass software-implemented functionality (e.g., virtual equipment), such as a clipboard store (for storing data in response to a copy or cut command), a transitory clipboard store (for storing data in response to the commencement of a drag operation), a contact list store, a user preference store, an autocomplete store (for storing data entered into a form), and so on. The system-level resources can also encompass control settings and device capabilities of any type that affect any component of the user device 106 (and/or the user device 106 as a whole, and/or any peripheral device associated with the user device 106). For example, a resource can correspond to a user-controlled ability to wipe or reboot the user device 106.
Other user-owned resources may pertain to application-specific resources. These are resources that are maintained by or otherwise associated with particular hosting applications. For example, the application-level resources may encompass data, services, etc. provided by an application. The data may correspond to any type of data, such as text data, control settings, image data, audio data, video data, markup language data, etc.
Any user-owned resource can be provided at a site that is local or remote with respect to the user device 106, or by a combination of sites. For example, a camera may represent a system-level resource that is a component of the user device 106. In another case, a user contact list may represent an application-specific resource that is provided by social networking application that is remotely located with respect to the user device 106. Another type of application-specific resource may correspond to a user's document repository maintained at a remote file storage site, and so on.
The above-described types of user-owned resources are mentioned by way of example, not limitation. Other environments can accommodate the inclusion of additional types of user-owned resources, and/or can omit one or more types of user-owned resources described above.
By way of overview, the access system 100 provides a security environment that is characterized by prescribed default behavior. In one implementation, for instance, the access system 100 isolates each principal from every other principal, such as by isolating each application from every other application. The access system 100 can achieve isolation in various ways, including, but not limited to, process-based isolation, language-based isolation, virtual machine-implemented isolation, and so on. The access system 100 can define distinct applications in any manner, such as by treating applications which originate from different sources as distinct applications.
Further, the access system 100 permits an application to access a user-owned resource on the basis of a least-privilege mode of access. This means that access system 100 permits an application to access only those resources that it needs to perform its services. Otherwise, by default, the access system 100 does not allow any application to access any of the user-owned resources described above. The access system 100 does, however, permit an application to access basic system resources, such as CPU resources, memory resources, communication resources, etc.
To achieve the above-described behavior, the access system 100 uses at least one type of intent-based access mechanism (IBAM). An IBAM receives an input action from the user which implicitly conveys the user's authentic intent to allow an application to access a particular user-owned resource (or a particular combination of user-owned resources). If the user performs such an action, the access system 100 will grant the application access to the user-owned resource based on knowledge that the IBAM has received authentic user input. The rights conferred by this action are narrowly tailored because they apply to only a particular user-owned resource (or combination of resources), rather than all user-owned resources. Further, in many cases, the rights have a limited duration (to be described below). Further, the rights apply in a limited context to the application with which the user is currently interacting.
By virtue of the above-summarized manner of granting privileges, the access system 100 can offer a user-friendly interaction experience to a user. This is because the access system 100 need not burden the user with special-purpose prompts and permission-based dialogs that are extraneous to the user's interaction with an application. At the same time, due to the manner in which it narrowly confers access rights, the access system 100 reduces the risk that malicious applications and other malicious entities may improperly gain access to sensitive user-owned resources.
Nevertheless, the access system 100 can also use prompts and dialogs (and the like) as supplemental security provisions. That is, while the access system 100 does not require the use of such security provisions, it does not preclude the use of them. For example, the access system 100 may opt to use prompts when the IBAM grants permanent (but revocable) access to a user-owned resource. This is because this type of access poses greater risk that a malicious application can gain improper access to a user-owned resource, compared to one-time or session-based access.
The access system 100 can gauge the user's access-related intent in at least two ways described below. In a first technique, the IBAM may correspond to a gadget that is embedded in an application user interface (UI). Here, the access system 100 determines the user's intent based on the manner in which the user interacts with the gadget while interacting with the application UI. In a second technique, the IBAM corresponds to logic for detecting a permission-granting (PG) input sequence. The PG input sequence corresponds to a telltale gesture that the user may perform while interacting with the application using one or more input devices. That is, the gesture can be composed of one or more triggering input events, applied at the same time or in series, produced by the user using one or more input devices. For instance, the PM input sequence can be expressed using one or more key actuations (e.g., by pressing Ctrl-P to print), a mouse gesture, a touch gesture, a voice command, a device-movement gesture, a static or dynamic hand or body gesture (which can be detected in image or video data), etc., or any combination thereof.
First consider the use of gadgets, also referred to herein as access control gadgets or ACGs. A gadget refers to a UI element. The access system 100 presents the gadget on a display mechanism of the user device, such as on a display monitor of a personal computer or the touch screen of a smart phone. More specifically, the access system 100 presents the gadget in the context of an application UI provided by an application. As such, a user perceives the gadget as forming an integral part of the application UI. The gadget itself has at least one user interface control mechanism that allows a user to interact with the gadget. The gadget also can have any size, shape, informational content, style, etc. For instance, a gadget may resemble a button, a panel, a menu, a slider mechanism, etc.
For example, consider the high-level depiction provided by
A user may interact with the gadget 110 to enable the application A to receive data from the user-owned resource N, or to provide data to the user-owned resource N, or to change the status of the user-owned resource N, etc. That is, the particular nature of the gadget 110 determines the type of access action that is invoked by the gadget 110. By default, however, the application A has no privileges to access any user-owned resource, including the user-owned resource N.
The access system 100 uses a resource monitor Y to provide the gadget 110. The resource monitor also plays a role in mediating access by the application A to the resource N (in a manner that will be described in greater detail below). In other words, the resource monitor Y exposes an interface which allows the application A to interact with the resource N, via the resource monitor Y.
More generally stated, the access system 100 provides a collection of resource monitors 112 that are associated with respective gadgets. Each resource monitor is associated with a particular type of user-owned resource. For example, the resource monitor X may be associated with different types of available printers, the resource monitor Y may be associated with different types of available cameras, and so on.
In other cases, a single resource monitor can implement two or more related gadgets. Further, in some cases, a single composite resource monitor (and associated composite gadget) may mediate access to two or more types of user-owned resources. For example, a composite resource monitor may provide access to both a camera device and a location device (e.g., a GPS device).
The access system 100 can isolate each resource monitor (and associated gadget) from each other. Further, the access system 100 can isolate each application from any resource monitor that presents gadgets which are embedded in the application's UI. This means, for instance, that the application A cannot control the pixels that are presented in the display space associated with the gadget 110; nor can the resource monitor Y control the pixels that are presented in the application UI 108. Further, as will be explained below in greater detail, in some cases, the access system 100 can isolate a resource monitor from content that appears in a gadget that is provided by the resource monitor. All of these provisions reduce the opportunities by which a malicious application or other entity may gain improper access to user-owned resources. Informally stated, these provisions reduce the “attack surface” of particular operations performed by the access system 100 or particular features of the access system 100.
The resource monitors 112 can be implemented in different ways. In one merely illustrative case, each resource monitor corresponds to a code module that runs on a layer between the applications 102 and an operating system 114 of the user device or other application-execution environment. In one implementation, a developer or other software provider can provide certain resource monitors as complementary functionality to the operating system 114. In addition, or alternatively, any user may independently install additional resource monitors, obtained from any source, such as a remote resource monitor (RM) store 116. To complement this manner of operation, the access system 100 can include functionality which allows the user to query the access system 100 to discover what resource monitors 112 have been installed in the access system 100.
Consider next the implementation of IBAMs as logic for detecting permission-granting (PG) input sequences. As stated above, a PG input sequence refers to a telltale action performed by the user while interacting with an application, using one or more input mechanisms. The access system 100 correlates each recognized gesture to a particular access-related action that affects a particular user-owned resource. For example, the access system 100 can interpret a first gesture as a request to copy data from an application into a clipboard store. The access system 100 can interpret a second gesture as a request to “paste data,” i.e., to copy data from the clipboard store into the application, and so on. Beyond these types of narrowly-drawn access privileges, the application does not have rights to access any user-owned resources.
In one implementation, a resource monitor may be associated with each PG gesture. Each resource monitor is further associated with a particular type of user-owned resource. However, in some cases, a single resource monitor can detect two or more PG input sequences. Further, in some cases, a single composite resource monitor may mediate access to two or more types of user-owned resources.
An operating system vendor or other appropriate entity may prescribe a rule that no two resource monitors are permitted to define the same global PG input sequence in different ways. However, an application can “internally” redefine an action to be performed when a user executes a PG input sequence. For example, assume that the access system 100 interprets the simultaneous pressing of the Ctrl and C keys as a request to transfer data from the application to a clipboard store. An application can respond to this gesture by performing some other application-centric function, effectively ignoring the fact that the access system 100 may have also stored data from the application into the clipboard store.
In certain cases, an application can also perform application-centric functions which are related to the functions invoked by the PG input sequences that are recognized by the access system 100. For example, an application can interpret an application-centric PG input sequence “yy” as a request to copy data between sub-modules provided by the application. This internal copy operation, however, does not entail storing the data in the clipboard store unless the user also activates the application-agnostic gesture (e.g., by pressing Ctrl and C) which invokes this function.
The access system 100 can employ yet other IBAMs for assessing the intent of the user to access user-owned resources (besides, or in addition to, the use of gadgets and PG input sequences). In general, an IBAM that mediates access to a system-level resource is referred to as a system-level IBAM, providing by a system-level resource monitor. An IBAM that mediates access to an application-specific resource is referred to as an application-specific IBAM, providing by an application-specific resource monitor.
A.2. An Illustrative Application
The access system 100 can carry out the functions described above in different ways. Generally, the access system 100 provides different functional “actors” that may perform different roles to accomplish an access-related transaction. These actors include at least one application, at least one resource monitor, at least one user-owned resource, and the operating system 114 of the execution environment. The description which follows provides examples in which the access system 100 assigns particular roles to these particular actors when performing particular access-related transactions. However, these examples are set forth by way of illustration, not limitation; other implementations can allocate tasks to the actors in the access system 100 in a different manner than is set forth in the detailed examples.
The application 202 can include functionality that enables it to interact with the various components of the access system 100 shown in
The gadget invocation module 204 can specify various parameters which govern the presentation of the gadget within the application UI. A first parameter can specify the location within the application UI at which the gadget is to be displayed. A second parameter provides an identifier of the user-owned resource associated with the gadget. A third parameter can specify the type of gadget which is to be displayed (and, by implication, the type of function that will be invoked by activating the gadget). An optional fourth parameter can specify the duration of the access rights that will be conferred upon activation of the gadget.
With respect to the duration parameter, in one case, a gadget can confer single-transaction access rights which allow the application 202 to access a user-owned resource for only a single transaction (such as a single camera access). In another case, the gadget can confer session-based access rights which allow the application 202 to access a user-owned resource until an application session terminates, e.g., which may be triggered by a user closing the application 202. In another case, the gadget can confer scheduled access rights which allow the application 202 to access a user-owned resource based on at least one scheduling condition, such as by allowing the application 202 to access the user-owned resource at a particular time or times, and/or at a particular location or locations. In another case, the gadget can confer permanent access rights to a user-owned resource that extend over multiple application sessions. These examples are cited by way of illustration, not limitation. Further, the access system 100 can also permit a user to expressly revoke any type of extended permission granted to the application 202, regardless of whether the application 202 is running at the time of revocation. (Extended types of permission include session-based, scheduled, and permanent access rights.)
For example, the gadget invocation module 204 can be implemented by sending a system call EmbedACG( ) to the operating system 114. For instance, the statement EmbedACG((x, y), “camera”, “take-picture”, one-time”) instructs the access system 100 to present a gadget at the location (x, y) within an application UI provided by the application 202. The gadget interacts with the camera (“camera”). The gadget type is “take-picture,” meaning that it operates to push a picture captured by the camera to the application 202. And its duration is “one-time,” meaning that the permission that is invoked upon activating the gadget lasts for only a single picture-taking instance. That is, the user can capture multiple pictures by pressing the gadget multiple times.
The application 202 may also include a permission-checking module 206. The permission-checking module 206 determines whether a child application, embedded in the application 202 (if any), is permitted to utilize the IBAM. In
Section B provides details pertaining to one manner of operation of a permission-checking protocol performed by the operating system 114. By way of overview, the permission-checking protocol grants permission to the application 202 to embed the gadget if: (a) the application UI provided by the application 202 is not nested in any other application UI provided by any other application; or (b) the application UI provided by the application 202 is nested in at least one ancestor application UI, but the ancestor application(s) which control these ancestor application UI(s) permit the application 202 to embed the gadget into its application UI.
For example, again consider
The operating system 114 can trigger the permission-checking module 206 in the application A (of
The application 202 can also include a data handling module 208 for handling various operations that involve the manipulation of data, in response to the various upcalls sent by the operating system 114 (note that the operating system 114 is the entity which sends all upcalls). For example, the data handling module 208 can receive a PushContent upcall which instructs the application 202 to accept data sent by the operating system 114. The data handling module 208 can receive a PullContent upcall which instructs the application 202 to supply data to the operating system 114. The data handling module 208 can also receive an IsDraggable upcall and/or an IntermediateEvent upcall when the access system 100 is employed to perform a drag-and-drop operation, as will be explained in greater detail at a later juncture of this explanation. The parameters of these upcalls can specify: the Window ID (WindowId); the nature of the data manipulation operation to be performed (eventName); and one or more other case-specific arguments (eventArgs). For example, in one case, eventArgs can specify the data to be pasted into the application 202 in a PushContent upcall.
A.3. An Illustrative Resource Monitor
The resource monitor 402 can include functionality that enables it to interact with the various components of the access system 100 shown in
The resource monitor 402 also includes a status management module 406 for monitoring events which affect the status of the gadget or the PG input sequence. For example, the status management module 406 can receive a Startup upcall from the operating system 114 that instructs the resource monitor 402 to commence its operation, e.g., by providing a gadget or activating a PG input sequence detection process. The status management module 406 can also receive a LostFocus upcall from the operating system 114 which indicates that the user is no longer actively interacting with the gadget provided by the resource monitor 402. The status management module 406 can also receive an EmbeddingAppExit upcall from the operating system 114 which indicates that the user has closed the application associated with the gadget or PG input sequence being handled by the resource monitor 402. The gadgetId parameter identifies a particular type of gadget, the appId parameter identifies the application in which the gadget is embedded, and the appHandle provides a handle of a running instance of the application.
An access management module 408 handles tasks relating to the mediated transfer of data from a source to a destination. The access management module 408 performs its operation in response to receiving an InputEvent upcall from the operating system 114. The operating system 114, in turn, sends the InputEvent upcall when a user interacts with the gadget associated with the resource monitor 402 or performs the PG input sequence associated with the resource monitor 402.
The access management module 408 can respond to the InputEvent upcall in at least one of three ways, depending on the type of gadget or PG input sequence that is associated with the resource monitor 402 in question. To simplify the illustration,
In a first case, the gadget or PG input sequence grants an application session-based or permanent access to the user-owned resource associated with the resource monitor 402. To do this, the access management module 408 makes an appropriate change in an access state storing module 410 to indicate that the application in question (identified by appId) is to be given appropriate access to the user-owned resource (where the duration of that access is conveyed by the type of gadget or PG input sequence that has been invoked).
In a second case, the gadget or PG input sequence grants an application one-time access to a particular user-owned resource. To do this, the access management module 408 sends an InitContentTransfer call to the operating system 114. That transfer call instructs the operating system 114 to push or pull appropriate data to or from a destination location (dest) or source location (src), respectively.
In a third case, the gadget or PG input sequence grants an application scheduled access to a particular user-owned resource, such as by granting the application access to the user-owned resource at a particular time or times, and/or at a particular location or locations. In this case, the access management module 408 automatically generates input events, rather than receiving such upcalls from the operating system 114. That automatically-generated event simulates the user's actuation of a gadget or PG input sequence in accordance with the designated scheduling condition(s). A scheduling control module 412 stores the scheduling condition(s) which govern the timing at which the access management module 408 is invoked in this manner. (Alternatively, the operating system 114 can implement the scheduling control module 412.) A user may prefer to grant scheduled access, rather than permanent access, to more effectively promote the goal of least-privileged access, and thereby reduce the risk of improper access to user-owned resources.
Finally, the resource monitor 402 can include any other logic 414 for performing any other respective function(s). For example, the other logic 414 can include a discovery mechanism that enables applications to discover the user-owned resources that are associated with the resource monitor 402. For example, suppose that the resource monitor 402 mediates access to all cameras installed by the user device 106. The discovery mechanism may store information regarding these available cameras. The application can query the discovery mechanism to access this information for any reason. Next suppose that the user or some other agent installs another type of camera in the user device 106. The discovery mechanism can add that new camera to its description of available cameras. Further, the gadget UI-providing module 404 can optionally incorporate new UI features that address any newly-encountered control features that may be used by the new camera device.
A.4. An Illustrative Operating System
To begin with, the operating system 114 includes a binding module 502 which responds to an EmbedACG call, made by an application, to embed a particular gadget within the application UI of the application, or to commence detection using a particular PG input sequence. For the case of gadgets, the binding module 502 responds to the EmbedACG call by starting the appropriate resource monitor process, binding embedded region(s) of the UI space to the resource monitor, and notifying the resource monitor of the activation of the gadget using a Startup upcall.
The binding module 502 can also work in conjunction with a permission-checking module 504 to determine whether a particular application is permitted to use a gadget or PG input sequence. It performs this task by sending a CheckNestedPermission upcall to any ancestor application(s) in which the specific application is nested. Section B provides further details regarding the operation of the permission-checking module 504.
An action detection module 506 detects various events that may occur which affect the access system 100, and sends appropriate upcalls to the appropriate resource monitor(s) in response. For example, the action detection module 506 can detect whenever the user activates a gadget or PG input sequence (e.g., by clicking the gadget with a mouse device, contacting a touch-sensitive gadget with a finger and/or stylus, producing the triggering input events associated with a PG input sequence, etc.). In response, the action detection module 506 will send an InputEvent upcall to the appropriate resource monitor (which is associated with the gadget or PG input sequence). That InputEvent causes the resource monitor to mediate a one-time grant of access rights or an extended grant of access of rights, depending on the type of IBAM that has been activated. In another case, the action detection module 506 detects when a user stops actively interacting with a gadget, and, in response, sends a LostFocus upcall to the appropriate resource monitor. In another case, the action detection module 506 detects when the user closes an application in which a gadget or PG input sequence was active, and, in response, sends an EmbeddingAppExit upcall to the appropriate resource monitor.
A discrete transfer module 508 executes a discrete transfer operation by sending a PullContent upcall to an application or other principal, a PushContent upcall to an application or other principal, or both a PullContent upcall and a PushContent upcall. The discrete transfer module 508 also can also send the IsDraggable and IntermediateEvent upcalls in the course of performing a drag-and-drop operation (as will be described in Section B). Any resource monitor can trigger the operation of the discrete transfer module 508 by sending it an InitContentTransfer system call.
Finally, the operating system 114 can include an interface management module 510 which implements various security-related safeguards. For example, the interface management module 510 can enforce a policy which achieves the default isolation behavior described in Section A.1.
Further, the interface management module 510 does not permit the user to interact with a gadget unless the gadget is fully visible (meaning that no object overlays any part of the gadget). For example, the interface management module 510 can display the gadget in a grayed-out mode of presentation if the gadget is at least partially obscured by another display object. This provision reduces the chances that a malicious entity may overlay information on top of a gadget with the intent of fooling the user into clicking on the gadget, when the user would not otherwise perform this action. The interface management module 510 can also allow a user to interact with a gadget only after it has been displayed in the same location for a minimum amount of time (e.g., 200 ms in one example).
As another safeguard, the interface management module 510 can dispatch user input events originating from physical devices (e.g., keyboard, touchscreen, mouse, or microphone) only to the in-focus application. This means that no application can artificially generate user input for other applications. Thus, when the gadget is in focus and the user acts on it, the user's input, dispatched to the corresponding resource monitor, is guaranteed to be authentic. As a related safeguard, the interface management module 510 can manage the visual feedback sent to a gadget, e.g., by ensuring that a cursor is displayed when the user hovers over a gadget. This provision can prevent, for example, a rogue application from confusing the user as to where the user is clicking within a UI space.
The above-described restrictions pertain to one particular implementation, rather than outright prohibitions. That is, other implementations can remove or relax the above restrictions in any manner that is deemed appropriate for a particular environment. Alternatively, or in addition, other implementations can introduce additional restrictions and/or increase the restrictiveness of existing constraints (e.g., by increasing the minimal amount of time that a gadget is required to be visible before input can be accepted).
The interface management module 510 can also host functionality which displays a control panel to the user, upon request from the user. The control panel displays the access rights granted to each application at a particular point in time. The user may also interact with the control panel to revoke any prior-granted permission. More specifically, the user can revoke the access rights that have been granted to an application even though, at the present time, the application has been closed and is no longer running.
The operating system 114 also includes any other logic 512 for performing any other functions.
As a final note, any of the functions attributed to the operating system 114 can also (or alternatively) be performed by other components of the access system 100, such as the resource monitors 112. Alternatively, or in addition, any of the above-described functions attributed to the resource monitors 112 can instead be performed by the operating system 114 or other components of the access system 100.
A.5. Application-Specific IBAMs
As noted in Section A.1, a resource monitor may mediate access to different types of user-owned resources, such as system-level resources and application-specific resources. Application-specific resources are assets that are hosted by a particular application. This section provides additional information regarding one manner in which the access system 100 can implement application-specific IBAMs, which mediate access to application-specific resources.
Consider the framework shown in
In the configuration of
Later sections describe a content-view gadget which represents one example of an application-specific IBAM.
A.6. Composite IBAMs
In the examples set forth above, each IBAM controls access to a single type of user-owned resource. In contrast, a composite IBAM may mediate access to two or more different types of user-owned resources.
Suppose that the purpose of the composite resource monitor 702 is to extract information from two user-owned resources, which is sent to a consuming application. In one approach, the access system 100 can be configured such that the access system 100 forwards the extracted data directly to the consuming application. This promotes isolation by preventing the composite resource monitor 702 from gaining access to the data. But in another approach, the access system 100 can forward the data to the composite resource monitor 702, which, in turn, forwards it to the consuming application. Section B provides additional details regarding the use of composite resource monitors.
A.7. Implementation Details
More specifically, the functionality associated with the applications 102, resource monitors 112, and user-owned resources 104 can be allocated between the local computing functionality 902 and the remote computing functionality 904 in any manner. For example, an application A can be implemented by code stored in the user device 106, and/or by code stored at a remote site. In addition, the resource monitor Y which provides the gadget 110 can be physically implemented by code in the user device 106 and/or by code provided at a remote site. The resource monitor Y may be implemented at a remote site, for instance, when a remote application hosts an application-specific gadget. The hosting application (e.g., application A) can incorporate that application-specific gadget by appropriately making reference to the source of its UI code.
The local computing functionality 902 can be implemented by any type of user device mentioned in Section A.1. The remote computing functionality 904 can be implemented by one or more server computers and associated data stores. The communication conduit 906 can be implemented by a local area network, a wide area network (e.g., the Internet), or a combination thereof.
A.8. Illustrative Gadgets
Another potential use of a scheduling-type gadget is to perform a periodic backup operation. Another use is to perform a periodic update operation, e.g., by extracting updates from a source entity having dynamically-changing information content. Another use is to perform some activity upon entering a particular region, and so on.
In general, the single-transaction access gadgets (1004, 1006, 1008) of
More specifically, the content-selection gadget 1604 operates as a container which encompasses one or more content-view gadgets (1606, 1608, . . . ). Each content-view gadget represents an application-specific gadget that is hosted by an application-specific resource monitor, provided, in turn, by a particular content provider. For example, a content-view resource monitor 1610 provides the content-view gadget 1606, and a content-view resource monitor 1612 provides the content-view gadget 1608, etc. Each content-providing resource monitor (1610, 1612) can apply a provider-specific look and feel to its content-view gadget (1606, 1608), optionally together with provider-specific functionality.
In contrast, a content-picking resource monitor 1614 provides the shell content-selection gadget 1604 (and, in one implementation, also provides the content-picking gadget 1504 of
In one manner of operation, the user can select one or more view items from any of the content-view gadgets (1606, 1608), where, again, the view items correspond to respective data items provided by the content-provider entities. The user may then activate an OK command button 1616. The access system 100 then transfers the selected data items from the appropriate content-provider entity(ies) to the application which provides the application UI 1602. In an alternative mode of operation, a user can use a drag-and-drop operation to move a view item in the content-selection gadget 1604 to any destination location. This results in the transfer of a corresponding data item to the designated location. In an alternative mode of operation, a user can directly click on (or otherwise activate) an entry in one of the content-view gadgets (1606, 1608). Still other modes of operation are possible.
The above-illustrated gadgets are representative, rather than exhaustive of the different types of gadget that can be used in a particular environment. However, in one approach, the access system 100 may accommodate a finite number of access control gadgets which are authorized to work in conjunction with the operating system 114.
In another environment, the access system 100 can permit any entity (such as a developer) to customize one or more aspects of a gadget. For example, the access system 100 can permit an entity to customize a limited set of properties of a gadget, such as its color, size, font etc. The access system 100 may also restrict the values that can be assigned to these properties.
In another case, the access system 100 can allow an entity to modify any gadget in a more free-form and arbitrary manner, and/or to perhaps invent entirely new gadgets. In this circumstance, an authoring entity may be expected to submit a modified or new gadget to an appropriate administrative entity associated with the access system 100, for the purpose of vetting that gadget. If the gadget is accepted, it can be placed in the RM store 116 for others to examine, download, and use.
B. Illustrative Processes
As a general qualification, the procedures of this section describe concrete actions that are performed by particular components within the access system 100 (e.g., applications 102, resource monitors 112, user-owned resources 104, and the operating system 114). However, this allocation pertains to only one representative implementation. Other implementations can assign different roles to different respective components, compared to the examples which follow. Further, other implementations can vary the ordering of operations performed by the components, compared to the examples which follow. Finally, to facilitate description, the procedures illustrated in the drawings may omit certain interactions and operations. For example, the operating system 114 plays some role in processing all input data and presenting all output data; but the procedures highlight only those functions performed by the operating system 114 which pertain to the access-related role it serves within the access system 100 of
The access pattern described in
Next consider a cut (or copy) and paste operation. The access system 100 can use the type of procedure of
Next consider a drag-and-drop operation. The access system 100 can use the type of procedure of
Advancing to
Advancing to
The procedure of
In another variation, a user can directly click on a view item in a content-view gadget to select it, rather than more indirectly selecting the view item and actuating the OK command button 1616. The operating system 114 will then send an InputEvent upcall directly to the content-view resource monitor which implements the content-view gadget. The content-view resource monitor can then obtain and transfer the corresponding data item to the target application, e.g., by sending an InitContentTransfer call to the operating system 114, along with the data item. The operating system 114 sends the data item to the application by using a PushContent upcall. Still other variations of the file-picking operation are possible.
The content-picking operation can also be performed in reverse, e.g., by designating data items to be stored by a content-providing entity. In this case, the pushes and pulls illustrated in
In block 2508, the access system 100 receives an indication that the user has activated the IBAM, e.g., by either interacting with the gadget or performing the PG input sequence. In block 2510, the access system 100 provides access to one or more user-owned resources associated with the IBAM. The access also has a duration associated with the IBAM. Illustrative durations include a single-transaction access, session-based access, permanent access, scheduled access, etc.
If the answer to block 2606 is “Yes,” then the operating system 114 advances to block 2608, where it determines whether X.Parent is the top-level application in the chain of nested applications. If this is not the case, then, in block 2610, the operating system 114 redefines the current X.Parent as X, and returns to block 2606 to repeat the above-described analysis. In this manner, the operating system 114 successively advances to the outermost top-level application, checking permissions at each step along the way.
Suppose that either block 2604 or block 2608 is answered in the affirmative. Then, in block 2612, the operating system 114 provides an active instance of the IBAM G for use in the application X, such as an active gadget. Alternatively, in block 2614, the operating system 114 provides an inactive instance of the IBAM G in the application X, such as a grayed-out and inoperable instance of the gadget. This behavior is environment-specific; that is, other environments can execute other actions in blocks 2612 and 2614.
In some cases, a child application may possess certain permanent or session-based rights to access a user-owned resource, gained prior to it being embedded in a parent application. If so, in one implementation, the child application does not lose those rights when it is embedded in a parent application, even if the parent application does not allow its children to embed gadgets.
C. Representative Computing Functionality
The computing functionality 2700 can include volatile and non-volatile memory, such as RAM 2702 and ROM 2704, as well as one or more processing devices 2706 (e.g., one or more CPUs, and/or one or more GPUs, etc.). The computing functionality 2700 also optionally includes various media devices 2708, such as a hard disk module, an optical disk module, and so forth. The computing functionality 2700 can perform various operations identified above when the processing device(s) 2706 executes instructions that are maintained by memory (e.g., RAM 2702, ROM 2704, or elsewhere).
More generally, instructions and other information can be stored on any computer readable medium 2710, including, but not limited to, static memory storage devices, magnetic storage devices, optical storage devices, and so on. The term computer readable medium also encompasses plural storage devices. In all cases, the computer readable medium 2710 represents some form of physical and tangible entity.
The computing functionality 2700 also includes an input/output module 2712 for receiving various inputs (via input modules 2714), and for providing various outputs (via output modules). One particular output mechanism may include a presentation module 2716 and an associated graphical user interface (GUI) 2718. The computing functionality 2700 can also include one or more network interfaces 2720 for exchanging data with other devices via one or more communication conduits 2722. One or more communication buses 2724 communicatively couple the above-described components together.
The communication conduit(s) 2722 can be implemented in any manner, e.g., by a local area network, a wide area network (e.g., the Internet), etc., or any combination thereof. The communication conduit(s) 2722 can include any combination of hardwired links, wireless links, routers, gateway functionality, name servers, etc., governed by any protocol or combination of protocols.
Alternatively, or in addition, any of the functions described in Sections A and B can be performed, at least in part, by one or more hardware logic components. For example, without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.
In closing, the description may have described various concepts in the context of illustrative challenges or problems. This manner of explanation does not constitute an admission that others have appreciated and/or articulated the challenges or problems in the manner specified herein.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
