Facebook Patent | Operating system with context-based permissions

Patent: Operating system with context-based permissions

Drawings: Click to check drawins

Publication Number: 20210126823

Publication Date: 20210429

Applicant: Facebook

Abstract

In one embodiment, an access control method includes receiving an access request that identifies a resource and an application requesting the resource. The method includes identifying permission settings associated with the application, where the permission settings include a contextual criterion. The method includes accessing context information associated with the contextual criterion. The method includes determining the context information satisfies the contextual criterion of the permission settings. The method includes allowing the application to access the resource in response to determining the context information satisfies the contextual criterion of the permission settings.

Claims

1. An access control method, comprising: receiving an access request identifying: a resource; and an application requesting the resource; identifying permission settings associated with the application, wherein the permission settings comprise a contextual criterion; accessing context information associated with the contextual criterion; determining the context information satisfies the contextual criterion of the permission settings; and allowing the application to access the resource in response to determining the context information satisfies the contextual criterion of the permission settings.

2. The method of claim 1, wherein: the contextual criterion identifies an approved location; the context information comprises a location for the device; and determining the context information satisfies the contextual criterion comprises determining that the location for the device matches the approved location.

3. The method of claim 1, wherein the contextual criterion identifies a restricted location; the context information comprises a location for the device; and determining the context information satisfies the contextual criterion comprises determining that the location for the device does not match the restricted location.

4. The method of claim 1, wherein: the contextual criterion comprises a time-based restriction identifying an approved time interval; the context information comprises a current time; and determining the context information satisfies the contextual criterion comprises determining that the current time is within the approved time interval.

5. The method of claim 1, wherein: the contextual criterion comprises a time-based restriction identifying a restricted time interval; the context information comprises a current time; and determining the context information satisfies the contextual criterion comprises determining that the current time is outside of the restricted time interval.

6. The method of claim 1, wherein: the contextual criterion comprises an activity-based restriction identifying an accelerometer threshold level; the context information comprises an accelerometer measurement; and determining the context information satisfies the contextual criterion comprises determining that the accelerometer measurement is less than the accelerometer threshold level.

7. The method of claim 1, wherein: the contextual criterion comprises an activity-based restriction identifying an accelerometer threshold level; the context information comprises an accelerometer measurement; and determining the context information satisfies the contextual criterion comprises determining that the accelerometer measurement is greater than the accelerometer threshold level.

8. A device, comprising: one or more hardware resources; a memory operable to store: one or more applications; and permission settings associated with the one or more applications; and an operating system executed by a processor operably coupled to the hardware resource and the memory, configured to: receive an access request identifying: a resource; and an application requesting the resource; identify permission settings associated with the application, wherein the permission settings comprise a contextual criterion; access context information associated with the contextual criterion; determine the context information satisfies the contextual criterion of the permission settings; and allow the application to access the resource in response to determining the context information satisfies the contextual criterion of the permission settings.

9. The device of claim 8, wherein: the contextual criterion identifies an approved location; the context information comprises a location for the device; and determining the context information satisfies the contextual criterion comprises determining that the location for the device matches the approved location.

10. The device of claim 8, wherein: the contextual criterion identifies a restricted location; the context information comprises a location for the device; and determining the context information satisfies the contextual criterion comprises determining that the location for the device does not match the restricted location.

11. The device of claim 8, wherein: the contextual criterion comprises a time-based restriction identifying an approved time interval; the context information comprises a current time; and determining the context information satisfies the contextual criterion comprises determining that the current time is within the approved time interval.

12. The device of claim 8, wherein: the contextual criterion comprises a time-based restriction identifying a restricted time interval; the context information comprises a current time; and determining the context information satisfies the contextual criterion comprises determining that the current time is outside of the restricted time interval.

13. The device of claim 8, wherein: the contextual criterion comprises an activity-based restriction identifying an accelerometer threshold level; the context information comprises an accelerometer measurement; and determining the context information satisfies the contextual criterion comprises determining that the accelerometer measurement is less than the accelerometer threshold level.

14. The device of claim 8, wherein: the contextual criterion comprises an activity-based restriction identifying an accelerometer threshold level; the context information comprises an accelerometer measurement; and determining the context information satisfies the contextual criterion comprises determining that the accelerometer measurement is greater than the accelerometer threshold level.

15. A computer program comprising executable instructions stored in a non-transitory computer readable medium that when executed by a processor causes the processor to: receive an access request identifying: a resource; and an application requesting the resource; identify permission settings associated with the application, wherein the permission settings comprise a contextual criterion; access context information associated with the contextual criterion; determine the context information satisfies the contextual criterion of the permission settings; and allow the application to access the resource in response to determining the context information satisfies the contextual criterion of the permission settings.

16. The computer program of claim 15, wherein: the contextual criterion identifies an approved location; the context information comprises a location for the device; and determining the context information satisfies the contextual criterion comprises determining that the location for the device matches the approved location.

17. The computer program of claim 15, wherein: the contextual criterion identifies a restricted location; the context information comprises a location for the device; and determining the context information satisfies the contextual criterion comprises determining that the location for the device does not match the restricted location.

18. The computer program of claim 15, wherein: the contextual criterion comprises a time-based restriction identifying an approved time interval; the context information comprises a current time; and determining the context information satisfies the contextual criterion comprises determining that the current time is within the approved time interval.

19. The computer program of claim 15, wherein: the contextual criterion comprises a time-based restriction identifying a restricted time interval; the context information comprises a current time; and determining the context information satisfies the contextual criterion comprises determining that the current time is outside of the restricted time interval.

20. The computer program of claim 15, wherein: the contextual criterion comprises an activity-based restriction identifying an accelerometer threshold level; the context information comprises an accelerometer measurement; and determining the context information satisfies the contextual criterion comprises determining that the accelerometer measurement is less than the accelerometer threshold level.

Description

TECHNICAL FIELD

[0001] This disclosure generally relates to permissions used in an operating system.

BACKGROUND

[0002] In computer programming, a permission may refer to access rights for specific users and groups of users. Permissions may be assigned to applications as well. Conventional operating systems may provide a static list of resource permissions to applications. These current operating systems may be designed to enforce blanket permissions, such as whether an application has access to a camera. After an application is given the blanket permission to access the camera, the application has permission to access the camera whenever.

SUMMARY OF PARTICULAR EMBODIMENTS

[0003] Disclosed herein are a variety of different ways of generating permissions for applications to access resources and enable capabilities. In particular embodiments, the use of these permissions may be specific for applications in an operating system for an augmented reality or virtual reality environment. The use of an augmented reality system or virtual reality system may be different than a typical computing system. As such, there may be privacy and security concerns that are unique to an augmented reality system or virtual reality system. As an example and not by way of limitation, within an augmented reality operating system environment, an application should not be given total access to the device’s camera. This may be because there are certain situations where a user may want to restrict camera access, such as within a bathroom. One goal of the disclosed methods may be to implement a more flexible permission scheme, where permissions incorporate contexts described by dynamic variables. Conventional operating systems may provide a static list of resource permissions to applications (e.g., can_access_camera). The current operating systems may be designed to enforce blanket permissions. This permission scheme may be restrictive because it can be inflexible, and it may not be based on dynamic information (e.g., the current location), and not sufficiently granular (e.g., grant/deny access to specific ports or websites). In addition, this permission scheme may not suitable for certain augmented reality applications (e.g., grant camera access in certain places but turn off camera access in others) because these blanket permission may not be sufficient for all usage contexts. These blanket permission may not be sufficient because it may be undesirable for an application to be granted permission to access the camera at all times.

[0004] In particular embodiments, when an application is initially installed, it may ask the user to grant context-based permissions. As an example and not by way of limitation, the application may ask the user for permission to access the device’s camera in particular contexts (e.g., when the user is outdoors). In particular embodiments, the granted permission may then be stored in a permission broker, which is running as a service. When the application wants to access the camera, the application may send a request to access the camera. Then the camera’s service would identify the app and may ask the permission broker for the list of permissions that has been granted to the application. The camera’s service may then check whether the conditions attached to the permissions are satisfied by the current context (e.g., the camera service may query other services for the current GPS location, Live-Maps location, time, etc.). If the contextual conditionals are satisfied, the application may be given access to the camera. If the contextual conditionals are not satisfied, the application may generate a notification requesting updated permissions. This may be in the instance for one-time use cases or needing to expand out the granted permission.

[0005] In particular embodiments, to implement context-based permissions, declarative language may be used to define an operating system’s support/enforce permissions. In this configuration, applications may specify their permission requirements with finer granularity and based on dynamic information. As an example and not by way of limitation, an application may only have access to a particular web address and nothing else based on a current location. In particular embodiments, when an application requests for resources, the permission broker will check whether the permission rule defined by the application is satisfied. If so, the permission broker may request the microkernel to issue a token (capability-based privilege; e.g., a particular process has privilege to certain capabilities) and pass that token to the application. When the application requests for resource access, the kernel may check whether the token is valid before granting access. The implementation of the context-based permissions may allow for more flexibility in setting conditions for permissions. The context-based permissions may improve the security and privacy of a user through restricting application permissions based on certain contexts.

[0006] Embodiments of the invention may include or be implemented in conjunction with an artificial reality system. Artificial reality is a form of reality that has been adjusted in some manner before presentation to a user, which may include, e.g., a virtual reality (VR), an augmented reality (AR), a mixed reality (MR), a hybrid reality, or some combination and/or derivatives thereof. Artificial reality content may include completely generated content or generated content combined with captured content (e.g., real-world photographs). The artificial reality content may include video, audio, haptic feedback, or some combination thereof, and any of which may be presented in a single channel or in multiple channels (such as stereo video that produces a three-dimensional effect to the viewer). Additionally, in some embodiments, artificial reality may be associated with applications, products, accessories, services, or some combination thereof, that are, e.g., used to create content in an artificial reality and/or used in (e.g., perform activities in) an artificial reality. The artificial reality system that provides the artificial reality content may be implemented on various platforms, including a head-mounted display (HMD) connected to a host computer system, a standalone HMD, a mobile device or computing system, or any other hardware platform capable of providing artificial reality content to one or more viewers.

[0007] The embodiments disclosed herein are only examples, and the scope of this disclosure is not limited to them. Particular embodiments may include all, some, or none of the components, elements, features, functions, operations, or steps of the embodiments disclosed above. Embodiments according to the invention are in particular disclosed in the attached claims directed to a method, a storage medium, a system and a computer program product, wherein any feature mentioned in one claim category, e.g. method, can be claimed in another claim category, e.g. system, as well. The dependencies or references back in the attached claims are chosen for formal reasons only. However any subject matter resulting from a deliberate reference back to any previous claims (in particular multiple dependencies) can be claimed as well, so that any combination of claims and the features thereof are disclosed and can be claimed regardless of the dependencies chosen in the attached claims. The subject-matter which can be claimed comprises not only the combinations of features as set out in the attached claims but also any other combination of features in the claims, wherein each feature mentioned in the claims can be combined with any other feature or combination of other features in the claims. Furthermore, any of the embodiments and features described or depicted herein can be claimed in a separate claim and/or in any combination with any embodiment or feature described or depicted herein or with any of the features of the attached claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1 illustrates an example operating system environment associated with a virtual reality system.

[0009] FIG. 2 illustrates an example permission request.

[0010] FIG. 3 illustrates an example list of permission settings.

[0011] FIG. 4 illustrates an example diagram flow of handling a hardware access request.

[0012] FIGS. 5A-5B illustrate example diagram flows of requesting hardware access within an operating system environment.

[0013] FIG. 6 illustrates an example network environment associated with a virtual reality system.

[0014] FIG. 7 illustrates an example method for handling a permission rule associated with an application.

[0015] FIG. 8 illustrates an example method for handling a hardware access request from an application.

[0016] FIG. 9 illustrates an example computer system.

DESCRIPTION OF EXAMPLE EMBODIMENTS

[0017] Conventional operating systems may provide a static list of resource permissions to applications (e.g., can_access_camera). The current operating systems may be designed to enforce blanket permissions. This permission scheme may be restrictive because it can be inflexible, and it may not be based on dynamic information (e.g., the current location), and not sufficiently granular (e.g., grant/deny access to specific ports or websites). In addition, this permission scheme may not suitable for certain augmented reality applications (e.g., grant camera access in certain places but turn off camera access in others) because these blanket permission may not be sufficient for all usage contexts. These blanket permission may not be sufficient because it may be undesirable for an application to be granted permission to access the camera at all times. It may be more desirable for the camera permission to be conditionally granted based on the user’s context, such as when the user is outdoors and not when the user is at home.

[0018] In particular embodiments, in order to implement dynamic information for permissions, the operating system may enforce context-based permissions. When an application is initially installed, it may ask the user to grant context-based permissions. As an example and not by way of limitation, the application may ask the user for permission to access the device’s camera in particular contexts (e.g., when the user is outdoors). In particular embodiments, the granted permission may then be stored in a permission broker, which is running as a service. When the application wants to access the camera, the application may send a request to access the camera. Then the camera’s service would identify the app and may ask the permission broker for the list of permissions that has been granted to the application. The camera’s service may then check whether the conditions attached to the permissions are satisfied by the current context (e.g., the camera service may query other services for the current GPS location, Live-Maps location, time, etc.). If the contextual conditionals are satisfied, the application may be given access to the camera. If the contextual conditionals are not satisfied, the application may generate a notification requesting updated permissions. This may be in the instance for one-time use cases or needing to expand out the granted permission.

[0019] In particular embodiments, these contexts may include a location-based context, a time-based context, and an activity-based context. As an example and not by way of limitation, location-based contexts may include “at home”, “at work”, “only here”, “only this room”, and the like. There may be opposite location-based contexts, such as “anywhere but here” for instance to avoid giving permissions to an application when a user is in their bedroom. As an example and not by way of limitation, time-based contexts may include “during the day”, “at night”, “for a specified time period”, and the like. As an example and not by way of limitation, activity-based contexts may include “while driving”, “while working out”, and the like. This may help restrict permissions to applications for certain contexts, such as a maps application to only receive GPS location when the user is driving. In particular embodiments, opposite contexts may be implemented in a location-based context, a time-based context, and an activity-based context. Applications may also request context-based permissions when needing to perform an action. As an example and not by way of limitation, while an application may need permission to access a camera (e.g., to generate an AR element on a wall, such as a painting), the application may not necessarily need persistent permission to access the camera. Therefore, applications may request one-time context-based permissions as necessary through notifications displayed to the user, which need to be accepted by the user. There can be multiple combinations of the various contexts to generate the context-based permissions. As an example and not by way of limitation, permission to access a camera may require the user to be outside of home and the time be during the day. Once the contextual conditionals are satisfied, the application may be given access to the camera.

[0020] In particular embodiments, to implement context-based permissions, declarative language may be used to define an operating system’s support/enforce permissions. In this configuration, applications may specify their permission requirements with finer granularity and based on dynamic information. As an example and not by way of limitation, an application may only have access to a particular web address and nothing else based on a current location. In particular embodiments, when an application requests for resources, the permission broker will check whether the permission rule defined by the application is satisfied. If so, the permission broker may request the microkernel to issue a token (capability-based privilege; e.g., a particular process has privilege to certain capabilities) and pass that token to the application. When the application requests for resource access, the kernel may check whether the token is valid before granting access. The implementation of the context-based permissions may allow for more flexibility in setting conditions for permissions. The context-based permissions may improve the security and privacy of a user through restricting application permissions based on certain contexts.

[0021] Referring to FIG. 1, an example operating system environment 100 is shown. The operating system environment 100 may be executed on a computing system. As an example and not by way of limitation, the computing system may be a virtual reality or augmented reality headset device. The operating system environment 100 may comprise an application 102, a kernel 104, a permission broker 106, and a hardware resource 108. In particular embodiments, each of the components may be connected through a link 110. In particular embodiments, the various components 102, 104, 106, 108 may communicate through system calls via the links 110. The links 110 may be embodied as other communication channels between components of an operating system environment. While only certain links 110 are shown, other links 110 connecting any of the components may be contemplated. In particular embodiments, links 110 may be added in response to establishing connections between components 102, 104, 106, 108. As an example and not by way of limitation, the kernel 104 may establish a connection between the application 102 and the hardware resource 108.

[0022] In particular embodiments, the application 102 may be any kind of application installed on a computing system. As an example and not by way of limitation, the application 102 may be a social media application, an online music application, etc. The application 102 may comprise one or more permission rules that defines a criterion for permitting the application 102 to access a hardware resource 108. The criterion may identify a logic predefined by the operating system and a condition for satisfying the logic. In particular embodiments, prior to installation of the application 102 on a computing system, one or more permission rules may be reviewed through a third-party to verify that the permission rules comply with established standards. These standards may be implemented to ensure the permission rules would not allow the application 102 to compromise the security or privacy of the user of the computing system. In particular embodiments, the permission rules may be installed with the application 102 on the computing system. The term “permission rules” may be used interchangeably with “permission settings.”

[0023] In particular embodiments, the kernel 104 may be a microkernel of an operating system environment 100. The kernel 104 may be configured to issue access tokens to applications requesting hardware resource access. The kernel 104 may check to determine whether an application 102 should be allowed access to a hardware resource 108 based on whether the context information satisfies contextual criterion associated with the permission rules. In particular embodiments, the kernel 104 may enable or deny access to the hardware resource 108 based on the determination. In particular embodiments, the kernel 104 may communicate with the permission broker 106 to determine whether the application 102 is allowed to access the hardware resource 108.

[0024] In particular embodiments, the permission broker 106 may be a service in a user space of an operating system environment 100. In particular embodiments, the permission broker 106 may record permission settings of various applications. The permission settings may define a condition that needs to be satisfied in order for an application to receive access to a hardware resource 108. As an example and not by way of limitation, the application 102 may be Instagram requesting access to a camera. The permission settings associated with Instagram may be the application 102 can only access the camera during the day in any location besides a user’s home. These permission settings may also apply to other settings for an application in addition to access to hardware resources. As an example and not by way of limitation, the permission settings may only allow an application 102 to access certain websites. Although example permission settings are discussed, other permission settings may be contemplated. In particular embodiments, the permission broker 106 may store permission settings of installed applications. The permission broker 106 may access the permission settings of an application 102 to determine whether the application 102 is allowed access. To do so, the permission broker 106 may access context information associated with a contextual criterion of the permission settings. As an example and not by way of limitation, if the permission settings of an application 102 specifies that the application 102 is allowed access to a hardware resource 108 only at the user’s home, then the permission broker 106 may communicate with a location service to retrieve location data and determine whether the permission settings are satisfied. In particular embodiments, the kernel 104 may conduct the determination of whether permission settings have been satisfied. In particular embodiments, the permission broker 106 may override permission settings associated with applications 102. As an example and not by way of limitation, the permission broker 106 may remove access to a hardware resource 108 or prevent an application 102 from performing an operation. As an example and not by way of limitation, if an application 102 has permission settings that specify the application 102 is allowed to access a camera any time during the day at any location, the permission broker 106 may have override the application’s 102 access with a setting that prevents camera access at night.

[0025] In particular embodiments, the application 102 may initially send a request to the permission broker 106 for an access token for the hardware resource 108 via the link 110. As an example and not by way of limitation, the application 102 may need to access a hardware resource 108 (e.g., a camera). The application 102 may send a request for an access token for the hardware resource 108 to the permission broker 106. The access token may represent permission information data that indicates a capability to access a resource, perform an operation, and other capabilities within an operating system environment 100. The permission broker 106 may review the permission settings associated with the application 102 to determine whether the application 102 should be allowed to receive an access token for the hardware resource 108. The permission broker 106 may additionally determine whether context information satisfies a contextual criterion of the permission settings. As an example and not by way of limitation, if a location context is satisfied for the application 102 to receive an access token, such as if the computing system is located within a user’s home location. In particular embodiments, the permission broker 106 may initially determine the application 102 has access to the hardware resource 108 without reviewing the context information. The permission broker 106 may send a request to the kernel 104 to issue an access token to the application 102 via the link 110. The kernel 104 may send an access token to the application 102 via the link 110. The application 102 may subsequently send a request to access the hardware resource 108 to the kernel 104 via the link 110 with the access token. The kernel 104 may send a request to the permission broker 106 to determine whether contextual criterion of the application’s 102 permission settings are satisfied. In particular embodiments, the kernel 104 may perform the determination. After receiving a determination from the permission broker 106, the kernel 104 may allow or deny access to the hardware resource 108 for the application 102.

[0026] Referring to FIG. 2, an example permission request 200 is shown. In particular embodiments, when an application 102 is installed on a computing system, the application 102 may request permission for certain capabilities. In particular embodiments, certain capabilities may be approved or denied in the background without user intervention. The certain capabilities that may be approved or denied in the background may be determined to not compromise the user’s privacy or security of the computing system. The user of a computing system may be presented the permission request 200 after installation of an application 102. The presentation of the permission request 200 may be in the form of a notification that appears on a display of the computing system of the user. The permission request 200 may be separate for different capabilities or the permission request 200 may combine similar capabilities. As an example and not by way of limitation, access to a website and access to a camera may both be restricted by similar contextual criterion. In particular embodiments, the permission broker 106 may generate the permission request 200 to request user approval for providing capabilities to an application 102. The permission request 200 may specify a capability that an application is requesting permission to access. As an example and not by way of limitation, the application 102 may be requesting permission to access the camera. The permission request 200 may comprise contextual criterion categories 202. Although only contextual criterion categories 202a-202c are shown, there may be other contextual criterion categories 202 not shown. In addition, there may be any combination of contextual criterion categories 202a-202c for a permission request 200. The permission broker 106 may identify the contextual criterion categories from the permission settings of the application 102. The permission broker 106 may identify for a particular capability (e.g., access to a camera) certain contextual criterion categories (e.g., location, time, activity). The permission request 200 may specify contextual criterion conditions 204a-204c that must be satisfied in order for the application 102 to have access to the capability (e.g., access to the camera). In particular embodiments, the user may adjust the permission request 200 by adding, removing, or manipulating the contextual criterion categories 202 and/or the contextual criterion conditions 204. As an example and not by way of limitation, if the user wishes to remove a restriction of using a camera while using the application 102, the user may remove the contextual criterion category 202, activity. As an example and not by way of limitation, the user may change the time contextual criterion category 202 to all day. In particular embodiments, the permission broker 106 may notify the user of security or privacy compromising changes.

[0027] In particular embodiments, the permission request 200 may comprise an approve interactive element 206 and a decline interactive element 208. The user may decide whether to approve the permission request 200 with the given contextual criterion. If the user decides to approve the permission request, the permission broker 106 may store the permission request 200 and associated the permission request 200 with the application 102. The permission broker 106 may also request the kernel 104 to issue an access token to the application for the particular capability. If the user decides to decline the permission request 200, the permission broker 106 may store the permission request 200 with a record to decline an application’s 102 request for an access token or access to a resource. While the user may initially approve the permission request 200, the user may alter or remove the application’s 102 access to a resource or capability.

[0028] Referring to FIG. 3, an example list 300 of example permission settings is shown. As an example and not by way of limitation, the list 300 may represent various permission settings that may be installed with an application 102. While described as a permissions setting, the permission settings may represent programmable rules to be evaluated to allow an application access to a resource or a capability. The list 300 of permission settings may specify various capabilities available to the application 102. Each of the permission settings may also specify contexts that need to be satisfied to provide the application 102 permission to enable the capability. The contexts may be associated with one or more dynamic variables, such as location, time, and the like. The contexts may also be associated with logic that is embedded into the permission setting. As an example and not by way of limitation, the application 102 may be allowed to create files through the “permit(file_crite)” permission setting with no specified context. As another example and not by way of limitation, the application may be allowed to use the camera through the “permit(camera, capture):-safe_location(location)”, which specifies a context. As another example and not by way of limitation, permission settings, such as “reject(net, udp)” may indicate what capabilities to deny an application. Additionally, permission setting “ask_user(camera, capture)” may request user approval of application access through a permission request 200.

[0029] In particular embodiments, the permission settings may be updated after an application 102 has been installed on a computing system (e.g., through an application update). The various dynamic variables may be updated, added and/or removed over time.

[0030] In particular embodiments, the list 300 of permissions settings may specify overrides that the permission broker 106 has specified for permission settings for applications 102. In particular embodiments, the overrides may be specific for certain applications or generalized to all applications installed on the computing device. In particular embodiments, the overrides may apply to only applications that request a particular capability. As an example and not by way of limitation, the permission broker 106 may restrict access to a camera for all applications. In particular embodiments, the user may override any permission settings.

[0031] In particular embodiments, the language of the permission settings may comprise a rule that may be programmable by an application. The language of the permission settings may comprise dynamic variables associated with the rule. These rules may be dynamically reevaluated when conditions change. As an example and not by way of limitation, when one of the dynamic variables change by a threshold amount, such as for a location variable, when the computing system has moved more than 20 meters. The language of the permission settings may standardize the rules implemented by the permissions settings. The language of permission settings may comprise one or more of permits, rejects, and ask users. The language of permission settings may allow for combinations of various dynamic variables to implement complex logic. As an example and not by way of limitation, “permit(camera, capture):-safe_location(Location), day_time(Time)” may allow an application to take pictures in safe locations only during the day. In particular embodiments, the use of the permits and rejects may enable and deny access to resources and capabilities if certain conditions are met. These conditions are based on the dynamic variables. As an example and not by way of limitation, while a “permit(camera, capture):-day_time(Time)” may allow for an application to access a hardware resource (e.g., a camera) during the day, a “reject(camera, capture):-day_time(Time)” would deny the application from accessing a hardware resource during the day. The dynamic variables may be evaluated and reevaluated when it is determined that a threshold change of the corresponding variable has occurred. As an example and not by way of limitation, if the variable is based on time, then after a period of time (e.g., 1 hour) the permission setting may be reevaluated to determine whether the application still has access to the corresponding hardware resource.

[0032] In particular embodiments, a computing system may automatically generate descriptions of an application’s capabilities based on the permission settings of the application. As an example and not by way of limitation, if the application has a list of permission settings: “permit(file_create)”, “permit(location, coarse)”, and “permit(camera, capture):-safe_Location(location)”, then the computing system may generate the descriptions: “Can create any file”, “Can get coarse GPS location”, and “Can take pictures in safe locations”. The computing system may analyze the permission settings of the application in order to generate the descriptions based on the rules and dynamic variables of the respective permission setting. This allows for generation of a description that is standardized and reduces errors in descriptions. Through the analysis of the specific rule matched with any dynamic rules in the permission setting, the computing system may be able to generate an accurate description of what the permission setting allows for an application to do. The description may be generated and presented to a user. The presentation of an application’s capabilities may allow for the user to properly approve or deny any permission requests the application may send. The presentation of the application’s capabilities may also allow the user to override any permission settings accordingly to restrict the application’s access to certain resources or capabilities.

[0033] In particular embodiments, a computing system may test permission settings associated with an application. As an example and not by way of limitation, a computing system may determine whether an application has access to certain capabilities. In particular embodiments, the computing system may have a test procedure where it determines if an application has access to a set of permission settings. The set of permission settings may be associated with particular capabilities that may compromise a user’s privacy or device security if the application is enabled to the respective permission settings. The test may quickly identify whether the application has access to these specific permission settings and may enable the user to revoke access to the capabilities associated with the respective permission settings.

……
……
……