Device-based application security

Disclosed are techniques and apparatuses for implementing device-based application security. These techniques enable a computing device to assign a security level from a hierarchy of security levels to an application. Once the security level is assigned to the application, authentication techniques associated with the security level can be initiated in response to a request to launch the application. When an indication is received that the security level for the application has been satisfied, the application can then be launched, availing a user of the application's full functionality.

TECHNICAL FIELD

The present disclosure is related generally to security techniques and, more particularly, to security techniques for allowing access to applications of a mobile device.

BACKGROUND

Conventional techniques that address application security on mobile devices are often binary—either the mobile device is locked, in which case a user can access a very limited subset of applications, or the mobile device is unlocked, in which case the user has full access to the applications on the mobile device. The subset of applications that are accessible when a mobile device is locked may include just those applications that have been declared to run above the lock screen (e.g., camera, touchless control, lock-screen widgets, and so on). However, mobile-device users may find this approach to be inconvenient in some instances and insufficient in others. Consequently, conventional techniques for application security can be unsatisfactory to mobile-device users.

DETAILED DESCRIPTION

Turning to the drawings, wherein like reference numerals refer to like elements, techniques of the present disclosure are illustrated as being implemented in a suitable environment. The following description is based on embodiments of the claims and should not be taken as limiting the claims with regard to alternative embodiments that are not explicitly described herein.

Conventional techniques for providing application security on mobile devices are often binary. These techniques are considered “binary” insofar as they involve simply locking and unlocking the device, e.g., by entering a 4-digit personal identification number (“PIN”). While the mobile device is locked, a user may be able to access some applications that have been declared to run above the lock screen, such as a camera, touchless control, lock-screen widgets, and so on. Once the device is unlocked, however, the user may have full access to applications on the device. Giving full access to each of the applications with a same authentication technique may be incongruous when security concerns for each application are considered. Entering a 4-digit PIN may seem excessive for launching a game that neither accesses personally identifiable information (“PII”) nor delivers such information over a network connection. On the other hand, mere entry of a 4-digit PIN may not be secure enough for launching a banking application that accesses financial information and allows a user to perform financial transactions.

One way in which application developers have chosen to address these issues of application security is to implement authentication techniques on a per-application basis. Developers of banking applications, for example, may program authentication techniques into the banking application that require a user to successfully enter a password before gaining access to banking functionality. Allowing developers to implement security on a per-application basis, however, may result in a host of issues, such as requiring users to remember different passwords for each application, delivering inconsistent user experiences over the variety of applications on a mobile device, applications failing to address security in a way that reflects a security level the device maker (or operating-system provider) would like to be associated with, and so on. Consequently, users can find such approaches for implementing application security on a mobile device to be unsatisfactory.

This disclosure describes techniques and apparatuses that facilitate device-based application security, which enables security to be addressed in a consistent and congruous manner for each of the applications on a mobile device. Device-based application security can be implemented, for example, so that authentication techniques initiated by the device to launch a game are different from those initiated by the device to launch banking applications. Further, by implementing security for the applications at the device level, the device maker (or operating-system provider) can ensure that applications that present similar security concerns are addressed in a consistent manner.

The device-based application-security techniques described herein can assign a security level from a hierarchy of security levels to an application on a mobile device. The hierarchy of security levels represents levels of authentication techniques that are required to launch applications.

By way of example, the hierarchy may include three security levels, where higher security levels are associated with increasingly stronger authentication techniques. In this example, a lowest security level may not require a user to provide any input to launch an application assigned to this level, such as no additional input after a device is unlocked and applications are accessible. To launch an application assigned to the next security level (e.g., a medium security level), a user may be required to enter a 4-digit PIN. To launch an application assigned to the highest security level, however, a user may be required to satisfy the conditions of an even stronger authentication technique, such as entering a password of at least ten characters that include at least one number and at least one capital letter, providing biometric information (e.g., a thumb print, a picture of the user's face, and so on), and so forth.

When a request to launch an application is received (e.g., a user taps an icon representative of an application on a home screen of a device), the authentication technique of the security level assigned to the application can be initiated. Continuing with the example above, if the request is received for an application assigned to the medium security level, a process to display an interface for entering a 4-digit PIN can be initiated. After the assigned security level for the application has been satisfied by the authentication technique, the application is then launched for user access.

FIG. 1illustrates an example environment100in which techniques described herein can be implemented. Environment100includes a computing device102having a display104capable of displaying various user interfaces to interact with applications on the computing device102. Display104can display a home screen106from which a user of the computing device102can request to launch applications. Display104can be configured as a touchscreen that allows a user to request that an application be launched by performing a gesture (e.g., tapping) relative to an icon representative of the application.

Home screen106can include several icons that are selectable to launch applications represented by those icons. By way of example, consider icons108,110,112which represent a game application, a maps application, and a banking application, respectively. By performing a gesture relative to icon108, a user can request to launch the game application. In a similar manner, gestures performed relative to icons110,112can be recognized as requests to launch the maps application and the banking application.

Prior to launching an application, a security level from a hierarchy of security levels is assigned to the application. The hierarchy of security levels represents levels of authentication techniques required to launch applications when initiated by a user of the device. A particular security level of the hierarchy can be assigned to an application based on a variety of factors, such as an indication of the security level coded into the application by its developer, user input that indicates which security level to assign to the application, PII exposed by the application, or permissions the application requests from the computing device102. The techniques described herein enable different security levels of the hierarchy to be assigned to different applications.

Using the environment100ofFIG. 1as an example, the security level assigned to the banking application can be different from the security level assigned to the maps application, both of which can be different from the security level assigned to the game application. The security level assigned to the banking application can be different from that assigned to the maps application insofar as it corresponds to stronger authentication techniques, e.g., entry of a password compared to simply entry of a 4-digit PIN. In a similar manner (based on differences in authentication-technique strength), the security level assigned to the maps application can be different (e.g., stronger) than that assigned to the game application. It is also to be appreciated that a same security level can be assigned to similar applications. A banking application and an online payment application may be assigned to the same security level, for example.

Regardless of the security level assigned to an application, the authentication techniques of the assigned security level can be initiated when a request to launch the application is received. In the context ofFIG. 1, a user may select icon108and thereby request to launch the game application. As discussed just above, the security level assigned to the game application can be different from that assigned to the maps or banking application. In particular, the security level assigned to the game application can correspond to less stringent authentication techniques than the security levels of the maps and banking applications.

InFIG. 1, the authentication techniques required to launch the game application are represented by start screen114. After icon108is selected by a user to request launch of the game application, start screen114can be displayed without requiring any additional user input, such as entry of a 4-digit PIN or password. This can be the case if the security level assigned to the game application corresponds to an authentication technique that does not require any input from a user to launch an application. The lowest or lower security levels of a security-level hierarchy can represent such authentication techniques, e.g., those that require little or no user input to launch applications.

In contrast, consider PIN screen116and password screen118. PIN screen116can be displayed responsive to selection of icon110to launch the maps application, and password screen118can be displayed responsive to selection of icon112to launch the banking application. PIN screen116represents the authentication techniques required to launch the maps application, and password screen118represents the authentication techniques required to launch the banking application. Once a 4-digit PIN is successfully entered via the PIN screen116, the maps application can be launched, giving the user full access to its features. Likewise, after a password is successfully entered via the password screen118, the banking application can be launched, giving the user full access to its features. In this example, entering a password is considered a stronger authentication technique, and therefore associated with a higher security level in the hierarchy, than entering a 4-digit PIN. It is to be appreciated, however, that in some implementations of device-based application security, entry of a 4-digit PIN can be considered a stronger authentication technique and thus associated with a higher security level than entering a password. In any case, start screen114, PIN screen116, and password screen118represent different authentication techniques that can be initiated in response to requests to launch applications.

More specifically, considerFIG. 2, which illustrates at200an example embodiment of computing device102ofFIG. 1. Computing device102can be, or can include, many different types of computing or electronic devices capable of implementing device-based application security. In this example, computing device102is shown as a smart phone, though other devices are contemplated. Other computing devices102may include, by way of example, a cellular phone, notebook computer (e.g., netbook or ultrabook), camera (compact or single-lens reflex) smart-watch, smart-glasses, tablet computer, personal media player, personal navigating device (e.g., global positioning system (“GPS”)), gaming console, desktop computer, video camera, or portable gaming device.

Computing device102includes processor202, which may be configured as a single or multi-core processor capable of enabling various functionalities of computing device102. In some cases, processor202includes a digital-signal-processing subsystem for processing various signals or data of computing device102. Processor202may be coupled with, and may implement functionalities of, any other components or modules of computing device102that are described herein.

Computing device102includes computer readable-memory (“CRM”)204. CRM204includes device data206, such as an operating system or firmware of computing device102that are executable by processor202. Device data206may also include various user data, such as images, music, documents, emails, contacts, and the like. CRM204also includes applications208that are executable by the processor202and application-security engine210, which in this example is embodied as computer-executable code stored on CRM204. In this example, CRM204is illustrated as including security-level (“SL”) hierarchy212and a mapping of applications to security levels214.

Security engine210can assign a security level of SL hierarchy212to an application. To do so, security engine210can assess a variety of factors, such as whether an indication of a security level is coded into the application by its developer, whether user input is received that indicates the security level to assign to the application, PII the application is configured to expose, and permissions requested by the application. Once a determination is made regarding which security level of SL hierarchy212to assign to an application, security engine210can create an entry in the SL mapping214that maps the application to the assigned security level in the hierarchy.

Refer now toFIG. 3which illustrates at300an example embodiment of SL hierarchy212depicted inFIG. 2. SL hierarchy212includes security level 1 (“SL1”)302, SL2304, and SLN306. Thus, in the example at300, SL hierarchy212has at least three different security levels but may have more, e.g., up to N different security levels. Although SL hierarchy212is depicted with at least three different security levels, SL hierarchy212may have more or fewer levels without departing from the spirit of the techniques described herein.

Further, the security levels, SL1302, SL2304, and SLN306can each be associated with respective authentication techniques, as illustrated. SL1302includes SL1 authentication techniques308, SL2304includes SL2 authentication techniques310, and SLN306includes SLN authentication techniques312. In this example, SL1 authentication techniques308, SL2 authentication techniques310, and SLN authentication techniques312can represent increasingly stronger authentication techniques. It follows then that SL1302, SL2304, and SLN306represent increasing levels of security in SL hierarchy212.

Given such a configuration of SL hierarchy212, SL1 authentication techniques308can represent authentication techniques that do not require user input to launch an application, such as those discussed with reference to start screen114. SL2 authentication techniques310, however, represent stronger authentication techniques than those represented by SL1 authentication techniques308. SL2 authentication techniques310can represent an authentication technique that requires a user to successfully enter a 4-digit PIN before an application is launched, for example. Still further, SLN authentication techniques312represent stronger authentication techniques than those represented by SL2 authentication techniques310. For example, SLN authentication techniques312can represent an authentication technique that requires a user to successfully enter a password having at least one lowercase letter, one capital letter, one number, and one symbol. It is to be appreciated that SL1 authentication techniques308, SL2 authentication techniques310, and SLN authentication techniques312can represent different authentication techniques than those described above without departing from the spirit and scope of the techniques described herein. By way of example and not limitation, other authentication techniques can include biometric authentication techniques (e.g., finger-print identification), capturing a photograph of the user and performing facial recognition, entry of a custom gesture using touch input, capturing speech from a user and performing audio recognition, and so on.

Security engine210can consider whether a security level has been coded into an application when assigning a security level to the application. In some implementations, the device-based application-security techniques described herein allow developers to include code in an application that indicates which security level to assign to the application. With reference toFIG. 3, for example, a developer of an application can indicate in his code to set the security level of the application to SL1302. Security engine210can then ascertain the indicated security level in conjunction with assigning a security level to the application. Once ascertained, security engine210can use the indicated security level as a basis for assigning the security level to the application.

Security engine210can also consider whether user input has been received that indicates a security level to assign to an application. With reference again toFIG. 3, a user of computing device102can be presented with an interface on display104that allows the user to select which of SL1302, SL2304, or SLN306to assign to an application. Security engine210can initiate such an interface to be presented to a user when first assigning a security level to the application. An interface to select or change security levels for applications208can also be displayed at any time, e.g., when a user selects to change settings of computing device102. After a user selects a security level for an application, security engine210can use the selected security level as a basis for assigning the security level to the application.

An interface that allows a user to select security levels for an application may limit which of the security levels the user can select, however. Security engine210may determine a minimum security level for a particular application, and the user interface simply may not allow the user to change the security level below the determined minimum level. Using the banking application as an example, security engine210may assign the banking application to SLN306, but determine that SL2304is a minimum security level for the banking application. As such, when a user interface is presented for changing the security level of the banking application, the user interface may indicate that the current security level of the banking application is SLN306. The user interface may also provide an option that allows the user to change the security level of the banking application from SLN306to SL2304. An option to change the security level to SL1302may be grayed out, frozen, or not appear at all, however, indicating that the security level of the banking application cannot be changed so SL1302. Alternately, the user interface may not limit which security levels of SL hierarchy212a user can select to assign to an application.

Additionally, security engine210can perform an assessment of an application, in which a variety of factors are considered, to automatically assign a security level to the application. In doing so, security engine210can consider a developer-provided indication or user input indicating a security level as factors in determining which security level to assign to the application. However, security engine210can also determine which security level to assign an application without considering these factors. Regardless of whether security engine210considers a developer-provided indication or user input indicating a security level, the security engine210can consider other factors to determine which security level to assign to an application.

Security engine210can consider PII exposed by an application, for example. Some types of PII may be more sensitive or cause greater harm if compromised than other types of PII. Consequently, security engine210can assign higher security levels (e.g., those having stronger authentication techniques) to applications that access more sensitive types of PII than to applications that access less sensitive types of PII. In the context ofFIG. 3, an application that exposes financial-account information (e.g., a banking application) can be assigned to SLN306whereas an application that merely exposes location information (e.g., a maps application) can be assigned to SL2304.

To determine the types of PII that an application puts at risk, the security engine210can check for a declaration in the code that specifies the types of PII used by the application. Device-based application-security techniques may be implemented so that defined types of PII an application can put at risk are recognized, such as contact information, financial accounts, messages from other users, location information, identity information (e.g., social security number, passport number, driver's license number, etc.), and so forth. Given the PII-type definitions, developers can declare in an application's code which of the PII types the application exposes. Further, a user may be able to specify which PII types he is comfortable having exposed by an application, e.g., via a settings interface. A user may also be able to specify which security levels to assign to applications that expose certain PII types via the settings interface. Security engine210can then assign a security level to an application according to the PII-type declaration in the application and user specification regarding PII types. Applications that do not expose PII types the user is unwilling to expose can be assigned to a lower security level, e.g., SL1302in the context ofFIG. 3.

Security engine210can also be configured to detect PII types that are exposed by an application in other ways. Security engine210can monitor packets that an application intends to send over a network for PII types, for example. Based on information included in the packets, security engine210can then assign a security level to the application. If the application attempts to send different PII types than those declared in the application, then the security engine210can cause a user to be notified of the discrepancy and to be prompted to change the security level assigned to the application.

Security engine210can also consider permissions requested by an application when determining which security level to assign to the application. Some permissions, if granted, may enable an application to cause more harm than other permissions. Consequently, security engine210can assign higher security levels (e.g., those having stronger authentication techniques) to applications that request potentially harmful permissions than applications that request permissions with less potential for harm. Device-based application-security techniques may be implemented so that if an application requests a permission on a list of permissions, security engine210can force the application into a higher security level. By way of example and not limitation, the list of permissions can include direct access to dial phone numbers, access to send electronic messages, access to GPS location, and so on.

Security engine210can also assign a security level to an application based on the permissions requested by the application and on user input regarding the requested permissions. For example, a user may be able to specify which permissions he is comfortable granting to an application via the settings interface. The user may also be able to specify which security levels to assign to applications that request certain permissions via the settings interface. Given these user preferences and permissions that are requested, the security engine210can assign a security level to a permission-requesting application.

In addition to assigning a security level to an application based on input received from a user of the computing device102, security engine210can assign a security level to an application based on a security level that users of other devices assign to the application. Security engine210of computing device102may assign SL2304to the maps application, for example. Security engines of other computing devices may also assign SL2304to instances of the maps application at those other devices. After using the maps application, however, users of such other devices may decide that the security level assigned to their instances of the maps application (SL2304) should be changed. A user may determine, for example, that based on the PII accessed by the maps application, its security level is to be changed to a higher security level, such as SLN306. Consequently, the user may manually change the security level assigned to his instance of the maps application to SLN306.

Once a threshold number of other device users have manually changed the security level of the maps application, an indication of these changes may be communicated to computing device102. Responsive to receiving this indication, security engine210can automatically change the security level assigned to the maps application on computing device102. In this particular example, the security engine210can change the security level so that SLN306is assigned to the maps application at computing device102rather SL2304. Alternately, security engine210can cause a notification to be displayed to the user that indicates the change made at the other devices. The notification can prompt the user of computing device102to change the security level assigned to the maps application. The notification can also include an option therein that allows the user to change the security level assigned to the maps application. In any case, security engine210can consider manual security-level selections (or changes) made by users of other devices when determining which security level to assign to an application.

Once the security engine210assigns a security level to an application, security engine210can cause the authentication techniques of the assigned security level to be administered when a request to launch the application is received. It should be noted that security engine210represents functionality of computing device102to administer the authentication techniques in lieu of applications208. The device-based application security described herein can be performed at an operating-system level or firmware level of computing device102rather than by applications208. Accordingly, security engine210initiates the corresponding authentication technique when a request is received to launch an application. The security engine210can check the SL mapping214to ascertain which security level is assigned to the application and then administer the authentication technique represented by that level. After an indication that the authentication technique for the assigned security level has been satisfied, security engine210can enable launch of the application.

The following discussion describes techniques enabling device-based application security. These techniques enable a computing device to assign a security level of a hierarchy of security levels to an application. Once the security level is assigned to the application, authentication techniques represented by the security level can be initiated in response to a request to launch the application. When an indication is received that authentication techniques of the security level for the application have been satisfied, the application can then be launched, availing a user of the application's full functionality. These techniques can be implemented utilizing the previously described environment, such as security engine210, SL hierarchy212, and SL mapping214ofFIG. 2. These techniques include the example method illustrated inFIG. 4, which is shown as operations performed by one or more entities.

FIG. 4is a flowchart400of a representative method for assigning a security level from a hierarchy of security levels to an application and launching the application in accordance with the assigned security level.

At402, a security level from a hierarchy of security levels is assigned to an application. Each of the security levels in the hierarchy is associated with an authentication technique required to launch applications. By way of example, security engine210assigns SL2304to the maps application on computing device102. SL2304corresponds to SL2 authentication techniques310, which can involve entry of a 4-digit PIN. Security engine210can assign SL2304to the maps application based on any of a variety of factors, such as the maps application including a declaration in its code indicating that SL2304be assigned, receiving user input specifying that SL2304be assigned to the maps application, a determination that the maps application exposes PII that corresponds to SL2304, a determination that the maps application requests permissions that correspond to SL2304, and so on.

At404, the authentication technique associated with the assigned security level is initiated responsive to a request to launch the application. By way of example, a user requests to launch the maps application, e.g., by performing a gesture relative to icon110ofFIG. 1. Responsive to this request, security engine210initiates SL2 authentication technique310because it is the authentication technique of the security level assigned to the maps application (SL2304). As noted above, SL2 authentication technique310can involve entry of a 4-digit PIN. In this example, security engine210can cause an interface to be displayed via display104that allows a user of computing device102to enter his 4-digit PIN.

At406, the application is launched responsive to an indication that the assigned security level for the application has been satisfied by the authentication technique. By way of example, a user of computing device102successfully enters his 4-digit PIN via PIN screen116. Security engine210determines that the 4-digit PIN was successfully entered and generates an indication indicating that SL2304has been satisfied by SL2 authentication techniques310(entry of the 4-digit PIN). Alternately, the security engine210receives the indication indicating that SL2304has been satisfied by SL2 authentication technique310. Regardless of whether security engine210makes the determination itself or receives the indication that SL2304is satisfied, the maps application can be launched as a result of SL2304being satisfied by SL2 authentication technique310.

At (optional)408, a different security level is assigned to the application based on the different security level being assigned to the application by users of other devices. By way of example, devices other than computing device102include the maps application. Like security engine210, the security engines of the other devices initially assign SL2304to the maps application on those devices. In this example, the users of those other devices manually change the security level assigned to the maps application on their devices. When at least a threshold number of other users have changed the security level initially assigned to the maps application on their devices, security engine210may be notified of the changes. Responsive to receiving such a notification, security engine210may change the security level assigned to the maps application on computing device102so that SLN306is assigned instead. In this way, the security engine210can ensure that the level of security applied to an application on computing device102is commensurate with that established by the mobile-device-using community.

FIG. 5illustrates various components of an example electronic device500that can be implemented as a computing device as described with reference to any of the previousFIGS. 1 through 4. Electronic device500can be any of many different types of devices that include many different applications for which device-based application security can be implemented, such as the computing device102described with reference toFIG. 1.

Electronic device500includes communication transceivers502that enable wired or wireless communication of device data504, such as received data and transmitted data, via a network or other connection. In some cases, these transceivers are for communicating via a wireless network or directly with other devices such as by near-field communication. Example wireless communication transceivers include wireless personal-area network radios compliant with various Institute of Electrical and Electronics Engineers (“IEEE”) 802.15 standards, wireless local-area network radios compliant with any of the various IEEE 802.11 standards, wireless wide-area networks radios for cellular telephony, and wireless metropolitan area network radios compliant with various IEEE 802.16 standards.

Example wired communication transceivers include wired local area network Ethernet transceivers, serial data interfaces, audio/video ports (e.g., high-definition multimedia interface (“HDMI”) ports), and Universal Serial Bus (“USB”) ports. These may be implemented using standard connectors or through the use of proprietary connectors and associated cables providing enhanced security or interconnect density.

Electronic device500may also include one or more data-input ports506via which any type of data, media content, and inputs can be received, such as user-selectable inputs, messages, music, television content, recorded video content, and any other type of audio, video, or image data received from any content or data source. Data-input ports506may include USB ports, coaxial-cable ports, and other serial or parallel connectors (including internal connectors) for flash memory, digital versatile discs, compact discs, and the like. These data-input ports may be used to couple the electronic device500to components, peripherals, or accessories such as keyboards, microphones, or cameras.

Electronic device500of this example includes processor system508(e.g., any of application processors, microprocessors, digital-signal processors, controllers, and the like) or a processor and memory system (e.g., implemented in a system-on-chip), which processes computer-executable instructions to control operation of the device. A processing system may be implemented at least partially in hardware, which can include components of an integrated circuit or on-chip system, digital-signal processor, application-specific integrated circuit, field-programmable gate array, a complex programmable logic device, and other implementations in silicon and other hardware. Alternatively or in addition, the electronic device can be implemented with any one or combination of software, hardware, firmware, or fixed-logic circuitry that is implemented in connection with processing and control circuits, which are generally identified at510. Although not shown, electronic device500can include a system bus, crossbar, interlink, or data-transfer system that couples the various components within the device500. A system bus can include any one or combination of different bus structures, such as a memory bus or memory controller, data protocol/format converter, a peripheral bus, a universal serial bus, a processor bus, or local bus that utilizes any of a variety of bus architectures.

Electronic device500also includes one or more memory devices512that enable data storage, examples of which include random-access memory, non-volatile memory, and a disk storage device. Memory devices512are implemented at least in part as physical devices that store information (e.g., digital or analog values) in storage media, which do not include propagating signals or waveforms. The storage media may be implemented as any suitable types of media such as electronic, magnetic, optic, mechanical, quantum, atomic, and so on. Memory devices512provide data-storage mechanisms to store the device data504, other types of information or data, and various device applications514(e.g., software applications). An operating system516can be maintained as software instructions within memory devices512and executed by processor system508. In some aspects, security engine518and security-level hierarchy520are embodied in memory devices512of electronic device500as executable instructions or code. Although represented as a software implementation, security engine518may be implemented as any form of a control application, software application, signal-processing and control module, firmware that is installed on the device, a hardware implementation, and so on.

Electronic device500also includes audio and video processing system522that processes audio data and passes through the audio and video data to audio system524and to display system526. Audio system524and display system526may include any modules that process, display, or otherwise render audio, video, display, or image data, such as from security engine518. Display data and audio signals can be communicated to an audio component and to a display component via a radio-frequency link, S-video link, HDMI, composite-video link, component-video link, digital video interface, analog-audio connection, or other similar communication link, such as media-data port528. In some implementations, audio system524and display system526are external components to electronic device500. Display system526can also be an integrated component of the example electronic device500, such as part of an integrated display and touch interface.

Electronic device500may also include sensors (not shown), which enable electronic device500to sense various properties, variances, or characteristics of an environment in which electronic device500operates. Sensors may include any suitable type of sensor, such as an infrared sensor, proximity sensor, light sensor, acoustic sensor, magnetic sensor, temperature/thermal sensor, micro-electromechanical systems, camera sensor (e.g., a charge-coupled device or complementary-metal-oxide semiconductor sensor), capacitive sensor, and so on. In some cases, sensors enable interaction with, or receive input from, a user of electronic device500. In such a case, sensors may include piezoelectric sensors, capacitive-touch sensors, input sensing-logic associated with hardware switches (e.g., keyboards, snap-domes, or dial-pads), and so on.

In view of the many possible embodiments to which the principles of the present discussion may be applied, it should be recognized that the embodiments described herein with respect to the drawing figures are meant to be illustrative only and should not be taken as limiting the scope of the claims. Therefore, the techniques as described herein contemplate all such embodiments as may come within the scope of the following claims and equivalents thereof.