WO2020094027A1 - Procédé et appareil pour traiter une demande d'invocation pour un module d'autorisation sensible dans un terminal - Google Patents

Procédé et appareil pour traiter une demande d'invocation pour un module d'autorisation sensible dans un terminal Download PDF

Info

Publication number
WO2020094027A1
WO2020094027A1 PCT/CN2019/115828 CN2019115828W WO2020094027A1 WO 2020094027 A1 WO2020094027 A1 WO 2020094027A1 CN 2019115828 W CN2019115828 W CN 2019115828W WO 2020094027 A1 WO2020094027 A1 WO 2020094027A1
Authority
WO
WIPO (PCT)
Prior art keywords
call
request
call request
module
application
Prior art date
Application number
PCT/CN2019/115828
Other languages
English (en)
Chinese (zh)
Inventor
汪步庆
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2020094027A1 publication Critical patent/WO2020094027A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules

Definitions

  • the present application relates to, but is not limited to, the communication field, and in particular, to a method and device for processing a call request of a sensitive authority module in a terminal.
  • the terminal can collect a large amount of user privacy data through microphones, cameras, Global Positioning System (GPS) and other sensors, and can also read user privacy data through internal interfaces, such as contacts, SMS, call records, etc. Wait.
  • GPS Global Positioning System
  • the current system architecture of the terminal provides a mechanism for applications (APPs, including third-party APPs, system APPs, etc.) to call a microphone, camera, GPS, and other sensors or applications to perform permission checks when reading user privacy data.
  • applications including third-party APPs, system APPs, etc.
  • some software may use the permission to call the sensor to obtain outside information or read the user's private data at will without the user's knowledge after obtaining the user's relevant permission, resulting in the leakage of user privacy.
  • the embodiment of the present application provides a method and device for processing a call request of a sensitive authority module in a terminal, so as to at least solve the problem in the related art that the software arbitrarily calls the sensor to obtain outside information or reads the user's private data without the user's knowledge.
  • the issue of leakage of user privacy is not limited to, but not limited to, but not limited to, but not limited to, but not limited to, but not limited to, but not limited to a call request of a sensitive authority module in a terminal, so as to at least solve the problem in the related art that the software arbitrarily calls the sensor to obtain outside information or reads the user's private data without the user's knowledge.
  • a method for processing a call request of a sensitive permission module in a terminal including: receiving a call request of an application in a terminal to call a sensitive permission module; determining whether the call request meets a predetermined condition , wherein the predetermined condition includes at least one of the following: the application is in the background when the call request is initiated, the screen of the terminal is off when the application initiates the call request, and the application initiates the call When the request is in the foreground but the application does not receive a touch operation on the interface of the application within a predetermined period before the call request is initiated; if the call request meets the predetermined condition, the call request A predetermined process is performed, wherein the predetermined process includes at least one of the following: rejecting the call request, issuing a reminder for the call request, and asking whether to allow the call request.
  • an apparatus for processing a call request of a sensitive authority module in a terminal including: a call request receiving module, configured to receive a call request of an application in the terminal to call a sensitive authority module; A module for determining whether the call request meets a predetermined condition, wherein the predetermined condition includes at least one of the following: the application is in the background when the call request is initiated, and the terminal is when the application initiates the call request Of the screen is off, the application is in the foreground when the call request is initiated, but no touch operation is received on the interface of the application within a predetermined time period before the application initiates the call request; the processing module is used to When the call request meets the predetermined condition, perform a predetermined process on the call request, wherein the predetermined process includes at least one of the following: reject the call request, issue a reminder for the call request, and ask whether The call request is allowed.
  • a storage medium in which a computer program is stored, wherein the computer program is set to execute the steps in any one of the above method embodiments during runtime.
  • an electronic device including a memory and a processor, the memory stores a computer program, the processor is configured to run the computer program to perform any of the above The steps in the method embodiment.
  • an abnormal call judgment is made for the call request, and it can be monitored that the application is in the background, the screen is turned off, or the user's touch is not received in the foreground
  • the call request initiated in the case of operation, and correspondingly perform one or more of rejection, reminder, query and other operations.
  • an effective monitoring application for sensitive permission modules can include At least one of the following: the effect of calling the microphone module, camera module, GPS module, SMS module, contact module, call recording module, etc.), in certain preferred embodiments, the recording, analysis and Show.
  • FIG. 1 is a block diagram of a hardware structure of a mobile terminal of a method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application;
  • FIG. 2 is a flowchart of a method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application
  • step S204 is a specific flowchart of step S204 in a method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application;
  • step S204 is another specific flowchart of step S204 in the method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application;
  • step S206 is a specific flowchart of step S206 in the method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application;
  • FIG. 6 is a specific flowchart of a method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application
  • FIG. 7 is another specific flowchart of a method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application
  • FIG. 8 is a structural block diagram of a device for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application
  • FIG. 9 is a detailed structural block diagram of a device for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application.
  • FIG. 10 is a schematic diagram of a system architecture according to an exemplary embodiment of the present application.
  • FIG. 11 is an overall flowchart according to an exemplary embodiment of the present application.
  • FIG. 13 is a statistical diagram of the use period of microphones and short messages according to an exemplary embodiment of the present application.
  • FIG. 14 is a schematic diagram of an interface for reminding a user after using a microphone in the background of an application according to an exemplary embodiment of the present application.
  • the terminal system for example, Android system, iOS system, etc.
  • a third-party application needs to access sensitive information such as contacts, SMS, or call GPS, Camera, microphone, etc.
  • the system's approach is to pop up a permission application dialog box.
  • the user can choose to allow or deny.
  • Some normal request users will choose to allow (for example, when users use WeChat to send pictures, WeChat requests permission to read photos).
  • this may also cause privacy leakage, because the application for obtaining permissions can have permanent permissions after being authorized by the user (unless the user enters the settings to manually close its permissions).
  • These applications may silently collect user's private data in the background without the user's knowledge.
  • the embodiments of the present application provide a processing solution for the call request of the sensitive authority module in the terminal.
  • the present application will be described in detail with reference to the accompanying drawings and in conjunction with the embodiments. It should be noted that the embodiments in the present application and the features in the embodiments can be combined with each other if there is no conflict.
  • FIG. 1 is a block diagram of a hardware structure of a mobile terminal of a method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application.
  • the mobile terminal 10 may include one or more (only one is shown in FIG. 1) processor 102 (the processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA, etc. ) And a memory 104 for storing data.
  • the above mobile terminal may further include a transmission device 106 for communication functions and an input and output device 108.
  • a transmission device 106 for communication functions may further include a transmission device 106 for communication functions and an input and output device 108.
  • FIG. 1 is merely an illustration, which does not limit the structure of the mobile terminal described above.
  • the mobile terminal 10 may also include more or fewer components than those shown in FIG. 1, or have a different configuration from that shown in FIG.
  • the memory 104 may be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the processing method of the call request of the sensitive authority module in the terminal in the embodiment of the present application, and the processor 102 is stored in the memory 104 by running Within the computer program, to perform various functional applications and data processing, that is, to implement the above method.
  • the memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory.
  • the memory 104 may include memories remotely provided with respect to the processor 102, and these remote memories may be connected to the mobile terminal 10 through a network. Examples of the above network include but are not limited to the Internet, intranet, local area network, mobile communication network, and combinations thereof.
  • the transmission device 106 is used to receive or send data via a network.
  • the specific example of the network described above may include a wireless network provided by a communication provider of the mobile terminal 10.
  • the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC for short), which can be connected to other network devices through the base station to communicate with the Internet.
  • the transmission device 106 may be a radio frequency (Radio Frequency, RF for short) module, which is used to communicate with the Internet in a wireless manner.
  • RF Radio Frequency
  • FIG. 2 is a flowchart of a method for processing a call request of a sensitive permission module in a terminal according to an embodiment of the present application, as shown in FIG. 2 As shown, the process includes the following steps.
  • Step S202 Receive a call request for the application in the terminal to call the sensitive authority module.
  • the concept of the sensitive authority module is well known in the art, and it is a series of modules related to user privacy, which can directly or indirectly control the operation of the sensor of the terminal, or read the user data in the terminal, and call these modules Need to perform permission check or permission application.
  • sensitive permission modules include but are not limited to: contact module, short message module, call record module, GPS module, Camera module, microphone module, etc.
  • Step S204 judging whether the call request meets a predetermined condition, wherein the predetermined condition includes at least one of the following: the application is in the background when the call request is initiated, and the terminal ’s The screen is off, the application is in the foreground when the call request is initiated, but no touch operation is received on the interface of the application within a predetermined time period before the application initiates the call request.
  • the predetermined condition includes at least one of the following: the application is in the background when the call request is initiated, and the terminal ’s The screen is off, the application is in the foreground when the call request is initiated, but no touch operation is received on the interface of the application within a predetermined time period before the application initiates the call request.
  • Step S206 when the call request meets the predetermined condition, perform a predetermined process on the call request, wherein the predetermined process includes at least one of the following: reject the call request, issue the call request Remind and ask if the call request is allowed.
  • the predetermined processing involved is intended to prevent abnormal calls, thereby preventing leakage of user privacy.
  • To alert the user by asking whether to allow the call request, you can use the Dialog to let the user decide whether to approve the call and give control to the user. When the user agrees, the call request is allowed.
  • the behavior of allowing the call request can be It is allowed for a long time. For security reasons, it may be allowed within a predetermined period of time, for example, to allow the application to call the sensitive permission module within 10 minutes, or only to authorize its use for more than 24 hours to re-authorize.
  • the execution body of the above steps may be a terminal.
  • an abnormal call judgment is made for the call request, and it can be monitored that the application is in the background, the screen is turned off, or the user's touch is not received in the foreground
  • the call request initiated in the case of operation, and correspondingly perform one or more of rejection, reminder, query and other operations.
  • an effective monitoring application for sensitive permission modules can include At least one of the following: the effect of calling the microphone module, camera module, GPS module, SMS module, contact module, call recording module, etc.), in certain preferred embodiments, the recording, analysis and Show.
  • the framework layer in the terminal receives the call request initiated by the application to call the sensitive permission module, wherein the call request includes one of the following: a call permission check request checkSelfPermission, call permission request requestPermission.
  • the frame layer in the terminal is generally versatile.
  • a simple and convenient method is to add a middleware layer, the middleware layer is a piece of processing code, and the normal processing code of the framework layer can be called by the middle
  • the middleware layer is called in the form of the interface corresponding to the middleware layer.
  • the middleware layer can be used to implement customized processing functions based on the general processing of the framework layer.
  • the middleware layer may include an abnormal call judgment component for performing abnormal call judgment, and may further include information reading for reading information required for abnormal judgment Components, the combination of the two can realize the judgment of abnormal calls, so that by calling the middleware layer on the basis of the framework layer, you can use a very convenient way to achieve abnormal calls without changing the original business logic of the framework. Judgment.
  • the middleware can communicate with the contact module, short message module, GPS module, Camera module, microphone module and so on. For the APP that has been authorized to start calling the privacy module, the middleware layer first makes abnormal call judgment.
  • step S204 the determination is made Whether the call request meets the predetermined condition may include the following steps.
  • Step S2042 The framework layer sends the call information corresponding to the call request to the middleware layer in the terminal, wherein the call information corresponding to the call request may include: the application that initiated the call request , And the judgment result of the framework layer judging whether to allow the call request.
  • step S2044 the middleware layer determines whether the call request meets the predetermined condition according to the call information.
  • the framework layer may change the interface calling behavior of checkSelfPermission or requestPermission to the middle of the terminal
  • the software layer sends the calling information corresponding to the calling request. That is to say, the calling information corresponding to the calling request can be transferred to the middleware layer through the calling interface set in the checkSelfPermission or the requestPermission.
  • step S204 exemplified above is only an example, and this solution can implement the method in this embodiment relatively easily without changing the frame layer.
  • step S204 directly modify the authorization check and application-related processing flow in the framework layer to add abnormal call judgment, for example, directly include a The abnormal call judgment component for judging abnormal calls and the information reading component for reading information required for abnormal judgment can also realize the judgment of abnormal calls.
  • step S204 directly modify the authorization check and application-related processing flow in the framework layer to add abnormal call judgment, for example, directly include a The abnormal call judgment component for judging abnormal calls and the information reading component for reading information required for abnormal judgment can also realize the judgment of abnormal calls.
  • other modules can also be used to implement abnormal call judgment, etc.
  • the specific implementation form of the abnormal call judgment is not limited in this application.
  • FIG. 4 is another specific flowchart of step S204 in the method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application.
  • the frame layer is directed to the middleware layer in the terminal.
  • step S2042 of sending the calling information corresponding to the calling request it also includes one of the following.
  • the framework layer judges whether the call request is allowed according to the call permission of the application for each sensitive permission module recorded in the system, and the judgment result is If permitted, continue the step of the framework layer sending the calling information corresponding to the calling request to the middleware layer in the terminal.
  • the framework layer determines whether the call request is allowed according to the call permission of the application for each sensitive permission module recorded in the system, and the judgment result is If it is not allowed, the framework layer initiates a requestPermission to the sensitive permission module requested by the checkSelfPermission, and determines whether to automatically authorize the requestPermission according to the type of the sensitive permission module. In the case of, continue the step of the framework layer sending the calling information corresponding to the calling request to the middleware layer in the terminal.
  • the framework layer determines whether to automatically authorize the requestPermission according to the type of the sensitive permission module called by the requestPermission, and if the judgment result is automatic In the case of authorization, continue the step of the framework layer sending the calling information corresponding to the calling request to the middleware layer in the terminal.
  • FIG. 5 is a specific flowchart of step S206 in the method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application. As shown in FIG. 5, step S206 is performed when the call request meets In the case of the predetermined condition, performing the predetermined processing on the call request may include the following steps.
  • Step S2062 the middleware layer returns a judgment result of judging whether the calling request satisfies the predetermined condition to the framework layer.
  • step S2064 the framework layer performs a predetermined process on the call request when the judgment result is that the call request meets the predetermined condition.
  • step S6 is a specific flowchart of a method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application.
  • the method further includes: step S602, Storing a call record generated by the call request to a database, wherein the call record includes at least one of the following: an identification of the application that initiated the call request, a type of the sensitive authority module called, and a call start Time, the time to end the call, and the duration of the call.
  • the call record generated by the call request may be stored in a database by the middleware layer, and the data that the middleware layer may obtain includes the time when the third-party APP accesses the contact module, the short message module, and the GPS module. Use Camera, microphone call duration, etc.
  • step S602 is another specific flowchart of a method for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application. As shown in FIG. 7, after storing the call record generated by the call request in the database in step S602 And also includes the following steps.
  • Step S702 Receive a call record viewing request.
  • Step S704 Read the call record corresponding to the call record view request from the database according to the call record view request, and analyze and / or display the read call record.
  • the following processing can be performed on the collected information: visual analysis of the obtained information (display of histograms, etc.), statistics of the number of visits of contacts, SMS, and GPS; statistics of camera, microphone call duration, user You can view this information at any time. In this way, users can easily know the details of their private data being accessed.
  • step S206 when the call request meets the predetermined condition, the process of performing the predetermined process on the call request may include: The predetermined condition satisfied by the call request determines predetermined processing corresponding to the predetermined condition, and performs the determined predetermined processing on the call request.
  • This correspondence relationship can be set according to requirements, for example, it can be preset before leaving the factory, or can be set by the user.
  • the correspondence between the predetermined condition and the predetermined process may be as follows.
  • the predetermined processing includes at least rejecting the call request.
  • the predetermined process includes at least issuing a reminder or asking whether the call request is allowed for the call request.
  • the predetermined condition includes that the application is in the foreground when the call request is initiated, but the touch operation is not received on the interface of the application within a predetermined time period before the application initiates the call request
  • the predetermined The processing includes at least issuing a reminder or asking whether the calling request is allowed for the calling request.
  • an apparatus for processing a call request of a sensitive authority module in a terminal is also provided.
  • the apparatus is used to implement the foregoing embodiment and the preferred embodiments, and descriptions that have already been described will not be repeated.
  • the term "module" may implement a combination of software and / or hardware that performs predetermined functions.
  • the devices described in the following embodiments are implemented in software, implementation of hardware or a combination of software and hardware is also possible and conceived.
  • FIG. 8 is a structural block diagram of an apparatus for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application. As shown in FIG. 8, the apparatus includes:
  • the call request receiving module 81 is configured to receive a call request for an application in a terminal to call a sensitive authority module.
  • the determining module 82 is configured to determine whether the calling request meets a predetermined condition, where the predetermined condition includes at least one of the following: the application is in the background when the calling request is initiated, and the application is in the background when the calling request is initiated.
  • the predetermined condition includes at least one of the following: the application is in the background when the calling request is initiated, and the application is in the background when the calling request is initiated.
  • the screen of the terminal is off, the application is in the foreground when the call request is initiated, but no touch operation is received on the interface of the application within a predetermined time period before the application initiates the call request.
  • the processing module 83 is configured to perform predetermined processing on the calling request when the calling request meets the predetermined condition, wherein the predetermined processing includes at least one of the following: rejecting the calling request, targeting the The call request issues a reminder, asking if the call request is allowed.
  • an abnormal call judgment is made for the call request, and it can be monitored that the application is in the background, the screen is turned off, or the user's touch is not received in the foreground
  • the call request initiated in the case of operation, and correspondingly perform one or more of rejection, reminder, query and other operations.
  • an effective monitoring application for sensitive permission modules can include At least one of the following: the effect of calling the microphone module, camera module, GPS module, SMS module, contact module, call recording module, etc.), in certain preferred embodiments, the recording, analysis and Show.
  • FIG. 9 is a detailed structural block diagram of a device for processing a call request of a sensitive authority module in a terminal according to an embodiment of the present application.
  • the call request receiving module 81 is located at a frame layer in the terminal for receiving The call request initiated by the application to call the sensitive permission module, wherein the call request includes one of the following: a call permission check request checkSelfPermission, a call permission application request requestPermission.
  • the frame layer in the terminal is generally versatile.
  • a simple and convenient method is to add a middleware layer and call the middleware layer on the basis of the framework layer to realize the judgment of abnormal call.
  • the middleware layer can communicate with the contact module, short message module, GPS module, Camera module, microphone module, etc.
  • the middleware layer first makes abnormal call judgment.
  • the device further includes: an information delivery module 91 located at the frame layer, and used to send the data to the middleware layer located at the terminal.
  • the judging module 82 sends the calling information corresponding to the calling request, the calling information corresponding to the calling request includes: the identification of the application that initiated the calling request, and the framework layer judging whether to allow the calling request critical result.
  • the judgment module 82 is used to judge whether the calling request meets the predetermined condition according to the calling information.
  • the framework layer may change the interface calling behavior of checkSelfPermission or requestPermission to the middle of the terminal
  • the software layer sends the calling information corresponding to the calling request.
  • the information transfer module 91 is used to transfer the call information corresponding to the call request to the judgment module located at the middleware layer through the call interface set in the checkSelfPermission or the requestPermission 82.
  • the system may further include a permission control module 92, which is located at the frame layer in the terminal and used to perform one of the following.
  • the The information transfer module 91 sends the call information corresponding to the call request to the judgment module 82 located in the middleware layer in the terminal.
  • the call request includes the checkSelfPermission, determine whether the call request is allowed according to the call permission of the application for each sensitive permission module recorded in the system, and if the judgment result is not allowed, check The sensitive permission module called by checkSelfPermission initiates requestPermission, and judges whether to automatically authorize the requestPermission according to the type of the sensitive permission module.
  • the judgment result is automatic authorization, the information transfer module 91 is called to The judgment module 82 located in the middleware layer in the terminal sends call information corresponding to the call request.
  • the call request includes the requestPermission
  • determine whether to automatically authorize the requestPermission according to the type of the sensitive permission module requested by the requestPermission and call the request if the judgment result is automatic authorization
  • the information transfer module 91 sends the call information corresponding to the call request to the judgment module 72 located in the middleware layer in the terminal.
  • the processing module 83 may be located at the frame layer of the terminal, and the judgment module 82 is used to judge whether the call request meets the predetermined condition The result is returned to the processing module 83; the processing module 83 is used to perform predetermined processing on the call request if the judgment result is that the call request meets the predetermined condition.
  • the system may further include: a storage module 93, configured to store a call record generated by the call request to a database, wherein the call record includes at least one of the following: the call request is initiated The identification of the application, the type of the sensitive permission module called, the time to start the call, the time to end the call, and the duration of the call.
  • a storage module 93 configured to store a call record generated by the call request to a database, wherein the call record includes at least one of the following: the call request is initiated The identification of the application, the type of the sensitive permission module called, the time to start the call, the time to end the call, and the duration of the call.
  • the call record generated by the call request may be stored in a database by the middleware layer, and the data that the middleware layer may obtain includes the time when the third-party APP accesses the contact module, the SMS module, and the GPS module Use Camera, microphone call duration, etc. Therefore, the storage module may be located at the middleware layer in the terminal.
  • the storage module may be located at the middleware layer in the terminal.
  • a storage module is directly provided in the framework layer, or the function of the storage module is implemented in other modules, which is not limited in this embodiment.
  • the system may further include: a viewing request receiving module 94 for receiving a call record viewing request; an analysis display module 95 for reading the call record viewing request according to the calling record viewing request Call record View the call record corresponding to the request, and analyze and / or display the read call record.
  • a viewing request receiving module 94 for receiving a call record viewing request
  • an analysis display module 95 for reading the call record viewing request according to the calling record viewing request Call record View the call record corresponding to the request, and analyze and / or display the read call record.
  • the following processing can be performed on the collected information: visual analysis of the obtained information (display of histograms, etc.), statistics of the number of visits of contacts, SMS, and GPS; statistics of camera, microphone call duration, user You can view this information at any time. In this way, users can easily know the details of their private data being accessed.
  • the processing module 83 is configured to: according to the predetermined condition that the call request satisfies when the call request meets the predetermined condition The condition determines a predetermined process corresponding to the predetermined condition, and performs the determined predetermined process on the call request.
  • the correspondence between the predetermined condition and the predetermined processing may be as follows: when the predetermined condition includes that the screen of the terminal is off when the application initiates the call request, the The predetermined processing includes at least rejecting the call request; when the predetermined condition includes that the application is in the background when the call request is initiated, the predetermined processing includes at least issuing a reminder or asking whether the call request is allowed for the call request The call request; when the predetermined condition includes that the application is in the foreground when the call request is initiated but the touch operation is not received on the interface of the application within a predetermined time period before the application initiates the call request , The predetermined processing includes at least issuing a reminder or asking whether the calling request is allowed for the calling request.
  • the above modules can be implemented by software or hardware, and the latter can be implemented by the following methods, but not limited to this: the above modules are all located in the same processor; or, the above modules can be combined in any combination The forms are located in different processors.
  • An embodiment of the present application further provides a storage medium in which a computer program is stored, wherein the computer program is configured to execute any of the steps in the above method embodiments during runtime.
  • the above storage medium may include, but is not limited to: a USB flash drive, a read-only memory (Read-Only Memory, ROM for short), a random access memory (Random Access Memory, RAM for short), Various media that can store computer programs, such as removable hard disks, magnetic disks, or optical disks.
  • An embodiment of the present application further provides an electronic device, including a memory and a processor, where the computer program is stored in the memory, and the processor is configured to run the computer program to perform the steps in any one of the foregoing method embodiments.
  • the electronic device may further include a transmission device and an input-output device, wherein the transmission device is connected to the processor, and the input-output device is connected to the processor.
  • FIG. 10 is a schematic diagram of a system architecture according to an exemplary embodiment of the present application.
  • the system in the terminal includes the following layers: a framework layer 1001, which When it detects that a third-party application checks or requests sensitive permissions (such as access to contacts, SMS, Camera, GPS, microphone, etc.), it communicates with the middleware layer 1002 and passes data to the middleware layer 1002 for judgment.
  • the middleware layer 1002 receives the data from the frame layer 1001, performs abnormal call judgment, and returns the result to the frame layer 1001, and at the same time transfers the corresponding third-party call data to the database layer 1003 for storage.
  • the database layer 1003 receives and processes incoming data from the middleware layer 1002, performs insertion, update, and the like.
  • the data display module 1004 analyzes the data in the database layer 1003 and displays it to the user, which can be displayed in various forms.
  • FIG. 11 is an overall flowchart according to an exemplary embodiment of the present application, and each part involved in FIG. 11 is briefly described below.
  • APP1APP2APP3 refers to third-party applications or independent applications of the system.
  • the contact module, short message module, Camera module, GPS module, and microphone module refer to some sensitive information modules in the mobile phone, including frame layer processing and sensor services, etc., which corresponds to the frame layer 1001 in FIG. 10.
  • the middleware layer corresponds to the middleware layer 1002 in FIG. 10.
  • the database corresponds to the database layer 1003 in FIG.
  • the data display module corresponds to the data display module 1004 of FIG.
  • SMSTYPE 1, // indicates the type of SMS data obtained
  • GPSTYPE // indicates calling GPS data type
  • Boolean isUseStart true; // true--start to use; false--end to use
  • the mobile phone comes with apps or apps downloaded from the third-party market.
  • apps read contacts, SMS data, or open / release Camera, GPS, microphone, and other services, the behavior of these apps will be detected at the frame layer 1001.
  • the processing of the framework layer 1001 is as follows: a request for invoking privacy permission by a third-party application will call the checkSelfPermission method or the requestPermissions method (regardless of whether the APP has obtained permission).
  • the framework layer passes the call information to the middleware layer 1002.
  • the framework layer returns True or False (True indicates that the APP has obtained permission, False indicates that the APP has not obtained permission).
  • the framework layer determines whether the user actively authorizes or the system automatically authorizes, and then the framework layer passes the result to the middleware layer 1002.
  • the return value of the third-party application uid and checkSelfPermission or requestPermissions can be passed into the middleware layer 1002 by modifying the Android SDK SDK checkSelfPermission and requestPermissions interfaces.
  • the processing flow of the middleware layer 1002 is as follows: the middleware layer 1002 judges whether it is an abnormal call, thereby rejecting or approving the request.
  • the middleware layer 1002 judges whether it is an abnormal call, thereby rejecting or approving the request.
  • the processing methods described below belong to one of many feasible processing methods. The list here is only for example and should not be understood as the only processing method. .
  • the third-party application uid can be obtained through the Android standard SDK interface (such as Binder.getCallingUid ()), so as to obtain the specific application package name.
  • FIG. 12 is a flowchart of permission inspection, application, and abnormality judgment according to an exemplary embodiment of the present application. The following provides a combination of the framework layer 1001 and the middleware layer 1002 in several scenarios in conjunction with FIG. Process of judgment.
  • the middleware layer 1002 first determines whether the third-party application is in the foreground or background. If it is in the background, it obtains the application package name and sends a Notification to inform the user that the request has been rejected. In the notification, the user can click to enter the permission list interface of the three-party application; if it is the foreground, it will detect whether the user has a touch event within a few seconds before the request event time. If there is no touch screen event, a Dialog will pop up to prompt the user. Allow or deny buttons. For the foreground application, the package name of the application, the time of querying the data, and the data marked as fetching SMS type are transferred to the database.
  • the detailed parameters are as follows: a) the package name of the third-party application; b) the data type of EnumTYPE.SMSTYPE GPS is GPSTYPE, and the contact is CONTACTTYPE; c) Whether the transfer is started is marked as true; d) The time when the transfer is started is transferred.
  • the middleware layer 1002 also needs to store the usage data in the database.
  • requestPermissions The result returned by requestPermissions is the user's active authorization.
  • the application is in the foreground and the user actively authorizes the SMS access permission.
  • the application can access the SMS normally.
  • the middleware layer 1002 writes the short message access time into the database.
  • step 1.1) is entered.
  • the middleware layer 1002 first determines whether the third-party application is in the foreground or background. If it is in the background, it obtains the application package name and sends a Notification to inform the user that the request has been rejected. In the notification, the user can click to enter the permission list interface of the three-party application; if it is the foreground, it will detect whether the user has a touch event within a few seconds before the request event time. If there is no touch screen event, a Dialog will pop up to remind the user that the user can click Allow or deny buttons.
  • the package name of the application and the time of querying the data and the data marked as fetching SMS type are transferred to the database.
  • the detailed parameters are as follows: a) the package name of the third-party application; b) the data type is EnumTYPE.MICROPHONETYPE, Camera is of CAMERATYPE type; c) whether the transfer start flag is true; d) the transfer start time; e) the transfer end time.
  • the middleware layer 1002 also needs to store the usage data in the database.
  • the result returned by requestPermissions is the user's active authorization.
  • the application is in the foreground and the user actively authorized the microphone access permission.
  • the application can access the microphone normally.
  • the middleware layer 1002 writes the microphone access time into the database.
  • the middleware layer 1002 detects the mobile phone screen extinguishing broadcast event, the current mobile phone screen is marked as off, at this time the middleware layer 1002 can directly refuse permission; the background application authorization can also Use a more flexible approach, such as authorizing only 24 hours (free access within 24 hours, re-authorization is required after 24 hours).
  • the middleware layer 1002 detects a bright screen event, the marked screen is modified to be in use state, and the processing flow at this time is the same as the processing flow in 1 and 2.
  • the processing of the database layer 1003 is as follows: after processing the incoming data of the middle layer, after checking the validity, it is inserted into the database and saved. Receive a query request from the data display layer and feed back the corresponding data to display.
  • the processing of the data display module 1004 is as follows: through various combinations of queries, the data in the database is displayed in the UI in different dimensions, which is convenient for users to analyze and judge, such as: the number of times the APP accesses contacts, SMS, GPS, call Camera, microphone Duration; analysis of an application ’s use of private data in the most recent period; which applications of a certain privacy data or sensor have been used in the most recent period; can set a fixed weekly or monthly push notification bar for analysis data to remind users to view; or discover Which applications frequently use private data to remind users, etc. for a certain period of time.
  • the specific display methods are not listed here one by one.
  • FIG. 13 is a statistical diagram of usage periods of microphones and short messages according to an exemplary embodiment of the present application.
  • the horizontal axis is the time coordinate, indicating 0-24 hours of the day. If the bar is filled with a specific pattern, it indicates that the microphone is used during this time. By using different patterns or colors to distinguish different apps, click to display the specific data used (duration and start and end time). By pinching two fingers together, you can display a week of usage charts. The use of the camera can be displayed in a similar manner to the use of the microphone in FIG. 13.
  • the horizontal axis is the time coordinate, representing 0-24 hours of a day.
  • the rectangular bar shows the number of times the SMS was accessed in a certain period of time.
  • the above is just a display example, and the specific display methods and reminder methods can be various. For example, it can periodically remind the statistics, remind the abnormal behavior data in a certain period of time, etc.
  • FIG. 14 is a schematic diagram of an interface for reminding a user after using a microphone in the background of an application according to an exemplary embodiment of the present application.
  • the terminal can directly refuse the call and use notification to remind the user.
  • an effective monitoring application for sensitive permission modules can include At least one of the following: the effect of calling the microphone module, camera module, GPS module, SMS module, contact module, call recording module, etc.), in certain preferred embodiments, the recording, analysis and Show.
  • modules or steps of this application can be implemented by a general-purpose computing device, and they can be concentrated on a single computing device or distributed in a network composed of multiple computing devices
  • they can be implemented with program code executable by the computing device, so that they can be stored in the storage device to be executed by the computing device, and in some cases, can be in a different order than here
  • the steps shown or described are performed, or they are made into individual integrated circuit modules respectively, or multiple modules or steps among them are made into a single integrated circuit module to achieve. In this way, this application is not limited to any specific combination of hardware and software.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Telephonic Communication Services (AREA)
  • Telephone Function (AREA)

Abstract

L'invention concerne un procédé et un appareil pour traiter une demande d'invocation pour un module d'autorisation sensible dans un terminal. Le procédé comprend les étapes consistant à : recevoir une demande d'invocation pour invoquer un module d'autorisation sensible par une application dans un terminal (S202) ; déterminer si la demande d'invocation satisfait des conditions prédéterminées, les conditions prédéterminées comprenant au moins l'un des éléments suivants : l'application est dans l'arrière-plan lors du lancement de la demande d'invocation, l'écran du terminal est dans un état éteint lorsque l'application lance la demande d'invocation, et l'application est au premier plan lors du lancement de la demande d'invocation, mais une opération tactile n'est pas reçue sur une interface de l'application pendant une durée prédéterminée avant que l'application lance la demande d'invocation (S204) ; et lorsque la demande d'invocation satisfait les conditions prédéterminées, effectuer un traitement prédéterminé sur la demande d'invocation, le traitement prédéterminé comprenant au moins l'un des éléments suivants : rejeter la demande d'invocation, émettre un rappel pour la demande d'invocation, et interroger pour savoir si la demande d'invocation est autorisée (S206).
PCT/CN2019/115828 2018-11-05 2019-11-05 Procédé et appareil pour traiter une demande d'invocation pour un module d'autorisation sensible dans un terminal WO2020094027A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811307589.4 2018-11-05
CN201811307589.4A CN109711141A (zh) 2018-11-05 2018-11-05 终端中敏感权限模块的调用请求的处理方法及装置

Publications (1)

Publication Number Publication Date
WO2020094027A1 true WO2020094027A1 (fr) 2020-05-14

Family

ID=66254866

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/115828 WO2020094027A1 (fr) 2018-11-05 2019-11-05 Procédé et appareil pour traiter une demande d'invocation pour un module d'autorisation sensible dans un terminal

Country Status (2)

Country Link
CN (1) CN109711141A (fr)
WO (1) WO2020094027A1 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109711141A (zh) * 2018-11-05 2019-05-03 中兴通讯股份有限公司 终端中敏感权限模块的调用请求的处理方法及装置
CN111143089B (zh) * 2019-12-23 2023-11-07 飞天诚信科技股份有限公司 一种应用程序调用第三方库动态提升权限的方法及装置
CN113468012A (zh) * 2020-03-31 2021-10-01 北京小米移动软件有限公司 权限使用监测方法、装置及介质
CN112100612B (zh) * 2020-09-03 2023-06-06 中国联合网络通信集团有限公司 一种终端权限保护方法、装置及终端
CN112860637A (zh) * 2021-02-05 2021-05-28 广州海量数据库技术有限公司 一种基于审计策略来处理日志的方法及系统
CN113505365A (zh) * 2021-07-02 2021-10-15 珠海市魅族科技有限公司 权限管理方法、装置、电子设备及存储介质
CN114489419A (zh) * 2022-01-13 2022-05-13 荣耀终端有限公司 权限控制方法及电子设备
CN114398655A (zh) * 2022-01-18 2022-04-26 支付宝(杭州)信息技术有限公司 一种在移动终端中针对目标应用的隐私保护方法和装置
CN115879149B (zh) * 2022-12-01 2023-06-30 武汉卓讯互动信息科技有限公司 一种App隐私合规安全检测方法和检测平台

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103544435A (zh) * 2013-10-18 2014-01-29 广东欧珀移动通信有限公司 防止偷拍的方法与装置
CN106845208A (zh) * 2017-02-13 2017-06-13 北京奇虎科技有限公司 异常应用控制方法、装置和终端设备
CN106933633A (zh) * 2017-03-14 2017-07-07 北京奇虎科技有限公司 权限管理方法、装置和移动终端
CN109711141A (zh) * 2018-11-05 2019-05-03 中兴通讯股份有限公司 终端中敏感权限模块的调用请求的处理方法及装置
CN109918930A (zh) * 2019-03-11 2019-06-21 维沃移动通信有限公司 一种信息保护方法及终端设备
CN110191465A (zh) * 2019-06-03 2019-08-30 努比亚技术有限公司 权限控制方法、移动终端及计算机可读存储介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9053230B2 (en) * 2013-01-14 2015-06-09 International Business Machines Corporation Framework and repository for analysis of software products
CN106997433A (zh) * 2017-03-22 2017-08-01 西安电子科技大学 一种Android系统权限管理方法
CN108549799B (zh) * 2018-04-13 2022-02-01 深圳壹账通智能科技有限公司 安卓权限的管理方法、装置、终端和计算机存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103544435A (zh) * 2013-10-18 2014-01-29 广东欧珀移动通信有限公司 防止偷拍的方法与装置
CN106845208A (zh) * 2017-02-13 2017-06-13 北京奇虎科技有限公司 异常应用控制方法、装置和终端设备
CN106933633A (zh) * 2017-03-14 2017-07-07 北京奇虎科技有限公司 权限管理方法、装置和移动终端
CN109711141A (zh) * 2018-11-05 2019-05-03 中兴通讯股份有限公司 终端中敏感权限模块的调用请求的处理方法及装置
CN109918930A (zh) * 2019-03-11 2019-06-21 维沃移动通信有限公司 一种信息保护方法及终端设备
CN110191465A (zh) * 2019-06-03 2019-08-30 努比亚技术有限公司 权限控制方法、移动终端及计算机可读存储介质

Also Published As

Publication number Publication date
CN109711141A (zh) 2019-05-03

Similar Documents

Publication Publication Date Title
WO2020094027A1 (fr) Procédé et appareil pour traiter une demande d'invocation pour un module d'autorisation sensible dans un terminal
EP3168747B1 (fr) Procédé et dispositif pour surveiller un fichier dans une cloison de système
CN104376266B (zh) 应用软件安全级别的确定方法及装置
WO2017113660A1 (fr) Procédé et dispositif de gestion de programme d'application
US20130055387A1 (en) Apparatus and method for providing security information on background process
EP3089068A1 (fr) Procédé, dispositif, terminal et support d'informations de gestion de programme d'application
US11748522B2 (en) Systems, devices, and methods for prevention of recording content
US11487866B2 (en) Remote permissions monitoring and control
US10447924B2 (en) Camera usage notification
CN105204949A (zh) 主动触发系统广播的方法与装置
CN106412884B (zh) Wifi连接的管理方法及装置
CN110956722A (zh) 一种智能锁异常报警的方法、设备、存储介质
EP3226128A1 (fr) Procédé et dispositif de paiement en ligne
CN105511739A (zh) 消息提醒方法及装置
CN107451464A (zh) 一种提示信息的输出方法及装置
CN104360875A (zh) 隐私模式启动方法和装置
CN112306566A (zh) 数据处理方法及装置
CN109409097B (zh) 信息管理方法、装置及计算机可读存储介质
CN112068975B (zh) 一种信息处理方法及装置
CN114066370A (zh) 库存服务调用方法、装置、设备、存储介质及程序产品
CN114564363A (zh) 一种微服务运营方法、装置、设备及可读存储介质
CN106155863A (zh) 终端预期行为控制方法及终端
CN106874749A (zh) 一种管理root权限的方法和装置
CN113806741A (zh) 信息处理方法及装置
CN112235451B (zh) 提供关于联系人被删除的报警的方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19881082

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 17.09.2021)

122 Ep: pct application non-entry in european phase

Ref document number: 19881082

Country of ref document: EP

Kind code of ref document: A1