User configurable profiles for security permissions

Permissions specified within an application permission manifest file of an application may be superseded with customized permissions. A user may customize the permissions by denying permissions, granting permissions, or requesting a prompt prior to an application attempting to access functionality and/or data protected by a permission. A user may customize permissions on a global or per application basis. Upon receiving input to customize a permissions profile, a package manager module creates a new permissions manifest file associated with an application. Upon receiving input to execute an application, a runtime environment that may be provided by the runtime accesses the new permissions manifest file instead of an original permissions manifest file, and operates the application using permissions granted in the new permissions manifest file.

BACKGROUND

Applications are created by programmers to fulfill specific tasks on a user device. For example, applications may provide utility, entertainment, and/or productivity functionalities to a user of the user device. Applications may be built into a user device (e.g., telecommunication, text message, clock, camera, etc.) or may be customized (e.g., games, news, transportation schedules, online shopping, etc.). An application is installed on a user device prior to fulfilling a specific task associated with the application. When users seek to install an application on to a user device, the users are prompted to grant certain permissions for an installation to occur. A permission is a restriction limiting or granting access to a functionality and/or to data on a user device. For example, a user may be prompted to allow the application to modify or delete stored content, receive text messages (SMS), manage other applications, record audio, pinpoint geographical location, access network services, determine user device status, or identity, modify, and read contact information, etc.

Often times, applications on user devices are configured by default to request that users grant the applications permission to access the functionalities and/or data stored on the user devices, even though an application may not use such access to execute the primary functions of the applications. Accordingly, by allowing applications to access a variety of excessive and unnecessary user device functionalities and/or data, users potentially expose themselves to privacy risks. For example, excessive permissions may be used by rogue applications to maliciously and unintentionally perform actions that steal sensitive user information or increase the likelihood of loss of confidentiality, integrity, or availability of sensitive information or critical services without a user's awareness.

DETAILED DESCRIPTION

This disclosure describes, in part, techniques for allowing a user to define permissions profiles for applications, regardless of the permissions specified within an application's permissions manifest file. A permissions manifest file may be a file that lists default permission settings for an application. A user may customize permissions by denying permissions, granting permissions, or requesting to be prompted with permission options prior to an application using the permissions to attempt to access functionalities provided by a user device and/or data stored on a user device. A user may customize permissions on a global or per application basis. The techniques described herein may reduce the likelihood that a user may be impacted by mobile malware, fraudulent SMS, and unauthorized sensitive data disclosure by limiting an application's access to excessive security permissions.

Operating systems (e.g., Android, etc.) allow developers to configure a large number of permissions for use in applications. A permission is a restriction limiting or granting access to a functionality provided by a user device or to data on a user device. Such restrictions may be used to protect critical data and functionalities that could be misused to negatively affect a user's experience. Examples of permissions include allowing an application to capture audio and/or video output, allowing an application to disable the user device, allowing an application to broadcast SMS receipt notifications, allowing an application to add voicemails into the system, allowing an application to access precise location from location sources such as GPS, cell towers, and Wi-Fi, etc.

If an application desires to access a feature protected by a permission, the application may declare that it seeks that permission by inserting an element in a permissions manifest file associated with the application. A list of permissions may be identified in the permissions manifest file described above. For example, in the Android® Operating System, a list of permissions may be identified in an AndroidManifest.xml file. In other operating systems, however, other types of permissions manifest files may identify the list of permissions. In at least some embodiments, the permissions manifest file may be located at the root of an application directory of an operating system.

In some instances, when an application is being installed on a user device, an installer application may determine whether to grant requested permissions by checking authorities that signed the application's certificates and, in some embodiments, asking a user to grant the requested permissions. In an instance where user input is requested, a user may be presented with a user interface notifying the user that he or she may install the application by granting permissions in a list of permission requests. In such instances, a user may be presented with the list of permissions and may have two options: grant the requested permissions and proceed with installation of the application, or cancel the installation. Many users may be unfamiliar with the permissions requested, unaware of the impacts of granting a permission, or are willing to accept risks associated with granting a permission to gain the claimed functionality of the application. Accordingly, many users grant an application permissions requested by the application and proceed with the installation without a clear understanding of the ramifications.

Often times, applications on user devices are configured by default to request that users grant the applications permission to access the functionalities and/or data stored on the user devices, even though an application may not use such access to execute the primary functions of the applications. Accordingly, by allowing applications to access a variety of excessive and unnecessary user device functionalities and/or data, users potentially expose themselves to privacy risks. For example, excessive permissions may be used by rogue applications to maliciously and unintentionally perform actions that steal sensitive user information or increase the likelihood of loss of confidentiality, integrity, or availability of sensitive information or critical services without the user's awareness.

This disclosure describes, in part, techniques for allowing a user to define permissions profiles associated with applications, regardless of the permissions specified within the applications' permissions manifest files. A user may customize permissions by denying permissions, granting permissions, or requesting to be prompted with permission options prior to an application using the permissions to attempt to access functionalities provided by a user device and/or data stored on a user device. A user may customize permissions on a global or per application basis. A global permissions manifest file may define a permissions profile for all applications associated with a user device. A permissions profile defined on a per application basis may be limited to controlling the permissions granted for a particular application. The techniques described herein may reduce the likelihood that a user may be impacted by mobile malware, fraudulent SMS, and unauthorized sensitive data disclosure by limiting an application's access to excessive security permissions.

Example Environment

FIG. 1is a schematic diagram showing an illustrative environment100for customizing permissions profiles for applications.FIG. 1includes a user device102storing a plurality of applications104(1)-104(N) and original permissions manifest files106(1)-106(N), customized permissions manifest files108(1)-108(N), and a global permissions manifest file110.

User device102can represent a diverse variety of device types and is not limited to any particular type of user device. Examples of user device102can include but are not limited to stationary computers, mobile computers, embedded computers, or combinations thereof. Example stationary computers can include desktop computers, work stations, personal computers, thin clients, terminals, game consoles, personal video recorders (PVRs), set-top boxes, or the like. Example mobile computers can include laptop computers, tablet computers, wearable computers, implanted computing devices, telecommunication devices, automotive computers, personal data assistants (PDAs), portable gaming devices, media players, cameras, or the like. Example embedded computers can include network enabled televisions, integrated components for inclusion in a computing device, appliances, microcontrollers, digital signal processors, or any other sort of processing device, or the like.

In some embodiments, one or more applications104(1)-104(N) may be stored on the user device102and may establish data communication with an application server through a data connection to a base station, which is then routed to the application server through the core network via a service node. As described above, applications104(1)-104(N) may include applications that provide utility, entertainment, and/or productivity functionalities to a user of the user device102. For example, the one or more applications104(1)-104(N) may include a navigation application that uses a data request to fetch map data from the application server, or a news application that uses a data request to fetch news information from the application server. Other examples of the one or more applications104(1)-104(N) may include applications for games to be played on the user device102, applications for shopping on the user device102, applications for sharing documents on the user device102, etc.

In some embodiments, individual applications104(1)-104(N) of the one or more applications104(1)-104(N) may desire to access a feature protected by a permission. In such embodiments, such applications104(1)-104(N) may declare that they seek that permission by inserting an element in an original permissions manifest file106(1)-106(N). A list of permissions may be identified in original permissions manifest files106(1)-106(N) associated with the individual applications104(1)-104(N). In general, a user does not have the ability to individually grant or deny permissions in an original permission manifest file (e.g., original permissions manifest file106(1)) of an application, such as the application104(1). Rather, the original permission manifest file (e.g., original permissions manifest file106(1)) is configured such that the user device102asks the user to either grant or deny all the permissions listed in the original permissions manifest file106(1) in their entirety during the installation of the application104(1). The original permissions manifest files106(1)-106(N) may be stored on the user device102.

In various embodiments, the user may be provided with an opportunity to create customized permissions manifest files108(1)-108(N) that are associated with the individual applications104(1)-104(N). In at least one embodiment, upon receiving a request to install an application, such as the application104(1), the user device102may prompt a user for input to grant or deny individual permissions for defining a customized permissions profile. Upon receiving the customized permissions profile, the user device102may create a new permissions manifest file, such as customized permissions manifest file108(1). The user device102may also repeat these procedures during the installation of other applications, such as the applications104(2)-104(N). Thus, when the user device102receives input to execute one of the applications104(1)-104(N), the user device may access one of the corresponding customized permissions manifest files108(1)-108(N), instead of a corresponding one of the original permissions manifest files106(1)-106(N).

Upon receiving subsequent requests to execute applications104(1)-104(N), the user device102may continue to access the applicable customized permissions manifest files108(1)-108(N), instead of the original permissions manifest files106(1)-106(N). As a result, the applications104(1)-104(N) may execute using customized permissions profiles in the customized permissions manifest files108(1)-108(N) instead of the permissions granted in the original permissions manifest files106(1)-106(N). In at least some embodiments, at least one of the customized permissions manifest files108(1)-108(N) may grant fewer permissions than a corresponding one of the original permissions manifest files106(1)-106(N).

In at least some embodiments, the user device102may also include a global permissions manifest file110. The global permissions manifest file110may be accessible via a settings menu provided by the user device102. In such an embodiment, a user may be presented with a list including a plurality of permissions and the user may identify a preference (i.e., grant or deny) for each of the permissions on the list, thereby defining a global permissions profile. Upon receiving user input defining the global permissions profile, the global permissions may be stored in the global permissions manifest file110. Then, upon receiving input to launch any of the applications104(1)-104(N), the user device102may access the global permissions manifest file110instead of the individual original permissions manifest files106(1)-106(N). As a result, the applications104(1)-104(N) may execute using the global permissions profile in the global permissions manifest file110instead of the permissions in the original permissions manifest files106(1)-106(N). In at least some embodiments, the global permissions manifest file110may grant fewer permissions than the original permissions manifest files106(1)-106(N).

Illustrative Embodiment

FIG. 2is a block diagram that illustrates selected components of a customizable permissions framework200on a user device102. The user device102may include a communication interface202, a user interface204, one or more processing units206, and/or computer-readable media208.

The communication interface202may include wireless and/or wired communication components that enable the user device102to transmit or receive voice or data communication via a telecommunication network or the Internet.

The user interface204may enable a user to provide inputs and receive outputs from the user device102. The user interface204may include a data output device (e.g., visual display, audio speakers, etc.), and one or more data input devices. The data input devices may include, but are not limited to, combinations of one or more of keypads, keyboards, mouse devices, touch screens, microphones, speech recognition packages, and any other suitable devices or other electronic/software selection methods. For simplicity, some components are omitted from the illustrated device.

The one or more processing unit(s)206can represent, for example, a CPU-type processing unit, a GPU-type processing unit, a field-programmable gate array (FPGA), another class of digital signal processor (DSP), or other hardware logic components that may, in some instances, be driven by a CPU. For example, and without limitation, illustrative types of hardware logic components that can be used include Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc. In various embodiments, the one or more processing unit(s)206may execute one or more modules and/or processes to cause server(s) to perform a variety of functions. Additionally, each of the one or more processing unit(s)206may possess its own local memory, which also may store program modules, program data, and/or one or more operating systems.

The computer-readable media208may include computer storage media and/or communication media. Computer storage media can include volatile memory, nonvolatile memory, and/or other persistent and/or auxiliary computer storage media, removable and non-removable computer storage media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Computer memory is an example of computer storage media. Thus, computer storage media includes tangible and/or physical forms of media included in a user device and/or hardware component that is part of a user device or external to a user device, including but not limited to random-access memory (RAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), phase change memory (PRAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, compact disc read-only memory (CD-ROM), digital versatile disks (DVDs), optical cards or other optical storage media, miniature hard drives, memory cards, magnetic cassettes, magnetic tape, magnetic disk storage, magnetic cards or other magnetic storage devices or media, solid-state memory devices, storage arrays, network attached storage, storage area networks, hosted computer storage or any other storage memory, storage device, and/or storage medium that can be used to store and maintain information for access by a computing device.

In contrast, communication media may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transmission mechanism. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. Such signals or carrier waves, etc. can be propagated on wired media such as a wired network or direct-wired connection, and/or wireless media such as acoustic, RF, infrared and other wireless media. As defined herein, computer storage media does not include communication media. That is, computer storage media does not include communications media consisting solely of a modulated data signal, a carrier wave, or a propagated signal, per se.

The computer-readable media208may also include one or more applications104(1)-104(N), permissions manifest files, (e.g., original permissions manifest files106(1)-106(N), customized permissions manifest files108(1)-108(N), and global permissions manifest file110) application framework216, libraries222, and at least one kernel226. As described above, the applications104(1)-104(N) may include applications that provide utility, entertainment, and/or productivity functionalities to a user of the user device102. For example, the applications104(1)-104(N) may include electronic mail applications, remote desktop applications, web browser applications, navigation applications, multimedia streaming applications, and/or so forth. The one or more applications104(1)-104(N), as described above, may include built-in applications210, custom applications212, and/or a security extension application214, such as a TrustZone® application, that is compatible with the ARM® family of processors produced by ARM Holdings PLC of Cambridge, England.

Built-in applications may be installed on a user device102prior to acquisition of the user device102by a user. Examples of built-in applications include telephony applications, contacts applications, electronic mail applications, camera applications, calendar applications, clock applications, SMS/MMS applications, etc. In some embodiments, custom applications may be acquired from third party providers after a user acquires the user device102. Examples of custom apps may include game applications (e.g., Amazed, Clickin2DaBeat, etc.), photo applications (e.g., Panoramio, Photostream, etc.), customized ringtone applications (e.g., RingsExtended, etc.), etc. The one or more applications104(1)-104(N) may also include a security extension application214, which is an application capable of providing system-wide security by partitioning system assets into regions (e.g., a secured environment and a normal environment), as described above. In at least some embodiments, one or more of the applications104(1)-104(N) (e.g., a security extension application such as TrustZone®, etc.) may execute techniques described herein, similar to a package manager module218described below.

In at least one embodiment, the application framework216may include a plurality of modules for implementing a standard structure of an application, such as application104(1). The application framework216may include modules such as the package manager module218and other modules220(e.g., activity manager module, resource manager module, location manager module, etc.).

In at least one embodiment, the package manager module218may present a user with a list of permissions as designated by the original permissions manifest files106(1)-106(N) during installation of an application, such as application104(1). The package manager module218may also receive user input granting or denying individual permissions for defining customized permissions and/or global permissions profiles. The package manager module218may modify original permissions manifest files, such as original permission manifest files106(1)-106(N), and/or create new permissions manifest files, such as customized permissions manifest files108(1)-108(N) and global permissions manifest file110, based on the user input received.

The computer-readable media208may also store the original permissions manifest files106(1)-106(N), the customized permissions manifest files108(1)-108(N), and the global permissions manifest file110, as described above. In at least one embodiment, each of the original permissions manifest files106(1)-106(N) and each of the customized permissions manifest files108(1)-108(N) may be stored in the root of a corresponding application of the applications104(1)-104(N). In at least one other embodiment, the original permissions manifest files106(1)-106(N), the customized permissions manifest files108(1)-108(N), and/or the global permissions manifest file110may be stored in the application framework216and/or stored in one or more modules of the application framework216.

The libraries222may include various libraries for storing data (e.g. surface manager, media framework, FreeType, etc.). Additionally, the libraries222may include runtime224(e.g., Android Runtime, etc.) for permitting application104(1)-104(N) to interface with the environment (e.g., environment100or200) in which they are running. The runtime224may include core libraries and may provide multiple runtime environments. In some embodiments, the multiple runtime environments may be virtual machines (e.g., Dalvik Virtual Machine, application virtual machine, etc.). In response to receiving input to execute an application, such as the application104(1), a runtime environment created for the application104(1) may access a customized permissions manifest file, such as customized permissions manifest file108(1), or the global permissions manifest file110, instead of a corresponding original permissions manifest file, such as original permissions manifest file106(1). Accordingly, the multiple runtime environments provided by the runtime224may execute applications104(1)-104(N) according to permissions defined in corresponding customized permissions manifest files108(1)-108(N) and/or the global permissions manifest file110, instead of the permissions defined in the corresponding original permissions manifest files106(1)-106(N). In at least some embodiments, the runtime environments (e.g., virtual machines) created by hypervisors may provide similar functionalities.

The kernel226may store a plurality of drivers228including display drivers, camera drivers, WiFi drivers, audio drivers, flash memory drivers, keypad drivers, etc. The computer-readable media208may include kernels in addition to kernel226. In at least one embodiment, the kernel226may receive input to execute an application. In turn, the kernel226may start a process in which a runtime224may create a runtime environment for executing the application. In at least some additional embodiments, one or more kernels (e.g., Android kernel module, SELinux policy, etc.) may execute functionality similar to a package manager module218described above.

Per Application Installation

FIGS. 3A-3Cillustrate embodiments of user interfaces300and306that may be presented to a user when installing an application, such as the application104(1). InFIG. 3A, user interface300is displayed on user device102. In at least one embodiment, when a user desires to install the application104(1), the package manager module218may prompt a user by the user interface300requesting that the user grant a plurality of permissions (e.g., permissions 1-6). In such an embodiment, permissions 1-6 represent the list of permissions identified in the original permissions manifest file corresponding to application104(1), such as original permissions manifest file106(1), as described above.

In the at least one embodiment, if a user wants to install the application104(1) and execute the functionality associated with the application104(1), the user selects the install option302. Upon selection of the install option302, the application104(1) may be installed on user device102. As shown by the small check marks in front of each of the permissions listed in the list of permissions, the package manager module218may grant application104(1) permission to access functionalities and/or data stored on the user device102corresponding to permissions 1-6 any time the user device102runs the application104(1). If the user does not want to grant any one of permissions 1-6, the user's only option is to select the cancel option304and the application104(1) will not be installed.

Many times, as described above, application104(1) does not use every permission requested in the list of permissions to properly function. At least some of these permissions may be excessive and unnecessary permissions, potentially exposing users to privacy risks. For example, excessive permissions may be used by rouge applications to maliciously and unintentionally perform actions that steal sensitive user information or increase the likelihood of loss of confidentiality, integrity, or availability of sensitive information or critical services without a user's awareness, as described above.

FIGS. 3B and 3Cillustrate embodiments of a user interface306presented to users for customizing permissions profiles for applications, as described herein. User interface306is displayed on user device102. In at least one embodiment, when a user desires to install an application, such as the application104(1), the package manager module218may prompt a user by presenting user interface306, instead of user interface300. As shown in the embodiment inFIG. 3B, the application104(1) is requesting access to permissions 1-6, as indicated by the original permissions manifest file106(1) for the application104(1). However, as shown inFIG. 3C, the user may customize which permissions the application104(1) may access and in doing so, may define a customized permissions profile for the application104(1).

In the at least one embodiment, the package manager module218may prompt the user to “allow”308a particular permission, “deny”310a particular permission, or receive a “prompt”312prior to an application using a particular permission of a list of permissions (e.g., permissions 1-6). In at least one embodiment, when a user indicates he or she would like to “allow”308a particular permission, he or she may be indicating that he or she wishes to grant the permission. In an alternative embodiment, when a user indicates he or she would like “deny”310a particular permission, he or she may be indicating that he or she would like to disable the permission for the application104(1). In an embodiment when a user selects “prompt”312, the user indicates that he or she would like to receive a prompt prior to the application104(1) accessing the functionality or data that is protected by a particular permission. An example embodiment of a prompt presented by the package manager module218in response to a user selecting “prompt”312is illustrated inFIG. 4and discussed below.

As illustrated inFIG. 3B, the user interface306shows an example embodiment of a user interface that is presented by the package manager module218and lists permissions as indicated by the original permissions manifest file106(1) corresponding to the application104(1).FIG. 3Bmay represent a default user interface wherein all of the permissions requested by the original permissions manifest file106(1) are allowed, as indicated by the check marks next to each of the permissions in the “allow”308column. If a user selects the install option302, the package manager module218may grant all of the permissions requested by the original permissions manifest file106(1). Alternatively, if the user selects the cancel option304, the application104(1) may not be installed on the user device102and consequently may not have access to any of the functionalities and/or data corresponding to the permissions requested.

In at least one embodiment shown inFIG. 3C, a user may customize a permissions profile via user input into user interface306. The user may choose to “allow”308particular permissions (e.g., permissions 1, 3, and 5), “deny”310particular permissions (e.g., permissions 2 and 6), and request a “prompt”312before an application, such as application104(1), attempts to access functionalities and/or data protected by particular permissions (e.g., permission 5). In such a scenario, when the user selects the install option304, the package manager module218may modify an original permissions manifest file, such as original permissions manifest file106(1), and/or create a new permissions manifest file, such as customized permissions manifest file108(1). The customized permissions manifest file108(1) may be stored in the computer-readable media208of the user device102. The customized permissions manifest file108(1) may store the state of each permission as defined by the user input. Upon receiving input to execute an application, such as application104(1), a runtime environment provided by the runtime224may access the customized permissions manifest file108(1) instead of the original permissions manifest file106(1) associated with the application104(1). Accordingly, when the application104(1) subsequently executes, the application104(1) may operate using the customized permissions profile indicated in the customized permissions manifest file108(1), instead of the permissions profile associated with the original permissions manifest file106(1).

For example, in the embodiment shown inFIG. 3C, when the user device102receives user input to launch application104(1), application104(1) may execute with permissions 1, 3, and 5. However, application104may execute without permissions 2 and 6. Additionally, each time application104(1) is executed, the package manager module218may prompt the user with a user interface requesting the user to grant or deny permission 4.

During installation of the application104(1), a user may alternatively select cancel option304and cancel the installation, denying all permissions for the application104(1). However, in such an embodiment, the user may not have access to the application104(1) or its associated functionality or data.

In at least one embodiment, a user may use an application permission control option to customize permissions after installation of an application, such as application104(1). In such embodiments, the package manager module218may present to a user an interface similar to user interface306and the user my provide input to customize permissions for the application104(1) by indicating whether to “allow”308permissions, “deny”310permissions, or receive a “prompt”312prior to accessing a functionality or data affected by a permission. As discussed above, the package manager module218may create a customized permissions manifest file, such as customized permissions manifest file108(1), that may be associated with the application104(1). Upon receiving input to execute the application104(1), the a runtime environment provided by the runtime224may access the customized permissions manifest file108(1) instead of a corresponding original permissions manifest file, such as original permissions manifest file106(1). Accordingly, the application104(1) may execute pursuant to the customized permissions profile of the customized permissions manifest file108(1) instead of the permissions profile of the original permissions manifest file106(1).

FIG. 4illustrates a prompt on a user interface400for customizing a permission for an application, such as application104(1), before an application104(1) attempts to access a functionality or data affected by the permission. As described above, a user may select “prompt”312, indicating that the user would like to receive a prompt prior to an application104(1) accessing a functionality or data affected by the permission. As illustrated inFIG. 4, the package manager module218may present user interface400for receiving user input regarding a particular permission (e.g., permission 4, in response to user selection of “prompt” for permission 4 inFIG. 3C) as requested by application104(1). The user may input custom permissions options for particular applications, such as applications104(1)-104(N). In at least one embodiment, a user may select “allow always”402, “allow once”404, “deny once”406, or “deny always”408.

In at least one embodiment, when a user selects “allow always”402, the user may be indicating that every time the application104(1) requests access to a functionality or data affected by a particular permission, that the package manager module218allows the application104(1) access to the functionality or data affected by the particular permission unless and until directed otherwise. In at least one embodiment, when a user selects “allow once”404, the user may be indicating that the application104(1) may access a functionality or data affected by the particular permission immediately following the selection of “allow once”404. However, when an application104(1) subsequently requests access to a functionality or data affected by the particular permission, the package manager module218may again prompt the user for permissions instruction. In at least one embodiment, when a user selects “deny once”406, the user may be indicating that the application104(1) may not access a functionality or data affected by a particular permission during an immediately subsequent execution of the application104(1). Similar to the “allow once”404option, when an application104(1) subsequently requests access to a functionality or data affected by the particular permission, the package manager module218may again prompt the user for permissions instruction. In at least one embodiment, when a user selects “deny always”408, the user may be indicating that the application104(1) may not access a functionally or data affected by the particular permission unless or until directed otherwise. A user may have an option to select a button410(e.g., “ok,” etc.) on the user interface400to indicate he or she has defined how the application104(1) may proceed.

There is no long term impact on the original permissions manifest files106(1)-106(N) in embodiments where the user selects “allow once”404or “deny once”406. However, in embodiments where the user selects “allow always”402or “deny always”408options, the package manager module218may be directed to modify an original permissions manifest file, such as original permissions manifest file106(1) with respect to the permission specified (e.g., enable or disable). In other embodiments where the user selects “allow always”402or “deny always”408options, the package manager module218may be directed to modify or create a new permissions manifest file, such as customized permissions manifest file108(1) or global permissions manifest file110with respect to the permission specified (e.g., enable or disable). As a result, the application104(1) may execute based on the user input provided via a prompt as illustrated by user interface400.

Global Permissions

FIG. 5is a block diagram that illustrates an additional embodiment of a user interface500for customizing a global permissions profile for applications executed by a user device102. In at least one embodiment, the package manager module218may provide a global permissions control option via a settings menu on the user device102. The global permissions control option may permit users to customize a comprehensive list of permissions associated with the plurality of applications104(1)-104(N). In some embodiments, permissions may be grouped into permission groups (e.g., “Services that cost you money,” etc.).

As shown inFIG. 5, a user may choose an option to “allow”502, “deny”504, “prompt”506, or request “app specific”508permissions for each permission (e.g., permissions 1-6) from user interface500. In at least one embodiment, when a user indicates he or she would like to “allow”502a permission, he or she may be indicating that he or she wishes to always grant the permission, or permit access to the functionality and/or data affected by the permission, regardless of the application (e.g., any application of applications104(1)-104(N)) that may be requesting the permission. In at least one embodiment, when a user indicates he or she would like to “deny”504a permission, he or she may be indicating that he or she would like to disable the permission, or withhold access to the functionality and/or data affected by the permission, regardless of the application (e.g., any application of applications104(1)-104(N)) that may be requesting the permission. In at least one embodiment, when a user selects “prompt”506, the user may be indicating that he or she would like to receive a prompt prior to any application (e.g., any application of applications104(1)-104(N)) attempting to access the functionality and/or data protected by a permission. In such circumstances, the package manager module218may present a user with a prompt as shown and discussed inFIG. 4, whenever an application, such as application104(1), requests access to the identified permission. When a user selects “application specific”508, the user may be indicating that the customized permissions as indicated at the time of installation for each of the applications104(1)-104(N) stored on the user device102should control the permissions profile for a particular permission. In such circumstances, a customized permissions manifest file, such as customized permissions manifest file108(1), which corresponds to a particular application, such as application104(1), may control access to functionality and/or data protected by the particular permission when the application104(1) executes, instead of a corresponding original permissions manifest file, such as original permissions manifest file106(1). A user may select a button510(e.g., “ok,” etc.) to indicate he or she has provided input to define the global permissions profile via user interface500.

In the at least one embodiment as shown inFIG. 5, a user has checked “allow”502for permissions 1 and 4. Accordingly, the user has indicated that he or she would like to always grant permissions 1 and 4, regardless of the application (e.g., any application of applications104(1)-104(N)) that may be requesting permissions 1 or 4. Additionally, in the at least one embodiment, the user has checked “deny”504for permissions 2 and 5. Accordingly, the user has indicated that he or she would like to always deny or disable permissions 2 and 5, regardless of the application (e.g., any application of applications104(1)-104(N)) that may be requesting permissions 2 or 5. The user also checked “prompt”506for permission 3 and “app specific”508for permission 6. Accordingly, the user has indicated that he or she would like to receive a prompt, as described inFIG. 4, prior to any of the applications104(1)-104(N) attempting to access the functionality and/or data protected by permission 3. Additionally, the user has indicated that he or she would like to defer to a customized permissions manifest file, such as customized permissions manifest file108(1) corresponding to an application, such as application104(1), any time the application104(1) requests access to the functionality and/or data protected by permission 6.

Based on user input defining the global permissions profile, the package manager module218may create a global permissions manifest file110. The global permissions manifest file110may be stored in the computer-readable media208. When the user device102receives input to execute an application, such as application104(1), the runtime environment provided by the runtime224may access the global permissions manifest file110instead of the original permissions manifest file, such as original permissions manifest file106(1) that is associated with the application104(1). When the application104(1) executes, the application104(1) may operate using the permissions granted in the global permissions manifest file110instead of the corresponding original permissions manifest file106(1).

Illustrative Embodiments

FIG. 6is a flow diagram that shows procedures600for customizing a permissions profile and running an application, such as application104(1), using permissions granted in a new permissions manifest file.

At block602, the package manager module218prompts a user for customized permissions. As illustrated inFIGS. 3B and 3Cand as described above, the package manager module218may prompt a user to provide input for customizing a permissions profile associated with at least one application, such as application104(1). In at least one embodiment, the package manager module218prompts the user during installation of the application104(1). In an alternative embodiment, the package manager module218prompts the user at some time after installation of the application104(1).

At block604, the package manager module218receives input to customize permissions. As described above, a user may provide input to customize a permissions profile. For example, the user may indicate that he or she would like to allow (e.g.,308) an application104(1) to access functionality and/or data protected by individual permissions of a list of permissions. Alternatively, the user may indicate that he or she would like to deny (e.g.,310) the application104(1) access to the functionality and/or data protected by individual permissions of a list of permissions. The user may also indicate that he or she would like to receive a prompt (e.g.312) before the application104(1) attempts to access the functionality and/or data protected by individual permissions for the application104(1).

At block606, the package manager module218creates a customized permissions manifest file, such as customized permissions manifest file108(1), that is associated with the application104(1). Upon receiving user input, the package manager module218may create a customized permissions manifest file108(1), as described above. The customized permissions manifest file108(1) may include the customized permissions profile and may be stored in the computer-readable media208.

At block608, the kernel226receives input to execute the application104(1). In turn, the kernel226may start a process in which a runtime environment may be created for executing the application104(1). In at least one embodiment, the runtime environment may be created by the runtime224.

At block610, the runtime environment accesses the customized permissions manifest file108(1) instead of the corresponding original permissions manifest file106(1).

At block612, the runtime environment executes the application104(1) using the customized permissions profile in the corresponding customized permissions manifest file108(1). In at least one embodiment as described above, the customized permissions manifest file108(1) may reduce the number of permissions an application104(1) may be granted as compared to the original permissions manifest file106(1).

FIG. 7is a flow diagram that shows procedures700for customizing permissions profiles and executing applications104(1)-104(N) using permissions granted in a global permissions manifest file110.

At block702, the packager manager module218receives input for customizing a global permissions profile. As described above, a user may access the global permissions manifest file110via a settings menu associated with the user device102. In some embodiments, the user may indicate that he or she would like to allow (e.g.,502) all applications104(1)-104(N) to access functionality and/or data protected by individual permissions of a list of permissions. Alternatively, the user may indicate that he or she would like to deny (e.g.,504) all applications104(1)-104(N) access to functionality and/or data protected by individual permissions of a list of permissions. In some embodiments, the user may indicate that he or she would like to receive a prompt506before any application (e.g., any application of applications104(1)-104(N)) attempts to access functionality and/or data protected by a particular permission. In other embodiments, a user may indicate that he or she would like the package manager module218to defer to a corresponding application specific permissions manifest file (e.g., a customized permissions manifest file, such as customized permissions manifest file108(1)) for permissions specific to an application104(1).

At block704, the package manager module218creates a global permissions manifest file110. As described above, upon receiving user input for customizing a global permissions profile, the package manager module218creates a global permissions manifest file110. The global permissions manifest file110may be stored in the computer-readable media220.

At block706, the kernel226receives input to execute an application, such as application104(1). In turn, the kernel226may start a process in which a runtime environment may be created for executing the application104(1). In at least one embodiment, the runtime environment may be created by the runtime224.

At block708, the runtime environment accesses the global permissions manifest file110instead of an original permissions manifest file, such as original permissions manifest file106(1), or a customized permissions manifest file, such as customized permissions manifest file108(1). As described above, the runtime environment may access the global permissions manifest file110instead of the original permissions manifest file106(1) associated with the application104(1). In an embodiment where there is a customized permissions manifest file, such as customized permissions manifest file108(1), in addition to the global permissions manifest file110, the runtime environment may access the global permissions manifest file110instead of the customized permissions manifest file108(1). In at least one embodiment, when a user defers to an application specific permissions manifest file in the global permissions manifest file110with respect to a particular application104(1), the runtime environment may access the applicable customized permissions manifest file108(1), instead of the global permissions manifest file110.

At block710, the runtime environment executes the application104(1) granting permissions defined in the global permissions manifest file110instead of the original permissions manifest file106(1) and/or the customized permissions manifest file108(1). In at least one embodiment as described above, the global permissions manifest file110may reduce the number of permissions that applications104(1)-104(N) may be granted as compared to the corresponding original permissions manifest files106(1)-106(N). In at least one embodiment, when a user defers to an application specific permissions manifest file in the global permissions manifest file110with respect to a particular application104(1), application104(1) may operate having access to the customized permissions profile as identified in the applicable customized permissions manifest file108(1), instead of the global permissions manifest file110.

FIG. 8is a flow diagram that shows procedures800for customizing permissions profiles and executing an application, such as application104(1), using permissions granted in either a customized permissions manifest file, such as customized permissions manifest file108(1), or a global permissions manifest file110.

At block802, the kernel226receives input to execute an application104(1). In turn, the kernel226may start a process in which a runtime environment may be created for executing the application104(1). In at least one embodiment, the runtime environment may be created by the runtime224.

At decision block804, the runtime environment determines whether an alternative permissions manifest file is available in addition to the original permissions manifest file, such as original permissions manifest file106(1). For example, the runtime environment determines whether a customized permissions manifest file108(1) and/or a global permissions manifest file110is available.

At block806, if no alternative permissions manifest file is available, the runtime environment executes the application104(1) using the permissions granted in the original permissions manifest file106(1). If neither a customized permissions manifest file108(1) or a global permissions manifest file110is available, the runtime environment may operate application104(1) using permissions granted in the original permissions manifest file106(1).

At decision block808, if an alternative permissions manifest file is available, the runtime environment determines a type of alternative permissions file available. For example, the runtime environment determines whether the alternative permissions manifest file is a customized permissions manifest file108(1) or a global permissions manifest file110, as described above.

If the alternative permissions manifest file is a customized permissions manifest file108(1), at decision block810, the runtime environment determines whether a global permissions manifest file110is also available. If a global permissions manifest file110is not available, the runtime environment executes the application104(1) granting permissions specified in the customized permissions manifest file108(1).

If a global permissions manifest file110is also available, the runtime environment determines whether the global permissions manifest file110refers to the customized permissions manifest file108(1). If the global permissions manifest file110does not refer to a customized permissions manifest file108(1), the runtime environment may execute the application104(1) granting permissions specified in the global permissions manifest file110, as shown in block814. However, if a global permissions manifest file110refers to the customized permissions manifest file108(1), application104(1) may operate using the permissions granted in the customized permissions manifest file108(1), as shown in block816.

If a global permissions manifest file110is available, at decision block812, the runtime environment determines whether the global permissions manifest file110refers to a customized permissions manifest file108(1). If the global permissions manifest file110does not refer to the customized permissions manifest file108(1), application104(1) may operate using permissions granted in the global permissions manifest file110, as shown in block814. However, if the global permissions manifest file110refers to the customized permissions manifest file108(1), application104(1) may operate using permissions granted in the customized permissions manifest file108(1), as shown in block816.

CONCLUSION