Safety verification method for control event and electronic equipment

Abstract

The invention discloses a safety verification method for a control event and electronic equipment, which are used for improving the safety of the control event of the electronic equipment. For example, an electronic device includes a multimode input service, a security verification service, and a first application. The method comprises the steps that a security verification service receives a first event sequence sent by a first application, and the first event sequence comprises at least one control event for a target control in the first application; the security verification service determines that a second event sequence identical to the first event sequence is stored, the second event sequence is a mirror image of a control event output by a multi-mode input service of the electronic equipment, and the multi-mode input service is used for outputting the control event triggered when a user operates the electronic equipment to the first application; the control event is used for controlling the first application to realize a corresponding function; and the security verification service sends a first security verification result to the first application, wherein the first security verification result is used for indicating that the security verification of the first event sequence is passed.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a security verification method and electronic device for controlling events. Background Technology

[0002] With the development of terminal technology, electronic devices are offering an increasing variety of input devices, such as keyboards, mice, touchscreens, and touchpads. Different types of input devices provide different input methods. Electronic devices can employ multimodal interaction technology to support various types of input devices. For example, the operating system of an electronic device may include a multimodal input subsystem. This subsystem can receive control events from multiple input devices, process these events into events recognizable by the application (APP), and then distribute them to the application for response. By integrating multiple input devices and methods through a multimodal input subsystem, a rich and diverse human-computer interaction experience can be provided to users.

[0003] Before a control event is finally responded to, it needs to be forwarded multiple times through the internal message channels of the electronic device. During this forwarding process, the control event may be tampered with, or one application on the electronic device may directly send an insecure control event to another application, which will lead to security risks to the electronic device. Therefore, how to ensure the security of events on electronic devices is an urgent problem to be solved. Summary of the Invention

[0004] This application provides a security verification method and electronic device for control events, which improves the security of control events in electronic devices.

[0005] A first aspect provides a security verification method for control events, applied to an electronic device. The method includes: a security verification service of the electronic device receiving a first event sequence sent by a first application of the electronic device, the first event sequence including at least one control event for a target control within the first application; the security verification service determining that a second event sequence identical to the first event sequence has been stored, the second event sequence being a mirror image of control events output by a multimodal input service of the electronic device, the multimodal input service being used to output control events triggered by user operations on the electronic device to the first application, the control events being used to control the first application to perform corresponding functions; and the security verification service sending a first security verification result to the first application, the first security verification result indicating that the security verification of the first event sequence has passed.

[0006] Through this implementation, the security verification service stores a mirror image of the control events output by the multimodal input service. Then, it can verify the first event sequence for the target control based on the stored control event sequence (i.e., the second event sequence). This achieves security verification of consecutive events containing multiple control events. The security verification can only pass if the first event sequence and the second event sequence are completely identical, allowing subsequent operations, such as the first application responding to the first event sequence to implement the first function of the target control, thereby improving the security of control events within the electronic device.

[0007] In one possible implementation, the method further includes: a security verification service receiving a third event sequence sent by a first application, the third event sequence including at least one control event for a target control; the security verification service determining that a fourth event sequence identical to the third event sequence is not stored; and the security verification service sending a second security verification result to the first application; wherein the second security verification result is used to indicate that the security verification of the third event sequence failed. Based on this implementation, the security verification service uses a storage mirror comparison method. Therefore, regardless of any modifications made during the control event forwarding process, this embodiment can detect differences between the third event sequence and the stored event sequence through comparison, i.e., it will not store a fourth event sequence completely identical to the third event sequence. Ultimately, the security verification will fail, thus the method of this embodiment can meet the security verification requirements under various circumstances.

[0008] In one possible implementation, the security verification service determines that it does not store a fourth event sequence identical to the third event sequence, which can include several scenarios. One scenario is that the security verification service stores zero control events. For example, if an application might directly send an insecure control event to another application, the security verification service will not have a corresponding mirror image. This allows the security verification service to identify such constructed event scenarios and reduce the security risks posed by constructed events to electronic devices. Another scenario is that the security verification service has stored a fifth event sequence, and the third event sequence differs from the fifth event sequence. That is, if the control event forwarding process by the multimodal input service is modified, the third event sequence actually received by the first application will differ from the fifth event sequence stored by the security verification service. This allows the security verification service to identify scenarios where events are modified during forwarding, reducing the security risks posed by modifications during event forwarding to electronic devices.

[0009] In one possible implementation, the third event sequence differs from the fifth event sequence, and may include one or more of the following scenarios: First, the number of control events in the third event sequence differs from the number of control events in the fifth event sequence, meaning the event is copied and retransmitted during forwarding. Therefore, the security verification service of this embodiment can meet the security verification requirements in the scenario of copying and retransmission. Second, the order of control events in the third event sequence differs from the order of control events in the fifth event sequence, meaning the event order is adjusted during forwarding. Therefore, the security verification service of this embodiment can meet the security verification requirements in the scenario of event order adjustment. Third, the event content of any control event in the third event sequence differs from the event content of the corresponding control event in the fifth event sequence, meaning the event content is tampered with during forwarding. Therefore, the security verification service of this embodiment can meet the security verification requirements under the condition of event content tampering.

[0010] In one possible implementation, the security verification service receives at least one control event sent by the multimodal input service; wherein, the second event sequence includes at least one control event, and the multimodal input service is used to synchronize each of the at least one control event between the first application and the security verification service; the security verification service stores at least one control event in the order in which the at least one control event is received. Based on this implementation, by storing a mirror image of the control events output by the multimodal input service, the security verification service can perform security verification on the first event sequence actually received by the target control, thereby improving the security of the control events of the electronic device.

[0011] In one possible implementation, before the security verification service stores at least one control event, the method further includes: the security verification service receiving an event registration request sent by a first application, the event registration request instructing the first application to load the target control. The security verification service responds to the event registration request and stores at least one control event sent by the multimodal input service. Based on this implementation, the security verification service only records and performs security verification of control events after the target control is loaded. This can be understood as the security verification service not recording and performing security verification of control events when the target control is not loaded, which can reduce the burden on the electronic device and decrease the functional and performance consumption of the electronic device.

[0012] In one possible implementation, after the security verification service receives an event registration request sent by the first application, the method further includes: the security verification service receiving an event deregistration request sent by the first application, the event deregistration request indicating that the target control has exited loading. In response to the event deregistration request, the security verification service stops storing at least one control event sent by the multimodal input service. Based on this implementation, the security verification service can store a sequence of control events from the time the target control is started until it exits loading, thereby enabling security verification of control events for the target control throughout its lifecycle, ensuring security requirements in secure interaction scenarios. When the target control exits loading, the security verification service does not record or perform security verification of control events, reducing the burden on the electronic device and lowering its functional and performance consumption.

[0013] In one possible implementation, the target control is a security control. That is, the method can be implemented only in scenarios with high security requirements, thereby reducing the number of control events that need to be verified, alleviating the burden on electronic devices, reducing the power consumption of electronic devices, and improving the performance of electronic devices.

[0014] In one possible implementation, the first event sequence is a gesture event, which includes at least two basic touch events; or, the first event sequence is a button event sequence, which includes at least two button events. Based on this implementation, the technical solution of this application can meet the security verification requirements of gesture events and button events, thereby improving the security of electronic devices.

[0015] In one possible implementation, the electronic device includes an operating system, which may include a multimodal input service and a security verification service. Based on this implementation, when the security verification service is deployed within the operating system, it can be tightly integrated with the system kernel and other services, helping to reduce compatibility issues and system conflicts, while also typically enjoying system-level priority and resource management. Furthermore, the security verification service can interact directly with the multimodal input service, reducing interactions during control event forwarding and improving the reliability of backup control events within the security verification service.

[0016] Secondly, a security verification method for control events is provided, applicable to electronic devices. The method includes: a first application of the electronic device receiving at least one control event for a target control within the first application; the first application sending a first event sequence to a security verification service of the electronic device, the first event sequence including at least one control event; the first application receiving a first security verification result sent by the security verification service, the first security verification result indicating that the security verification service has stored a second event sequence identical to the first event sequence, wherein the second event sequence is a mirror image of a control event output by a multimodal input service of the electronic device, the multimodal input service being used to output control events triggered by user operations on the electronic device to the first application, the control events being used to control the first application to perform corresponding functions; and the first application, based on the first security verification result, responding to the first event sequence to perform a first function of the target control.

[0017] In one possible implementation, the method further includes: a first application sending a third event sequence to a security verification service, the third event sequence including at least one control event for a target control; the first application receiving a second security verification result sent by the security verification service, the second security verification result indicating that the security verification service does not store a fourth event sequence identical to the third event sequence; the first application refusing to respond to the third event sequence based on the second security verification result, and / or outputting a prompt message indicating that the electronic device has a security risk.

[0018] In one possible implementation, the second security verification result further indicates one or more of the following: the number of control events stored by the security verification service is zero; the number of control events in the third event sequence is different from the number of control events in the fifth event sequence stored by the security verification service; the order of control events in the third event sequence is different from the order of control events in the fifth event sequence; or, the event content of any control event in the third event sequence is different from the event content of the corresponding control event in the fifth event sequence.

[0019] In one possible implementation, a first application sends a first event sequence to a security verification service of an electronic device, including: the first application determining that the first event sequence meets a first condition, and the first application sending the first event sequence to the security verification service. The first condition includes one or more of the following: the first event sequence is a gesture event associated with a target control; the number of key events included in the first event sequence is greater than or equal to a first threshold; or, the first event sequence includes preset key events.

[0020] In one possible implementation, the method further includes: a first application sending an event registration request to a security verification service, the event registration request instructing the first application to load a target control.

[0021] In one possible implementation, after the first application sends an event registration request to the security verification service, the method further includes: the first application sending an event deregistration request to the security verification service, the event deregistration request instructing the target control to exit loading.

[0022] In one possible implementation, the target control is a security control.

[0023] Thirdly, this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method as described in any of the first and / or second aspects above.

[0024] Fourthly, this application provides an electronic device including modules / units for performing the methods corresponding to any one of the designs in the first and / or second aspects described above. These modules / units can be implemented in hardware or by hardware executing corresponding software.

[0025] Fifthly, this application provides a computer-readable storage medium storing a computer program that, when executed by at least one processor, implements the method as described in any one of the first and / or second aspects above.

[0026] Sixthly, this application provides a chip including a processor and an interface; the processor is configured to read instructions through the interface to perform the methods described in any of the first and / or second aspects above.

[0027] In a seventh aspect, this application provides a computer program product comprising a computer program that, when run on a computer, enables the computer to perform the methods described in any of the first and / or second aspects above.

[0028] The beneficial effects of the design in any of the second to seventh aspects mentioned above can be referred to the beneficial effects of the corresponding design in the first aspect mentioned above, and this application will not elaborate on them one by one. Attached Figure Description

[0029] Figure 1A A schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0030] Figure 1B A software system architecture block diagram of an electronic device provided in an embodiment of this application;

[0031] Figure 1C A system architecture block diagram of an electronic device provided in an embodiment of this application;

[0032] Figure 2A and Figure 2BA diagram illustrating the process of controlling the forwarding of events;

[0033] Figure 3A and Figure 3B A schematic diagram illustrating the security verification process for control events provided in an embodiment of this application;

[0034] Figure 4A and Figure 4B This is a schematic diagram of the interface effect provided in the embodiments of this application;

[0035] Figures 5A to 5D Example diagrams of unsafe events provided for embodiments of this application;

[0036] Figure 6A A schematic diagram of a scenario provided for an embodiment of this application;

[0037] Figure 6B A flowchart illustrating a security verification method for control events provided in an embodiment of this application;

[0038] Figure 6C Another flowchart illustrating the security verification method for control events provided in this application embodiment;

[0039] Figure 7 This is another flowchart illustrating the security verification method for control events provided in the embodiments of this application;

[0040] Figure 8A This is another scenario illustration provided for an embodiment of this application;

[0041] Figure 8B A flowchart illustrating the security verification method for gesture events provided in this application embodiment;

[0042] Figure 9A This is another scenario illustration provided by an embodiment of the present application;

[0043] Figure 9B A flowchart illustrating the security verification method for key events provided in this application embodiment;

[0044] Figure 9C This is a schematic diagram of the interface effect provided in the embodiments of this application;

[0045] Figure 10 A schematic diagram illustrating the process of developing, packaging, and installing the security verification service provided in this application embodiment onto an electronic device;

[0046] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0047] The following explanations of some terms used in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0048] The embodiments of this application involve at least one, including one or more; where "multiple" means two or more. Furthermore, it should be understood that in the description of this specification, terms such as "first" and "second" are used only for descriptive purposes and should not be construed as indicating or implying relative importance or order. For example, a first event sequence and a second event sequence do not represent the degree of importance of the two or their order, but are merely for descriptive distinction. In the embodiments of this application, "and / or" merely describes an association relationship, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0049] The directional terms mentioned in the embodiments of this application, such as "up", "down", "left", "right", "inner", and "outer", are only for reference to the directions in the accompanying drawings. Therefore, the directional terms used are for better and clearer explanation and understanding of the embodiments of this application, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the embodiments of this application.

[0050] References to "one embodiment," "in some examples," or "some embodiments" as described in this specification mean that one or more embodiments of this specification include a particular feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in some examples," "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0051] The method provided in this application can be applied to electronic devices. These electronic devices can enable human-computer interaction. For example, the electronic device can be a mobile phone, tablet computer, wearable device (e.g., watch, bracelet, etc.), in-vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), smart home device (e.g., smart TV, smart speaker, etc.), or any other electronic device with human-computer interaction capabilities. It is understood that this application does not limit the specific type of electronic device.

[0052] Please see Figure 1A The diagram shown is a structural schematic of an electronic device 100 provided in an embodiment of this application. Figure 1A As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0053] Processor 110 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors. The controller may serve as the central nervous system and command center of the electronic device 100. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution. Processor 110 may also include memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that processor 110 has recently used or is repeatedly used. If processor 110 needs to reuse an instruction or data, it can directly retrieve it from the memory. This avoids repeated access, reduces the waiting time of processor 110, and thus improves system efficiency.

[0054] Display screen 194 is used to display the display interface of an application, etc. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Miniled LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or N display screens 194, where N is a positive integer greater than 1. For example, electronic device 100 may be a mobile phone with a foldable display screen, which has at least two display screens. In the embodiments of this application, display screen 194 can be used to display an interface (or page or window, etc.) including one or more applications (APPs). Each application page may include one or more controls, and users can interact with these controls through input devices, for example... Figures 4A-4B The various interfaces shown.

[0055] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system and software code for at least one application program. The data storage area may store data generated during the use of electronic device 100 (e.g., images, videos, etc.). Furthermore, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0056] Touch sensor 180K, also known as a "touch panel," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touch screen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of electronic device 100, in a different position than display screen 194. In this embodiment, touch sensor 180K can serve as an input device. It can detect user operations and transmit the detected user operation information to higher layers, enabling electronic device 100 to respond to user operations and perform corresponding functions. For example, an application in electronic device 100 can respond to user operations on controls to perform the functions of those controls.

[0057] Button 190 includes a power button, volume buttons, etc. Button 190 can be a mechanical button or a touch button. In this embodiment, button 190 can serve as one of the input devices, and electronic device 100 can receive input from the user via the button, generating key signal inputs related to user settings and function control of electronic device 100. Besides the input devices mentioned above, electronic device 100 may also include other input devices or external input devices, such as a keyboard, mouse, microphone, motion sensing device, or sensor, etc., without limitation.

[0058] Understandable Figure 1A The components shown do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include components that are more... Figure 1A More or fewer components, or combinations of components, or separation of components, or different arrangements of components. The components illustrated can be implemented in hardware, software, or a combination of both. Furthermore, Figure 1A The combination / connection relationships between the components can also be adjusted and modified.

[0059] Figure 1B This is a software system architecture block diagram of an electronic device provided in an embodiment of this application. For example... Figure 1B As shown, the software system architecture of an electronic device can be a layered architecture. For example, the software can be divided into several layers, each with a clear role and division of labor. Layers communicate with each other through software interfaces. In some embodiments, the operating system is divided into four layers, from top to bottom: the application layer, the application framework layer (FWK), the runtime and system libraries, and the kernel layer.

[0060] The application layer can include a series of application packages. For example... Figure 1B As shown, the application package can include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS. The application framework layer provides application programming interfaces (APIs) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0061] like Figure 1B As shown, the application framework layer can include an activity manager, window manager, content providers, view system, phone manager, resource manager, and notification manager. The activity manager manages the lifecycle of each application and provides common navigation and back functions, offering an interactive interface for all program windows. The window manager manages window programs. The window manager can obtain screen size, determine the presence of a status bar, lock the screen, or capture the screen. The content provider stores and retrieves data, making this data accessible to applications. This data can include videos, images, audio, made and received phone calls, browsing history, bookmarks, or phone books.

[0062] The view system includes user-interactive controls, such as security controls. The view system can be used to build applications. The display interface can consist of one or more views. For example, a display interface including a text notification icon can include a view displaying text and a view displaying images. In this embodiment, a security control of the application can be displayed, and the user can interact with the security control to implement its function. That is, the user's interaction with the security control can generate a control event, and the application can respond to the control event to implement the function of the security control. Before the control event generated by the user interaction is responded to, the control event can be provided to an application or service for event security verification. The control event is verified for security; only if the control event is secure is a response allowed. Optionally, the application can be located at the application layer, such as a third-party application; the service may be located at the application framework layer, such as a service provided by the operating system. Optionally, the application or service may store a mirror image of the control events of user interaction and compare the control events actually received by the application with the control events stored in itself. If they are completely consistent, it indicates that the control events actually received by the application are safe, and then the application may allow the response to the control events for the safe control. Conversely, if they are inconsistent, it indicates that the control events actually received by the application are unsafe, and the application may refuse to respond to the control events for the safe control or output relevant prompt information.

[0063] The notification manager allows applications to display notification information in the status bar, such as informative messages that can disappear automatically after a short pause without user interaction. The notification manager can also display notifications as icons or scrolling text in the system's top status bar, such as notifications from background applications, or as dialog windows on the screen. Examples include displaying text messages in the status bar, emitting alert sounds, vibrating electronic devices, or flashing indicator lights. In this embodiment, if a security check of a control event for a security control fails, indicating a security risk, the user can be notified through any notification form from the notification manager so that they are aware of the security risk and can take appropriate countermeasures.

[0064] The runtime consists of the core libraries and the virtual machine. The runtime is responsible for the scheduling and management of the operating system. The core libraries consist of two parts: one part contains the functionalities that the Java language needs to call, and the other part consists of the core libraries of the operating system. The application layer and application framework layer run in the virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0065] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0066] The kernel layer is the layer between hardware and software. The kernel layer includes at least display drivers, camera drivers, audio drivers, or sensor drivers. Below the kernel layer can be a hardware layer, which may include various sensors, such as accelerometers, gravity sensors, and touch sensors. In this embodiment, a touch sensor can be used as one of the input devices. This touch sensor can detect user operations and transmit the detected user operation information to the upper layer, enabling the application to respond to user operations on controls and perform corresponding functions. Besides touch sensors, the hardware layer may also include sensors corresponding to other input devices, such as photoelectric sensors or Hall effect sensors corresponding to buttons, without limitation.

[0067] It should be understood that the hardware structure of electronic devices can be as follows: Figure 1A As shown, the software system architecture can be as follows: Figure 1BAs shown, the software programs and / or modules corresponding to the software system architecture in the electronic device can be stored in the internal memory 121, and the processor 110 can run the software programs and applications stored in the internal memory 121 to execute the process of the security verification method for control events provided in the embodiments of this application.

[0068] Please see Figure 1C , Figure 1C This is another system architecture block diagram of the electronic device provided in the embodiments of this application. In this architecture, the electronic device may include one or more applications, an input system, and an operating system (OS).

[0069] Applications can include those that come pre-installed with the electronic device, including system applications and third-party applications pre-installed at the factory. System applications can also be referred to as system services and are considered part of the operating system. Applications can also include user-installed applications. Furthermore, applications in this embodiment can also include portable applications. These applications can run using the application framework provided by the host program, allowing users to use them directly without installing their packages, making it faster, more convenient, and saving storage space on the electronic device. These applications can also be called parasitic applications, lightweight applications, mini-programs, etc.

[0070] An input system is a system used by users to control electronic devices, such as controlling applications within the electronic device. Input systems can include built-in input devices or external input devices. See also Figure 1C As shown, built-in input devices can be hardware devices built into electronic devices such as keyboards, touchpads, accelerometers, and angular accelerometers, or software input systems such as gesture recognition systems, voice recognition systems, body movement recognition systems, motion sensing recognition systems, and facial expression recognition systems. External input devices can be hardware devices such as wearable devices, virtual reality (VR) devices, and sensors.

[0071] The operating system can be any operating system; for example, the operating system can be... Or other operating systems. Figure 1CAs shown, the operating system may include a multi-modal input subsystem and a security verification subsystem. The multi-modal input subsystem provides multi-modal input services. That is, when a user controls an electronic device through the input system, the input system generates corresponding raw control events. Different types of input devices can generate different types of raw control events. The multi-modal input subsystem provides a management framework for these control events. It can normalize and standardize the raw control events received from various types of input devices to obtain target control events that can be recognized (or processed) by the multi-modal client, and then distribute these target control events to the multi-modal client. The multi-modal client is the consumer of the multi-modal input subsystem and can be an application in the electronic device. By integrating raw control events from various types of input devices, the multi-modal input subsystem provides users with a diverse human-computer interaction experience. The multi-modal input subsystem is divided into a framework part and a service part. The framework part encapsulates various interfaces for other subsystems and applications to call, while the service part implements these interfaces and implements the core logic for event dispatching and processing. These two parts run in different processes and communicate through sockets or inter-process communication (IPC) mechanisms, depending on the specific interface.

[0072] The security verification subsystem, also known as the event security arbitration center, provides security verification services for control events. It performs security verification on control events before they are finally responded to by the application. Only after the security verification is passed can the control event be allowed to be responded to, thereby improving the security of users when using electronic devices.

[0073] In some embodiments, such as Figure 1C As shown, the security verification subsystem can be deployed in the operating system. That is, the security verification subsystem can be a system service or function in the operating system. Since the system services that come with the operating system usually have higher stability and compatibility, and when deployed in the operating system, they can be tightly integrated with the system kernel and other services. This tight integration helps to reduce compatibility issues and system conflicts, and usually enjoys system-level priority and resource management, which can improve the effectiveness of security verification.

[0074] In some embodiments, the functionality of the security verification subsystem can also be implemented through a standalone application, which users can choose to install based on their needs. Alternatively, the functionality of the security verification subsystem can also be a functional module within an application, such as a security application like a mobile security manager.

[0075] In some embodiments, the multimodal input subsystem can receive raw control events from various types of input devices in the input system, process these raw control events to obtain target control events recognizable by the application, and then forward the target control events to the application for processing. For example, the multimodal input subsystem can convert raw control events from various types of input devices into basic touch events (i.e., target control events) and send them to the application. Basic touch events are events recognizable by the application and can be processed by the application. On one hand, the multimodal input subsystem can forward the target control events to the application through an internal message channel, and the application can pass the target control events to the target controls that need to respond to the target control events. On the other hand, the multimodal input subsystem can synchronously forward the target control events to the security verification subsystem, which stores a mirror image of the target control events.

[0076] When a sequence of control events for a target control needs to be responded to, for example, when the actual sequence of control events received by the application meets the triggering condition of a gesture event bound to the target control, the security verification subsystem can perform security verification on the control event sequence. The security verification subsystem can verify whether the control event sequence is consistent with the control event sequence stored in itself. For example, the security verification subsystem can compare and confirm whether the order, content, number, etc. of the control events in the two sequences are consistent, so as to determine the security of the control event sequence, and then determine whether the target control allows the application to respond to the control event sequence.

[0077] The aforementioned mirroring of storage control events can be understood as a backup or copy of storage control events.

[0078] Any application can include one or more application processes. When an application process executes, it can load (or run) one or more controls. You can think of an application as a complete software package, an application process as a runtime instance of the application responsible for executing its code, and controls as UI elements within the application used for user interaction. Controls run within the application process and help build the user interface. Ultimately, controls provide functionality through the application process, thereby enabling the overall functionality of the application.

[0079] In the embodiments of this application, the application response to the control event can be understood as the application process of the application responding to the control event, or the target control of the control event within the application responding to the control event.

[0080] During the runtime of each application process, one or more controls can be displayed on the application interface, allowing users to interact with them. A control is typically a component with a user interface (UI). A component usually refers to an independent functional module that provides a user interface, focusing on UI presentation and human-computer interaction. Controls not only have properties and methods but also handle graphical display and user input. A control is an element within the user interface. The following examples illustrate several possible control types:

[0081] (1) Text input control, used for text input. Text input controls may include single-line text input controls and multi-line text input controls. Single-line text input controls can be used for scenarios such as entering usernames and passwords on login pages, while multi-line text input controls can be used for scenarios such as comment sections and posting articles.

[0082] (2) Button control, which can be used to respond to user clicks.

[0083] (3) Progress bar control, used to display the progress of a certain operation to provide users with a user-friendly prompt.

[0084] (4) Security controls are interface elements or components used to enhance application security, such as login boxes, permission checks, or data encryption functions. These controls help protect applications from unauthorized access and other security threats, thereby ensuring user data and system security. They typically work in conjunction with application processes to ensure the integrity and confidentiality of the application through stringent security measures.

[0085] In addition to the controls mentioned above, other types of controls can also exist, such as custom dialog controls, video controls, popup controls, menu controls, or timepicker controls. Different controls can achieve different functions and interface effects.

[0086] From the perspective of security requirements or security risks, all controls can be divided into ordinary controls and secure controls. Ordinary controls refer to controls with low security requirements or low security risks. This can be understood as controls that, even if they respond to unsafe control events, pose little security risk and will not cause significant harm to the user. Examples include text input controls and progress bar controls. Secure controls, on the other hand, are designed for scenarios with high security requirements. In these scenarios, responding to unsafe control events could potentially cause significant harm to the user; therefore, secure controls have higher security requirements for their control events.

[0087] A control event is a single input action or set of input actions performed by a user through an input device to control an electronic device. For example, a control event is generated when a user interacts with a control on an application interface, and this control event is used to control the control to perform the corresponding function. The multimodal input subsystem can process and transform the raw control events to ultimately output the target control event that can be recognized and processed by the application.

[0088] The target control event output by the multi-modal input subsystem can be a single-point event. A single-point event can be understood as an event generated by a user's instantaneous operation, or an event generated by an operation performed within a unit of time during user interaction. For example, a single-point event can be a basic touch event or a key event. Basic touch events can also be called basic interaction events, and all gesture events are built upon basic touch events. Basic touch events can include four types: down, move, up, and cancel. Key events can also be called keyboard events. Key events and gesture events are handled differently. Gesture events require the fulfillment of a certain gesture triggering condition, which may require waiting for multiple single-point events before execution. Key events, on the other hand, are different. Each triggered key event is a clearly defined action that can be executed independently. For example, pressing the number key "1" inputs the number 1, and pressing the direction key moves in a certain direction. Of course, the specific function needs to be combined with the specific scenario.

[0089] A sequence of events can be a control event sequence composed of multiple single-point events. For example, a sequence of events can include gesture events, which are typically a type of touch event. A gesture event is usually a combination of multiple (e.g., at least two) basic touch events. Gesture events can include basic gesture events or complex gesture events. Electronic device operating systems typically support various basic user gestures, such as click, long press, and swipe, with corresponding gesture events being click events, long press events, and swipe events, respectively. For example, a click event can be composed of down and up events, while a swipe is composed of down, a series of move, and up events. Basic gestures can be combined into more complex gestures; complex gesture events can be understood as combinations of basic gesture events. For example, a drag event can be composed of a long press event and a swipe gesture event. User input is a continuous process. Gesture recognition refers to the process of identifying which gesture triggers the currently triggered basic touch event. Once a gesture is recognized, the corresponding gesture event is triggered. There can be a binding relationship between gestures and basic touch events. Developers can bind gestures to components, and when a specific gesture is recognized, the corresponding callback function is triggered. The multi-modal input subsystem can send single-point events to the application. The application can use the gesture recognition system to identify which gesture trigger condition the currently received single-point event meets, and thus determine the function that should be responded to.

[0090] In multi-level component nesting scenarios, gesture event responses can be influenced by multiple factors. The operating system of electronic devices provides mechanisms for multi-level gesture event handling to address these situations. In some cases, recognizing one gesture may prevent the recognition of others; therefore, gesture event responses have priorities and mutual exclusion. For example, if a component is bound to click and swipe events, the gesture that first meets the trigger condition will trigger the corresponding callback. Furthermore, the priority and mutual exclusion between gestures can be controlled by setting properties. The operating system of electronic devices also provides mechanisms for customizing gesture event handling. Developers can control the response order and processing logic of gesture events in a customized way to adapt to different application scenarios and user interaction needs. Through these mechanisms, the operating system of electronic devices can effectively convert and process control events from different types of input devices into gesture events for application processing, thereby providing a rich human-computer interaction experience.

[0091] When a user interacts with a control, the raw control events generated by the user interaction enter the multimodal input subsystem. The target control events, processed by the multimodal input subsystem, need to be passed to various controls within the application to complete the response. The application provides an external interface to receive the target control events, which can then be forwarded to the corresponding controls via internal message channels (such as IPC channels) of the electronic device.

[0092] See Figure 2A and Figure 2B The diagram shown illustrates the forwarding process of target control events. Figure 2A As shown, the electronic device includes an operating system side and an application side. The operating system side includes a multi-modal input subsystem and other functions, while the application side may include one or more applications, each of which may include multiple controls, such as... Figure 2A The diagram shows application A, which includes controls 1 through 4. After a user interacts with the computer, such as interacting with control 4, the multi-modal input subsystem receives the raw control event, transforms it into a target control event, and determines the control that needs to respond to the target control event. For example, the control that needs to respond to the target control event might be... Figure 2A When the control 4 shown is used, the operating system can forward the message to application A through the internal message channel of the electronic device. Then, application A passes it to control 4 inside application A. Control 4 responds to the target control event or a control event composed of multiple target control events (such as a gesture event) to complete the corresponding function.

[0093] exist Figure 2A The scenario shown illustrates a data transfer relationship between the user, the application, and control 4 within the application. However, in practice, applications often have external capability dependencies, meaning some functions within the application rely on external capabilities. For example, external capabilities might include permission authorization provided by the operating system, usage consent prompts, or public capabilities provided by system applications, such as embedded application cards. Figure 2B As shown, application A may include external capability pages corresponding to these external capabilities. This includes external capability page 1 corresponding to third-party applications and external capability page 2 corresponding to system applications. Here, third-party applications refer to non-system applications other than application A, while system applications are those provided by the operating system. After a user interacts with the computer, such as interacting with control 2 on external capability page 2, the multimodal input subsystem receives the original control event, transforms it into a target control event, and determines the control that needs to respond to the target control event. For example, the control that needs to respond to the target control event might be... Figure 2BWhen the control 2 shown is used, the operating system can forward the message to application A through the internal message channel of the electronic device. Then, application A passes it to the system application, and then the system application passes it to control 2 inside the system application. Control 2 responds to the target control event or a control event composed of multiple target control events (such as a gesture event) to complete the corresponding function.

[0094] Please compare. Figure 2A and Figure 2B As shown, Figure 2A Originally, there was only a data transfer relationship between the user, the application, and controls within the application (4), but... Figure 2B The relationship becomes one of transmission between user → application → external application → control 2 within the external application. When a user needs to interact with an external capability page within application A, application A will participate in the handling of some events. Therefore, application A may have the potential to modify the event content, copy and resend, adjust the event order, or construct events, thereby indirectly manipulating the external capabilities integrated within application A.

[0095] As above Figure 2A and Figure 2B As shown by the arrows, each arrow represents one forwarding. This means that before a control event receives a final response, it must be forwarded at least once through the message channel. During this forwarding process, there is a possibility of interception and tampering, making the controls within the application vulnerable to malicious attacks. Alternatively, there is also the possibility of one application directly sending malicious events to another, which also makes the controls within the application susceptible to malicious attacks. Therefore, event security protection is necessary to reduce the probability of malicious attacks on the application's controls.

[0096] To ensure event security, several security controls are provided to protect events in secure scenarios. These controls are provided by the operating system, and developers can choose to use them based on their needs. Typically, a security control includes code to determine whether a control event has been tampered with. Before responding to a control event, this code checks if the event has been modified. If the determination shows the event has not been modified, it is considered secure, and the control event can be responded to. However, if the determination shows the event has been modified, it is considered insecure, and the control event should not be responded to. For example, a security control can use a digest-based verification method to verify whether a control event has been tampered with. The sender of the control event pre-extracts a digest and sends both the control event and the digest to the receiver (i.e., the security control). The security control can then re-extract the digest for the control event and compare the received digest with its own extracted digest to determine if the control event has been tampered with.

[0097] However, the control events output by the multi-mode input subsystem to the security control are single-point events. Therefore, the security control's judgment on event security is based on these single-point events. Consequently, this method of security protection through the security control is limited to protecting single-point events and cannot guarantee the security of continuous events. As mentioned above, operations affecting event security, besides tampering with event content, also include copying and resending, adjusting event order, or constructing events. If the above-described digest extraction verification method is used, it can only verify whether the content of a single-point event has been tampered with, but it cannot determine whether other types of operations exist.

[0098] For example, in the case of a copy-and-retransmit operation, which involves copying a control event and forwarding it to a security control, as long as the event content is not tampered with, the copied control event will always be successfully verified during digest verification. Therefore, digest verification cannot determine whether a copy-and-retransmit operation has occurred.

[0099] For example, the operation of adjusting the order of events involves changing the order of multiple single events. However, even though the order has been adjusted, as long as the content of the single events is not tampered with, the digest verification method can still be successfully verified. Therefore, the digest verification method cannot determine whether the operation of adjusting the order of events has occurred.

[0100] For example, in the case of fabricated event operations, where the user does not interact with the event and another application on the electronic device creates a fictitious event, as long as the fabricated event is not tampered with during the forwarding process, the security control can eventually compare the digest extracted from the received event content with the digest carried by the event, and the verification will pass. Therefore, the digest verification method cannot determine whether a fabricated event operation has occurred.

[0101] To address this, embodiments of this application provide a security verification method for control events. For example... Figure 3A and Figure 3B The diagram shown is a schematic representation of a security verification process for a control event provided in an embodiment of this application. The multi-modal input subsystem processes the original control event and can then forward the resulting target control event to the target control, such as... Figure 3A The data is ultimately passed to control 4 through the relationship between user → application → control 4 within the application, or as follows: Figure 3B The data is ultimately passed to control 2 within the system application via the following relationship: user → application → external application → control 2 within the external application. Furthermore, as... Figure 3A and Figure 3BAs shown, in addition to forwarding target control events to the target control, the multimodal input subsystem also forwards target control events to the security verification subsystem, which stores a mirror image of the target control event. Finally, when a response is needed to a received sequence of control events (containing one or more target control events), the received sequence (referred to as the first event sequence) is compared with the control event sequence stored in the security verification subsystem (referred to as the second event sequence). If the comparison indicates that the first and second event sequences are identical, the first event sequence is deemed secure, and a response to it is permitted. Since the security verification subsystem can completely back up all control events output by the multimodal input subsystem, by comparing the stored control event sequence with the actual control event sequence received by the target control, various modifications to the control event sequence, i.e., continuous events, during the forwarding process can be verified. Therefore, this security verification method effectively verifies the security of continuous events received by the target control, thereby improving the event security of electronic devices.

[0102] In some embodiments, the method provided in this application can be applied to scenarios requiring secure interaction (hereinafter referred to as secure interaction scenarios). In these scenarios, when a control event involving security risks (such as a gesture event or a key event) needs to be responded to, a security verification subsystem can be used to perform security verification. The control event can only be responded to after the security verification subsystem confirms the security of the control event. The following uses a mobile phone as an example to list several possible application scenarios of the technical solution provided in this application. It should be noted that, in the following text, when referring to a control responding to a control event, it can be understood that the application process of the application containing the control executes the code related to the control event in the control to implement the function corresponding to the control event.

[0103] Application Scenario 1: In some scenarios, it is necessary to verify whether the control of the current electronic device is triggered by a real user, reducing the security risks brought by computer-simulated user operations. One way to verify whether a real user is controlling the electronic device is to use a control for dragging a pattern to verify the puzzle. The user is prompted to drag the pattern to complete the puzzle for verification. Only when the user's operation meets the conditions for successful puzzle completion will the next step be allowed. During the user's operation, the user's operation on the electronic device will generate a sliding event. Before the control responds to the sliding event, the security verification subsystem provided in this application embodiment can perform a security verification on the sliding event. The control can only respond to the sliding event after the security verification subsystem confirms the security of the sliding event. If the security verification subsystem confirms that the sliding event is unsafe, the control will not respond to the sliding event, or the control can also output a prompt message to inform the user that the electronic device currently has a security risk.

[0104] like Figure 4A The image shown illustrates the interface effect of a drag-and-drop pattern verification scenario. When verifying whether a genuine user is controlling an electronic device, a control for drag-and-drop pattern verification can be loaded, displaying the following... Figure 4A The interface 401 shown in (a) includes a button control 4012 and a display area 4011 for dragging patterns. The user can drag the button in the button control 4012 to control the movement of puzzle pieces 40111 displayed in the display area 4011. When the puzzle piece 40111 moves to the designated position, the puzzle is successfully completed. During this process, the user's operation of the electronic device will generate a sliding event. Before the button control 4012 responds to the sliding event, the security verification subsystem performs a security verification on the sliding event.

[0105] If the security verification subsystem indicates that the sliding event is safe, or that the sliding event is executable (or responsive), then the button control 4012 will respond to the sliding event, and the display effect in the display area 4011 will change accordingly, presenting as shown below. Figure 4A In the interface 402 shown in (b), compared to the interface 401, the position of the button in the button control 4012 will change, and the position of the puzzle piece 40111 will also change as the button moves.

[0106] If the security verification subsystem indicates that the sliding event is unsafe, or that it is not executable (or responsive), and the button control 4012 does not respond to the sliding event, then the display effect in the display area 4011 will not change. Alternatively, if the sliding event is indicated to be unsafe, a further prompt message can be displayed to the user. Figure 4A As shown in interface 403 (c), a prompt message 4031 will be output, prompting the user that "An insecure event has occurred; please perform a security check." Alternatively, a link to the security check can be provided, allowing the user to choose whether to navigate to the security check interface to scan the electronic device and identify any existing risks.

[0107] Application Scenario 2: In some scenarios, user operations on electronic devices may involve asset transfers, such as electronic payments and money transfers. Alternatively, user operations on electronic devices may involve personal privacy, such as entering account passwords. In these scenarios, if electronic devices are controlled through insecure control events, it will directly affect the user's property security and privacy security, making event security verification particularly necessary.

[0108] Taking money transfer as an example, when a user makes a transfer, they need to enter the transfer amount and confirm the transfer. If the transfer amount is entered or the transfer is confirmed arbitrarily through an insecure event, the user's property will be lost. Therefore, in this scenario, application developers can use a secure keyboard (or secure input control) during development. Correspondingly, in actual use cases, a secure input control can be loaded to ensure security when a user makes a transfer on the transfer page. The user's operations on the transfer interface will generate control events such as key events or click events. These control events ultimately need to be forwarded to the secure input control for response. The secure input control can perform security verification on the received control events through the security verification subsystem provided in this application embodiment. Only after the security verification subsystem confirms the security of the control event can the secure input control respond to the control event, that is, enter the transfer amount or initiate the transfer. If the security verification subsystem confirms that the control event is insecure, the secure input control will not respond to the control event, that is, refuse to enter the transfer amount or refuse to initiate the transfer, or the secure input control can also output a prompt message to inform the user that the electronic device currently has a security risk.

[0109] like Figure 4B The image shown is a schematic diagram of the interface in a money transfer scenario. When a user needs to transfer money to another user, the electronic device can display something like this. Figure 4B The interface 404 shown in (a) includes a transfer page 4042, which loads a secure input control 4041. Users can input transfer amounts and initiate transfers through the secure input control 4041. During this process, user operations on the electronic device (i.e., the display area corresponding to the secure input control 4041) will generate key events. Key events are generated for each key pressed in the secure input control 4041. Before the secure input control 4041 responds to a key event, a security verification subsystem performs a security verification on the key event. Since key events are single-point events, meaning each key event can be executed independently (e.g., pressing the number key "1" inputs 1), security verification can be triggered at some critical key events, such as... Figure 4B In the scenario shown, a security check can be triggered when the "transfer" button is pressed. In the security check process for key events, in addition to arbitrating the currently triggered key event, batch arbitration can also be performed on the currently triggered key event and other previous key events.

[0110] If the security verification subsystem indicates that the key events are secure, or that they are executable (or responsive), the secure input control 4041 will respond to the key event for the "Transfer" button, initiating the transfer process. Correspondingly, the display on the transfer page 4042 will change accordingly, presenting as shown below. Figure 4B The interface 405 shown in (b) displays a jump prompt message 4051, indicating that the transfer has been successfully initiated and the user is being redirected to the payment page.

[0111] If the security verification subsystem indicates that the key events are insecure or unresponsive based on the security verification results of the most recent key events, and the secure input control 4041 does not respond to the key event for the "Transfer" button, then the display on the transfer page 4042 will either remain unchanged, revert to the display before the most recent key events, or exit the transfer interface. Alternatively, if the key events are indicated to be insecure, further prompts can be displayed to the user. Figure 4B As shown in interface 406 (c), a prompt message 4061 will be output, prompting the user that "An insecure event has occurred; please perform a security check." Alternatively, a link to the security check can be provided, allowing the user to choose whether to navigate to the security check interface to scan the electronic device and identify any existing risks.

[0112] Application Scenario 3: In some scenarios, before a control receives a control event, the control event may be forwarded several times. The more participants in the forwarding process, the greater the possibility that the control event may be modified. For these scenarios, it is necessary to confirm the security of the control event before responding to it.

[0113] For example, since a mini-program runs within a host application framework, control events generated by user actions must be forwarded through the host application framework before reaching the mini-program, at which point the controls within the mini-program will respond. The host application framework is a third party to the mini-program, meaning it is not strictly secure. Therefore, the mini-program needs to perform security checks on received control events before deciding whether to respond. The controls within the mini-program can use the security verification subsystem provided in this application to perform security checks on the control events. Only after the security verification subsystem confirms the security of the control event can the controls within the mini-program respond to it. If the security verification subsystem determines that the control event is insecure, the controls within the mini-program will not respond to the control event, or they may output a prompt message indicating that the user's electronic device currently faces a security risk.

[0114] For example, application 1 may embed a page of another application 2. Control events generated by user actions on the page of application 2 need to be forwarded through application 1 before reaching the page of application 2, where the controls respond to these events. However, application 1 is a third party to application 2, and application 2 may not trust the control events forwarded by application 1. Therefore, the controls within the page of application 2 need to perform security verification on the received control events before deciding whether to respond. The controls within the page of application 2 can use the security verification subsystem provided in this embodiment to perform security verification on the control events. The control events can only be responded to after the security verification subsystem confirms their security. If the security verification subsystem confirms that the control events are insecure, it will not respond to them, or it may output a prompt message to alert the user that their electronic device currently faces a security risk.

[0115] The above description primarily uses touch operation as an example. However, in real-world scenarios, the multi-mode input subsystem can receive control events from different types of input devices. The security verification process for these control events described above is equally applicable and will not be elaborated further. In the embodiments of this application, execution and response are interchangeable; control execution of control events can be understood as control response to control events.

[0116] In this embodiment, insecure control events are mainly caused by modification operations or events constructed by other applications during the forwarding of control events. Modification operations include, but are not limited to, tampering with event content, copying and resending, and adjusting the order of events. By storing a mirror image of the control events through the security verification subsystem (security verification service) of this embodiment, security issues under various modification operation scenarios can be addressed, thereby improving the security of electronic devices. Several possible scenarios are illustrated below.

[0117] Scenario 1: Security verification in the case of event content tampering

[0118] Event content tampering refers to altering the content of an event during the control event forwarding process. For example, for a basic touch event, the event content may include the coordinates of the touch location; event content tampering could mean altering the coordinates of that basic touch event.

[0119] See Figure 5AAs shown, the click event output by the multimodal input subsystem includes two basic touch events: down and up. The coordinates of the down event are (x1, y1). The multimodal input subsystem forwards the down and up basic touch events sequentially to the application process. In addition, it forwards them sequentially to the security verification subsystem, which stores mirror images of the down and up basic touch events. Ultimately, the security verification subsystem stores the down and up basic touch events, with the down event's coordinates being (x1, y1). After being forwarded through the electronic device's internal message channel, the down and up basic touch events are finally received by the security controls within the application process. During this forwarding process, the event content may be tampered with, for example... Figure 5A As shown, the security control still receives the two basic touch events, down and up, but the coordinates of the down event have changed to (x2, y2).

[0120] The security control, through a gesture recognition system, can identify a single click event as a combination of the two basic touch events, down and up. The security control can then respond to this single click event. To enhance event security, before the security control or application process responds to the single click event, it can submit the received single click event to a security verification subsystem for security verification. The security verification subsystem compares its stored control event sequence with the single click event received by the security control. By comparing the coordinates of the down events, it can detect inconsistencies, indicating that the event content has been tampered with. The security verification subsystem outputs a corresponding security verification result, indicating that the single click event failed security verification, meaning the single click event is insecure or not allowed to be responded to.

[0121] Scenario 2: Security verification in the case of copying and retransmitting

[0122] Copy and resend refers to copying a control event during the control event forwarding process and then forwarding it to a control within the application.

[0123] See Figure 5BAs shown, the control events output by the multi-mode input subsystem are, in sequence, four basic touch events: down, up, down, and up. This means that the combination of these four basic touch events originally constitutes a double-click event. The multi-mode input subsystem not only forwards these four basic touch events sequentially to the application process but also sequentially to the security verification subsystem. The security verification subsystem can store images of the four basic touch events. After these basic touch events are forwarded through the electronic device's internal message channel, they are ultimately received by the security controls within the application process. During the forwarding process, there is a possibility of event duplication and retransmission, such as... Figure 5B As shown, the security control actually receives five basic touch events: down, down, up, down, and up.

[0124] The security control, through a gesture recognition system, identifies combinations of basic touch events as double-tap events, which the security control can then respond to. It should be noted that, for ease of description, this is still referred to as a double-tap event, but in real-world scenarios where duplication and retransmission occur, a double-tap event might be identified as other types of control events. To enhance event security, before the security control or application process responds to a double-tap event, the security control can submit the received double-tap event to a security verification subsystem for security verification. The security verification subsystem compares its stored control event sequence with the double-tap event received by the security control. By comparing, it can detect an extra "down" event, indicating potential event duplication and retransmission. The security verification subsystem outputs a corresponding security verification result, indicating that the double-tap event failed security verification, meaning the double-tap event is insecure or not allowed to be responded to.

[0125] Scenario 3: Security verification in the event sequence adjustment scenario

[0126] Event order adjustment refers to adjusting the order of single-point events included in a control event during the forwarding of a control event, or adjusting the order of multiple key events.

[0127] See Figure 5CAs shown, taking the adjustment of the order of key events as an example, the control event sequence output by the multimodal input subsystem includes five key events: pressing the "→" key, pressing the "→" key, pressing the "a" key, pressing the "tab" key, and pressing the "enter" key. A key event is an independently executable event. The multimodal input subsystem sends these five key events sequentially to the application process and the security verification subsystem. The security verification subsystem stores a mirror image of the control event sequence. The sequence stored by the security verification subsystem is consistent with the order of the five key events output by the multimodal input subsystem, namely, pressing the "→" key, pressing the "→" key, pressing the "a" key, pressing the "tab" key, and pressing the "enter" key. However, after these five key events are forwarded through the internal message channel of the electronic device, they are ultimately received by the security control within the application process. During the forwarding process, there is a possibility that the order may be adjusted, such as... Figure 5C As shown, the actual sequence of control events received by the security control is the five key events: pressing the "→" key, pressing the "→" key, pressing the "tab" key, pressing the "a" key, and pressing the "enter" key.

[0128] Each key event is independently executable. Therefore, for a key event, the security control can request a security verification subsystem to perform a security verification when predetermined conditions are met. For example, the predetermined conditions could be encountering a critical key event or the number of key events reaching a preset threshold. If the predetermined conditions are met, the security control can submit the sequence of control events it receives to the security verification subsystem for security verification. The security verification subsystem can compare its stored sequence of control events with the sequence of control events actually received by the security control. By comparing, it can detect that the order of the key events "a" and "tab" has been adjusted, thus identifying a possible operation involving event order manipulation. The security verification subsystem can output a corresponding security verification result, indicating that the security verification for that key event failed, meaning that the key event is unsafe or not allowed to be executed.

[0129] Scenario 4: Security verification under constructed events

[0130] Constructed events refer to control events that are not generated by user interaction but are fabricated by the electronic device's application or code, or are generated by a malfunction of the electronic device. Such control events are not forwarded through the multi-mode input subsystem, therefore the security verification subsystem will not receive these control events and store their corresponding images. Alternatively, even if such events are forwarded through the multi-mode input subsystem, the security verification subsystem can be configured not to receive control events from input devices other than the multi-mode input device or a specified input device. In this case, the security verification subsystem will not store images of such control events. Therefore, when a security control requests security verification, the verification will fail because no image of the control event can be found.

[0131] See Figure 5D As shown, application A directly sends five down events to application B. These five down events can be combined to form a long press event. Before the security control or application process within application B responds to this long press event, the security control can submit the received long press event to the security verification subsystem for security verification. Since the security verification subsystem has not received any control events, it cannot find a mirror image of the long press event, thus determining that an event construction operation may exist. The security verification subsystem can output the corresponding security verification result, indicating that the security verification of the long press event failed, meaning the long press event is insecure or not allowed to be responded to.

[0132] Based on the above scenarios, the security verification subsystem stores a mirror image of the control event and compares the control event actually received by the application process with the control event stored in its own memory before the control event is responded to, in order to verify whether the control event has been modified during the forwarding process, thereby verifying the security of the control event and improving the security of the electronic device.

[0133] It should be noted that the above scenarios are merely examples. In practical applications, there may be other situations where control events need to be modified, which are not listed one by one in the embodiments of this application.

[0134] In the above introduction, the electronic device can realize the security verification of control events. The following will explain the implementation principle of the security verification method for control events with reference to the accompanying drawings.

[0135] Please see Figure 6A This is a schematic diagram of a scenario provided in an embodiment of this application. Figure 6A As shown, the operating system provides multi-modal input services and security verification services. Multi-modal input services can be provided by, for example, by... Figure 1CThe multi-mode input subsystem shown provides the security verification service, which can be provided by, for example, a system such as... Figure 1C The security verification subsystem shown is provided. The electronic device also includes a first application, which can be any application within the electronic device. For example, it can be a system application provided by the operating system, a user-installed application, or a small program or lightweight application running within the host program; no specific restrictions are placed on this. In this embodiment, when the electronic device runs the first application, the first application can send a first event sequence targeting the first application's control to the security verification service to request the security verification service to perform event security verification on the first event sequence. Only when the security verification passes is a response to the first event sequence allowed.

[0136] Please see Figure 6B This is a flowchart illustrating a security verification method for control events provided in an embodiment of this application. This method can be applied to, for example... Figure 6A In the scenario shown, the method includes the following steps.

[0137] Step 601: The first application receives at least one control event. Alternatively, the target control of the first application receives at least one control event.

[0138] Control events, also known as input events, are used to control the application of an electronic device to perform a certain function. For example, a control event can be a single input action or a set of input actions performed by a user through an input device to control the application of the electronic device to perform a specific function. For instance, a control event is generated when a user interacts with a control on the application interface, and this control event is used to control the control to perform the corresponding function. Besides control events generated by user interaction, other applications may also generate control events; for example, a second application might construct control events and send them to a first application to control the first application's functions.

[0139] The target control can be any control loaded by the first application during its execution. When the electronic device runs the first application, its operating system runs the application process of that first application. This application process is an instance of a program running within the operating system of the electronic device. Each time the first application is launched, the operating system of the electronic device creates a new application process for it. When the operating system of the electronic device runs this application process, it can display the application interface of the first application on the display screen of the electronic device. This application interface can display one or more controls, which can be used by the user to interact with and achieve the corresponding functions. Different controls can achieve the same or different functions, and the target control can be any one of these one or more controls.

[0140] During the operation of the first application, the user can interact with the target control. During this process, the first application will receive at least one control event triggered by the interaction with the target control. It can be understood that a control event can be a single-point event, triggered by a momentary user action. As the user continues to interact, the target control will continuously receive control events. In other words, at least one control event can include multiple control events, and the target control can receive at least one control event through multiple receptions.

[0141] At least one control event can be sent by a multimodal input service. This service can receive control events triggered by user operations on the electronic device, process the control events, and output the processed control events to a first application. These control events can be used to control the first application to perform corresponding functions. Optionally, a control event can be a basic touch event, such as down, move, up, or cancel events. Alternatively, a control event can be a key event, which is a control event input by the user via a keyboard or keypad, which can be a physical keyboard or a soft keyboard.

[0142] Step 602: The first application sends a first event sequence to the security verification service. Accordingly, the security verification service can receive the first event sequence sent by the first application. The first event sequence includes at least one control event triggered for the target control. Alternatively, the first application can send the first event sequence to the security verification service, or the target control of the first application can send the first event sequence to the security verification service.

[0143] The first event sequence refers to the sequence of control events received by the first application, in which each control event is ordered according to the order of receipt.

[0144] In some embodiments, the first application may send the first event sequence to the security verification service when it determines that the first event sequence meets a first condition. The first condition may include one or more of the following:

[0145] (1) The first event sequence constitutes the gesture event associated with the target control. That is, when the first event sequence contains basic touch events, if the first event sequence is recognized as a gesture event by the gesture recognition system, the developer can bind at least one gesture event to the target control when developing the target control. These gesture events are the gesture events that the target control needs to respond to. If a gesture event associated with the target control is recognized, the first event sequence can be sent to the security verification service before responding to the gesture event to request the security verification service to perform security verification and assist in deciding whether to respond to the gesture event. The gesture event can be any gesture event.

[0146] (2) When the first event sequence is a sequence of key events, the first condition can be that the number of key events included in the first event sequence is greater than or equal to a first threshold. That is, for key events, key events can be submitted in batches.

[0147] (3) When the first event sequence is a sequence of key events, the first condition may be that the first event sequence includes a preset key event. The preset key event may also be called a critical key event. When a critical key event appears in the first event sequence, the first event sequence is sent to the security verification service.

[0148] Based on this implementation method, instead of checking each control event individually, all control events can be provided to the security verification service at the event execution point for security verification at once. This not only ensures event security but also guarantees interactive performance and reduces the processing burden on electronic devices.

[0149] In some implementations, the first application may proactively send the first event sequence to the security verification service. For example, the first application may call an interface provided by the security verification service to send the first event sequence to the security verification service. Alternatively, the security verification service may also monitor controls within the first application, and when it detects that a target control meets a first condition, it obtains the first event sequence from the first application.

[0150] For example, the first application can send a security verification request to a security verification service, which can indicate detailed information about the first event sequence. For instance, if the first event sequence comprises a gesture event, the detailed information can include one or more basic touch events that make up the gesture event. Each basic touch event can include its event content, such as event type, event trigger coordinates, and time trigger timestamp. If multiple basic touch events are included, the detailed information can also include the order of the multiple basic touch events. As another example, if the first event sequence is a sequence of key events, the detailed information can include the timing sequence of the occurrence of multiple key events.

[0151] Step 603: The security verification service determines that a second event sequence identical to the first event sequence has been stored.

[0152] In this embodiment, the multimodal input service can be used to synchronize each control event in at least one control event between the first application and the security verification service. That is, when the multimodal input service outputs a control event for a target control to the first application, the multimodal input service also synchronously sends the control event to the security verification service. The security verification service can store mirror images of these control events, and these control events can form a control event sequence (such as a second event sequence). In other words, for at least one control event received by the first application in step 601, when the multimodal input service outputs each control event in at least one control event to the first application, it also synchronously sends these control events to the security verification service. Thus, the security verification service can also receive at least one control event sent by the multimodal input service and store at least one control event according to the receiving order of the at least one control event.

[0153] In some embodiments, the security verification service may have one or more of the following capabilities:

[0154] (1) The security verification service only allows the storage of images of multi-mode control events from electronic devices. Multi-mode refers to the various types of input devices of an electronic device. Since user control events via multi-mode input are often processed by the multi-mode input service and then forwarded to the corresponding application, the security verification service only allows the storage of images of multi-mode control events from electronic devices. This means that the security verification service only allows the storage of images of control events from the multi-mode input service.

[0155] In this way, control events that are not triggered by the user through multi-mode will not be stored in the security verification service. If security verification is subsequently performed on control events that are not triggered by the user through multi-mode, the security verification will fail because there is no corresponding image.

[0156] (2) The security verification service can store a mirror image of the multimodal control event. That is, when the multimodal input service forwards the control event to the application, it also forwards the control event to the security verification service.

[0157] When the security verification service receives a first event sequence from the first application, it can compare the first event sequence with its own stored control event sequences to determine whether a second event sequence identical to the first event sequence has been stored. The sequence of control events stored by the security verification service is called the second event sequence. Therefore, it can also be described as the security verification service determining whether the first event sequence and the second event sequence are the same. For example, the security verification service can determine whether the order, position, and content of events in the first event sequence and the second event sequence are the same.

[0158] It should be noted that the second event sequence and the first event sequence are used for ease of distinction and do not restrict the differences in the content of the events. The first event sequence refers to the control events actually received by the first application, while the second event sequence refers to the sequence of control events stored by the security verification service.

[0159] Step 604: The security verification service sends the first security verification result to the first application, indicating that the security verification has passed.

[0160] If the security verification service has stored a second event sequence that is exactly the same as the first event sequence, it indicates that the first event sequence is a control event from a multi-mode system, and that each control event in the first event sequence has not been modified during the internal message channel forwarding process. Therefore, the security verification for the first event sequence passes, and the security verification service generates a first security verification result and sends it to the first application. The first security verification result may indicate one or more of the following: security verification passed, the first event sequence is secure, the first event sequence has not been modified, execution of the first event sequence is permitted, or response to the first event sequence is permitted.

[0161] Step 605: The first application responds to the first event sequence based on the first security verification result to realize the first function of the target control.

[0162] The first function is the function implemented when the first application or target control responds to the first event sequence, and there are no specific restrictions on the first function.

[0163] For example, the first event sequence is a gesture event, which may include at least two basic touch events. When developing the target control, the developer can define the correspondence between the gesture events and the first function for that target control. Then, the first application can respond to the gesture event to implement the first function in the target control. For an example, see [link to example]. Figure 4A As shown, the first event sequence is a sliding event. If the security check passes, the application can respond to the sliding event by sliding a puzzle piece. Alternatively, the first event sequence could be a key event sequence, which may include at least two key events. In this case, the first application responds to the first event sequence by responding to the key key events within that sequence to achieve the first function. See also [example description]. Figure 4B As shown, the first event sequence is the key event sequence. If the security check passes, the transfer process can be initiated by responding to the key event for the "transfer" button.

[0164] In one implementation, the target control is the control that actually responds to the first event sequence. After the target control determines that the security check has passed based on the first security check result, the target control can directly respond to the first event sequence to implement the first function. That is, the application process of the first application executes the code of the target control to implement the first function.

[0165] In another implementation, the target control can be a dedicated control for security verification, while the first event sequence should actually be responded to by another control. After the target control determines that the security verification has passed based on the first security verification result, the target control can forward the first event sequence to the actual responding control, and the control responds to the first event sequence to realize the first function.

[0166] Based on the above implementation, a mirror image of the control events forwarded by the multimodal input service can be stored through a security verification service. In this way, the security verification service can compare the control events actually received by the first application with its stored control events, achieving security verification of the control events actually received by the first application. Only when the security verification passes will the control event sequence be responded to, thereby improving the security of the electronic device. Since this method can store complete information about the control events forwarded by the multimodal input service, no matter what modifications are made during the control event forwarding process, this method will fail the security verification. Therefore, the method of this application embodiment can meet the security verification requirements in various situations.

[0167] In some embodiments, the actual sequence of control events received by the first application may also be insecure, in which case the verification of the control event sequence will fail. See also Figure 6C This is another flowchart illustrating the security verification method for control events provided in this application embodiment. This method can also be applied to, for example... Figure 6A In the scenario shown, the method includes the following steps.

[0168] Step 611: The first application sends the third event sequence to the security verification service. Accordingly, the security verification service can receive the third event sequence sent by the first application.

[0169] The third event sequence includes at least one control event triggered by the target control. The first application sends the third event sequence to the security verification service, or alternatively, the target control of the first application sends the third event sequence to the security verification service.

[0170] It should be noted that the third event sequence and the first event sequence are used for ease of distinction and do not restrict the differences in the content of the events. For example, the third event sequence can be the first event sequence, or the third event sequence can include control events received before or after the first event sequence.

[0171] Step 612: The security verification service determines that it does not store a fourth event sequence that is the same as the third event sequence. Alternatively, the security verification service determines that the control event sequence it stores is different from the third event sequence.

[0172] When the security verification service receives a third event sequence, it can compare it with its own stored control event sequences to determine whether a fourth event sequence identical to the third event sequence has already been stored. For example, if the security verification service has already stored a sequence of control events called a fifth event sequence, it can also be described as the security verification service determining whether the third and fifth event sequences are the same. For instance, the security verification service can determine whether the order, position, and content of events in the third and fifth event sequences are identical.

[0173] Steps 611 and 612 can be found in the foregoing. Figure 6B The descriptions of the corresponding steps in the illustrated embodiments will not be repeated here.

[0174] Step 613: The security verification service sends a second security verification result to the first application, indicating that the security verification failed.

[0175] If a fourth event sequence identical to the third event sequence is not stored, the security check on the third event sequence will fail, and the security check service will generate a second security check result. The second security check result may indicate one or more of the following: security check failed, the third event sequence is insecure, the third event sequence poses a security risk, the third event sequence has been modified, execution of the third event sequence is not permitted, or response to the third event sequence is not permitted.

[0176] There are several possible reasons why a fourth event sequence that is completely identical to the third event sequence is not stored. For example, the security verification service may store zero control events. That is, the security verification service does not store any control events. This could be because the control events in the third event sequence were constructed by a second application, in which case the third event sequence would not be stored in the security verification service. Another example is that the security verification service has stored a fifth event sequence, and the third event sequence is different from the fifth event sequence. Here, to distinguish a fourth event sequence that is completely identical to the third event sequence, we use the fifth event sequence to represent the control event sequence stored by the security verification service. This could be because the control events in the third event sequence were modified when forwarded through the internal message channel of the electronic device, such as by tampering with the event content, adjusting the event order, or copying and retransmitting. In this case, although the security verification service stores the fifth event sequence, because the third event sequence has been modified and is different from the fifth event sequence, the security verification will fail.

[0177] The third event sequence differs from the fifth event sequence in one or more of the following ways: the number of control events in the third event sequence differs from the number of control events in the fifth event sequence stored by the security verification service; the order of control events in the third event sequence differs from the order of control events in the fifth event sequence; or, the event content of any control event in the third event sequence differs from the event content of the corresponding control event in the fifth event sequence.

[0178] For example, the third event sequence includes M control events, and the fourth event sequence includes P control events, where M and N are both positive integers. The third event sequence differs from the fifth event sequence in one or more of the following ways: the values ​​of M and P are different; the order of the M control events is different from the order of the P control events; the event information of any one of the M control events is different from the event content of the corresponding control event in the P control events.

[0179] Optionally, the security verification service can determine the differences between the third and fifth event sequences by comparing them. In this case, the second security verification result may also indicate one or more of the following: the number of control events stored by the security verification service is zero; the number of control events in the third event sequence differs from the number of control events in the fifth event sequence stored by the security verification service; the order of control events in the third event sequence differs from the order of control events in the fifth event sequence; or, the event content of any control event in the third event sequence differs from the event content of the corresponding control event in the fifth event sequence. This facilitates the identification of security risks.

[0180] Step 614: Based on the second security check result, the first application either refuses to respond to the third event sequence or outputs a security warning message. For example... Figure 4A and Figure 4B If the security check fails, the system can prompt the user with the message "An unsafe event has occurred. Please perform a security check."

[0181] Based on the above implementation, a mirror image of the control events forwarded by the multi-mode input service can be stored through a security verification service. In this way, the security verification service can compare the control events actually received by the first application with the control events stored in itself to achieve security verification of the control events actually received by the first application, so as to meet the security verification requirements in various situations. Furthermore, when the security verification fails, the first application will not respond to the control event sequence, which can improve the security of electronic devices.

[0182] In one implementation, after comparing the second, fourth, or fifth event sequences, the security verification service can mark the second, fourth, or fifth event sequences as verified, thus rendering them unusable for subsequent security verification processes. Alternatively, the security verification service can store the second, fourth, or fifth event sequences for a single use; that is, after comparing the second, fourth, or fifth event sequences, the security verification service can delete them, thereby saving storage space in the electronic device.

[0183] In one implementation, the security verification service may not clear the second, fourth, or fifth event sequence, but instead clear all stored control events uniformly when the target control indicates that security verification is not required (e.g., the target control exits loading).

[0184] In one implementation, the security verification service can also record the security verification process, which makes it convenient to trace previous unsafe events when subsequent security risk investigation is needed.

[0185] Please see Figure 7 This is another flowchart illustrating the security verification method for control events provided in this application embodiment. This method can be applied to, for example... Figure 6A In the scenario shown, the method includes the following steps:

[0186] Step 701: The first application loads the target control.

[0187] For example, if a user performs an operation to open a first page of a first application, and that first page contains a target control, then the application process of the first application will respond to the operation and open the first page. During this process, the application process of the first application will load the target control.

[0188] From the perspective of security requirements or security risks, all controls can be divided into ordinary controls and secure controls. Ordinary controls refer to controls with low security requirements or low security risks, while secure controls are designed for scenarios with high security requirements. In these scenarios, responding to unsafe control events could cause significant losses to users; therefore, secure controls have higher security requirements for control events.

[0189] In some scenarios, considering that performing security checks on all control events received by all controls might consume significant processing resources of the electronic device, resulting in high power consumption and potentially impacting the operation of other applications, security checks can be performed only in scenarios with high security requirements. This not only ensures event security to a certain extent but also maintains the operating performance of the electronic device and reduces power consumption. In other words, the method of this application embodiment can be applied to secure interaction scenarios in electronic devices. In these scenarios, when responding to control events involving security risks, security checks can be performed, and the control event can only be responded to if the security check passes. See also... Figure 7 As shown, the target control can be a secure control. When developing the first application, the developer can selectively introduce secure controls. When a secure control is loaded into the application's interface, subsequent processes can be executed to perform security checks on control events.

[0190] Step 702: The first application sends an event registration request to the security verification service, which instructs the first application to load the target control.

[0191] After the target control starts, i.e., after the target control is successfully loaded or has completed initialization, the first application can send an event registration request to the security verification service. This event registration request can indicate that the target control has been loaded, loaded successfully, or completed initialization, aiming to notify the security verification service that it can begin storing control event images. For example, the security verification service can provide an interface, such as an event registration interface, which the first application can call to register events. In other words, the security verification service does not normally store control event images; it only begins storing control event images after event registration is performed for a target control (such as a security control).

[0192] In some embodiments, the purpose of registering events for the target control is also to notify the security verification service of at least one control event that the target control is interested in, so that the security verification service can perform event management. For example, the target control may bind one or more control events (such as gesture events), and the at least one control event that the target control is interested in may be some or all of the one or more control events.

[0193] Optionally, at least one control event may include at least one gesture event, in which case the event registration request may include information about at least one gesture event, such as an event identifier (identity, ID). Alternatively, at least one control event may also include a key event, in which case the event registration request may indicate whether the key event should be monitored and backed up. If it indicates that key events should be monitored and backed up, it may mean that all key events should be monitored and backed up; if it indicates that key events should not be monitored and backed up, it may mean that none of the key events should be monitored and backed up. In one example, key events may be monitored and backed up by default, in which case the event registration request may not indicate this. In another example, the event registration request may also indicate at least one critical key event, meaning that these critical key events should be monitored and backed up.

[0194] Step 703: The security verification service stores the control events sent by the multimodal input service.

[0195] In some embodiments, if the event registration request includes at least one control event, the security verification service can also register the event based on at least one control event. When the first application registers the event of the target control with the security verification service, it is equivalent to providing the atomic information or capability information of the target control to the security verification service for registration, facilitating the management of the control by the security verification service.

[0196] Step 704: The multimodal input service synchronously forwards control events to the first application and security verification service.

[0197] The multi-mode input service can receive raw control events generated by users operating various types of input devices on electronic devices, process these raw control events, and then forward them to the first application and the security verification service. For example, the multi-mode input service can forward control events to the first application through the electronic device's internal message channel, and at the same time, the multi-mode input service will also forward the control events to the security verification service.

[0198] The sequence of control events actually received by the first application is called the first event sequence. Since the control events included in the first event sequence need to be forwarded through an internal message channel, there may be one or more forwarding processes. Therefore, there is a possibility that the first event sequence received by the first application may be inconsistent with the control event sequence actually output by the multimodal input service.

[0199] Step 705: The security verification service stores the control events sent by the multimodal input service in sequence.

[0200] That is, after the security verification service starts storing control events, the security verification service will record all control events output by the multi-modal input service to facilitate subsequent security verification.

[0201] Step 706: The first application sends a first event sequence to the security verification service. Accordingly, the security verification service can receive the first event sequence sent by the first application. The first event sequence includes one or more control events actually received by the first application.

[0202] Step 707: The security verification service determines whether a second event sequence identical to the first event sequence has been stored.

[0203] Step 708: If the result of step 707 is yes, the security verification service sends a first security verification result to the first application. The first security verification result indicates that the security verification has passed. Alternatively, the first security verification result may also indicate that the security verification service has stored a second event sequence that is the same as the first event sequence.

[0204] Step 709: The first application responds to the first event sequence based on the first security verification result to realize the first function of the target control.

[0205] Step 710: If the result of step 707 is negative, the security verification service sends a second security verification result to the first application, indicating that the security verification failed.

[0206] Step 711: Based on the second security check result, the first application either refuses to respond to the first event sequence or outputs a security warning message.

[0207] The process of steps 706 to 712 above is the same as Figure 6B Steps 601 to 607 in the illustrated embodiment are similar, therefore please refer to... Figure 6B The descriptions of the corresponding parts in the illustrated embodiments will not be repeated here.

[0208] Step 712: The first application sends an event deregistration request to the security verification service. Correspondingly, the security verification service receives the event deregistration request sent by the first application. This event deregistration request instructs the target control to exit loading.

[0209] The target control may exit loading because it was canceled or closed, the page containing the target control was closed, or the primary application terminated. In this case, after the target control exits loading, there is no need to perform security checks on the control events that the target control needs to respond to. The primary application can then notify the security check service, which can then stop recording control events to reduce the power consumption of the electronic device.

[0210] Step 713: The security verification service responds to the event cancellation request and stops storing control events sent by the multimodal input service.

[0211] Based on the above implementation, the security verification service can store the sequence of control events from the time the target control is started until it is unloaded. This allows for security verification of the target control's control events throughout its lifecycle, ensuring security requirements in secure interaction scenarios. When the target control is not loaded, the security verification service does not record or verify control events, reducing the burden on electronic devices and lowering their functional and performance consumption.

[0212] The following section uses security verification for gesture events as an example to introduce the security verification process for control events. (See also...) Figure 8A The diagram shown is a schematic representation of another scenario provided by an embodiment of this application. Figure 8A As shown, when the electronic device runs the first application, after the user's interactive operation is converted into basic touch events by the multi-modal input service, the multi-modal input service forwards the basic touch events one by one to the first application and the security verification service. When it is determined that the triggering condition of the gesture event is met, that is, when the sequence of first events actually received by the first application constitutes the first gesture event, the first application requests the security verification service to perform security verification on the first gesture event, so as to determine whether to respond to the first gesture event based on the security verification result.

[0213] See Figure 8B The diagram shown is a flowchart of a security verification method for gesture events provided in an embodiment of this application. The method includes the following steps.

[0214] Step 801: The first application loads the security control.

[0215] Step 802: The first application sends an event registration request to the security verification service.

[0216] Step 803: The security verification service begins storing a mirror image of the underlying touch events.

[0217] Step 804: The multi-modal input service forwards basic touch events one by one to the first application and the security verification service, for example... Figure 8AThe basic touch events 1 to N are shown.

[0218] Step 805: The security verification service stores a mirror image of the underlying touch events. For example, the security verification service stores a sequence of underlying touch events, which includes underlying touch events 1 to N sent by the multimodal input service.

[0219] Step 806: The first application determines whether the triggering conditions for the gesture event are met. If not, it continues to wait until the triggering conditions for the gesture event are met.

[0220] The triggering condition for a gesture event is met when the first event sequence received by the first application is recognized as a first gesture event by the gesture recognition system. Alternatively, the triggering condition for a gesture event can also be understood as the first application being about to respond to a gesture event. That is, in this embodiment, when a gesture event is triggered, a security verification service can be requested to perform a security verification on the gesture event.

[0221] Step 807: If the result of step 806 is yes, the first application sends the first gesture event to the security verification service.

[0222] That is, when the triggering conditions of the first gesture event are met, the first application can send the detailed information of the first gesture event to the security verification service. In this way, based on this implementation method, it is not necessary to check each event one by one. Instead, all the information of the gesture event is provided to the security verification service at the execution point of the gesture event for security verification at one time. This not only ensures the security of the event, but also ensures the interactive performance and reduces the processing burden of electronic devices.

[0223] Step 808: The security verification service compares the first gesture event with its own stored basic touch event sequence to determine whether the first gesture event is the same as its stored basic touch event sequence. If the first gesture event is the same as the basic touch event sequence stored by the security verification service, then the number, order, and content of the basic touch events included in the first gesture event are exactly the same as the number, order, and content of the basic touch events stored by the security verification service.

[0224] Step 809: If the result of step 808 is yes, the security verification service sends the first security verification result to the first application, and the first security verification result indicates that the security verification is successful.

[0225] Step 810: The first application responds to the first gesture event based on the first security verification result to realize the first function of the security control.

[0226] like Figure 8AAs shown, the basic touch event sequence stored by the security verification service includes four basic touch events: down, up, down, and up. This basic touch event sequence constitutes a double-click event. (See [link / reference]). Figure 8A In Example 1, the first gesture event received by the first application is also the four basic touch events: down, up, down, and up. The order of the basic touch events is consistent. If the security verification service further confirms that the content contained in each basic touch event is also consistent, then the security verification of the first gesture event passes, and the first application can respond to the first gesture event.

[0227] Step 811: If the result of step 808 is negative, the security verification service sends a second security verification result to the first application, indicating that the security verification failed.

[0228] Step 812: Based on the second security verification result, the first application either refuses to respond to the first gesture event or outputs a security prompt message.

[0229] See Figure 8A Example 2: The first gesture event received by the first application includes five basic touch events: down, up, down, down, and up. Since there is an additional "down" event, the security check for this first gesture event will fail, and the first application can refuse to respond to it. Alternatively, it can be handled as follows: Figure 4A and Figure 4B The method can prompt the user that "an unsafe event has occurred, please perform a security check".

[0230] for Figure 8B For each step of the embodiment, please refer to Figure 7 The corresponding steps will not be elaborated upon here.

[0231] Based on the above implementation, at the event execution point of a gesture event, the details of the gesture event recorded in the application process can be provided to a security verification service. The security verification service is then invoked to perform security verification. This service verifies the event details, determining whether the event sequence, location, and content are identical to its own backup. Finally, based on the security verification result, it decides whether to respond to the gesture event. Compared to related technologies where security controls judge each event individually, this application embodiment uses a batch event security verification method. It eliminates the need to extract a summary for each event, instead performing security verification by comparing events. This reduces the burden on electronic devices and lowers their functional and performance consumption. Furthermore, by comparing gesture events, this application embodiment can meet the security verification needs of various scenarios, such as verifying the event sequence for consecutive events.

[0232] The following section uses the security verification of key events as an example to introduce the security verification process for control events. See also... Figure 9A The diagram shown is a schematic representation of another scenario provided by an embodiment of this application. Figure 9A As shown, when the electronic device runs the first application, the user sequentially inputs each key event in the second key event sequence. The multi-modal input service forwards each key event sequentially to the first application and the security verification service. The first application actually receives each key event in the first key event sequence. When the triggering condition of a key event is met, the first application requests the security verification service to perform event security verification on the first key event sequence to determine whether to respond to the first key event sequence based on the security verification result.

[0233] See Figure 9B The diagram shown is a flowchart of a key event security verification method provided in an embodiment of this application. The method includes the following steps.

[0234] Step 901: The first application loads the security control.

[0235] Step 902: The first application sends an event registration request to the security verification service, which indicates that the security control has been loaded.

[0236] If the event registration request indicates that the security control has been loaded, it can be assumed that the security control needs to monitor and back up key events by default.

[0237] Step 903: The security verification service stores a mirror image of the underlying touch events. That is, after event registration, it begins storing a mirror image of the underlying touch events.

[0238] Step 904: The multimodal input service synchronously forwards the key event to the first application and the security verification service.

[0239] Step 905: The security verification service stores a mirror image of the key events. That is, the security verification service records the received key events sequentially, such as... Figure 9A The second key event sequence is shown.

[0240] Step 906: The first application determines whether the triggering conditions for the key event are met. If not, it continues to wait until the triggering conditions for the key event are met.

[0241] Because key events and gesture events are handled differently, each key event has a specific, independent action within a particular scenario. For example, in English input mode, pressing "a" inputs the letter 'a'. Therefore, the security verification methods for key events differ from those for gesture events. The triggering conditions for a key event can include one or more of the following:

[0242] (1) The number of key events reaches a first threshold. The first threshold can be any value, and there are no specific restrictions on its value. For example, if the first threshold is 10, when the first application receives 10 key events, it is determined that the triggering condition for the key event is met. In other words, the first application can request the security verification service to perform a security verification every 10 key events.

[0243] (2) A critical key event has been triggered. This means the first application can determine whether the triggering conditions for a key event are met based on whether a critical key event has been triggered or whether a critical key event has been received. If a critical key event has been triggered, the triggering conditions are confirmed. For example, a critical key event could be an enter event, a delete event, or an exit event. In addition, the first application can determine the critical key event based on specific security requirements.

[0244] Step 907: If the result of step 906 is yes, the first application sends the first key event sequence to the security verification service. That is, the first event sequence is the first key event sequence.

[0245] When the triggering conditions of a key event are met, the first application can organize the received key events and send them to the security verification service. That is, the first application sends a first key event sequence to the security verification service, which may include at least one key event recently received by the first application.

[0246] Step 908: The security verification service determines whether the first key event sequence is the same as the stored second key event sequence.

[0247] Since the multimodal input service synchronously forwards the key events to the security verification service, the security verification service also synchronously stores the key event sequence, i.e., the second key event sequence. Therefore, the security verification service can determine whether the first key event sequence has been modified by comparing the first key event sequence and the second key event sequence.

[0248] Optionally, for better user experience, an allowable tolerance range can be set for key events. For example, if the comparison result between the first and second key event sequences is still within the tolerance range, the security check of the first key event sequence is considered to have passed. However, if the comparison result exceeds the tolerance range, the security check of the first key event sequence is considered to have failed. For instance, if the first and second key event sequences only have two key events whose positions have been swapped, the security check of the first key event sequence can be considered to have passed. However, if more than two key events are misplaced, the security check of the first key event sequence is considered to have failed.

[0249] Step 909: If the result of step 908 is yes, the security verification service sends the first security verification result to the first application, and the first security verification result indicates that the security verification is successful.

[0250] Step 910: The first application responds to the first key event sequence based on the first security verification result to implement the first function.

[0251] It's important to note that while each key event is executable independently, each key event only produces a corresponding display effect on the screen. The implementation of the first function may require a confirmation operation after multiple key events have occurred to ultimately achieve the first function. Therefore, responding to the first key event sequence here can refer to responding to the last one or more key events (such as the confirmation operation) in the first key event sequence to achieve the first function. Alternatively, it can be understood as, after the final confirmation operation, the first function can be implemented based on these key events in the first key event sequence.

[0252] For example, in the scenario of inputting text in the first application, the first function is the text input function. The user can display candidate text by performing operations in the input box. That is, each operation of the user has a display effect. However, the candidate text needs to be selected and confirmed by the user before it can be entered into the input box. That is, the user selects the text to be entered from the candidate text. For example, the selection operation can be pressing the corresponding number key or the space key. Therefore, responding to the first key event sequence can refer to responding to the selection operation to enter text in the input box.

[0253] For example, in the scenario of account and password login in the first application, the first function is the user login function. The first key event sequence can include multiple key events for the user to enter their account and password, as well as a key event for final confirmation of login (such as pressing the enter key). Then, responding to the first key event sequence can refer to responding to the key event for confirming login, and submitting the entered account and password to the backend server in the login request.

[0254] See Figure 9A and Figure 9C As shown, Figure 9C This is a schematic diagram of an interface effect. The user actually inputs the second key event sequence, i.e., the entered account is "1234", the Tab key switches to the password input box, and the entered password is "Abc". If the first application receives the first key event sequence as... Figure 9A Example 1 shows the interface as follows: Figure 9C As shown in (a), since the first key event sequence and the second key event sequence stored by the security verification service are completely consistent, the security verification is passed, and the key event in the first key event sequence can be responded to, and a login request can be sent to the server.

[0255] Step 911: If the result of step 908 is negative, the security verification service sends a second security verification result to the first application, indicating that the security verification failed.

[0256] Step 912: Based on the second security verification result, the first application either refuses to respond to the first key event sequence or outputs a security warning message.

[0257] "Refuse to respond to the first key event sequence" can mean refusing to respond to the last one or more key events in the first key event sequence (such as a confirmation operation). Alternatively, it can be understood as refusing to respond to all key events in the first key event sequence, for example, canceling the display of an already presented effect.

[0258] For example, in the scenario described above where text is entered in the first application, no text will be entered into the input box. Furthermore, already presented candidate text can be hidden. Alternatively, another approach could be used... Figure 4A and Figure 4B The method can prompt the user that "an unsafe event has occurred, please perform a security check".

[0259] For example, in the scenario described above where account and password login is performed in the first application, no corresponding login request will be generated. Furthermore, the already entered account and password can be revoked from display. For instance, if the first application receives the first key event sequence... Figure 9A Example 2 shows the interface as follows: Figure 9C As shown in (b), and because the first key event sequence and the second key event sequence stored by the security verification service are inconsistent, the security verification will fail. The system can refuse to respond to the key events in the first key event sequence, will not send a login request to the server, and can revoke the username and password entered in the key events of the first key event sequence, as shown in [image / description]. Figure 9C The interface shown in (c) is an example. Alternatively, it can be used as shown in [example]. Figure 4A and Figure 4B The method can prompt the user that "an unsafe event has occurred, please perform a security check".

[0260] Based on the above implementation, when a key event meets predetermined conditions, the key event details recorded in the application process can be provided to a security verification service. The security verification service then performs a security verification, verifying the event details and determining whether the event sequence, content, etc., are identical to its own backup. The first application can then decide whether to ultimately respond to the key event based on the security verification result. Compared to related technologies where security controls judge each key event individually, which fails to verify the order of key events, this application embodiment uses a batch key event security verification method, which can verify the event order. Furthermore, this application embodiment does not require extracting a summary for each event; instead, it performs security verification by comparing events, reducing the burden on electronic devices and lowering their functional and performance consumption.

[0261] The security verification method for control events provided in this application can perform security verification on control events before the event execution point, ensuring consistency with the events output by the multimodal input service and improving the security of control events. For example, for gesture events, which are generated by the combination of multiple basic touch events, the solution in this application can verify all basic touch events of the gesture event before triggering the gesture action, ensuring consistency with the basic touch events output by the multimodal input service and ensuring the security of the gesture event. Similarly, for key events, multiple key events can be verified in batches to ensure consistency with the events output by the multimodal input service. Furthermore, the solution in this application can perform comprehensive verification of the time, location, type, and order of event generation, ensuring consistency with the events output by the multimodal input service in all aspects, comprehensively ensuring the security of control events. In addition to ensuring security requirements, the solution in this application further ensures interactive performance. That is, instead of checking each event individually, this solution provides all events to the security verification service at once for unified verification at the event execution point. This batch event arbitration method reduces the performance loss caused by judging each event individually in related technologies, improving interactive performance and thus enhancing the interactive experience of the security controls.

[0262] In the above description, the electronic device includes a security verification subsystem (or security verification service). In this embodiment, the security verification service may be configured pre-installed at the factory or installed by the user after the electronic device leaves the factory. Taking the user installing the security verification service in the electronic device as an example, the following will combine... Figure 10 This explains the development, deployment, and installation process of the security verification service.

[0263] Please see Figure 10 This is a schematic diagram illustrating the process of developing, packaging, and installing a security verification service provided in one embodiment of this application onto an electronic device. Figure 10 As shown, during the packaging process of the customer system, the developer obtains the installation package 1000 of the security verification service through the development platform.

[0264] In some embodiments, the installation package 1000 of the security verification service may include an installation file 1010 for the security verification service. The installation file 1010 includes the basic files required for the normal operation of the security verification service.

[0265] In some embodiments, such as Figure 10 As shown, after the development platform obtains the security verification service installation package 1000, it can publish the installation package 1000 to the application market. After the application market publishes the installation package 1000, electronic devices can download the installation package 1000 from the application market, thus installing the security verification service on the electronic device.

[0266] In some embodiments, developers may distribute the security verification service installation package 1000 in some applications (such as mobile security managers) or systems. That is, the security verification service can be downloaded as a feature of the application or selected as a feature of the operating system. For example, as a feature of the operating system, the security verification service may be included in new versions of the operating system. After a new version of the operating system is released, users can choose to update to the new version of the operating system, and then the security verification service will be installed in the electronic device.

[0267] Figure 11 This is a schematic diagram of the structure of the electronic device 1100 provided in an embodiment of this application. The electronic device 1100 can be the electronic device with a multi-mode input subsystem and a security verification subsystem as described above. For example... Figure 11 As shown, the electronic device 1100 may include: one or more processors 1101; one or more memories 1102; a communication interface 1103; and one or more computer programs 1104. These devices can be connected via one or more communication buses 1105. The one or more computer programs 1104 are stored in the memory 1102 and configured to be executed by the one or more processors 1101. The one or more computer programs 1104 include instructions. For example, when the electronic device 1100 is the electronic device with a multi-mode input subsystem and a security verification subsystem as described above, the instructions can be used to perform relevant steps of the electronic device as in the corresponding embodiments above, such as executing... Figure 6B , Figure 7 , Figure 8B , Figure 9BThe relevant steps. Communication interface 1103 is used to enable communication between electronic device 1100 and other devices, such as a transceiver.

[0268] The methods provided in the embodiments of this application above are described from the perspective of an electronic device as the executing entity. To implement the functions of the methods provided in the embodiments of this application above, the electronic device may include hardware structures and / or software modules, implementing the above functions in the form of hardware structures, software modules, or a combination of hardware structures and software modules. Whether a particular function is executed in the form of hardware structures, software modules, or a combination of hardware structures and software modules depends on the specific application and design constraints of the technical solution.

[0269] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)). Where there is no conflict, the solutions in the above embodiments can be combined.

[0270] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0271] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0272] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0273] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0274] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A security verification method for control events, characterized in that, Applied to electronic devices, the method includes: The security verification service of the electronic device receives a first event sequence sent by a first application of the electronic device, the first event sequence including at least one control event for a target control within the first application; The security verification service determines that a second event sequence identical to the first event sequence has been stored. The second event sequence is a mirror image of the control event output by the multimodal input service of the electronic device. The multimodal input service is used to output the control event triggered by the user's operation on the electronic device to the first application. The control event is used to control the first application to perform the corresponding function. The security verification service sends a first security verification result to the first application, which indicates that the security verification of the first event sequence has passed.

2. The method according to claim 1, characterized in that, The method further includes: The security verification service receives a third event sequence sent by the first application, the third event sequence including at least one control event for the target control; The security verification service determines that a fourth event sequence identical to the third event sequence is not stored. The security verification service sends a second security verification result to the first application; wherein the second security verification result is used to indicate that the security verification of the third event sequence failed.

3. The method according to claim 2, characterized in that, The security verification service determines that no fourth event sequence identical to the third event sequence is stored, including: The security verification service determines that the number of stored control events is zero; or, The security verification service determines that a fifth event sequence has been stored, and that the third event sequence is different from the fifth event sequence.

4. The method according to claim 3, characterized in that, The third event sequence differs from the fifth event sequence, including one or more of the following: The number of control events in the third event sequence is different from the number of control events in the fifth event sequence; The order of the control events in the third event sequence is different from the order of the control events in the fifth event sequence; The event content of any control event in the third event sequence is different from the event content of the corresponding control event in the fifth event sequence.

5. The method according to any one of claims 1 to 4, characterized in that, Before the security verification service determines that a second event sequence identical to the first event sequence has been stored, the method further includes: The security verification service receives at least one control event sent by the multimodal input service; wherein, the second event sequence includes the at least one control event, and the multimodal input service is used to synchronize each of the at least one control event between the first application and the security verification service; The security verification service stores the at least one control event in the order in which the at least one control event is received.

6. The method according to claim 5, characterized in that, Before the security verification service stores the at least one control event in the order in which the at least one control event is received, the method further includes: The security verification service receives an event registration request sent by the first application, and the event registration request instructs the first application to load the target control; The security verification service responds to the event registration request and stores at least one control event sent by the multimodal input service.

7. The method according to claim 6, characterized in that, After the security verification service receives the event registration request sent by the first application, the method further includes: The security verification service receives an event cancellation request sent by the first application, and the event cancellation request instructs the target control to exit loading; In response to the event cancellation request, the security verification service stops storing at least one control event sent by the multimodal input service.

8. The method according to any one of claims 1 to 7, characterized in that, The target control is a security control.

9. The method according to any one of claims 1 to 8, characterized in that, The first event sequence is a gesture event, which includes at least two basic touch events; or, The first event sequence is a key event sequence, which includes at least two key events.

10. The method according to any one of claims 1 to 9, characterized in that, The electronic device includes an operating system, which includes the multi-modal input service and the security verification service.

11. A security verification method for control events, characterized in that, Applied to electronic devices, the method includes: The first application of the electronic device receives at least one control event for a target control within the first application; The first application sends a first event sequence to the security verification service of the electronic device, the first event sequence including the at least one control event; The first application receives a first security verification result sent by the security verification service. The first security verification result is used to indicate that the security verification service has stored a second event sequence that is the same as the first event sequence. The second event sequence is a mirror image of the control event output by the multi-mode input service of the electronic device. The multi-mode input service is used to output the control event triggered by the user's operation on the electronic device to the first application. The control event is used to control the first application to implement the corresponding function. The first application responds to the first event sequence based on the first security verification result to implement the first function of the target control.

12. The method according to claim 11, characterized in that, The method further includes: The first application sends a third event sequence to the security verification service, the third event sequence including at least one control event for the target control; The first application receives a second security verification result sent by the security verification service, the second security verification result being used to indicate that the security verification service does not store a fourth event sequence that is the same as the third event sequence; Based on the second security verification result, the first application refuses to respond to the third event sequence and / or outputs a prompt message indicating that the electronic device has a security risk.

13. The method according to claim 12, characterized in that, The second security verification result also indicates one or more of the following: The number of control events stored in the security verification service is zero. The number of control events in the third event sequence is different from the number of control events in the fifth event sequence stored by the security verification service; The order of the control events in the third event sequence is different from the order of the control events in the fifth event sequence; or, The event content of any control event in the third event sequence is different from the event content of the corresponding control event in the fifth event sequence.

14. The method according to any one of claims 11 to 13, characterized in that, The first application sends a first event sequence to the security verification service of the electronic device, including: The first application determines that the first event sequence satisfies the first condition; The first application sends the first event sequence to the security verification service; The first condition includes one or more of the following: The first event sequence consists of gesture events associated with the target control; The number of key events included in the first event sequence is greater than or equal to a first threshold; or, The first event sequence includes preset key events.

15. The method according to any one of claims 11 to 14, characterized in that, The method further includes: The first application sends an event registration request to the security verification service, the event registration request instructing the first application to load the target control.

16. The method according to any one of claims 11 to 14, characterized in that, After the first application sends an event registration request to the security verification service, the method further includes: The first application sends an event deregistration request to the security verification service, the event deregistration request instructing the target control to exit loading.

17. The method according to any one of claims 11 to 16, characterized in that, The target control is a security control.

18. An electronic device, characterized in that, It includes a processor and a memory, the processor and the memory being connected together, the memory storing a computer program, which, when executed by the processor, enables the method as described in any one of claims 1 to 10, or enables the method as described in any one of claims 11 to 17.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 10, or to perform the method as described in any one of claims 11 to 17.

20. A computer program product, characterized in that, The computer program product includes a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 10, or to perform the method as described in any one of claims 11 to 17.

Images