Facebook Patent | Operating system implementation of language to describe permissions

Patent: Operating system implementation of language to describe permissions

Drawings: Click to check drawins

Publication Number: 20210124821

Publication Date: 20210429

Applicant: Facebook

Abstract

In one embodiment, an access control method includes receiving, from an application, a permission rule defining a criterion for permitting the application to access a resource, where the criterion identifies a logic predefined by the operating system and a condition for satisfying the logic. The method includes storing the permission rule and associating the stored permission rule with the application. The method includes receiving, from the application, a request to access the resource. The method includes accessing the stored permission rule associated with the application. The method includes determining that the application is permitted to access the resource by processing the logic and the condition. The method includes allowing the application to access the resource.

Claims

1. An access control method, comprising: receiving, from an application, a permission rule defining a criterion for permitting the application to access a resource, wherein the criterion identifies a logic predefined by an operating system and a condition for satisfying the logic; storing the permission rule; associating the stored permission rule with the application; receiving, from the application, a request to access the resource; accessing the stored permission rule associated with the application; determining that the application is permitted to access the resource by processing the logic and the condition; and allowing the application to access the resource.

2. The method of claim 1, wherein: the condition for satisfying the logic comprises a reference to mutable data; and the reference is predefined by the operating system.

3. The method of claim 2, further comprising: accessing current data associated with the reference, wherein the determination that the application is permitted to access the resource is further determined by processing the current data.

4. The method of claim 1, wherein: the operating system comprises a microkernel and a permission service; and the determination that the application is permitted to access the resource is performed by the permission service.

5. The method of claim 4, further comprising: associating, by the microkernel, a token with the determination that the application is permitted to access the resource; receiving, by the microkernel, the token from the application; and determining that the token received from the application is associated with the determination that the application is permitted to access the resource, wherein the allowing the application to access the resource is performed by the microkernel based on the token.

6. The method of claim 5, further comprising: generating, by the microkernel, the token; sending, by the microkernel, the generated token to the permission service; and sending, by the permission service, the token to the application.

7. The method of claim 5, further comprising: determining, by the permission service, that the application is prohibited from accessing the resource by processing the logic and the condition; sending, by the permission service, an update request to the microkernel requesting the token to be associated with the determination that the application is prohibited from accessing the resource; receiving, by the microkernel, the token from the application after the permission service sent the update request; determining, by the microkernel, that the token received from the application after the permission service sent the update request is associated with the determination that the application is prohibited from accessing the resource; and denying the application to access the resource.

8. A device, comprising: one or more resources; a memory operable to store: one or more applications; and permission rules defining a criterion for permitting an application to access a resource, wherein the criterion identifies a logic predefined by an operating system and a condition for satisfying the logic; and the operating system executed by a processor operably coupled to the memory, configured to: receive, from an application, a permission rule; store the permission rule; associate the stored permission rule with the application; receive, from the application, a request to access the resource; access the stored permission rule associated with the application; determine that the application is permitted to access the resource by processing the logic and the condition; and allow the application to access the resource.

9. The device of claim 8, wherein: the condition for satisfying the logic comprises a reference to mutable data; and the reference is predefined by the operating system.

10. The device of claim 9, wherein the operating system is further configured to: access current data associated with the reference, wherein the determination that the application is permitted to access the resource is further determined by processing the current data.

11. The device of claim 8, wherein: the operating system comprises a microkernel and a permission service; and the determination that the application is permitted to access the resource is performed by the permission service.

12. The device of claim 11, wherein the microkernel is configured to: associate a token with the determination that the application is permitted to access the resource; receive the token from the application; and determine that the token received from the application is associated with the determination that the application is permitted to access the resource, wherein the allowing the application to access the resource is performed by the microkernel based on the token.

13. The device of claim 12, wherein: the microkernel is configured to: generate the token; send the generated token to the permission service; and the permission service is configured to: send the token to the application.

14. The device of claim 12, wherein: the permission service is configured to: determine that the application is prohibited from accessing the resource by processing the logic and the condition; send an update request to the microkernel requesting the token to be associated with the determination that the application is prohibited from accessing the resource; receive the token from the application after the permission service sent the update request; and the microkernel is configured to: determine that the token received from the application after the permission service sent the update request is associated with the determination that the application is prohibited from accessing the resource; and deny the application to access the resource.

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, from an application, a permission rule defining a criterion for permitting the application to access a resource, wherein the criterion identifies a logic predefined by the operating system and a condition for satisfying the logic; store the permission rule; associate the stored permission rule with the application; receive, from the application, a request to access the resource; access the stored permission rule associated with the application; determine that the application is permitted to access the resource by processing the logic and the condition; and allow the application to access the resource.

16. The computer program of claim 15, wherein: the condition for satisfying the logic comprises a reference to mutable data; and the reference is predefined by the operating system.

17. The computer program of claim 16, further comprising instructions that when executed by the processor causes the processor to: access current data associated with the reference, wherein the determination that the application is permitted to access the resource is further determined by processing the current data.

18. The computer program of claim 15, further comprising instructions that when executed by the processor causes the processor to: implement a microkernel and a permission service; and the determination that the application is permitted to access the resource is performed by the permission service.

19. The computer program of claim 18, further comprising instructions that when executed by the processor causes the processor to: associate, using the microkernel, a token with the determination that the application is permitted to access the resource; receive, using the microkernel, the token from the application; and determine that the token received from the application is associated with the determination that the application is permitted to access the resource; wherein the allowing the application to access the resource is performed by the microkernel based on the token.

20. The computer program of claim 19, further comprising instructions that when executed by the processor causes the processor to: determine, using the permission service, that the application is prohibited from accessing the resource by processing the logic and the condition; send, using the permission service, an update request to the microkernel requesting the token to be associated with the determination that the application is prohibited from accessing the resource; receive, using the microkernel, the token from the application after the permission service sent the update request; determine, using the microkernel, that the token received from the application after the permission service sent the update request is associated with the determination that the application is prohibited from accessing the resource; and deny the application to access the resource.

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.

……
……
……