A cross-browser API fingerprint information collaborative obfuscation method and device

Abstract

This application provides a cross-browser API fingerprint information collaborative obfuscation method, apparatus, and electronic device. The method intercepts API requests sent by a website when a user visits a browser, determines a corresponding target fingerprint countermeasure strategy based on the type of website visited, generates a virtual identity profile for the user based on the user's hardware and software description information, performs a consistency check on the virtual identity profile, generates virtual API information based on the virtual identity profile, and responds to API call requests initiated by the website using this virtual API information. By constructing a virtual identity answer and virtualizing browser API execution information, this embodiment of the application can ensure the normal operation of website functions while protecting user privacy.

Description

Technical Field

[0001] This application relates to the field of data security technology, and in particular to a cross-browser API fingerprint information collaborative obfuscation method, apparatus and electronic device. Background Technology

[0002] Browser fingerprinting countermeasures refer to a series of technical means to prevent or interfere with websites (or trackers) from collecting, analyzing, and using browser fingerprints for user identification and cross-site tracking. The core objective is to break the uniqueness of browser fingerprints and protect user privacy. Existing browser fingerprinting countermeasure technologies include: browser built-in privacy mode technology, browser extension fingerprint obfuscation technology, proxy server technology, virtualization environment technology, and layered rendering technology.

[0003] While existing browser fingerprinting techniques have some effectiveness in countering fingerprinting, the problem of inconsistency across browser APIs still exists. This means that the information returned by APIs for the same user may be logically inconsistent across different browsers. Summary of the Invention

[0004] In view of this, embodiments of this application provide a cross-browser API fingerprint information collaborative obfuscation method, apparatus, and electronic device to solve the problem of logical inconsistency in cross-browser API return information in existing browser fingerprinting anti-counterfeiting technologies.

[0005] In a first aspect, embodiments of this application provide a cross-browser API fingerprint information collaborative obfuscation method, wherein the method includes: In response to user commands in the browser, intercept API call requests sent by the website accessed by the user; Obtain the deployment environment description information of the browser and the type of website accessed by the user. The deployment environment description information includes: software description information and hardware description information. Based on the website type, determine the target fingerprint countermeasure strategy corresponding to the operation instruction; According to the target fingerprint countermeasure strategy, a virtual identity profile of the user is generated based on the software description information and hardware description information, and the virtual identity profile is verified for consistency. If the virtual identity profile consistency verification passes, virtual API information is generated based on the virtual identity profile, and the API call request is responded to through the virtual API information.

[0006] Secondly, embodiments of this application provide a cross-browser API fingerprint information collaborative obfuscation device, wherein the device includes: The API interception module is used to intercept API call requests sent by the website accessed by the user in response to the user's operation instructions in the browser. The network access module is used to obtain the deployment environment description information of the browser and the type of website accessed by the user. The deployment environment description information includes: software description information and hardware description information. Based on the website type, the module determines the target fingerprint countermeasure strategy corresponding to the operation instruction. The virtual identity profile management module is used to generate the user's virtual identity profile based on the software description information and hardware description information according to the target fingerprint countermeasure strategy. The cross-API consistency coordination module is used to perform consistency verification on the virtual identity profile. If the consistency verification of the virtual identity profile passes, virtual API information is generated based on the virtual identity profile, and the API call request is responded to through the virtual API information.

[0007] Thirdly, embodiments of this application provide an electronic device, wherein the electronic device includes: a processor; and a memory storing a program; wherein the program includes instructions, which, when executed by the processor, cause the processor to perform the cross-browser API fingerprint information collaborative obfuscation method described in the first aspect.

[0008] Fourthly, embodiments of this application provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the cross-browser API fingerprint information collaborative obfuscation method described in the first aspect.

[0009] The beneficial effects of this application are: This application provides a cross-browser API fingerprint information collaborative obfuscation method, apparatus, and electronic device. The method intercepts API requests sent by a website when a user visits a browser, determines a corresponding target fingerprint countermeasure strategy based on the type of website visited, generates a virtual identity profile for the user based on the user's hardware and software description information, performs a consistency check on the virtual identity profile, generates virtual API information based on the virtual identity profile, and responds to API call requests initiated by the website using this virtual API information. By constructing a virtual identity answer and virtualizing browser API execution information, this embodiment of the application can ensure the normal operation of website functions while protecting user privacy. Attached Figure Description

[0010] Further details, features, and advantages of this application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1This paper illustrates a flowchart of a cross-browser API fingerprint collaborative obfuscation method provided in this application. Figure 2 This paper illustrates another flowchart of the cross-browser API fingerprint collaborative obfuscation method provided in this application; Figure 3 This paper presents a schematic diagram of a cross-browser API fingerprint collaborative obfuscation device provided in this application. Figure 4 A structural block diagram of an exemplary electronic device that can be used to implement embodiments of this application is shown. Detailed Implementation

[0011] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0012] It should be understood that the steps described in the method embodiments of this application may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0013] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this application are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0014] It should be noted that the terms "a" and "a plurality of" used in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0015] When users browse the internet, websites record various details of their browser usage, such as the browser used, screen size, system fonts, and rendering details of browser graphics. By piecing together these collected details, websites can generate a browser identity for each user, corresponding to their browser fingerprint. To prevent the leakage of user information caused by this process, browser fingerprinting techniques have emerged. Conventional browser fingerprinting techniques generally involve: smoothing out all user fingerprints to make them look identical, virtualizing user fingerprints so that each generated fingerprint is unique, or installing plugins to return incorrect information to websites. Currently, existing browser fingerprinting solutions on the market include the following categories: 1) Browser Built-in Privacy Mode Technology. Taking Tor Browser, Firefox's strict privacy mode, and Brave Browser as examples, these browsers attempt to make all users appear the same on websites. Specifically, Tor Browser completely disables ports such as the Canvas API and WebGL API, returning blank or standardized responses. Firefox uses strict mode to block fingerprint reading scripts and restricts API call permissions. Brave Browser blocks known fingerprint recognition scripts by randomizing some API responses.

[0016] 2) Browser Extension Fingerprint Obfuscation Techniques. Taking browser extensions such as Privacy Badger, Canvas Defender, and Chameleon as examples, these techniques circumvent fingerprint recognition by modifying or forging browser API responses. Specifically, Canvas Defender adds random noise to the Canvas to alter the fingerprint characteristics. User-Agent Switcher randomizes or fixes the User-Agent string. Font FingerprintDefender returns a forged list of fonts.

[0017] 3) Proxy server technology. Taking HTTP proxy and VPN services as examples, browser requests are processed uniformly through intermediate proxy servers, and hardware information and network characteristics are standardized.

[0018] 4) Virtualization environment technology. For example, using Docker containers to run a standardized browser environment, creating a standardized browsing environment through virtual machines and containerization technology, and isolating the characteristics of the real device.

[0019] 5) Layered rendering technology. This type of technology is mainly used in the field of 3D graphics and has limited application in web component loading. Some advanced graphics rendering systems adopt multi-layered rendering strategies, such as the LOD (Level of Detail) technology in game engines, which renders 3D models of different precision according to distance and importance.

[0020] Existing fingerprint countermeasures have some effectiveness, but they are prone to the following shortcomings: Shortcoming 1: Severe Functionality Degradation. The biggest problem with existing privacy protection technologies is sacrificing functionality for privacy. This manifests in several ways: Complete API Disabling. For example, Tor Browser completely disables APIs like Canvas, WebGL, and AudioContext, causing numerous website functions to fail. CAPTCHA Display Failure. For instance, with the Canvas API disabled, Canvas-based CAPTCHAs cannot be displayed correctly. Rich Media Application Crashes. For example, online design tools, games, and video players that require WebGL support cannot run. Website Layout Inconsistencies. For instance, with font APIs restricted, websites cannot correctly render specific fonts.

[0021] Weakness 2: Obvious Anti-Fingerprinting Characteristics. Excessive privacy protection actually exposes users' privacy intentions, specifically manifested in: Suspicious Extreme Configurations. For example, browsers completely lacking Canvas fingerprinting or WebGL support are rare characteristics. Abnormal Standardization Characteristics. For example, all users returning the same standardized information can easily be identified as privacy-preserving users in batches. Abnormal Behavioral Patterns. For example, frequent API call failures and empty value returns are identified as suspicious traffic by websites.

[0022] Shortcoming 3: Lack of intelligence and adaptability. Existing obfuscation strategies are too simplistic, specifically manifested in: static forgery (e.g., extensions often use fixed forgery configurations, giving users the same new identity across all websites); complete randomness (e.g., generating entirely new random fingerprints with each visit, disrupting website session management mechanisms); and lack of context awareness (e.g., failing to differentiate between website types and user needs, applying the same protection strategy to all websites, lacking learning ability, such as the inability to adjust protection strength based on user behavior and preferences).

[0023] Weakness 4: Poor detection and evasion capabilities. Websites can detect and bypass existing adversarial techniques in various ways, specifically: API consistency checks, detecting forgery by comparing the return results of multiple APIs; behavioral pattern recognition, identifying adversarial tools by analyzing API call patterns; temporal feature analysis, detecting obfuscation behavior through API response time anomalies; and backup fingerprinting schemes, switching to backup recognition methods when the primary fingerprint is obfuscated.

[0024] Shortcoming 5: Lack of Information Consistency. The most critical flaw in existing technology is the lack of consistent coordination across APIs, specifically manifested in: Information Mismatch. For example, mismatches between Canvas fingerprints and WebGL hardware information can easily be detected through cross-validation. Logical Conflicts. For example, forged GPU information may not match the device type described by the User-Agent. Version Inconsistency. For example, logical contradictions may exist between the operating system version and the supported API versions. Abnormal Feature Combinations. For example, combinations of information returned by multiple APIs may not exist in reality.

[0025] Shortcoming 6: Performance and compatibility issues. Specifically: increased processing latency, with real-time forgery and API response processing increasing page load time; increased memory usage, as maintaining forged data and complex logic consumes additional resources; compatibility issues, with certain functions on some websites being incompatible with obfuscation techniques; and delayed updates, unable to adapt to new fingerprinting technologies in a timely manner.

[0026] Shortcoming 7: Lack of a holistic solution. This is specifically manifested in: fragmented technology, with various countermeasures operating independently and lacking a unified coordination mechanism; rigid strategies, making it impossible to dynamically adjust protection strategies according to the actual environment; and difficulty in measuring effectiveness, lacking an effective protection effectiveness evaluation and feedback mechanism.

[0027] Based on the aforementioned shortcomings, there is an urgent need for a novel fingerprint obfuscation technology solution that can protect user privacy while ensuring the normal operation of website functions, possess intelligent adaptability, and support cross-API information consistency coordination. In view of this, this application provides a cross-browser API fingerprint information collaborative obfuscation method, apparatus, and electronic device. Specifically, in its first aspect, this application provides a cross-browser API fingerprint information collaborative obfuscation method, which is applicable to any electronic device equipped with cross-browser API fingerprint information collaborative obfuscation functionality, including but not limited to personal mobile terminals, computers, or servers. Figure 1 As shown, the method includes the following steps: S11. In response to the user's operation instructions in the browser, intercept the API call request sent by the website accessed by the user; S12. Obtain the deployment environment description information of the browser and the type of website accessed by the user. The deployment environment description information includes: software description information and hardware description information. S13. Based on the website type, determine the target fingerprint countermeasure strategy corresponding to the operation instruction; S14. Based on the target fingerprint countermeasure strategy, generate the user's virtual identity profile based on the software description information and hardware description information, and perform consistency verification on the virtual identity profile. If the virtual identity profile consistency verification passes, virtual API information is generated based on the virtual identity profile, and the API call request is responded to through the virtual API information.

[0028] This application intercepts API requests sent by a website when a user visits a browser, determines a corresponding target fingerprint countermeasure strategy based on the type of website visited, and generates a virtual identity profile for the user based on the user's hardware and software description information. After the virtual identity profile passes a consistency check, virtual API information is generated based on the virtual identity profile and used to respond to API call requests initiated by the website. By constructing a virtual identity answer and virtualizing browser API execution information, this application can ensure the normal operation of website functions while protecting user privacy.

[0029] The following section will provide a detailed explanation of steps S11-S15 with specific examples: As one implementation method, responding to user operation instructions on the browser can specifically be an action instruction generated when the user enters or clicks a link in the browser. After receiving the operation instruction, the browser can respond to the user's operation by accessing the corresponding address or interface. The browser can be a browser on a computer or a browser on a mobile terminal. The user accesses the website by clicking or browsing the corresponding interface of the redirected URL through the user interface. For example, a user can access a blog website by clicking on a news blog page. During this process, the blog website will initiate an API call request to the user's device to obtain relevant user information. At this time, step S11 is executed to intercept the API call request sent by the website. Specifically, a browser API interceptor can be used to intercept call requests from different websites for different API interfaces.

[0030] The website requests access to the following API types: Canvas API, WebGL API, Navigator API, Font API, Audio API, and Screen API. The Canvas API provides information such as browser canvas operations and pixel data. The WebGL API provides browser renderer information and some hardware characteristics. The Navigator API provides browser user agent platform information. The Font API provides information such as the enumeration of the fonts currently used by the browser and font rendering. The Audio API provides information such as the audio information currently used by the browser, obtaining corresponding audio characteristics and audio fingerprints. The Screen API provides screen information of the current interface before browsing, such as screen information and resolution. Therefore, API call requests include: Canvas API call requests, WebGL call requests, Navigator call requests, etc.

[0031] As one implementation method, during step S11, this application sets up corresponding API interceptors for different APIs, such as Canvas API interceptor, WebGL API interceptor, Navigator API interceptor, Font API interceptor, Audio API interceptor, and Screen API interceptor. Each interceptor is responsible for capturing the call request of the corresponding API, and during step S15, it replaces the real API information with virtual API information and returns virtual API information to the website call request.

[0032] After intercepting the API call request, step S12 is executed to obtain the browser's deployment environment description information. This deployment environment description information includes: software description information and hardware description information. The software description information refers to information about the software environment in which the browser is installed, specifically including: operating system description information and browser description information. The operating system description information includes: operating system type and operating system version; the operating system version is indicated by the operating system version number, such as Windows 11. The browser description information includes: browser type and browser version; the browser version is indicated by the browser version number, such as Explorer 120. The hardware description information specifically refers to the hardware information of the device on which the browser is installed, including CPU model, memory model, monitor model, monitor resolution, etc.

[0033] In some possible embodiments, after performing step S11, the method further includes the following steps: S11-1. In response to the user's operation command on the browser, a pre-set context analysis program is invoked to perform demand analysis on the operation command and determine the domain name, function and risk level of the website accessed by the user. S11-2. Determine the type of website accessed by the user based on the domain name, function, and risk level.

[0034] The pre-built context analysis program is a pre-developed program with context parsing capabilities. It can be invoked by the user when they generate an operation command in the browser. As an example, when a user enters a URL or clicks a link in the browser, the context analysis program can be automatically launched to perform context analysis on the website, identify the website's domain name, functional requirements, and risk level, and provide basic information for subsequent intelligent decision-making.

[0035] During step S11-1, the context analysis program integrates a website classification database and machine learning algorithms. The machine learning algorithms automatically identify the business type of the target website visited by the user. For example, it identifies whether the target website's business is finance, e-commerce, or information. The main inputs to this context analysis program are the target website's URL and the user's historical behavior data. Based on the input, the context analysis program can automatically assess the website's type, risk level, and functions.

[0036] Specifically, the context analysis program analyzes the API interfaces that the website may need. Specifically, it can determine the API interfaces that the target website visited by the current user may use by using the information recorded in the website category database. For example, if the target website contains 3D display content, it will need to call the WebGL API. If the target website involves image processing, it will need to call the Canvas API, etc.

[0037] Furthermore, this context analysis program can assess a website's privacy breach risk based on factors such as its tracking history, privacy policies, and business model. As one implementation, the context analysis program integrates a website classification and identification sub-algorithm, which extracts the main domain from the complete URL and analyzes domain keywords and suffix features.

[0038] Furthermore, during step S11-2, a pre-trained classification model can be invoked to determine the website type characteristics, functions, and risk level matching the domain name. Here, "function" refers to the services provided by the website; for example, an e-commerce website's function is to provide shopping services (or functions). For instance, the pre-trained classification model can be used to classify websites according to the following classification logic: If the domain name matches the characteristics of a financial institution, the system returns: {Website Type: "Financial Services", Basic Risk: "High"}. For example, domain names related to banking, payment, securities, and insurance would return: {Website Type: "Financial Services", Basic Risk: "High"}. Otherwise, the system checks whether the domain name matches the characteristics of an e-commerce platform.

[0039] If the domain name matches the characteristics of an e-commerce platform, the following return value is returned: {Website Type: "E-commerce", Basic Risk: "Medium"}. For example, domain names related to shopping, online stores, or retail return: {Website Type: "E-commerce", Basic Risk: "Medium"}. Otherwise, the system determines whether the domain name matches the characteristics of news media.

[0040] If the domain name matches the characteristics of news media, the following result will be returned: {Website Type: "News & Information", Basic Risk: "Low"}. For example, domain names related to news, blogs, or information publishing will return: {Website Type: "News & Information", Basic Risk: "Low"}.

[0041] If none of the above types apply, the following will be returned: {Website Type: "General Website", Basic Risk: "Medium"}.

[0042] By employing the embodiments of this application, a pre-built context analysis program can quickly and intelligently analyze the type, function, and risk level of the website visited by the user based on the website URL. This helps to quickly determine the corresponding target fingerprint countermeasure strategy based on the analysis results provided by the context analysis program.

[0043] Furthermore, step S13 determines the target fingerprint countermeasure strategy corresponding to the operation command based on the determined website type. In some possible implementations, the target fingerprint countermeasure strategy can be determined through the following steps: S13-1. Determine the identity obfuscation strength of the website visited by the user based on the risk weight coefficient, privacy weight coefficient, and functional weight coefficient of the website type. S13-2. Determine the matching target fingerprint countermeasure strategy based on the identity confusion strength as the target fingerprint countermeasure strategy, wherein the identity confusion strength is positively correlated with the privacy protection strength and positively correlated with the degree of functional abnormality.

[0044] It is understandable that different types of websites have different requirements for collecting user information, and from the user's perspective, the importance of their own fingerprint varies from website to website. To ensure that the website's functions can be properly implemented while obfuscating the user's real fingerprint information, this application sets weight coefficients for three dimensions: website risk, privacy, and functionality. Based on these weight coefficients, the degree of identity information obfuscation required by a website is comprehensively evaluated.

[0045] As one implementation method, during step S13-1, the three weighting coefficients can be weighted and summed. The resulting weighted sum can be used to characterize the identity obfuscation strength of the website visited by the user. Specifically, the identity obfuscation strength satisfies the following formula: The identity confusion strength of the i-th website type = Σ(website risk weight i × functional requirement weight i × privacy protection weight i).

[0046] The higher the identity obfuscation strength value, the lower the correlation between the generated virtual identity fingerprint and the user's real identity fingerprint. For example, for news websites, with a preset risk weight of 0.9, privacy weight of 0.9, and function weight of 0.6, the corresponding identity obfuscation strength is 0.9 * 0.9 * 0.6 = 0.486. For e-commerce websites, with a preset risk weight of 0.6, privacy weight of 0.6, and function weight of 0.7, the corresponding identity obfuscation strength is 0.252. For financial websites, with a preset risk weight of 0.3, privacy weight of 0.4, and function weight of 0.9, the corresponding identity obfuscation strength is 0.108. News websites have the highest identity obfuscation strength and require a strong obfuscation strategy. This means that the virtual API information generated through this strong obfuscation strategy has a lower correlation with the real API information called by the website.

[0047] There is a mapping relationship between identity obfuscation strength and fingerprint countermeasure strategy; that is, different fingerprint countermeasure strategies should be adopted for websites with different identity obfuscation strengths. This mapping relationship between identity obfuscation strength and fingerprint countermeasure strategy can be pre-constructed based on historical fingerprint countermeasure strategies and historical website obfuscation effects. During the execution of step S13-2, the fingerprint countermeasure strategy corresponding to the calculated identity obfuscation strength can be obtained by looking up a table, which is the final target fingerprint countermeasure strategy to be executed.

[0048] As one implementation method, a context analysis program can be invoked to perform behavioral analysis and risk assessment on a website. For example, the website's API call frequency and interaction patterns can be obtained by accessing its historical records. Similarly, user preferences can be obtained by accessing user historical records. Furthermore, the context analysis program includes a pre-built risk assessment engine, which can obtain information such as the website's tracking risk level, privacy sensitivity, and functional importance. Further, based on the risk assessment results, an obfuscation strength is determined, and a corresponding target fingerprint countermeasure strategy is identified based on this obfuscation strength.

[0049] As one implementation method, a parallel processing mechanism can be used to simultaneously customize differentiated strategies for websites with three different risk levels. Specifically: For low-risk websites, a high-obfuscation strategy is adopted. This strategy is suitable for websites such as news portals, personal blogs, information query websites, and open-source project pages. The key features of this low-risk website processing strategy are: maximizing privacy protection while accepting a certain degree of functional limitations. Specifically, this is achieved by returning highly standardized, common device configurations, significantly reducing the uniqueness of fingerprints. The specific obfuscation scheme includes: using a preset template for Canvas fingerprints, returning the most basic WebGL configuration, and standardizing the user agent to a common version.

[0050] The strategy for handling medium-risk websites falls under the category of medium obfuscation. This strategy is applicable to websites such as e-commerce, social media, online services, and SaaS applications. The key characteristics of this strategy are: balancing privacy protection with functional integrity, ensuring the normal operation of core business functions. Specifically, this is achieved by generating reasonable virtual device configurations, maintaining functional availability while providing effective protection. The specific obfuscation scheme involves: Canvas retaining necessary features to support CAPTCHA display, and WebGL providing sufficient information to support 3D display, ensuring the normal operation of the shopping cart and payment processes.

[0051] The strategy for handling high-risk websites is a light obfuscation strategy. This strategy is applicable to website types such as banking websites, payment platforms, government portals, and medical systems. The key characteristics of this high-risk website handling strategy are: minimizing the level of obfuscation to ensure that it does not trigger anomaly detection in security systems. Specifically, this is achieved by making only minor adjustments to non-critical information while retaining most of the genuine device characteristics. The specific obfuscation scheme primarily modifies non-sensitive system information to avoid affecting multi-factor authentication and device fingerprint verification.

[0052] It is understandable that different risk levels and website types require different target fingerprint countermeasures, and the corresponding obfuscation rules also differ. For example, for high-risk websites, to ensure their normal functionality, a fingerprint countermeasure strategy with the first level of obfuscation can be used; for medium-risk websites, a fingerprint countermeasure strategy with the second level of obfuscation can be used; and for low-risk websites, a fingerprint countermeasure strategy with the third level of obfuscation can be used. The first level of obfuscation is less than the second level, which is less than the third level. The higher the level of obfuscation, the lower the correlation between the generated virtual identity profile and the real identity profile.

[0053] The same fingerprint countermeasure strategy specifies obfuscation rules for different API information. For example, the following obfuscation scheme is used for the Canvas API: For high-risk websites, light obfuscation is used to ensure normal Canvas functionality. For medium-risk websites, medium obfuscation is used to balance privacy and functionality. For low-risk websites, strong obfuscation is used to maximize user privacy protection. The following obfuscation scheme is used for the WebGL API: For financial websites, real information must be allowed to ensure security verification. For e-commerce websites, medium obfuscation is used to ensure 3D display functionality. For news websites, since they have no special functional requirements, strong obfuscation can be used. The obfuscation scheme for the Navigator API adjusts the degree of modification of user agent information according to the risk level. For example, font information obfuscation determines the font list based on website functional requirements and returns the corresponding font list. For some special policies, such as financial websites allowing some real APIs to pass, obfuscation of this API is not required. Priority settings for critical business function protection are established, with different levels of obfuscation corresponding to different priorities.

[0054] In this application, a virtual identity profile refers to a complete and logically consistent set of virtual device configuration information, including operating system, hardware specifications, browser version, etc., used to replace the user's real device information. As described above, different fingerprint countermeasure strategies correspond to different levels of obfuscation in the identity profiles. Therefore, when performing step S14, it is necessary to obfuscate the user's real device information according to the target fingerprint countermeasure strategy corresponding to the type of website the user visits, in order to generate the corresponding virtual identity profile.

[0055] As one implementation method, step S14 can be achieved through the following steps: S14-1. Based on the software description information conversion relationship specified by the target fingerprint countermeasure strategy, convert the software description information into virtual software information; S14-2. Based on the hardware description information conversion relationship specified by the target fingerprint countermeasure strategy, convert the hardware description information into virtual hardware information; S14-3. Store the virtual software information and the virtual hardware information in the virtual identity file path corresponding to the user.

[0056] In this application, the target fingerprint countermeasure strategy specifies obfuscation rules for the user's real device information, specifically including: software description information conversion relationships and hardware description information conversion relationships. By specifying the software description information conversion relationships, the user's real software description information for the browser can be converted into virtual software information, and the specified hardware description information can be used to convert the user's real hardware description information for the browser into virtual hardware description information. For example, converting the operating system version from Windows 11 to Windows 10 can employ a backward compatibility strategy to avoid using too new a system version. Converting the browser version from Chrome 120 to Chrome 118 can employ a slight version adjustment to stay within a reasonable version range. Converting the CPU model from Intel i7 to Intel i5 can employ a performance level adjustment strategy to reduce the uniqueness of the hardware configuration. Converting the GPU model from RTX 4080 to GTX 1660 can employ a GPU downgrading strategy to select a more common graphics card model. Converting a 4K monitor to a 1080P monitor can employ a resolution normalization strategy to use the most common display configuration. Further, step S14-3 is executed to store all the converted information in the same path.

[0057] As another implementation, a basic identity template can be selected from the identity template library based on the user's actual device type, and then the appropriate device configuration information can be filtered out in conjunction with the risk level setting. Furthermore, the appropriate device configuration information is populated into the basic identity template to obtain a virtual identity profile.

[0058] As another implementation, a pre-built virtual identity profile generation program (also known as a virtual identity profile generator) can generate and output a virtual identity profile based on user context information output by a context analysis program and the analyzed website type and website risk level. Specifically, the virtual identity profile generation program can generate the corresponding virtual identity profile according to the following steps: Step 1: Initialize the system, including: loading the device configuration database; initializing the consistency verifier (used to perform consistency checks on virtual identity profiles).

[0059] Step 2: Device Category Identification. This includes detecting real-world user environment characteristics (mobile devices, high-end desktops, standard desktops) and classifying devices based on hardware capabilities.

[0060] Step 3: Candidate Configuration Filtering. This includes filtering configurations from the hardware database that match the actual device categories and filtering suitable sets of virtual configurations based on risk level.

[0061] Step 4: Optimal Configuration Selection. This includes evaluating the reasonableness score of each candidate configuration and selecting the optimal configuration that balances privacy protection and functional compatibility.

[0062] Step 5: Complete Identity Profile Construction. This includes: extracting operating system information from the selected configuration to build a virtual operating system, selecting and setting compatible browser versions. For hardware configuration: selecting a processor that matches the actual performance level, configuring a graphics processor that matches the CPU, setting an appropriate memory size, configuring common screen resolutions, and generating corresponding API support capabilities based on the hardware configuration.

[0063] In some possible embodiments, the API call requests include: Canvas API call requests, WebGL call requests, and Navigator call requests. The Canvas API call request allows the website to obtain GPU-related rendering features through Canvas drawing operations. The WebGL API call allows the website to directly query GPU hardware information, including renderer model and manufacturer information. The Navigator API call allows the website to obtain system information such as user agent strings, platform information, and hardware concurrency. Traditional fingerprinting techniques often process each API independently, leading to contradictory returned information. For example, the Canvas fingerprint might display high-end GPU features, but WebGL might return low-end GPU information. This inconsistency is easily detected by cross-validation by the website. Therefore, this application introduces a virtual identity profile consistency check to verify the consistency of the generated virtual identity profile, ensuring that all virtual API information is generated based on the same virtual identity profile, thereby ensuring logical consistency of all API responses.

[0064] If the virtual identity profile consistency verification passes, generating virtual API information based on the virtual identity profile includes: Generate a corresponding Canvas fingerprint feature based on the virtual CPU model and virtual GPU model in the virtual identity file, and respond to the Canvas API call request based on the Canvas fingerprint feature; Generate corresponding WebGL renderer information based on the virtual GPU model in the virtual identity file, and respond to the WebGL call request based on the WebGL renderer information; User agent information is generated based on the virtual GPU model and the virtual software operating system version number in the virtual identity file, and the Navigator call request is responded to based on the user agent information.

[0065] Among them, Canvas fingerprint features can be generated by utilizing subtle differences in HTML5 Canvas API drawing operations, WebGL renderer information can be identified by obtaining GPU hardware information and rendering features through the WebGL graphics API, in addition, the device's font features can be generated by detecting the list of fonts installed on the system, and the device's audio features can be identified by measuring subtle differences in audio processing through the Web Audio API.

[0066] Furthermore, consistency verification is performed on the generated virtual identity profile. As one implementation method, before storing the virtual identity profile in step S14-3, the existence of the virtual identity profile, its version time logic, and API support capability matching are verified. If the virtual identity profile has a reasonable existence, correct version time logic, and matching API support capability, then the consistency verification of the virtual identity profile is deemed successful. Here, reasonable existence checks the authenticity and logical consistency of each configuration in the virtual identity profile to ensure that there are no hardware combinations that are impossible in reality. Version time logic refers to whether the generation time of the corresponding software system or functional module conforms to the publisher's release time logic; if not, the version time logic is incorrect. API support matching refers to whether the API is supported for invocation; if not, the API support capability is mismatched. It can be understood that the consistency verification in this application mainly includes the following parts: 1) Compatibility check: Ensure the operating system version matches the hardware support capabilities. 2) Reasonableness verification: Verify that the hardware combination actually exists in reality. 3) Matching confirmation: Check whether the performance levels of the CPU and GPU match. 4) Commonality assessment: Prioritize configuration combinations with higher market share.

[0067] As one implementation method, a pre-built API response consistency coordinator (also known as an API response consistency coordinator) can determine the consistency of the generated virtual identity profile based on the input virtual identity profile and the API call request. As an example, the following consistency coordination algorithm can be used to generate virtual API information after API consistency has been achieved: N1. Select a basic virtual identity template. This includes: choosing a template from the template library based on the user's actual operating system type and selecting a suitable identity template based on the risk level.

[0068] N2. Ensure the hardware configuration is appropriate. This includes: verifying the compatibility between the CPU and GPU, checking the correspondence between memory size and device class, and confirming the consistency between monitor resolution and hardware capabilities.

[0069] N3. Generate coordinated responses for each API. For example, generate Canvas fingerprint features based on virtual GPU and CPU characteristics. WebGL renderer information can be constructed based on the virtual GPU and operating system. Navigator information can be generated using virtual browser and operating system information, as well as a font list based on the virtual operating system version, and screen information can be configured using a virtual display.

[0070] N4. Cross-validation for consistency. This involves checking the logical compatibility of all API responses, verifying the match between hardware performance and software capabilities, and confirming that there is no contradictory information.

[0071] N5. Return the complete set of coordinated responses.

[0072] As one implementation method, consistency verification can be performed through the following steps: Step A: Initialize the coordinator. This includes: loading the virtual identity profile for the current session and creating a response cache store. Step B: Canvas API response coordination. This includes: Step B1: Check the cache, including generating a cache key-value pair: "canvas_operation type_canvas size". If the result of the same request exists in the cache, return it directly.

[0073] Step B2: Generate a GPU-specific fingerprint, including: obtaining the GPU model and operating system information from the virtual identity; using the GPU features as a random seed to generate a Canvas fingerprint; and ensuring that the same virtual GPU generates the same Canvas features.

[0074] Step B3, caching and returning the results, includes: storing the generated fingerprint in the cache and returning the Canvas fingerprint that matches the virtual GPU.

[0075] Step 3: WebGL API response coordination. This may include: Generate the corresponding response based on the WebGL parameter type: If the WebGL parameter is "RENDERER" (renderer information): Returns the renderer name of the virtual GPU. Return format: "ANGLE (GPU manufacturer, GPU model, DirectX version information)" If the WebGL parameter is "VENDOR" (vendor information): Returns the vendor name of the virtual GPU If the WebGL parameter = "VERSION" (version information): Returns the WebGL version that matches the virtual system. otherwise: Generate other parameter values ​​consistent with the virtual identity.

[0076] This will generate the corresponding WebGL renderer information.

[0077] Step 4: Verify GPU information consistency. Step D1: Extract virtual GPU information. This includes: obtaining the GPU manufacturer (such as NVIDIA, AMD, Intel) and GPU model (such as GTX 1660, RTX 3060, etc.) from the virtual identity profile.

[0078] Step D2: Construct a standard format response. This includes organizing GPU information according to the browser's standard format and ensuring that the information format is consistent with the actual hardware response.

[0079] Step 5: GPU-specific fingerprint feature generation. This includes: Step E1, Seed Generation, includes: using the virtual GPU model as the primary seed and combining it with the virtual operating system version as the secondary seed.

[0080] Step E2: Simulate GPU rendering. This includes simulating rendering results based on GPU performance characteristics and generating image data that conforms to those characteristics.

[0081] Step E3: Return consistent fingerprints. This includes ensuring that the same virtual GPU always produces the same fingerprint and that different virtual GPUs produce significantly different fingerprint features.

[0082] Step 6: Return the reconciled API response.

[0083] It is understood that the consistency coordination engine in this application is primarily responsible for Canvas response coordination, WebGL response coordination, and Navigator response coordination. For example, if the generated virtual identity profile is Pad + Windows 10 + Chrome 118 + Intel i5 + GTX 1660, then the Canvas response coordination could generate a corresponding Canvas fingerprint feature based on the i5+GTX1660 configuration in the virtual identity. The WebGL response coordination could return renderer information that perfectly matches the virtual GPU (GTX1660). The Navigator response coordination could provide user agent information consistent with the virtual system (Windows 10 + Chrome 118). When performing consistency checks on the above response coordinations, it is necessary to ensure that the Canvas fingerprint feature, WebGL renderer information, and performance parameters all point to the same GPU model to ensure that the API response information passes cross-validation on the website.

[0084] In addition, it can verify operating system matching (verify that the system version in the user agent string matches the API support capabilities), browser compatibility (check the matching of browser version with WebGL version and Canvas feature support), and hardware performance logic (ensure that the performance levels of CPU and GPU match and the memory size is reasonable).

[0085] By using the embodiments of this application, corresponding virtual response information is generated for different APIs such as Canvas, WebGL, fonts, and hardware. By performing consistency verification on the virtual identity file, strict logical consistency checks, device matching verification, version compatibility checks, and abnormal pattern recognition are performed. Since all virtual API information is generated based on the same virtual identity file, the information source can be ensured to be unified and the logical consistency of the information returned by different browser APIs can be ensured.

[0086] As an example of an application scenario, the cross-browser API fingerprint information collaborative obfuscation method provided in this application can be applied to, for example... Figure 2 The virtual identity profile collaborative obfuscation system shown includes: a network access layer, a context-aware regulator, a virtual identity profile manager, a cross-API consistency coordinator, and a browser API interception layer. The network access layer is used to determine the risk and obfuscation level of different website types (news blogs, e-commerce platforms, financial services) and to intelligently select strategies based on the determined information. It generates corresponding obfuscation policy instructions for the context-aware regulator, which then invokes the website type identifier, behavior pattern analyzer, and risk assessment engine integrated into a pre-built context analysis program.

[0087] The website type identifier performs domain name analysis, functional requirements analysis, and reputation assessment. The behavior pattern analyzer performs API call frequency analysis, interaction pattern analysis, and user preference analysis. The risk assessment engine tracks website risk, analyzes privacy sensitivity and functional importance, and aggregates contextual information. This contextual information is output to the virtual identity profile manager, which generates identity profiles that combine device information, verify reasonableness, and perform consistency checks. After the consistency check passes, the identity profile storage manages the corresponding virtual identity profiles according to session state, profile lifecycle, and version control, ultimately generating a profile database (including Windows configuration libraries, macOS configuration libraries, and Linux configuration libraries) to obtain virtual identity information.

[0088] Furthermore, the API response generator integrated in the cross-API consistency coordinator generates a Canvas fingerprint, constructs WebGL information, generates a font list, and returns hardware information. The consistency verifier integrated in the cross-API consistency coordinator performs logical consistency checks, device matching verification, version compatibility checks, and anomaly pattern identification. Finally, step S15 coordinates the response to the corresponding API request based on the virtual API information.

[0089] Specifically, various interceptors integrated into the browser's API interception layer intercept the corresponding API requests and respond to the corresponding API requests based on the coordinated API response.

[0090] Based on the method provided in the first aspect, in the second aspect, this application provides a cross-browser API fingerprint information collaborative obfuscation device, wherein, as Figure 3 As shown, the device 30 includes: API interception module 301 is used to intercept API call requests sent by the website accessed by the user in response to the user's operation instructions in the browser. The network access module 302 is used to obtain the deployment environment description information of the browser and the type of website accessed by the user. The deployment environment description information includes: software description information and hardware description information. Based on the website type, the module determines the target fingerprint countermeasure strategy corresponding to the operation instruction. Virtual identity profile management module 303 is used to generate the user's virtual identity profile based on the software description information and hardware description information according to the target fingerprint countermeasure strategy; The cross-API consistency coordination module 304 is used to perform consistency verification on the virtual identity file. If the consistency verification of the virtual identity file passes, virtual API information is generated based on the virtual identity file, and the API call request is responded to through the virtual API information.

[0091] In some possible embodiments, after the step of intercepting the API call request sent by the website accessed by the user, the API interception module 301 is further configured to: In response to the user's operation command on the browser, a pre-built context analysis program is invoked to perform demand analysis on the operation command and determine the domain name, function and risk level of the website visited by the user. The type of website accessed by the user is determined based on the domain name, function, and risk level.

[0092] In some possible embodiments, determining the target fingerprint countermeasure strategy corresponding to the operation instruction based on the website type includes: The identity obfuscation strength of the website visited by the user is determined based on the risk weight coefficient, privacy weight coefficient, and functional weight coefficient of the website type. The target fingerprint countermeasure strategy is determined based on the identity obfuscation strength, wherein the identity obfuscation strength is positively correlated with the privacy protection strength and the degree of functional abnormality.

[0093] In some possible embodiments, the step of generating the user's virtual identity profile based on the software description information and hardware description information according to the target fingerprint countermeasure strategy, and performing consistency verification on the virtual identity profile, includes: According to the software description information conversion relationship specified by the target fingerprint countermeasure strategy, the software description information is converted into virtual software information; According to the hardware description information conversion relationship specified by the target fingerprint countermeasure strategy, the hardware description information is converted into virtual hardware information; The virtual software information and the virtual hardware information are stored in the virtual identity profile path corresponding to the user.

[0094] In some possible embodiments, the API call request includes: a Canvas API call request, a WebGL call request, and a Navigator call request; the step of generating virtual API information based on the virtual identity profile if the virtual identity profile consistency verification passes includes: Generate a corresponding Canvas fingerprint feature based on the virtual CPU model and virtual GPU model in the virtual identity file, and respond to the Canvas API call request based on the Canvas fingerprint feature; Generate corresponding WebGL renderer information based on the virtual GPU model in the virtual identity file, and respond to the WebGL call request based on the WebGL renderer information; User agent information is generated based on the virtual GPU model and the virtual software operating system version number in the virtual identity file, and the Navigator call request is responded to based on the user agent information.

[0095] In some possible embodiments, before storing the virtual software information and the virtual hardware information in the virtual identity profile path corresponding to the user, the cross-API consistency coordination module is further configured to: The existence of the virtual identity file is verified for its rationality, version time logic, and API support capability matching. If the existence of the virtual identity file is reasonable, the version time logic is correct, and the API support capability is matched, then the consistency verification of the virtual identity file is determined to be successful.

[0096] In some possible embodiments, the cross-API consistency coordination module is further configured to: Load the virtual identity profile corresponding to the user from the virtual identity profile path and create a response cache storage area; According to each API call request, a corresponding cache key value is generated in the cache storage area. The Canvas fingerprint feature is cached under the cache key value corresponding to the Canvas API call request. The WebGL renderer information is cached under the cache key value corresponding to the WebGL call request. The user agent information is cached under the cache key value corresponding to the Navigator call request. The API call request is responded to by invoking information stored in the response cache.

[0097] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in this application comply with relevant laws and regulations and do not violate public order and good morals.

[0098] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0099] Thirdly, exemplary embodiments of this application also provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the electronic device to perform a method according to an embodiment of this application.

[0100] An exemplary embodiment of this application also provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0101] An exemplary embodiment of this application also provides a computer program product, including a computer program, wherein, when executed by a computer's processor, the computer program is used to cause the computer to perform a method according to an embodiment of this application.

[0102] refer to Figure 4The present invention describes a structural block diagram of an electronic device 400 that can serve as a server or client of this application, which is an example of a hardware device that can be applied to various aspects of this application. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the application described and / or claimed herein.

[0103] like Figure 4 As shown, the electronic device 400 includes a computing unit 401, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM 402) or a computer program loaded from a storage unit 408 into a random access memory (RAM 403). The RAM 403 may also store various programs and data required for the operation of the electronic device 400. The computing unit 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output interface (I / O interface 405) is also connected to the bus 404.

[0104] Multiple components in electronic device 400 are connected to I / O interface 405, including: input unit 406, output unit 407, storage unit 408, and communication unit 409. Input unit 406 can be any type of device capable of inputting information to electronic device 400. Input unit 406 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 407 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 408 may include, but is not limited to, disks and optical discs. Communication unit 409 allows electronic device 400 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0105] The computing unit 401 can be a variety of general-purpose and / or dedicated processing components with processing and computing capabilities. Some examples of the computing unit 401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 401 performs the various methods and processes described above. For example, in some embodiments, the aforementioned cross-browser API fingerprint information co-obfuscation method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 408. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 400 via ROM 402 and / or communication unit 409. In some embodiments, the computing unit 401 can be configured to perform the aforementioned cross-browser API fingerprint information co-obfuscation method by any other suitable means (e.g., by means of firmware).

[0106] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0107] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0108] As used in this application, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0109] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0110] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0111] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

Claims

1. A cross-browser API fingerprint information collaborative obfuscation method, characterized in that, The method includes: In response to user commands in the browser, intercept API call requests sent by the website accessed by the user; Obtain the deployment environment description information of the browser and the type of website accessed by the user. The deployment environment description information includes: software description information and hardware description information. Based on the website type, determine the target fingerprint countermeasure strategy corresponding to the operation instruction; According to the target fingerprint countermeasure strategy, a virtual identity profile of the user is generated based on the software description information and hardware description information, and the virtual identity profile is verified for consistency. If the virtual identity profile consistency verification passes, virtual API information is generated based on the virtual identity profile, and the API call request is responded to through the virtual API information.

2. The method of claim 1, wherein, After the step of intercepting the API call request sent by the website accessed by the user, the method further includes: In response to the user's operation command on the browser, a pre-built context analysis program is invoked to perform demand analysis on the operation command and determine the domain name, function and risk level of the website visited by the user. The type of website accessed by the user is determined based on the domain name, function, and risk level.

3. The method according to claim 1, characterized in that, The step of determining the target fingerprint countermeasure strategy corresponding to the operation instruction based on the website type includes: The identity obfuscation strength of the website visited by the user is determined based on the risk weight coefficient, privacy weight coefficient, and functional weight coefficient of the website type. The target fingerprint countermeasure strategy is determined based on the identity obfuscation strength, wherein the identity obfuscation strength is positively correlated with the privacy protection strength and the degree of functional abnormality.

4. The method according to claim 1, characterized in that, The step of generating a virtual identity profile for the user based on the software description information and hardware description information according to the target fingerprint countermeasure strategy, and performing a consistency check on the virtual identity profile, includes: According to the software description information conversion relationship specified by the target fingerprint countermeasure strategy, the software description information is converted into virtual software information; According to the hardware description information conversion relationship specified by the target fingerprint countermeasure strategy, the hardware description information is converted into virtual hardware information; The virtual software information and the virtual hardware information are stored in the virtual identity profile path corresponding to the user.

5. The method according to claim 1, characterized in that, The API call requests include: Canvas API call requests, WebGL call requests, and Navigator call requests; if the virtual identity profile consistency verification passes, generating virtual API information based on the virtual identity profile includes: Generate a corresponding Canvas fingerprint feature based on the virtual CPU model and virtual GPU model in the virtual identity file, and respond to the Canvas API call request based on the Canvas fingerprint feature; Generate corresponding WebGL renderer information based on the virtual GPU model in the virtual identity file, and respond to the WebGL call request based on the WebGL renderer information; User agent information is generated based on the virtual GPU model and the virtual software operating system version number in the virtual identity file, and the Navigator call request is responded to based on the user agent information.

6. The method according to claim 4, characterized in that, Before storing the virtual software information and the virtual hardware information in the virtual identity profile path corresponding to the user, the method further includes: The existence of the virtual identity file is verified for its rationality, version time logic, and API support capability matching. If the existence of the virtual identity file is reasonable, the version time logic is correct, and the API support capability is matched, then the consistency verification of the virtual identity file is determined to be successful.

7. The method according to claim 5, characterized in that, The method further includes: Load the virtual identity profile corresponding to the user from the virtual identity profile path and create a response cache storage area; According to each API call request, a corresponding cache key value is generated in the cache storage area. The Canvas fingerprint feature is cached under the cache key value corresponding to the Canvas API call request. The WebGL renderer information is cached under the cache key value corresponding to the WebGL call request. The user agent information is cached under the cache key value corresponding to the Navigator call request. The API call request is responded to by invoking information stored in the response cache.

8. A cross-browser API fingerprint information collaborative obfuscation device, characterized in that, The device includes: The API interception module is used to intercept API call requests sent by the website accessed by the user in response to the user's operation instructions in the browser. The network access module is used to obtain the deployment environment description information of the browser and the type of website accessed by the user. The deployment environment description information includes: software description information and hardware description information. Based on the website type, the module determines the target fingerprint countermeasure strategy corresponding to the operation instruction. The virtual identity profile management module is used to generate the user's virtual identity profile based on the software description information and hardware description information according to the target fingerprint countermeasure strategy. The cross-API consistency coordination module is used to perform consistency verification on the virtual identity profile. If the consistency verification of the virtual identity profile passes, virtual API information is generated based on the virtual identity profile, and the API call request is responded to through the virtual API information.

9. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing a program; wherein the program includes instructions that, when executed by the processor, cause the processor to perform the method according to any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.

Images