Authenticating interface element interactions

Abstract

The present disclosure relates to authenticating interface element interactions. An access control system is provided for preventing surreptitious granting of access to privacy-related functions on an electronic device. A software-based event that grants access to a device function can be verified by confirming that the software event corresponds to a hardware input event. This verification prevents substitution of user interface inputs that can be used to fraudulently grant access to particular functions.

Description

[0001] Case Separation Statement This application is a divisional application of Chinese invention patent application filed on May 24, 2021, entitled "Interaction of Authentication Interface Elements" and with application number "202180043382.4".

[0002] Cross-referencing This application claims priority to U.S. Provisional Application No. 63 / 041,797, filed June 19, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates in its entirety to mobile electronic devices. More specifically, this disclosure relates to systems and associated methods for enabling access to protected functions via authenticated interaction with user interface elements presented on the user interface of a mobile electronic device. Background Technology

[0004] It is possible to restrict an application's ability to access certain functions provided by an electronic device. Restricted functions may include access to the user's privacy-related data or functions of the mobile device that could be used to collect private user data. The operating system of the electronic device may include privacy controls that manage the restrictions imposed on privacy-related functions. Such privacy controls can be used to enable or disable access to functions provided by the electronic device. Generally, a privacy control system is configured to restrict access only to privacy-related functions explicitly granted by the user of the electronic device. Summary of the Invention

[0005] This paper describes an access control system for preventing unauthorized access to privacy-related functions on electronic devices. Software-based events granting access to device functions are verified by confirming that the software event corresponds to a hardware input event. This verification prevents spoofing of user interface inputs that could be used to fraudulently grant access to specific functions.

[0006] One embodiment provides a method comprising: displaying, via a display of an electronic device, user interface elements corresponding to a function executed on one or more processors of the electronic device; and receiving an instruction to interact with the user interface elements. The method further comprises: in response to receiving the instruction and determining that the instruction corresponds to a hardware input event, sending an authentication token from a first component of the electronic device to a second component of the electronic device; verifying the validity of the authentication token by the second component; and, after verifying the validity of the authentication token, initiating the execution of the function.

[0007] One embodiment provides a non-transitory machine-readable medium that stores instructions that, when executed by one or more processors, cause one or more processors to perform operations including those described herein.

[0008] One embodiment provides a data processing system on an electronic device, the system including a display, a memory device, and one or more processors coupled to the memory device and the display. The one or more processors are configured to execute instructions stored in the memory device. These instructions cause the one or more processors to perform operations as described herein.

[0009] Other features of the embodiments of the present invention will become apparent from the accompanying drawings and the following detailed description. Attached Figure Description

[0010] The embodiments disclosed herein are illustrated by way of example rather than limitation in the accompanying drawings, in which similar reference numerals refer to similar elements, and in the drawings: Figure 1 An access control system for privacy-sensitive data and hardware of computing devices is shown; Figures 2A to 2B A system for implementing an authentication interface interaction for selection functions on electronic devices is shown; Figure 3 A system including an electronic device is shown, in which an access control prompt is displayed to enable access to functions provided by the electronic device; Figure 4 A system is shown in which an electronic device verifies input for selecting advertisements to be displayed within an application executed by the electronic device; Figure 5 A system is shown in which an electronic device verifies input for pasting data from the electronic device's clipboard memory; Figure 6 This demonstrates a method for performing authentication interface element interactions with the verified UI element; Figure 7 The method for drawing the verified interface elements is shown; Figures 8A to 8C This demonstrates a method for managing access to functions provided by processes of an electronic device using verified UI elements; Figure 9 The system demonstrates a method for gating access to device functions behind verified UI elements and facilitating notifications to the user when such functions are accessed. Figure 10 A system is shown that displays transparency notifications associated with paste operations performed between applications; Figure 11 A method for displaying transparency notifications for paste operations performed between different applications is shown; Figure 12 A system is shown in which an application can present different paste options based on data patterns within the clipboard; Figure 13 This demonstrates a method for returning the detected pattern type to the requesting application; Figure 14 This demonstrates a system for secure clipboard access based on user input validation; Figure 15 This is a block diagram illustrating an exemplary API architecture that can be used in some implementation schemes; Figures 16A to 16B This is a block diagram of an exemplary API software stack according to the implementation plan; Figure 17 It is a block diagram of a device architecture for mobile or embedded devices according to the implementation plan; and Figure 18 It is a block diagram of the computing system according to the implementation plan. Detailed Implementation

[0011] References to “one embodiment” or “implementation” in this specification mean that a particular feature, structure, or characteristic described in connection with that embodiment can be included in at least one embodiment of the invention. The phrase “in one embodiment” appearing in various places throughout this specification does not necessarily refer to the same embodiment. The processes depicted in the following figures are performed by processing logic, which includes hardware (e.g., circuitry, special-purpose logic), software (as instructions on a non-transitory machine-readable storage medium), or a combination of hardware and software. Various embodiments will now be referenced in detail, examples of which are shown in the accompanying drawings. Numerous specific details are set forth in the following detailed description in order to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention can be practiced without these specific details. In other instances, well-known methods, processes, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure various aspects of the embodiments.

[0012] It will also be understood that while the terms “first,” “second,” etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are merely used to distinguish one element from another. For example, a first contact may be named a second contact, and similarly, a second contact may be named a first contact, without departing from the scope of the invention. Both a first contact and a second contact are contacts, but they are not the same contact.

[0013] The terminology used in the description of the invention herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in the specification and appended claims, the singular forms “a” and “an” are intended to also cover the plural forms unless the context clearly indicates otherwise. It will also be understood that the term “and / or” as used herein refers to and covers any and all possible combinations of one or more of the items listed in association. It will also be understood that the terms “comprises” and / or “comprising” as used in this specification specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0014] As used herein, depending on the context, the term "if" can be interpreted as meaning "when..." or "in response to determination" or "in response to detection". Similarly, depending on the context, the phrase "if it is determined..." or "if [the stated condition or event] is detected" can be interpreted as meaning "when it is determined..." or "in response to determination..." or "when [the stated condition or event] is detected" or "in response to detection".

[0015] Implementations of computing devices, user interfaces for such devices, and associated processes for using such devices are described. In some implementations, the computing device is a portable communication device, such as a mobile phone, that also includes other functions, such as PDA and / or music player functions. Exemplary implementations of portable multi-functional devices include, but are not limited to, the iPhone from Apple Computer, Inc. (Cupertino, California). ® iPad ® and iPod touch ® equipment.

[0016] In one implementation, software events used to grant access to device functionality are verified by confirming that a software event occurs in response to a hardware input event received via a hardware input device, such as, but not limited to, a touchscreen interface, a touchpad interface, a hardware mouse, or a hardware keyboard. This verification prevents software-based spoofing of user interface input, which could be used to fraudulently grant access to a specific function through gating, unless a hardware input event is received from the user of the electronic device. An application or operating system daemon can designate user interface (UI) elements or hotkey events as inputs requiring verification. An application or operating system daemon can designate UI elements or hotkey events by registering them with a source daemon of the operating system that provides instructions for incoming hardware events. In one implementation, registration of UI elements or hotkey events may include the exchange of cryptographic materials such as a shared secret. Software events indicating a combination of UI element selection or hotkey input can provide an authentication token generated based on the shared secret. The authentication token can be verified to validate the input event. In other implementations, other registration and / or verification techniques may be used.

[0017] The authentication interface element interactions are described using various authentication technologies, as provided by the various embodiments described herein, for various functions. In one embodiment, access to location services on an electronic device is gated via an authentication user interface interaction. In one embodiment, attribute data of ad clicks is gated via an authentication user interface interaction. In one embodiment, access to clipboard memory is gated via an authentication user interface interaction. Authentication user interactions can be received from various input devices. For example, authentication user interactions can be hardware touch events received via a touchscreen interface. Authentication user interactions can also be hotkey events received from a physical keyboard. Authentication user interactions can also be click events received via a touchpad or mouse peripheral. Other types of physical input interactions may also be supported.

[0018] Figure 1A system 100, according to an embodiment, is illustrated that imposes access restrictions on an application. System 100 includes user data 110 and system resources 120 accessible by application 103. In one embodiment, access to privacy-sensitive user data 110 and system resources 120 is mediated by an access control module 117. Privacy-sensitive user data 110 may be categorized into different classes, including but not limited to contacts 111, calendar data 112, reminders 113, photo library 114, and messages 116, where these messages may include text (e.g., SMS) messages, email messages, and / or instant messages delivered via instant messaging applications. Privacy-sensitive system resources 120 include, but are not limited to, clipboard 121, camera / microphone 123, location services 125, and other resources 127, which may include software resources, hardware resources, or combinations thereof. Access to user data 110 may be mediated at each class level. Access to system resources 120 may be mediated at each resource level. System 100 can protect various additional types of privacy-sensitive information as categories of user data 110 or other types of privacy-sensitive system resources 120, including but not limited to message history, web browser data (e.g., browser history, cookie data, etc.), system backup data, and any type of location history data that can be stored by system 100.

[0019] In one implementation, access control module 117 is a system daemon, and application 103 can communicate with this system daemon via system call API 118, such as inter-process communication (IPC) calls. The application includes an identifier 104 for identifying the application to access control module 117. In one implementation, identifier 104 is a universally unique identifier. In one implementation, identifier 104 is unique to each system. In one implementation, identifier 104 is unique to each user.

[0020] Application 103 may be provided with default access to a limited set of resources. This default access may be policy-based access (e.g., policy access 132), which grants application 103 access based on the application's standard functionality. For example, if application 103 is a camera application, policy access 132 to camera / microphone 123 and photo library 114 may be granted to application 103 based on policies associated with application 103. System 100 may be configured to disallow access to privacy-sensitive system resources by default, except for those resources to which policy access 132 is granted to application 103. In one embodiment, before granting application 103 access to user data 110 or system resource 120 outside of policies, access control module 117 may trigger a graphical interface prompt that indicates to the system user that they can explicitly grant or deny access to user data 110 or system resource 120. For example, before application 103 can access the user's contact 111, application 103 makes a call to system call API 118 of access control module 117 to explicitly request access to contact 111 134. The user can then grant or deny access to contact 111.

[0021] Explicit authorization of the application before granting access to selection functions. Explicit authorization systems can be used to gate access to selected privacy-related functions of an application. Authorization prompts can be displayed before granting an application access to privacy-related resources. Authorization prompts can also be displayed automatically in response to an application's attempt to access privacy-related resources.

[0022] Figures 2A to 2B A system for implementing an authentication interface interaction for selection functions on electronic devices is shown. Figure 2A A system 200 for implementing authentication interface interaction is shown. Figure 2B API process 250 used for authentication interface interaction is shown.

[0023] like Figure 2AAs shown, system 200 may include application 103 and verifier daemon 214. System 200 also includes source daemon 204 and input device 202. Application 103 may communicate with verifier daemon 214 via system call API 118 or another mechanism to enable inter-process communication within the operating environment on the computing device. Source daemon 204 and verifier daemon 214 may be processes associated with the operating system of the electronic device. Source daemon 204 may be a process configured to report the occurrence of hardware input events from the input device. Source daemon 204 may also report events from sensor devices (including but not limited to accelerometers). In one embodiment, verifier daemon 214 is a process configured to gate or control access to specific device functions. In one embodiment, verifier daemon 214 is a component of the window manager or user interface framework of the operating system of the electronic device. In one embodiment, application 103 may instruct verifier daemon 214 to display verified UI elements 220 for which verified hardware input has been enabled. In one implementation, application 103 may display the verified UI element 220 and directly perform verification of hardware input received at the verified UI element 220. In various implementations, application 103 or verifier daemon 214 may perform a registration operation 222 to register the verified UI element 220 with source daemon 204. Source daemon 204 is a software component of the system configured to receive hardware input events corresponding to input device 202. Input device 202 is a hardware input device, such as a physical keyboard, touch input device, and / or pointer device.

[0024] Registration operation 222 registers the verified UI element 220 with source daemon 204. Registration operation 222 can specify the verified UI element 220 via various mechanisms, which may vary based on the UI, composition, or windowed interface held in place on the electronic device. In one embodiment, registration operation 222 specifies an identifier for the verified UI element 220 among various UI elements presented for display. In one embodiment, a bounding box for the verified UI element 220 may be provided during registration operation 222. The bounding box may be a screen space bounding box or a bounding box containing the surface of the verified UI element 220. When source daemon 204 receives a hardware event from input device 202 to select the verified UI element 220, authentication notification 224 may be sent to one or more of verifier daemon 214 or application 103. In one embodiment, verifier daemon 214 receives authentication notification 224, performs a verification operation to authenticate authentication notification 224, and notifies application 103 of authentication notification 224 or receives the authentication notification. In one implementation, application 103 receives authentication notification 224 and sends at least a portion of authentication notification 224 to verifier daemon 214 for verification. Verifier daemon 214 can then respond to application 103 with the verification result. In one implementation, application 103 performs the functions of verifier daemon 214 or includes logic equivalent to that of verifier daemon 214. In this implementation, application 103 can directly verify the authenticity of authentication notification 224.

[0025] In one implementation, instead of the verified UI element 220, a registration operation 222 is performed to register a verified hotkey that can be received via a hardware keyboard attached to system 200. The verified hotkey may be a keyboard hotkey for performing protected operations, such as a paste operation that causes application 103 to attempt to access a memory buffer designated as the clipboard or clipboard of system 200. The clipboard or clipboard is a memory buffer used to store data associated with copy and paste operations performed within or between applications. In some configurations, when accessing data inserted into memory by different applications, system 200 expects an authentication notification 224 of the hardware input event, as described in further detail below, before providing application 103 with access to the clipboard or clipboard memory.

[0026] Authentication notification 224 may be verified and / or authenticated by verifier daemon 214 and / or application 103 using various techniques. In one embodiment, authentication notification 224 includes an authentication token. The authentication token may be generated based on a shared secret provided or established during registration operation 222. Verifier daemon 214 and / or application 103 may verify the authentication token to verify authentication notification 224. In one embodiment, source daemon 204 is a trusted component of system 200. Source daemon 204 may be a software module signed by the vendor of system 200. The signature may be generated based on the source code of source daemon 204 to enable verification of the vendor and the integrity of source daemon 204. System 200 may verify the signature of source daemon 204 before loading source daemon 204 into memory. Verifier daemon 214 and / or application 103 may also verify the signature of source daemon 204 as part of the authentication and verification process used for authentication notification 224. The operating system may be configured such that certain system events can be triggered only by trusted components of the system.

[0027] API process 250 used for authentication interface interaction Figure 2B As shown in the image. Figure 2B The API process 250 shown is an example of one implementation, and other implementations described herein may provide additional or alternative API processes. API process 250 may be implemented by application 103, UI module 212, validator daemon 214, and source daemon 204. Application 103, validator daemon 214, and source daemon 204 have been described in detail above. UI module 212 is a component of the operating system that performs or facilitates UI operations on behalf of application 103. UI module 212 may include components of a UI client framework and / or a window management framework.

[0028] The validator daemon 214 and the source daemon 204 can perform a set of operations 255 to establish a secure channel. The secure channel can then be used to perform operation 260 to establish a shared secret. This shared secret can form the basis for an authentication token used to verify input to the validated UI element. Application 103 can perform a drawing operation 261 to draw the application UI. The drawing operation 261 can be included in a series of operations performed to draw the application's UI elements. In one embodiment, when application 103 performs a drawing operation 262 to draw the UI element that will undergo validation input, UI module 212 can perform operation 264 to request the validator daemon 214 to draw the element that will be registered as such. Figure 2AThe UI element 220 is the UI element being verified. Alternatively, application 103 may directly request the validator daemon 214 to draw the UI element. The validator daemon 214 may perform operation 265 to register the UI element as the verified UI element with the source daemon 204. UI registration operation 265 is used to identify the area in which the verified UI element will be drawn. In one embodiment, UI registration operation 265 can also be used to establish a shared secret or exchange cryptographic material between the validator daemon 214 and the source daemon 204. In the illustrated embodiment, the area in which the UI element will be drawn is specified by application 103 during drawing operation 262. The validator daemon 214 may then draw the UI element at the requested location directly or using request 266 to UI module 212. Alternatively, when the UI element is associated with a prompt presented by the operating system, the operating system component may replace application 103.

[0029] After the secure UI element is prepared, the source daemon 204 may detect input from an input device (e.g., touchscreen, touchpad, mouse) during operation 270. The source daemon 204 may perform operation 271 to detect whether the input corresponds to input to a registered UI element. Operation 271 may include comparing details associated with the input event with details specified for the UI element (e.g., UI identifier or coordinates) during registration performed in operation 265. If the detected input corresponds to input to a registered UI element, the source daemon 204 may perform operation 274 to send a message and authorization token to application 103. Application 103 may then perform operation 276 to send a data request and authorization token to verifier daemon 214. Verifier daemon 214 may perform operation 278 to verify the authorization token. If the authorization token is valid, verifier daemon 214 may perform operation 280 to return data to application 103, which is authorized to return via input to the registered UI element.

[0030] Similar operations can be performed via hotkey input from the physical keyboard. When the physical keyboard is in use, the source daemon 204 can generate an authentication token in response to detecting a registered hotkey input at the keyboard. This authentication token can be used by the application to enable authenticated access to the clipboard. When the physical keyboard is in use, the verifier daemon 214 is not responsible for drawing UI elements.

[0031] Figure 3A system 300 is shown that includes an electronic device 322, in which an access control prompt 324 is displayed to enable access to the functions provided by the electronic device 322. The electronic device 322 may be a mobile computing device, such as a laptop or tablet. The electronic device 322 may also be a desktop computer. The technology shown in system 300 can also be applied to smartphone devices.

[0032] System 300 is shown displaying a prompt that allows an application to access location service functions of electronic device 322. A similar prompt may also be displayed when an application requests access to privacy-sensitive data or hardware on electronic device 322. For example, when an application first attempts to access hardware resources of electronic device 322, such as a camera or microphone, a prompt similar to access control prompt 324 may be presented on the display 321 of electronic device 322. A similar prompt may also be presented when an application attempts to access privacy-sensitive data such as user contacts, photos, or clipboard storage. Access control prompt 324 may include a first interface element 325 that allows the user to block (“disallow”) access to the function. A second interface element 326 may be presented to allow (“agree”) the application to access the function. In one embodiment, once access to the prompted function is granted to the application, the application may continue to access the function for a limited period of time or unless the access is revoked within the permission settings of electronic device 322.

[0033] Access control prompt 324 can be achieved by registering the second interface element 326 as such Figure 2A The verified UI element 220 in the [reference] is configured as the verified access control prompt. The registration and input processing of the second interface element 326 for the access control prompt 324 can be based on, as follows: Figure 2B The API process 250 in the electronic device 322 is used for execution. For location service functions, a component of the operating system of the electronic device 322 that acts as an authenticator daemon 214 may register the second interface element 326 with the source daemon 204. The source daemon 204 may be a component of the operating system that is assigned to handle hardware input events and trigger software events in response to these hardware input events. In one embodiment, registration may include the exchange of cryptographic material used by the source daemon 204 to generate an authentication token. This authentication token may be issued along with a software event notifying the authenticator daemon 214 that input has been received at the registered UI element (e.g., the second interface element 326). The authentication token is used by the authenticator daemon 214 to ensure that the software event has not been spoofed by malicious logic executed on the electronic device 322. If the authentication token is not sent along with the software event or an invalid token is issued, access to the functions associated with the authenticated access prompt will not be provided or enabled.

[0034] Figure 4 A system 300 is illustrated in which an electronic device 322 verifies input for selecting an advertisement to be displayed within an application executed by the electronic device 322. The electronic device 322 can execute an application 422 having a user interface 421 displayed on a display 321 of the electronic device 322. The application 422 can be an application that periodically displays UI elements 425, including an advertisement 426, on the user interface 421. In response to receiving input (e.g., touch, click) for selecting to display the UI element 425 of the advertisement 426, the operating system of the electronic device 322 can launch or move to a foreground browser application and load a Uniform Resource Locator (URL) associated with the advertisement 426. In one embodiment, logic associated with the operating system's app store framework can be invoked in response to the selection of the advertisement 426 and provide the URL associated with the advertisement. The provided URL can be a link to an app store page in the app store or a website on the web (e.g., the Internet) where a user can purchase and / or download software programs advertised by the advertisement 426. In addition to providing the URL, the app store framework may also provide attribute data along with the URL that identifies the application 422 displaying the ad 426 selected by the user. The attribute data may be provided along with the URL that opens in response to the selection of ad 426. The attribute data may also be, or alternatively, recorded internally by the app store framework. The attribute data may be aggregated across advertising campaigns. The aggregated metrics may then be incorporated into advertising metrics used for the advertising campaign. The advertising metrics used for the advertising campaign may be provided to clients of the advertising service that has agreed to run ad 426.

[0035] In one implementation, to prevent malware on electronic devices from generating erroneous attribute data, the generation and transmission of the attribute data of the selected advertisements are handled in a manner such as... Figure 2A The verified UI element 220 is gated behind the scenes. Registration and input processing of the UI element 425 displaying the advertisement 426 can be based on, for example... Figure 2B The API process 250 in the application 322 executes the API. For example, application 422 can register UI element 425, which displays advertisement 426, as a verified UI element. Components of the operating system of electronic device 322 can also register UI elements on behalf of application 422. Once registered as a verified UI element, a software event indicating that an advertisement has been selected on the user interface will not result in the transmission of attribute data unless the software event corresponds to a hardware input event received at the electronic device. When a software event reporting the occurrence of input is determined to correspond to a hardware input event, attribute data may be emitted along with the provided URL and / or recorded by the app store framework.

[0036] Figure 5A system 500 is illustrated in which an electronic device 512 verifies input for pasting data from a clipboard memory of the electronic device 512. The electronic device 512 may be a handheld electronic device, such as a smartphone. The techniques described for the electronic device 512 are also applicable to other types of electronic devices described herein, such as workbench computing devices, laptop computing devices, or desktop computing devices. The electronic device 512 may present a user interface 513 for an application. The user interface 513 enables a user to input a gesture that allows a display interface element 514 to be used for pasting data stored in the clipboard. Data can be inserted into the clipboard via a copy action. The copy action can be performed by an application having the user interface 513, or from a different application on the electronic device 512. The data may also have been inserted into the clipboard by an application on a different device that shares a clipboard with the electronic device 512. For example, multiple devices sharing a public cloud service account may have a shared clipboard. The shared clipboard allows for copying and pasting operations to be performed between multiple devices.

[0037] To prevent malicious access to the clipboard memory by applications running on electronic device 512, interface element 514 can be configured as follows: Figure 2A The verified UI element 220. Registration and input processing of interface element 514 can be based on... Figure 2B API process 250 and with Figure 3 The second interface element 326 and Figure 4 The UI element 425 is executed in a similar manner. The application displaying the user interface 513 may register the interface element 514, or the interface element 514 may be registered on behalf of the application by a component of the operating system of the electronic device 512. For example, a clipboard manager or UI component may register the interface element 514 with the input processing component of the operating system of the electronic device 512 and verify that the software event providing notification of selection of the interface element 514 corresponds to a hardware input event received via the input device of the electronic device 512.

[0038] Figure 6 A method 600 is shown for performing interaction with an authenticated interface element of the verified UI element 220. According to method 600, a logically executable operation on the electronic device receives a hardware event (602) associated with an input device. The hardware event can be received from the input device by a component of the electronic device's operating system, which is configured to act as... Figure 2A The source daemon 204 operates accordingly. The logic of the electronic device can process hardware events to determine whether the hardware event is an indication of interaction with a user interface element registered as a verified UI element.

[0039] The logic can determine that a hardware event is associated with input to a verified UI element configured to enable access to restricted functions provided by the electronic device (604). The restricted function can be a function provided by a process executing on one or more processors of the electronic device. The secure UI element can be a verified UI element corresponding to a function provided by that process. This determination can be performed by comparing data associated with the hardware input with registration data of the verified UI element. The registration data can specify an identifier for the verified UI element 220 among various UI elements presented for display by the electronic device. The registration data can additionally or alternatively specify window coordinates or screen coordinates associated with the verified UI element. The selection of the verified UI element can be determined when the hardware input event is determined to be within the specified coordinates of the verified UI element or to correspond to the UI identifier of the verified UI element.

[0040] The logic can then generate an authentication token to enable authenticated access to restricted functions (606). The authentication token may be generated based on a shared secret or other cryptographic material generated or exchanged during the registration of the verified UI element. In one embodiment, the shared secret or other cryptographic material is exchanged via an encrypted communication channel established between a validator daemon and a source daemon in the operating system of the electronic device. In one embodiment, the application may act as a validator and may also participate in the creation or management of the shared secret or other cryptographic material. The authentication token may be generated before a hardware event is received, or once it has been determined that the hardware event corresponds to the verified UI element. In one embodiment, a timestamp may be provided as input to the authentication token generation process and sent along with the authentication token. The timestamp may be, for example, a timestamp associated with a hardware event received from an input device. The timestamp may be used by the validator during the verification of the input.

[0041] The logic can then trigger a software event to report the occurrence of a hardware event and, via that software event, issue an authentication token (608). The software event can be an event provided by the operating system's event system to notify the software of an input event corresponding to a UI element displayed by the user interface. In one implementation, the authentication token is a mechanism used to verify the authenticity of the software event. Fraudulent software events generated by software executing on an electronic device will not correspond to hardware events. Such fraudulent software events will not contain an authentication token or will contain a software token that is not verifiable. In cases where other verification mechanisms are used, fraudulent software events will also lack the specified verification mechanism (e.g., a signature) or include an incorrect verification mechanism. The software event can be propagated through the event system and received by the application or other software component that wants to act on the software event. The application or other component can then send a request to access restricted functionality.

[0042] The logic may then receive a request for access to a restricted function, wherein the request includes an authentication token (610). If the authentication token is valid (“Yes” 612), the logic may provide the data stored in the memory buffer (614). If the authentication token is invalid (“No” 612), the logic may deny access to the data stored in the memory buffer (616). Determining the validity of the authentication token may be performed by generating a new authentication token using a shared secret or other cryptographic material and comparing the new authentication token with the received token. The generation of the new authentication token may be performed using a timestamp received along with the authentication token in the request for access to the restricted function.

[0043] Figure 7 A method 700 for drawing a verified interface element is illustrated. Method 700 can be executed by software and hardware logic of an electronic device as described herein. According to method 700, logic on the electronic device may receive a request (702) at a verifier daemon providing access to the verified interface element that enables restricted operations. The logic may then send a notification to a source daemon to identify a UI area that will contain the verified interface element (704). This notification may specify the verified interface element via various techniques, including via a UI identifier or via UI, window, or screen space coordinates. The logic may then draw the verified interface element in the UI of the requesting application (706). The logic of the electronic device may then be configured to trigger a software event including verification data in response to a hardware input event for selecting the verified interface element (708). The verification data may be an authentication token, an authentication token and timestamp, a signature including a software event, a signature associated with the generator of the software event, or another verification mechanism.

[0044] Figures 8A to 8C Methods 800, 820, and 830 are shown for using verified UI elements to manage access to functions provided by processes of an electronic device. Figure 8A A method 800 for implementing access prompting gating for location service functions is shown. Figure 8B A method 820 for implementing access prompt gating for advertising attribute functionality is shown. Figure 8C A method 830 for implementing access prompt gating for clipboard functionality is shown. Methods 800, 820, and 830 can be performed by any of the electronic devices described herein using the techniques described above for the respective restricted functions.

[0045] Figure 8AMethod 800 includes allowing the logic of an electronic device to receive a request from an application to access a location service function of the electronic device (802). The logic may determine whether to grant the application access to the location service (804). If, for example, the application is granted access to the location service based on a previous access prompt presented to the application (“Yes” 804), the logic may allow the application to access the location service (806). If the application has not yet been granted access to the location service (“No” 804), the logic may then display a verified UI element to prompt for access to the location service function (808). Access to the function may then be provided in response to a selection of the verified UI element that enables access to the location service function. Enabling access to the location service function enables the application to obtain access to location data of the electronic device, including the determined current location of the electronic device or location history data of the electronic device.

[0046] Figure 8B Method 820 includes providing logic of an electronic device to receive an input event to select an advertisement to be presented within the user interface of an application (822). The logic may determine that the input event is an authenticated input event (824), such that the input event is verified as associated with an actual hardware input event using the techniques described herein. If the input corresponds to an authenticated input event (“Yes” 824), the logic may emit the URL associated with the advertisement along with attribute data of the application indicating that the advertisement is displayed to a browser (826). If the input does not correspond to an authenticated input event (“No” 824), the logic will emit only the URL associated with the advertisement to the browser (828).

[0047] Figure 8C Method 830 includes providing logic associated with the electronic device to receive, at the clipboard daemon, a request from the application to access memory associated with the clipboard (832). In this case, the clipboard daemon may act as a validator for the input of verified UI elements used to gate access to the clipboard memory (e.g., such as...). Figure 2A(Verifier daemon 214 in the context of the application). Alternatively, other UI system or window manager daemons may act as verifiers for input to the verified UI elements. The logic may determine whether the access control system of the computing device grants the application clipboard access (834). If access has been previously granted ("Yes", 834), the logic may allow access to the memory associated with the clipboard (836). If access has not been previously granted ("No", 834), the logic may determine whether the request is synchronous or asynchronous (838). For synchronous requests, the application may request clipboard data from the clipboard daemon and wait for the request to return the clipboard data. For asynchronous requests, the application may send a request to the clipboard and continue with other operations. The clipboard daemon may then use the clipboard data to respond to the request asynchronously. If the request is synchronous (i.e., not asynchronous), the clipboard logic may return null (840) or otherwise not return information in the clipboard memory. If the request is asynchronous, the clipboard daemon may request to display or otherwise trigger an access control prompt to receive user approval for clipboard access by the application (842).

[0048] Figure 9 A system 900 is illustrated for gating access to device functions behind verified UI elements and facilitating notifications to the user when such functions are accessed. System 900 includes software and hardware components of a computing device. The computing device associated with the system may be, but is not limited to, a desktop computer, laptop computer, tablet computer, mobile phone (e.g., smartphone), wearable device, personal digital assistant (PDA), media player, gaming device, television or set-top box, smart appliance, and / or smart speaker device. The software component of system 900 may be instructions executed by one or more processors (e.g., application processor, system processor, sensor processor, always-on processor, etc.) or firmware executed by one or more microcontrollers.

[0049] In one implementation, the software on system 900 includes application 103, which is communicatively coupled to access control module 117 via system call API 118. Application 103 can communicate via access control module 117 via system call API 118 to obtain access to resources such as privacy-sensitive user data or system resources. Default access to certain resources can be provided to application 103 via security profile 906. The application's security profile can be dynamically generated or updated by compiling one or more rules specifying the resources accessible to the application.

[0050] When application 103 first accesses a privacy-sensitive resource, access control module 117 can trigger UI module 212 to display a dialog prompt including verified UI elements, such as Figure 3 Access control prompt 324 provides a dialog prompt that allows the user to explicitly grant or deny access to the resource. Access status for the resource can be logged based on the response provided to the access control prompt. This response is related to the source daemon 204's reception of hardware input events, which detects hardware input events and responds by sending software events to software components of system 900.

[0051] In some implementations, system 900 may maintain an access control record 920 that records access decisions on a per-user basis, where each user on the system has a separate record instance. In one implementation, access control record 920 identifies resources for which a user has been granted or denied access, and the specific application or process that triggered the access request. In one implementation, access control record 920 may store unknown states of some resources that may indicate that no result or rights transfer has been recorded for that resource. In one implementation, access control record 920 includes a distributed record 922 and a centralized record 924. Distributed record 922 is used to persist previously granted or denied access to data files or folders. In one implementation, distributed record 922 may be stored in an extended file system data containing user data for the file or folder. For distributed record 922, if a file or folder with a record is deleted, in one implementation, the portion of distributed record 922 associated with that file or folder may also be deleted. Centralized record 924 may be stored in a central database for each user and may be dedicated to recording the results of access requests to system resources. In various implementations, access records to clipboard storage 912 and location data 914 may be stored in a distributed record 922 or a centralized record 924. In one implementation, attribute data 916 is briefly stored during relay to a browser application. In this implementation, access control to attribute data 916 is not maintained. In one implementation, an app store framework 917 may maintain a record of attribute data 916 generated for selected advertisements. In this implementation, access to this data is maintained via access control record 920. Default access to attribute data 916 may be managed through a security profile 906.

[0052] System 900 is configurable such that if application 103 attempts to access location data 914 in a manner that disconnects from the user's intention to access location data 914, access to application 103 will be denied. In various embodiments, location data 914 includes any data accessible via location service module 915. Location data 914 may include the current location of the electronic device including system 900 and / or the location history of the electronic device. Access to location data 914 may be granted to application 103 once the user has authorized access via a verified UI element, where location service module 915 or UI module 212 acts as a authenticator daemon. Access to location data 914 may be gated on a per-access basis, or persistent access to location service 915 by application 103 may be stored in access control log 920. Conditional access to location data 914 may also be provided, allowing application 103 to access location data 914 while it is active and / or in the foreground, and access in the background is disabled.

[0053] System 900 is configurable such that if a user of application 103 selects an advertisement displayed by application 103, attribute data linking the displayed advertisement and application 103 is not emitted unless the selection of the advertisement corresponds to an expression of the user's intent to select the application. This expression of user intent is recorded in the form of hardware input to a verified UI element (e.g., UI element 425) displaying the advertisement. The hardware input for selecting the advertisement is detected by source daemon 204. The hardware input may be verified via an authentication token emitted by source daemon 204 along with notification of the input, or via another verification method described herein (e.g., trusted component, signature). The occurrence of the hardware input is verified by a validator daemon. In various embodiments, app store 917 or UI module 212 may include a validator daemon that verifies that the input received from the verified UI element corresponds to the hardware input detected by source daemon 204.

[0054] Access control module 117 is configured to communicate with clipboard daemon 913 to manage access control to clipboard memory 912. Access control module 117 may also communicate with location services module 915 or a framework to manage access to location data 914. In one embodiment, access control module 117 may communicate with app store 917 framework to determine whether to generate, store, or send attribute data for an ad selected by the user. Alternatively, app store 917 framework may directly manage whether to emit attribute data without interacting with access control module 117. In one embodiment, access control module 117 may maintain a record of whether the user has decided to opt out of the transmission of attribute data for the selected ad. In this embodiment, app store 917 framework will not emit attribute data 916 for the selected ad. System call API 118 provides access to... Figure 2B One or more variants of the API process 250 are used to access the interface of the clipboard memory 912, location data 914, and attribute data 916.

[0055] In one implementation, the clipboard daemon 913 can receive requests submitted via system call API 118 to copy data to the clipboard memory 912 (copy) and to copy data out of the clipboard memory (paste). Access to the clipboard daemon 913 can be gated via access control module 117. In one implementation, the clipboard daemon 913 may alternatively perform its own access control operations. Provided based on... Figure 2B The API process 250 uses the certified clipboard API to protect clipboard operations between applications. In this implementation, the clipboard daemon 913 and / or UI module 212 are used to draw a paste button on the UI on behalf of application 103. Since application 103 does not directly draw the paste button, it is more difficult for maliciously coded applications to display a spoofed paste button. The clipboard daemon 913 will also know where the paste button is displayed in the UI and can use this information to verify requests to access data in the clipboard. When the clipboard daemon 913 draws the paste button, it can notify the source daemon 204 that the paste button is a verified UI element associated with a verified hardware input. The verified UI element can be identified based on a UI identifier associated with that area. In some specific implementations, the clipboard daemon 913 can use the screen coordinates in which the paste button is drawn to identify the verified UI element to the source daemon 204. Various other techniques can be used depending on the specific implementation details of the UI system.

[0056] When the source daemon 204 detects hardware input corresponding to the paste button, it can send a notification of the hardware input and an authentication token to the application 103. The application 103 can receive the authentication token and send it to the daemon acting as a authenticator (e.g., such as...). Figures 2A to 2B The authentication token is sent by an operating system component (e.g., the authenticator daemon 214) to the clipboard daemon 913. In one embodiment, the authenticator daemon is the clipboard daemon 913. In another embodiment, the UI module 212 includes the authenticator daemon. The authentication token may include cryptographic material generated based on a shared secret, which is pre-exchanged between or pre-generated by the authenticator daemon (e.g., the clipboard daemon 913 or the UI module 212) and the source daemon 204. In one embodiment, the authenticator daemon and the source daemon 204 are privileged processes capable of communicating via a secure channel provided by the operating system. This secure channel can be used to exchange the shared secret or other cryptographic material. The shared secret may be used by the source daemon 204 to generate the authentication token in response to the detection of touch input to a UI area that has been identified as a paste button location or a UI identifier. A timestamp may be provided as input to the authentication token generation process and sent along with the authentication token. Suppose that application 103 attempts to change the timestamp associated with touch input when trying to access clipboard memory 912, the changed timestamp will cause the token authentication process at the clipboard to fail when the changed timestamp is used to verify the authentication token.

[0057] Using the above techniques, if application 103 attempts to access the clipboard in a manner that disconnects from the user's intention to access the clipboard, access to application 103 will be denied. However, in some scenarios, exemption from authentication access to the clipboard can be implemented. When exemption is maintained in place, the application will be allowed to access the clipboard without authentication. Exemption-based access is enabled for scenarios where the likelihood of malicious or covert access to the clipboard is low. Exemption can be enabled based on the application that puts data into the clipboard or the timing of copy and paste operations. For example, when an application puts data into the clipboard, the application's identifier, the identifier of the team associated with the application (e.g., the developer or vendor), and the timestamp where the data is stored can be saved as clipboard metadata. When an application attempts to access data in the clipboard, the application identifier, team identifier, and access attempt timestamp can be compared with the corresponding elements of the clipboard metadata. Exemption can be configured to allow an application to access data placed in the clipboard by that application, allowing a single application to perform copy and paste operations without authentication. Exemption can also be configured to allow an application to access data placed by an application with the same team identifier. Exemption can also be configured to allow any application to access the clipboard for a limited amount of time after data has been stored there. Furthermore, as mentioned above, once non-exempt access to the clipboard is authenticated, the same application can continue to access the clipboard until new data is stored there.

[0058] Furthermore, variations of the authenticated paste technology can be employed in some cases. In one implementation, it may not be necessary for the clipboard daemon to draw the paste icon. In this scenario, the application can register a UI identifier for the paste icon with the input daemon. When touch input is detected at a location associated with the registered UI identifier, the source daemon 204 can then generate an authentication token. An additional variation is keystroke-based clipboard authentication, which can be enabled as a supplement to or replacement of touch-based clipboard authentication. When the physical keyboard is in use, the input daemon can generate a clipboard authentication token in response to detecting a paste hotkey entered on the keyboard. This authentication token can be used by the application to enable authenticated access to the clipboard.

[0059] Transparency notification for selecting functions As an alternative to or supplement to the requirement for verified hardware input before granting access to a selected function, a notification may be displayed via the UI when the system grants access to the selected function. For example, in some implementations, a system that notifies the user when cross-application pasting occurs may replace or supplement an explicit authorization prompt to enable access to the clipboard memory 912. The clipboard daemon 913 may receive requests directly via system call API 118. When facilitating cross-application pasting operations, the clipboard daemon 913 may send a request to the UI module 212 to trigger the display of a clipboard transparency notification. The clipboard transparency notification may indicate the application pasting from the clipboard and the source application of the pasted data. For cross-system pasting using a shared clipboard, the source device of the pasted data may be displayed. The clipboard daemon 913 may also perform additional privacy and security measures, such as expiring data stored in the clipboard after a certain period of time.

[0060] Figure 10 A system 1000 is shown that displays a transparency notification associated with a paste operation performed between applications. When a user pastes data from the clipboard, the data contained in the clipboard is inserted into the application and displayed via the application's user interface 513. For example, a user of an electronic device 512 can perform... Figure 5 The paste operation shown is to paste a URL into the user interface 513 of the note-taking application. In response to the paste operation, the pasted data is inserted into the user interface 513. With respect to the URL, the pasted data can be displayed as a selectable interface element 1006. Since the pasted data is inserted into the clipboard by different applications, when inserting clipboard data, a clipboard transparency notification 1005 can be displayed indicating the application accessing the clipboard to perform the paste operation (Notes) and the application inserting the information into the clipboard (Safari). To achieve this functionality, clipboard metadata identifying the source application of the copy action that caused the data to be inserted into the clipboard is maintained. Clipboard metadata can be created when an application inserts data into the clipboard, and the clipboard metadata can be checked when an application attempts to access the clipboard. Transparency notifications can be presented based on this metadata.

[0061] Figure 11 A method 1100 is shown for displaying transparency notifications for paste operations performed between different applications. Method 1100 includes having software logic on an electronic device perform an operation to receive a request from an application to access memory associated with the clipboard at a clipboard daemon (1102). The software logic may be, for example, as... Figure 9The clipboard daemon 913 in the code. Logic can determine whether the data in the clipboard comes from an application different from the requesting application (1104). If the data comes from a different application ("Yes", 1104), the logic can present a clipboard transparency notification (1106). If the data does not come from a different application ("No", 1104), the logic can bypass the presentation of the clipboard transparency notification (1108).

[0062] In various implementations, transparency notifications can be performed by the user in conjunction with or in place of verified UI elements that provide other functionality offered by the electronic device. For example, a notification or indication may be displayed when an application is granted access to location data. A notification may also be displayed when attribute data is emitted in response to an advertising selection.

[0063] Modification of UI elements based on clipboard data In one implementation, different paste operations can be presented based on detected data patterns within the clipboard. The pattern can be determined by the application executing the clipboard data without triggering an transparency notification.

[0064] Figure 12 A system 1200 is illustrated in which an application can present different paste options based on data patterns within the clipboard. For example, the clipboard storage 1202 may include data patterned as a URL (e.g., https: / / developer.apple.com / wwdc20 / ). Applications such as web browser applications can detect URL patterns in the clipboard storage and, in response to input gestures at the application's search bar and / or address bar 1203, can present a UI element 1204 that enables a paste and go operation. The paste and go operation inserts a URL into the clipboard and causes the web browser to load the webpage identified by the URL. Other types of pattern-specific operations, such as a paste and search operation, can be enabled, which performs a web search based on data within the clipboard. In one embodiment, a paste and search operation can be performed if the data within the clipboard has a search query pattern. Applications other than web browser applications can also analyze the data patterns of the clipboard data to adjust the type of paste UI element to be presented and / or determine whether to fully present the paste UI element. For example, some applications may only support pasting certain types of data (e.g., image data, files, audio data, numerical values, etc.). If the data in the clipboard does not match the expected pattern, such applications may not render the paste UI elements.

[0065] In previous implementations, the application itself could perform clipboard pattern analysis, and reading clipboard data pasted by different applications could trigger a false clipboard transparency notification because the data in the clipboard was being accessed but not actually pasted into the target application. To avoid this problem, the implementation described herein provides an API interface that allows applications to request the operating system logic to perform pattern analysis on the clipboard data and return data indicating that a data pattern from the expected data patterns was detected within the clipboard data.

[0066] Figure 13 A method 1300 is shown for returning a detected pattern type to a requesting application. According to method 1300, software logic associated with the operating system, such as logic within or associated with the clipboard daemon, may receive a request from the application for an indication of a pattern in data stored in the clipboard (1302). The logic may then analyze the data in the clipboard to determine if a pattern exists within the data (1304). In one embodiment, the analysis logic is configured to determine whether the data contains one or more patterns from a set of known patterns (e.g., URLs, search bar data, numerical values, etc.). The logic may then return the detected pattern type to the application (1306). In various embodiments, if no pattern is detected, no pattern may be returned, a general pattern type may be returned, or an "unknown" pattern type may be returned. The requesting application may use the returned pattern type to determine the type of paste UI element to display to paste clipboard data.

[0067] Figure 14 A system 1400 for secure clipboard access based on user input validation is illustrated. System 1400 includes an electronic device 1402 that can be physically or wirelessly attached to an input device in the form of a physical keyboard 1405. Electronic device 1402 can execute an application that presents a user interface 1401 on the display of electronic device 1402. User interface 1401 may include an interface element 1410 that enables copying and an interface element 1420 that enables pasting. User interface 1401 may also include a text area 1403 into which text can be typed, copied, and pasted. Pasting can be performed at a cursor position 1430 in the text area 1403 of user interface 1401. The interface element 1420 for performing the paste operation can be drawn by the application via a UI module 212 as described herein, directly drawn by the UI module 212, or via... Figure 9 The clipboard daemon 913 is used for drawing. Paste operations from different applications via interface element 1420 can be performed via the Secure Paste API.

[0068] The Secure Paste API can also facilitate secure pasting between applications in response to hotkey combinations 1406 provided from the physical keyboard 1405 to the electronic device 1402. Hotkey combinations 1406 can be registered with the source daemon 204 in a manner similar to the registration of verified UI elements. When the source daemon 204 receives the registered hotkey combination, it emits a message including data (e.g., authentication token, signature, etc.) that can be verified by the validator daemon before granting access to the electronic device's clipboard memory or other protected features (e.g., location data, advertising attribute data, etc.).

[0069] Exemplary APIs and Data Processing Systems The implementation described herein includes one or more application programming interfaces (APIs) in an environment, wherein calling program code interacts with other program code invoked through one or more programming interfaces. Various function calls, messages, or other types of calls may also include various parameters, which can be transferred via the API between the calling program and the called program code. Furthermore, the API may provide the calling program code with the ability to use data types or categories defined in the API and implemented in the called program code.

[0070] An API allows developers of API calling components (which can be third-party developers) to utilize specified features provided by the API-implemented components. There can be one API calling component or more such components. An API can be a source code interface provided by a computer system or library to support service requests from applications. An operating system (OS) can have multiple APIs to allow applications running on the OS to call one or more of those APIs, and a service (such as a library) can have multiple APIs to allow applications using the service to call one or more of those APIs. APIs can be specified according to the programming language that can be interpreted or compiled when the application is built.

[0071] In some implementations, an API implementation component may provide more than one API, each providing a different view or having different aspects that access different aspects of the functionality implemented by the API implementation component. For example, one API of the API implementation component may provide a first set of functions and be exposed to third-party developers, while another API of the API implementation component may be hidden (not exposed) and provide a subset of the first set of functions, as well as another set of functions, such as test or debug functions not in the first set. In other implementations, the API implementation component itself may call one or more other components via a lower-level API, thus being both an API calling component and an API implementation component.

[0072] An API defines the language and parameters used by an API calling component when accessing and using specified features of an API implementation component. For example, an API calling component accesses specified features of an API implementation component through one or more API calls or references exposed by the API (e.g., implemented by function or method calls), and uses parameters to pass data and control information via these API calls or references. An API implementation component may return a value from an API call received from an API calling component. While an API defines the syntax and results of API calls (e.g., how to initiate an API call and what an API call can do), it may not reveal how an API call completes the function specified by the API call. Various API calls are transmitted via one or more application programming interfaces between the calling component (API calling component) and the API implementation component. Transmitting API calls may include issuing, initiating, referencing, calling, receiving, returning, or responding to function calls or messages; in other words, transmission can describe the actions of either the API calling component or the API implementation component. API function calls or other references may send or receive one or more parameters via parameter lists or other structures. Parameters can be constants, keys, data structures, objects, object classes, variables, data types, pointers, arrays, lists, or pointers to functions or methods, or references to data or other items to be passed via the API.

[0073] Furthermore, data types or classes can be provided by the API and implemented by the API implementation component. Therefore, the API calling component can use the definitions provided in the API to declare variables, use pointers to such types or classes, and use or instantiate constant values ​​of such types or classes.

[0074] Typically, APIs can be used to access services or data provided by API implementation components, or to initiate operations or computations provided by API implementation components. By way of example, API implementation components and API calling components can each be any of an operating system, library, device driver, API, application, or other module (it should be understood that API implementation components and API calling components can be modules of the same or different types). In some cases, API implementation components may be implemented at least partially in firmware, microcode, or other hardware logic components. In some implementations, an API may allow client programs to use services provided by a Software Development Kit (SDK) library. In other implementations, applications or other client programs may use APIs provided by an application framework. In these implementations, applications or client programs may incorporate calls into functions or methods provided by both the SDK and the API, or use data types or objects defined in the SDK and provided by the API. In these implementations, the application framework may provide a main event loop for the program, which responds to various events defined by the framework. The API allows applications to utilize the application framework to specify events and responses to events. In some implementations, API calls can report the capabilities or status of hardware devices to the application, including capabilities or status related to input capabilities and status, output capabilities and status, processing capabilities, power status, storage capacity and status, communication capabilities, etc., and the API may be implemented in part by firmware, microcode, or other low-level logic components that execute in part on the hardware components.

[0075] API invocation components can be local components (i.e., on the same data processing system as the API implementation component) or remote components (i.e., on a different data processing system than the API implementation component), which communicate with the API implementation component via a network through the API. It should be understood that an API implementation component can also act as an API invocation component (i.e., it can make API calls to APIs exposed by different API implementation components), and an API invocation component can also act as an API implementation component by implementing APIs exposed to different API invocation components.

[0076] An API can allow multiple API call components written in different programming languages ​​to communicate with an API implementation component (therefore, the API may include features for translating calls and returns between the API implementation component and the API call component); however, the API may be implemented in a specific programming language. In one implementation, the API call component may call APIs from different providers, such as one set of APIs from an OS provider and another set of APIs from a plugin provider, as well as another set of APIs from another provider (e.g., a software library provider) or the creator of another set of APIs.

[0077] Figure 15 This is a block diagram illustrating an exemplary API architecture that can be used in some embodiments of the present invention. For example... Figure 15 As shown, API architecture 1500 includes an API implementation component 1510 (e.g., an operating system, library, device driver, API, application, software, or other module) that implements API 1520. API 1520 specifies one or more functions, methods, classes, objects, protocols, data structures, formats, and / or other characteristics of the API implementation component that can be used by API calling component 1530. API 1520 may specify at least one calling convention that specifies how functions in the API implementation component receive parameters from the API calling component and how functions return results to the API calling component. API calling component 1530 (e.g., an operating system, library, device driver, API, application, software, or other module) makes API calls through API 1520 to access and use the characteristics of API implementation component 1510 specified by API 1520. API implementation component 1510 may return values ​​to API calling component 1530 through API 1520 in response to API calls.

[0078] It should be understood that API implementation component 1510 may include additional functions, methods, classes, data structures, and / or other features not specified through API 1520 and not available to API invocation component 1530. It should be understood that API invocation component 1530 may be on the same system as API implementation component 1510, or may be remotely located and accessed via a network using API 1520. Although Figure 15 The example shows a single API call component 1530 interacting with API 1520, but it should be understood that other API call components written in a different language (or the same language) than API call component 1530 can use API 1520.

[0079] API implementation component 1510, API 1520, and API call component 1530 may be stored in a machine-readable medium, which includes any mechanism for storing information in a machine-readable (e.g., computer or other data processing system) form. For example, machine-readable media include disks, optical disks, random access memory; read-only memory, flash memory devices, etc.

[0080] In one implementation, the access control module 117 described herein may be communicatively coupled to the API implementation component 1510 to mediate access to privacy-related system resources such as Figure 1Access to user data and system resources is shown. Before API implementation component 1510 can perform certain operations, API implementation component 1510 may communicate with access control module 117 to determine whether such operations can be performed.

[0081] Figures 16A to 16B This is a block diagram of exemplary API software stacks 1600 and 1610 according to the implementation scheme. Figure 16A An exemplary API software stack 1600 is illustrated, in which application 1602 can use service APIs to call service A or service B and use OS APIs to call operating system 1604. Furthermore, services A and B can use several OS APIs to call operating system 1604.

[0082] Figure 16B An exemplary API software stack 1610 is illustrated, including application 1, application 2, service 1, service 2, and operating system 1604. As shown, service 2 has two APIs, one (service 2 API 1) receiving calls from application 1 and returning values, and the other (service 2 API 2) receiving calls from application 2 and returning values. Service 1 (e.g., a software library) calls OS API 1 and receives the returned values, and service 2 (e.g., a software library) calls both OS API 1 and OS API 2 and receives the returned values. Application 2 calls OS API 2 and receives the returned values.

[0083] Figure 17 This is a block diagram of a device architecture 1700 for a mobile or embedded device according to an implementation scheme. Device architecture 1700 includes a memory interface 1702, a processing system 1704 including one or more data processors, an image processor and / or graphics processing unit, and a peripheral device interface 1706. Various components can be coupled via one or more communication buses or signal lines. These components can be individual logic components or devices or can be integrated into one or more integrated circuits, such as system-on-a-chip (SoC) integrated circuits.

[0084] The memory interface 1702 can be coupled to the memory 1750, which may include high-speed random access memory such as static random access memory (SRAM) or dynamic random access memory (DRAM) and / or non-volatile memory such as, but not limited to, flash memory (e.g., NAND flash, NOR flash, etc.).

[0085] Sensors, devices, and subsystems can be coupled to peripheral interface 1706 to facilitate multiple functions. For example, motion sensor 1710, light sensor 1712, and proximity sensor 1714 can be coupled to peripheral interface 1706 to facilitate mobile device functionality. One or more biometric sensors 1715 may also be present, such as a fingerprint scanner for fingerprint recognition or an image sensor for facial recognition. Other sensors 1716 may also be connected to peripheral interface 1706, such as positioning systems (e.g., GPS receivers), temperature sensors, or other sensing devices to facilitate related functions. Camera subsystem 1720 and optical sensor 1722 (e.g., charge-coupled device (CCD) or complementary metal-oxide-semiconductor (CMOS) optical sensors) can be used to facilitate camera functions such as taking photos and video clips.

[0086] Communication functionality can be facilitated by one or more wireless communication subsystems 1724, which may include radio frequency receivers and transmitters and / or optical (e.g., infrared) receivers and transmitters. The specific design and implementation of the wireless communication subsystem 1724 may depend on the communication network through which the mobile device intends to operate. For example, a mobile device including the illustrated device architecture 1700 may include a wireless communication subsystem 1724 designed to operate over a GSM network, CDMA network, LTE network, Wi-Fi network, Bluetooth network, or any other wireless network. Specifically, the wireless communication subsystem 1724 may provide a communication mechanism in which a media playback application can retrieve resources from a remote media server or retrieve scheduled events from a remote calendar or event server.

[0087] The audio subsystem 1726 can be coupled to the speaker 1728 and the microphone 1730 to facilitate voice-enabled functions such as speech recognition, speech copying, digital recording, and telephone functionality. In the smart media device described herein, the audio subsystem 1726 may include a high-quality audio subsystem supporting virtual surround sound.

[0088] I / O subsystem 1740 may include touchscreen controller 1742 and / or other input controller 1745. For computing devices including display devices, touchscreen controller 1742 may be coupled to touch-sensitive display system 1746 (e.g., a touchscreen). Touch-sensitive display system 1746 and touchscreen controller 1742 may detect contact and movement and / or pressure using, for example, any of a variety of touch and pressure sensing technologies, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with touch-sensitive display system 1746. Display output of touch-sensitive display system 1746 may be generated by display controller 1743. In one embodiment, display controller 1743 may provide frame data to touch-sensitive display system 1746 at a variable frame rate.

[0089] In one embodiment, a sensor processor 1744 is included to monitor, control, and / or process data received from one or more of a motion sensor 1710, a light sensor 1712, a proximity sensor 1714, or other sensors 1716. The sensor processor 1744 may include logic to interpret the sensor data to determine the occurrence of one of multiple motion events or activities by analyzing the sensor data from the sensors. In one embodiment, the sensor processor 1744 also manages a camera subsystem 1720 and an audio subsystem 1726 coupled to the sensor processor 1744 via a peripheral device interface 1706. Multimedia captured by the camera subsystem 1720 and / or the audio subsystem 1726 may be relayed to a memory 1750 for access by software executing on the processing system 1704, or processed by the sensor processor 1744 or other processors in the system to determine environmental metadata. In one embodiment, the sensor processor may configure a live audio stream to a hearing aid device or wireless earbud connected via a wireless processor, thereby enabling the audio stream to bypass the processing system 1704 and the memory 1750.

[0090] In one embodiment, the I / O subsystem 1740 includes an additional input controller 1745 that can be coupled to other input / control devices 1748, such as one or more buttons, rocker switches, thumb wheels, infrared ports, USB ports, and / or pointer devices such as styluses, or up / down buttons of volume controls for control devices such as speakers 1728 and / or microphones 1730.

[0091] In one implementation, memory 1750, coupled to memory interface 1702, may store instructions for operating system 1752, including POSIX-compliant and incompatible operating systems or embedded operating systems. Operating system 1752 may include instructions for handling basic system services and for performing hardware-related tasks. In some specific implementations, operating system 1752 may be a kernel.

[0092] The memory 1750 may also store communication instructions 1754 to facilitate communication with one or more additional devices, one or more computers, and / or one or more servers, such as retrieving network resources from a remote network server. The memory 1750 may also include user interface instructions 1756, including graphical user interface instructions that facilitate graphical user interface processing.

[0093] In addition, memory 1750 may store sensor processing instructions 1758 that facilitate sensor-related processing and functions; telephone instructions 1760 that facilitate telephone-related processes and functions; instant messaging instructions 1762 that facilitate electronic messaging-related processes and functions; web browser instructions 1764 that facilitate web browsing-related processes and functions; media processing instructions 1766 that facilitate media processing-related processes and functions; location service instructions that facilitate location-based functions, including GPS and / or navigation instructions 1768 and Wi-Fi-based location instructions; camera instructions 1770 that facilitate camera-related processes and functions; and / or other software instructions 1772 that facilitate other processes and functions, such as security processes and functions, and system-related processes and functions. Memory 1750 may also store other software instructions, such as web video instructions that facilitate web video-related processes and functions; and / or web shopping instructions that facilitate web shopping-related processes and functions. In some specific embodiments, media processing instructions 1766 are divided into audio processing instructions and video processing instructions, respectively, for facilitating audio processing-related processes and functions and video processing-related processes and functions. Mobile device identifiers, such as International Mobile Equipment Identity (IMEI) 1774 or similar hardware identifiers, may also be stored in memory 1750.

[0094] Each of the instructions and applications identified above may correspond to a set of instructions for performing one or more of the functions described above. These instructions do not need to be implemented as a separate software program, process, or module. Memory 1750 may include additional instructions or fewer. Furthermore, various functions may be performed in hardware and / or software, including in one or more signal processing and / or application-specific integrated circuits.

[0095] Figure 18This is a block diagram of a computing system 1800 according to an implementation scheme. The illustrated computer system 1800 is intended to represent one or more specific implementations of a series of computing systems (wired or wireless), including, for example, desktop computer systems, laptop computer systems, tablet computer systems, cellular phones, personal digital assistants (PDAs) including cellular-enabled PDAs, set-top boxes, entertainment systems or other consumer electronic devices, smart electrical devices, or smart media playback devices. Alternative computing systems may include more, fewer, and / or different components. The computing system 1800 can be used to provide computing devices and / or server devices that may be connected to the computing devices.

[0096] The computing system 1800 includes a bus 1835 or other communication device for conveying information, and a processor 1810 coupled to the bus 1835 capable of processing information. Although the computing system 1800 is illustrated as having a single processor, it may include multiple processors and / or coprocessors. The computing system 1800 may also include a memory 1820, such as random access memory (RAM) or other dynamic storage devices coupled to the bus 1835. The memory 1820 may store information and instructions executable by the processor 1810. During the execution of instructions by the processor 1810, the memory 1820 may also be used to store temporary variables or other intermediate information.

[0097] The computing system 1800 may also include a read-only memory (ROM) 1830 and / or other data storage device 1840 coupled to the bus 1835 for storing information and instructions for the processor 1810. The data storage device 1840 may be or include a variety of storage devices, such as flash memory devices, magnetic disks or optical disks, and may be coupled to the computing system 1800 via the bus 1835 or via a remote peripheral interface.

[0098] The computing system 1800 may also be coupled to a display device 1850 via a bus 1835 to display information to a user. The computing system 1800 may also include a numeric-alphanumeric input device 1860, which includes numeric keys and other keys, and may be coupled to the bus 1835 to transmit information and command selections to the processor 1810. Another type of user input device includes a cursor control device 1870, such as a touchpad, mouse, trackball, or cursor arrow keys, for transmitting directional information and command selections to the processor 1810 and controlling cursor movement on the display device 1850. The computing system 1800 may also receive user input from a communicatively coupled remote device via one or more network interfaces 1880.

[0099] The computing system 1800 may also include one or more network interfaces 1880 to provide access to a network such as a local area network (LAN). The network interface 1880 may include, for example, a wireless network interface with an antenna 1885, which may represent one or more antennas. The computing system 1800 may include multiple wireless network interfaces, such as Wi-Fi and Bluetooth. ® A combination of near field communication (NFC) and / or cellular telephone interfaces. The network interface 1880 may also include, for example, a wired network interface for communicating with remote devices via a network cable 1887, which may be, for example, an Ethernet cable, a coaxial cable, a fiber optic cable, a serial cable, or a parallel cable.

[0100] In one implementation, network interface 1880 may provide access to a local area network (LAN) for example, by conforming to the IEEE 802.18 standard, and / or wireless network interface may provide access to a personal area network (PAN) for example, by conforming to the Bluetooth standard. Other wireless network interfaces and / or protocols may also be supported. As a supplement to or alternative to communication via wireless LAN standards, network interface 1880 may provide wireless communication using, for example, Time Division Multiple Access (TDMA), Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Long Term Evolution (LTE), and / or any other type of wireless communication protocol.

[0101] The computing system 1800 may also include one or more energy sources 1805 and one or more energy measurement systems 1845. The energy source 1805 may include an AC / DC adapter coupled to an external power source, one or more batteries, one or more charge storage devices, a USB charger, or other energy sources. The energy measurement system includes at least one voltage or current measuring device capable of measuring the energy consumed by the computing system 1800 during a predetermined time period. Furthermore, one or more energy measurement systems may be included to measure, for example, the energy consumed by a display device, cooling subsystem, Wi-Fi subsystem, or other commonly used or high-energy-consuming subsystems.

[0102] As described above, one aspect of the present invention is the collection and use of data available from specific legal sources to improve the user experience regarding access to protected resources on a data processing system. This disclosure contemplates that, in some cases, the collected data may include personal information about a user's application usage patterns. The collection of such application usage patterns may also inadvertently reveal other information that can be used to uniquely identify a user, such as demographic data, location-based data, online identifiers, telephone numbers, email addresses, home addresses, data or records related to a user's health or fitness level (e.g., vital sign measurements, medication information, exercise information), date of birth, or any other personal information. This disclosure recognizes that, in the present invention, the use of such personal information data can be used to benefit the user, for example, to improve the user experience of performing tasks using the data processing system or computing device described herein.

[0103] This disclosure assumes that entities responsible for collecting, analyzing, disclosing, transmitting, storing, or otherwise using such personal information data will comply with established privacy policies and / or privacy practices. Specifically, it is expected that such entities will implement and consistently apply privacy practices generally recognized as meeting or exceeding industry or governmental requirements for protecting user privacy. Such information regarding the use of personal data should be highlighted and easily accessible to users, and should be updated as data collection and / or use changes. Users' personal information should be collected only for lawful use. Furthermore, such collection / sharing should only occur after receiving user consent or other lawful grounds provided for in applicable law. In addition, such entities should consider taking any necessary steps to protect and safeguard access to such personal information data and ensure that others with access to personal information data comply with their privacy policies and processes. Additionally, such entities may be subject to third-party assessments to demonstrate their compliance with widely accepted privacy policies and practices. Furthermore, policies and practices should be tailored to the specific types of personal information data collected and / or accessed, and made applicable to applicable laws and standards, including jurisdiction-specific considerations that may be used to impose higher standards. For example, in the United States, the collection or access to certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA); while health data in other countries may be subject to other regulations and policies and should be handled accordingly.

[0104] Regardless of the foregoing, this disclosure also anticipates implementation schemes for users to selectively block the use or access to personal information data. That is, this disclosure anticipates providing hardware and / or software components to prevent or block access to such personal information data. For example, the inventive technology can be configured to allow users to opt-in or opt-out at any time during or after system configuration to participate in the collection of personal information data. In addition to providing "opt-in" and "opt-out" options, this disclosure also envisions providing notifications related to access to or use of personal information. For example, users may be notified when downloading an application that their personal information data will be accessed, and then reminded again just before the application accesses the personal information data.

[0105] Furthermore, the purpose of this disclosure is to manage and process personal information data to minimize the risk of unintentional or unauthorized access or use. Once data is no longer needed, this risk can be minimized by limiting data collection and deleting data. Additionally, and where applicable, including in certain health-related applications, data deidentification can be used to protect user privacy. Deidentification can be facilitated, where appropriate, by removing identifiers, controlling the amount or specificity of stored data (e.g., collecting location data at the city level rather than the address level), controlling how data is stored (e.g., aggregating data among users), and / or other methods such as differentiated privacy.

[0106] Therefore, while this disclosure broadly covers the use of personal information data to implement one or more of the various disclosed embodiments, it is also contemplated that various embodiments can be implemented without access to such personal information data. That is, various embodiments of the present invention will not be rendered inoperable due to the absence of all or part of such personal information data. For example, content can be selected and delivered to the user based on aggregated non-personal information data or an absolute minimum amount of personal information, such as content processed only on the user's device or other non-personal information that can be used for content delivery services.

[0107] Exemplary embodiments of this disclosure have been described in the foregoing description. It will be apparent that various modifications may be made thereto without departing from the broader spirit and scope of this disclosure. Accordingly, the specification and drawings are to be regarded as illustrative rather than limiting. Specific details in the descriptions and examples provided can be used anywhere in one or more embodiments. Various features of different embodiments or examples may be combined differently with some of the included features and others excluded features to suit a variety of different applications. Examples may include subjects such as methods, means for performing the actions of the method, at least one machine-readable medium including instructions that, when executed by a machine, cause the machine to perform the actions of the method, or actions of an apparatus or system according to the embodiments and examples described herein. Furthermore, the various components described herein may be means for performing the operations or functions described herein.

[0108] One embodiment provides a method comprising: displaying, via a display of an electronic device, user interface elements corresponding to a function executed on one or more processors of the electronic device; and receiving an instruction to interact with the user interface elements. The method further comprises: in response to receiving the instruction and determining that the instruction corresponds to a hardware input event, sending an authentication token from a first component of the electronic device to a second component of the electronic device; verifying the validity of the authentication token by the second component; and, after verifying the validity of the authentication token, initiating the execution of the function.

[0109] Further regarding the above method, the first component may be a first daemon process associated with the operating system of the electronic device, and the second component may be a second daemon process associated with the operating system of the electronic device. The second component may be a process executing on one or more processors of the electronic device. In one embodiment, in response to verifying the validity of the authentication token, the method may additionally include: the second component sending an indication that the authentication token is valid to the process. The first component may use cryptographic materials provided by the second component to generate the authentication token and send a timestamp associated with the authentication token along with the authentication token. Verifying the validity of the authentication token includes: using the timestamp to generate a second authentication token. Furthermore, the second component may provide cryptographic materials during the registration of a user interface element. The registration of the user interface element includes: specifying the user interface element to the first component as an indication of approval for performing the function. The method may additionally include: presenting an indication of the performance of the function. This indication may include a notification displayed on the user interface of the electronic device or another indication to the user that a protected function has been performed.

[0110] In various implementations, the protected functionality may include accessing data stored in a memory buffer configured as a clipboard or pasteboard by the electronic device's operating system, sending ad attribute data in response to a selection of an ad displayed by the process, or sending location information associated with the electronic device.

[0111] One embodiment provides a non-transitory machine-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations including: displaying user interface elements corresponding to a function of a process executing on one or more processors of an electronic device via a display of an electronic device; and receiving instructions for interacting with the user interface elements. These operations further include: in response to receiving the instructions and determining that the instructions correspond to a hardware input event, sending an authentication token from a first component of the electronic device to a second component of the electronic device; verifying the validity of the authentication token by the second component; and, after verifying the validity of the authentication token, initiating the execution of the function.

[0112] One embodiment provides a data processing system on an electronic device, the system including a display, a memory device, and one or more processors coupled to the memory device and the display. The one or more processors are configured to execute instructions stored in the memory device. These instructions cause one or more processors to perform the following operations: displaying user interface elements corresponding to functions of a process executed by the one or more processors via the display; receiving instructions for interaction with the user interface elements; and in response to receiving the instructions: sending an authentication token from a first component of the electronic device to a second component of the electronic device based on a determination that the instructions correspond to a hardware input event; verifying the validity of the authentication token by the second component; and initiating the execution of the function after verifying the validity of the authentication token.

[0113] One embodiment provides a non-transitory machine-readable medium storing instructions that, when executed by one or more processors of an electronic device, cause the one or more processors to perform operations including: receiving a hardware event associated with an input device; determining that the hardware event is associated with a request to access data stored in a memory buffer configured as a clipboard or pasteboard by the operating system of the electronic device; generating an authentication token to enable authenticated access to the memory buffer in response to determining that the hardware event is associated with the request to access the memory buffer, the authentication token being generated at least in part based on a shared secret and a timestamp; triggering a software event to report the occurrence of the hardware event, the software event including the authentication token and the timestamp; receiving a request from an application executed by one or more processors of the electronic device to access data in the memory buffer, the request including the authentication token and the timestamp; verifying the authentication token and the timestamp; and providing the data stored in the memory buffer to the application in response to verifying the authentication token and the timestamp.

[0114] In another implementation, these operations additionally include: at a first software process, receiving a hardware event associated with an input device; determining that the hardware event is associated with a request to access data stored in a memory buffer; generating an authentication token to enable authenticated access to the memory buffer; and triggering a software event to report the occurrence of the hardware event, the software event including the authentication token and a timestamp. These operations additionally include: at a second software process, receiving a request from an application executed by one or more processors of an electronic device to access data in a memory buffer, the request including an authentication token and a timestamp; verifying the authentication token and timestamp; and providing the data stored in the memory buffer to the application in response to verifying the authentication token and timestamp. These operations may also include: generating or exchanging a shared secret via a privileged communication channel established via the first and second software processes. The hardware event may be an input event associated with a hardware input device, such as a touch event received from a touch input device, a click event received from a pointer device, or a keyboard hotkey received from a keyboard device. Determining that the hardware event is associated with a request to access data stored in a memory buffer includes: determining that the input event is associated with a user interface element configured to trigger a paste action or another protected function described herein.

[0115] One embodiment provides a data processing system including a display, a memory device, and one or more processors coupled to the memory device and the display, the one or more processors being configured to execute instructions stored in the memory device. These instructions cause the one or more processors to perform the following operations: receiving a request from a first process executed by the one or more processors, wherein the request is a request to access memory associated with a clipboard or pasteboard, and the first process is associated with an application executed by the one or more processors; determining that the memory includes data placed into the memory by a second process executed by the one or more processors, the second process being distinct from the first process, wherein the determination is performed based on metadata associated with the data, and metadata is generated in association with inserting the data into the memory; and presenting a notification on the display in response to the determination. The notification may indicate that the first application has pasted data from the second application.

[0116] In another implementation, these instructions cause one or more processors to perform the following operations: receive a request from a first application, the request being an indication of a pattern for data stored in memory; analyze the data stored in memory to determine if a pattern exists within the data; and return a pattern type to the first application, the pattern type being associated with the detected pattern within the data. Based on the pattern type detected within the data, the first application can adjust paste interface elements presented via a display. The pattern type can be a Uniform Resource Locator, a numeric pattern, or a search query pattern.

[0117] One embodiment provides a non-transitory machine-readable medium storing instructions that cause one or more processors to perform operations including: preventing access to location service functions provided by an electronic device; receiving a hardware input event corresponding to a user interface element presented on a display of the electronic device, wherein receiving the hardware event at the user interface element is designated as an indication of approval for access to the location service functions; sending a message by a first component of the electronic device indicating the occurrence of the hardware input event, the message including an authentication token; verifying the authentication token upon receiving the message; and enabling access to the location service functions provided by the electronic device in response to verifying the authentication token.

[0118] Other features of this embodiment will become apparent from the accompanying drawings and the detailed description described above. Therefore, the true scope of these embodiments will be apparent to a skilled practitioner upon studying the drawings, description, and appended claims.

Claims

1. A method comprising: Receive a request from an application on the electronic device to access the location services of the electronic device; Determine whether the application has been granted access to the location service; When access to the location service has not yet been granted to the application, the verified user interface elements are displayed to indicate that access to the location service will be granted to the application. The display includes: Receive a request to provide the verified user interface elements; Identify the user interface area that will contain the verified user interface elements; The verified user interface elements are registered with the verified process by a process independent of the application; and The verified user interface elements are rendered in the identified user interface area by the process independent of the application; and In response to determining that a hardware event is associated with a selection of the verified user interface element, the application is granted access to the location service.

2. The method according to claim 1, further comprising: When the application has been granted access to the location service, the application is allowed to access the location service.

3. The method according to claim 1, wherein, The verified user interface elements are rendered within the application's user interface by the process independent of the application.

4. The method according to claim 1, wherein, Determining that the hardware event is associated with the selection of the verified user interface element includes: In response to the detection of a hardware event associated with the selection of the verified user interface element, a software event including verification data is triggered by the verified process that detected the hardware event, wherein the verified process is independent of the process and the application.

5. The method according to claim 4, wherein, The verification data includes at least one of the authentication token or signature attached to the software event.

6. The method according to claim 5, wherein, The signature is associated with the party that generated the software event.

7. A non-transitory machine-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform an operation comprising: Receive a request from an application on the electronic device to access the location services of the electronic device; Determine whether the application has been granted access to the location service; When access to the location service has not yet been granted to the application, the verified user interface elements are displayed to indicate that access to the location service will be granted to the application. The display includes: Receive a request to provide the verified user interface elements; Identify the user interface area that will contain the verified user interface elements; The verified user interface elements are registered with the verified process by a process independent of the application; and The verified user interface elements are rendered in the identified user interface area by the process independent of the application; and In response to determining that a hardware event is associated with a selection of the verified user interface element, the application is granted access to the location service.

8. The non-transitory machine-readable medium according to claim 7, wherein, The operation also includes: When the application has been granted access to the location service, the application is allowed to access the location service.

9. The non-transitory machine-readable medium according to claim 7, wherein, The verified user interface elements also include: Send a notification to identify the user interface area that will contain the verified user interface elements.

10. The non-transitory machine-readable medium according to claim 9, wherein, The notification identifies the verified user interface element through a user interface element identifier.

11. The non-transitory machine-readable medium according to claim 9, wherein, The verified user interface elements are rendered within the application's user interface by the process independent of the application.

12. The non-transitory machine-readable medium according to claim 7, wherein, Determining that the hardware event is associated with the selection of the verified user interface element includes: In response to the hardware event associated with the selection of the verified user interface element, a software event including verification data is triggered.

13. The non-transitory machine-readable medium according to claim 12, wherein, The verification data includes at least one of the authentication token or signature attached to the software event.

14. The non-transitory machine-readable medium according to claim 13, wherein, The signature is associated with the party that generated the software event.

15. An apparatus comprising: Memory; and At least one processor, said at least one processor being configured to: Receive a request from an application to access location services on the device; Determine whether the application has been granted access to the location service; When access to the location service has not yet been granted to the application, the verified user interface elements are displayed to indicate that access to the location service will be granted to the application. The display includes: Receive a request to provide the verified user interface elements; Identify the user interface area that will contain the verified user interface elements; The verified user interface elements are registered with the verified process by a process independent of the application; and The verified user interface elements are rendered in the identified user interface area by the process independent of the application; and In response to determining that a hardware event is associated with a selection of the verified user interface element, the application is granted access to the location service.

16. The device according to claim 15, wherein, The at least one processor is further configured to: When the application has been granted access to the location service, the application is allowed to access the location service.

17. The device according to claim 15, wherein, The verified user interface elements are rendered within the application's user interface by the process independent of the application.

18. The device according to claim 15, wherein, Determining that the hardware event is associated with the selection of the verified user interface element includes: In response to the hardware event associated with the selection of the verified user interface element, a software event including verification data is triggered.

19. The device according to claim 18, wherein, The verification data includes at least one of the authentication token or signature attached to the software event.

20. The device according to claim 19, wherein, The signature is associated with the party that generated the software event.

21. An apparatus comprising: Memory; and At least one processor, said at least one processor being configured to: Receive an input event corresponding to a selection of an advertisement associated with the application; Determine whether the input event is an authenticated input event; In response to the determination that the input event is an authenticated input event, the transmission of attribute data corresponding to the selection, including data identifying the application, is permitted; as well as In response to another determination that the input event is not an authenticated input event, another transmission corresponding to the selection, excluding attribute data identifying the application, is permitted.

22. The device according to claim 21, wherein, The at least one processor is configured to determine whether the input event is an authenticated input event by: Verify whether the input event is associated with a hardware input event.

23. The device according to claim 21, wherein, The at least one processor is configured to allow the transmission of attribute data corresponding to the selection, including data identifying the application, in such a way as follows: Access the network identifier corresponding to the advertisement associated with the attribute data.

24. The device according to claim 23, wherein, Accessing the network identifier corresponding to the advertisement associated with the attribute data includes: The Uniform Resource Locator (URL) associated with the advertisement, along with the attribute data, is sent to the browser.

25. The device according to claim 24, wherein, The at least one processor is further configured to: When the input event is determined to be an unauthenticated input event, the URL associated with the advertisement is sent to the browser without the attribute data.

26. The device according to claim 21, wherein, The advertisement is displayed within the application.

Images