Browser tab page data storage methods that support data encryption

Abstract

This invention provides a browser tab page data storage method supporting data encryption, comprising: real-time monitoring of browser tab page interaction behavior to generate dynamic factors; combining the tab page's process ID to generate a session key that dynamically changes with the tab page's lifecycle; encrypting structured and unstructured data of the tab page separately based on an adaptive encryption strategy; wherein, structured data is encrypted hierarchically according to field sensitivity, and unstructured data is encrypted through a key-data mapping binding; the encrypted data is associated with and stored as a timestamp credential of the session key, and decryption is only allowed to be performed in the memory of the tab page process that generated the session key, with the session key not being stored locally; when the tab page is closed, the session key and the decrypted data in the process memory are simultaneously cleared. This invention overcomes the current shortcomings of not being able to dynamically generate keys and not being able to prevent keys from being stored locally.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method for storing browser tab pages that supports data encryption. Background Technology

[0002] As browser functionality continues to expand, tabs have become the core platform for users to multitask simultaneously. The data stored on tabs includes sensitive information such as user account passwords, browsing history, and form information, making the need for secure storage of tab data increasingly prominent.

[0003] Currently, browser tab page data storage mainly adopts local storage technologies, such as IndexedDB and LocalStorage. However, existing technologies have obvious drawbacks: First, key generation largely depends on fixed browser attributes (such as tab page URL and fixed device identifier). After generation, it remains static throughout the tab page's lifecycle, making it vulnerable to being stolen by malicious programs through memory scanning. Furthermore, it cannot dynamically adjust key security based on user interaction behavior. Second, session keys are at risk of being stored locally. Some solutions temporarily store keys in the browser cache or local configuration files, which may remain even after the tab is closed, posing a potential risk of data leakage.

[0004] In summary, current browser tab data storage methods are insufficient in terms of key dynamism and storage security, making it difficult to meet users' high-security storage needs for sensitive data. There is an urgent need for a tab data storage solution that can achieve dynamic key generation, differentiated data encryption, key non-localization, and process-level security isolation. Summary of the Invention

[0005] The main objective of this invention is to provide a browser tab page data storage method that supports data encryption, aiming to overcome the current shortcomings of not being able to dynamically generate keys and not being able to keep keys stored in the local memory.

[0006] To achieve the above objectives, the present invention provides a browser tab page data storage method that supports data encryption, comprising the following steps:

[0007] Real-time monitoring of browser tab page interaction behavior generates dynamic factors, which, combined with the tab page's process ID, generate a session key that dynamically changes with the tab page's lifecycle.

[0008] An adaptive encryption strategy is used to encrypt both structured and unstructured data on the tab page. Structured data is encrypted according to the sensitivity of each field, while unstructured data is encrypted through a mapping between a key and the data.

[0009] The encrypted data is associated with the timestamp credential of the session key and stored, and the decryption operation is only allowed to be completed in the memory of the tag page process that generates the session key; the session key is not stored on the ground.

[0010] When the tab is closed, the session key and decrypted data in the process memory are cleared simultaneously.

[0011] Furthermore, real-time monitoring of browser tab page interaction behavior generates dynamic factors, including:

[0012] Get the sequence of user interaction events within the tab page;

[0013] Temporal features are extracted from the user interaction event sequence to obtain a multidimensional feature vector including the standard deviation of the event interval and the entropy of the operation intensity.

[0014] Through nonlinear transformation, the multidimensional feature vector is mapped into a dynamic factor that is updated in real time as the time window slides, and the difference in dynamic factors between adjacent time windows is positively correlated with the activity level of interactive behavior.

[0015] Furthermore, the user interaction event sequence includes the click coordinate change rate, the character input interval in the input box, the scrolling operation acceleration, and the page element hover duration.

[0016] Furthermore, by combining the process ID of the tab page, a session key that dynamically changes with the lifecycle of the tab page is generated, including:

[0017] The process ID of the tab page is hashed to obtain a fixed identifier value. The dynamic factor is divided into multiple time segments according to a preset time slice and a feature hash value is generated for each segment.

[0018] Using the fixed identifier value as the initial seed, the feature hash values ​​of each time segment are used sequentially as the iterative perturbation parameters of the chaotic mapping to generate a segmented key corresponding to the number of time slices;

[0019] The weight of the segmented keys is dynamically adjusted by the intensity of real-time interactive behavior during the tab page's lifecycle, forming a session key that is continuously and dynamically updated throughout the entire lifecycle of the tab page, from loading to closing.

[0020] Furthermore, based on an adaptive encryption strategy, the structured and unstructured data of the tag page are encrypted separately, including:

[0021] For structured data, each field is classified; high-sensitivity fields are encrypted in real time using the SM4 algorithm combined with a dynamically changing session key, medium-sensitivity fields are encrypted using the AES-CTR algorithm combined with time-slice segmented key encryption of the session key, and low-sensitivity fields are encrypted using lightweight XOR encryption.

[0022] For unstructured data, it is divided into n data fragments according to the data block size. At the same time, the session key is split into n key fragments, and a one-to-one mapping relationship between data fragments and key fragments is established. The i-th data fragment is encrypted with the i-th key fragment, and the mapping relationship is dynamically obfuscated by the hash value of the tab process ID. During decryption, the integrity of the data fragments and the consistency of the mapping relationship must be verified at the same time.

[0023] Furthermore, the encrypted data is associated with and stored as a timestamp credential of the session key, and decryption is only permitted within the memory of the tag page process that generated the session key; the session key is not stored locally, including:

[0024] The encrypted data is used to generate a data fingerprint according to the data type. The timestamp certificate of the session key is used to generate an association certificate with the data fingerprint. An invisible watermark of the tab process ID is embedded in the association certificate.

[0025] An independent encryption operation area is allocated in the memory of the tab page process that generates the session key. The encryption operation area only receives data decryption requests with the associated credentials, and the session key exists in the form of temporary electrical signal storage during the decryption process, without generating disk cache or memory snapshot.

[0026] When storing encrypted data, verify the match between the hidden watermark in the associated credential and the process ID of the current storage partition. Only encrypted data that matches can be written to the preset storage area, and the storage area does not include metadata for reverse-derived session keys.

[0027] Furthermore, the encrypted data is associated with and stored as a timestamp credential of the session key, and decryption is only permitted within the memory of the tag page process that generated the session key; the session key is not stored locally, including:

[0028] The encrypted data is used to generate a data digest. The timestamp credential of the session key and the data digest are XORed with the process ID to generate an association tag. The association tag embeds a tag lifecycle stage identifier.

[0029] In the memory of the tag page process that generates the session key, a hardware-isolated encryption operation sandbox is partitioned. The encryption operation sandbox only accepts decryption requests with the associated tag, and the session key exists in the form of a dynamic electrical signal stream during the decryption process. Static residency is avoided by refreshing the memory address offset in real time. The session key only participates in the decryption operation within the encryption operation sandbox and does not generate disk logs or memory snapshots. Only the decrypted usable data can be obtained outside the sandbox.

[0030] The encrypted data is stored in the encrypted partition of the browser's local storage, and the associated tags are stored in a separate credential partition. The two partitions are associated through an implicit hash mapping of the tag page process ID. Data reading can only be triggered when the process ID, associated tag, and lifecycle stage identifier match.

[0031] Furthermore, it also includes:

[0032] Throughout the lifecycle of the tag page, real-time data on the dynamic changes in user biometrics during page interactions is collected.

[0033] When the deviation between the dynamic change data of biometrics and the historical baseline exceeds a preset threshold, the current session key is automatically frozen and the session key regeneration process is triggered. During the freeze period, only the metadata of the encrypted data is allowed to be read, while decryption operations are prohibited.

[0034] The present invention also provides a browser tab page data storage device that supports data encryption, comprising:

[0035] The generation unit is used to monitor the interactive behavior of browser tab pages in real time to generate dynamic factors, and combine them with the process ID of the tab page to generate a session key that changes dynamically with the life cycle of the tab page.

[0036] The encryption unit is used to encrypt the structured and unstructured data of the tag page separately based on an adaptive encryption strategy; among them, the structured data is encrypted according to the sensitivity of the fields, and the unstructured data is encrypted through the mapping and binding of keys and data.

[0037] The storage unit is used to associate and store the encrypted data with the timestamp credentials of the session key, and the decryption operation is only allowed to be completed in the memory of the tag page process that generates the session key; the session key is not stored on the ground.

[0038] The clearing unit is used to simultaneously clear the session key and decrypted data in the process memory when the tab page is closed.

[0039] This invention provides a browser tab page data storage method supporting data encryption, comprising: real-time monitoring of browser tab page interaction behavior to generate dynamic factors; combining the tab page's process ID to generate a session key that dynamically changes with the tab page's lifecycle; encrypting structured and unstructured data of the tab page separately based on an adaptive encryption strategy; wherein, structured data is encrypted hierarchically according to field sensitivity, and unstructured data is encrypted through a key-data mapping binding; the encrypted data is associated with and stored as a timestamp credential of the session key, and decryption is only allowed in the memory of the tab page process that generated the session key, with the session key not being stored locally; when the tab page is closed, the session key and the decrypted data in the process memory are simultaneously cleared. In this invention, browser tab page interaction behavior generates dynamic factors, which, combined with the tab page's process ID, generate a session key that dynamically changes with the tab page's lifecycle; simultaneously, the encrypted data is associated with and stored as a timestamp credential of the session key, and decryption is only allowed in the memory of the tab page process that generated the session key, with the session key not being stored locally, overcoming the current shortcomings of not being able to dynamically generate keys and not being able to prevent keys from being stored locally. Attached Figure Description

[0040] Figure 1 This is a schematic diagram of the steps of a browser tab page data storage method supporting data encryption in one embodiment of the present invention;

[0041] Figure 2 This is a structural block diagram of a browser tab page data storage device that supports data encryption in one embodiment of the present invention;

[0042] Figure 3 This is a schematic block diagram of the structure of a computer device according to an embodiment of the present invention.

[0043] The implementation, functional features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0044] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0045] It is particularly important to note that all technical steps, algorithm applications, and parameter settings in the technical solution of this application have clear technical objectives and application value. They do not utilize complex steps and algorithmic formulas to achieve simple functions. To provide detailed explanations of each step and avoid ambiguity, some conventional algorithms are used for illustration. However, this does not mean that the algorithms and technical features listed herein are the only way to implement the technical solution of this application, nor is it intended to limit the scope of protection of this application. This application is not a combination or stacking of the listed algorithms and technical features; its essence is to exemplify the implementation methods of this application to fully explain it. It does not pursue formal complexity by adding meaningless technical steps, nor does it involve the accumulation of technologies divorced from practical needs; it conforms to the conventional logic of technical improvement and design.

[0046] Reference Figure 1 One embodiment of the present invention provides a browser tab page data storage method that supports data encryption, comprising the following steps:

[0047] Step S1: Real-time monitoring of browser tab page interaction behavior generates dynamic factors, which, combined with the tab page's process ID, generate a session key that dynamically changes with the tab page's lifecycle.

[0048] Step S2: Encrypt the structured and unstructured data of the tag page separately based on an adaptive encryption strategy; wherein, the structured data is encrypted hierarchically according to the sensitivity of the fields, and the unstructured data is encrypted through the mapping and binding of keys and data.

[0049] Step S3: The encrypted data is associated with the timestamp credential of the session key and stored, and the decryption operation is only allowed to be completed in the memory of the tag page process that generated the session key; the session key is not stored on the ground.

[0050] Step S4: When the tab page is closed, the session key and decrypted data in the process memory are cleared synchronously.

[0051] In this embodiment, as described in step S1 above, the aim is to construct a dynamic key generation mechanism deeply bound to the tab's lifecycle. Specifically, this includes: the browser capturing user interaction behavior of the current tab in real time through a kernel-level monitoring module, including but not limited to mouse click coordinate sequences, keyboard input timing, page scrolling speed changes, element hover duration, etc., and quantifying these behaviors along a timeline into dynamic factors including parameters such as operation interval, frequency, and intensity. Simultaneously, the process ID corresponding to the tab (as a unique process identifier) ​​is extracted and converted into a fixed base value using an irreversible hash algorithm. Subsequently, a key derivation algorithm based on chaotic mapping is used, with the process ID as the base value as the initial seed, and the real-time generated dynamic factors as iterative perturbation parameters, continuously updating the session key throughout the tab's entire lifecycle from loading to closing. For example, when the user's interaction behavior with the tab changes significantly (such as a sudden increase or decrease in operation frequency), the perturbation intensity of the dynamic factors is adjusted accordingly, causing the session key to iterate synchronously into a new key form, ensuring that the key always dynamically changes with the tab's active state, rather than remaining a fixed value.

[0052] As described in step S2 above, for structured data in the tab (such as form fields, cookie key-value pairs, structured JSON data returned by the API, etc.), it is first classified according to a preset sensitivity assessment model (based on data type, including the probability of privacy information, etc.). For example, account passwords and payment information are classified as high-sensitivity fields, and ordinary text descriptions are classified as low-sensitivity fields. A tiered encryption scheme is adopted for fields of different levels: high-sensitivity fields are encrypted using the national cryptographic SM4 algorithm combined with a real-time updated session key; medium-sensitivity fields are encrypted using the AES-CCM algorithm combined with the time-slice value of the session key; and low-sensitivity fields are encrypted using lightweight XOR encryption to reduce computational overhead.

[0053] For unstructured data (such as image caches, audio clips, binary files, etc.), the data is first fragmented into fixed-size chunks. Simultaneously, the session key is split into key chunks of the same number as the data chunks using the Shamir secret-sharing algorithm, establishing a one-to-one mapping relationship. That is, the i-th data chunk can only be decrypted using the i-th key chunk, and the mapping relationship is dynamically obfuscated using the hash value of the process ID. This mechanism ensures that even if some key chunks are leaked, the complete data cannot be recovered, significantly improving the attack resistance of unstructured data.

[0054] As described in step S3 above, in the data storage stage, a unique data fingerprint (based on the SHA-256 algorithm) is first generated for the encrypted data. This fingerprint, along with a high-precision timestamp (accurate to milliseconds) from the time the session key was generated, is then linked using elliptic curve cryptography (ECC) to create an association credential. This association credential embeds an invisible watermark of the tab's process ID, serving as a binding identifier between the data and the key. The encrypted data body is stored in an encrypted partition of the browser's local database, while the association credential is stored separately in a temporary memory file named after the process ID. This file exists only when the tab process is active and is automatically encrypted and hidden when the process is paused. Regarding decryption access control, the browser allocates an independent memory encryption operation area for the tab process that generates the session key. This area, through a strong binding mechanism between the process ID and the memory page table, only accepts decryption requests carrying valid association credentials. The session key exists only in this operation area as a temporary electrical signal throughout the entire process, without being written to any disk cache or memory snapshot. Furthermore, the electrical signal form of the key is automatically refreshed after each decryption operation to avoid the risk of leakage caused by storing the key on disk.

[0055] As described in step S4 above, when the browser detects a tab closing instruction (including scenarios such as user-initiated closing and abnormal process termination), it immediately triggers a kernel-level cleanup signal. This signal locks the memory address range where the session key is located and the temporary cache area of ​​the decrypted original data through a hook function, prohibiting any read and write operations to prevent the data from being maliciously copied.

[0056] For session keys, electrical signal-level zeroing is employed. A reverse-level signal is sent to the memory cell storing the key, overwriting the electrical signal trace of the original key, and simultaneously deleting the mapping record of that key from the memory page table, ensuring physical recovery is impossible. For decrypted data in process memory, differentiated erasure is performed based on data type: structured data is directly erased using memory block erasure instructions, while unstructured data is overwritten by generating high-entropy random noise, and the entropy value of the overwritten memory block is verified to reach a preset threshold (e.g., ≥0.9), ensuring the original data cannot be restored. After erasure, an audit log is generated, including erasure time, memory address, and entropy verification result. This log is stored only in the browser security kernel and cannot be accessed by the user layer. Simultaneously, the tab's process ID is marked as "destroyed," permanently prohibiting any subsequent key reconstruction or data access requests based on that ID, forming a closed-loop security protection.

[0057] In one embodiment, real-time monitoring of browser tab page interaction behavior generates dynamic factors, including:

[0058] Get the sequence of user interaction events within the tab page;

[0059] Temporal features are extracted from the user interaction event sequence to obtain a multidimensional feature vector including the standard deviation of the event interval and the entropy of the operation intensity.

[0060] Through nonlinear transformation, the multidimensional feature vector is mapped into a dynamic factor that is updated in real time as the time window slides, and the difference in dynamic factors between adjacent time windows is positively correlated with the activity level of interactive behavior.

[0061] In this embodiment, the browser uses an event capture module integrated into its kernel to monitor all user-triggered interactive behaviors within the current tab in real time, forming a continuous event sequence. These interactive behaviors include, but are not limited to: mouse clicks (including click location coordinates and click duration), keyboard input (including key type and interval between adjacent key inputs), page scrolling (including scroll direction, scroll speed, and acceleration), and element operations (including hover duration and selection state switching timing for page elements such as forms, buttons, and dropdown lists). The event capture module records these behaviors sequentially according to the event timestamp (accurate to milliseconds), forming a raw interactive event sequence including event type, physical parameters (such as coordinates and speed), and timestamps, providing basic data for subsequent feature extraction.

[0062] Based on the acquired original interaction event sequence, a temporal feature extraction algorithm is used for quantification, transforming it into a feature vector that can be used to generate dynamic factors. Specifically, the difference between the timestamps of two consecutive similar or dissimilar events (i.e., the event interval) is calculated. Statistical analysis is performed on all event intervals within a certain time range to solve for their standard deviation. This value reflects the stability of the user's operation rhythm; the larger the standard deviation, the more drastic the fluctuation of the operation interval.

[0063] The physical parameters of interactive events (such as click pressure, scrolling speed, and input frequency) are mapped to intensity values. The distribution entropy of these intensity values ​​in the time series (i.e., the operation intensity entropy value) is calculated using the information entropy algorithm. A higher entropy value indicates a stronger randomness in the operation intensity, while a lower entropy value indicates a more regular operation pattern.

[0064] In addition, other feature parameters can be added according to the interaction scenario, such as the frequency of event type switching (reflecting the diversity of user operations) and the proportion of high-frequency events (reflecting the user's dependence on specific functions), and finally integrated to form a multi-dimensional feature vector including the standard deviation of event interval, operation intensity entropy value and other auxiliary features, so as to realize the quantitative description of user interaction behavior.

[0065] Finally, a pre-defined nonlinear transformation model (such as a transformation algorithm based on radial basis functions or chaotic mapping) is used to map the obtained multidimensional feature vectors into specific dynamic factor values. To ensure the real-time performance of the dynamic factors, a fixed-duration sliding time window (e.g., 100 milliseconds) is set. Feature extraction and nonlinear transformation are performed independently within each time window to generate the corresponding dynamic factor. The nonlinear transformation introduces higher-order terms, piecewise functions, or random perturbation terms to create a complex, non-one-to-one mapping relationship between the feature vectors and the dynamic factors, enhancing the dynamic factors' resistance to inverse derivation.

[0066] Meanwhile, the update mechanism of dynamic factors is related to the activity level of user interaction: when user interaction is active (such as high-frequency clicking or rapid input), the feature vectors of adjacent time windows differ significantly, and the difference in dynamic factors generated after nonlinear transformation increases accordingly; when interaction is slow (such as long periods of inactivity or constant scrolling), the feature vector changes slowly, and the difference in dynamic factors decreases accordingly. Through this mechanism, dynamic factors can reflect the active state of user interaction in real time, providing dynamic input for the subsequent generation of session keys that change dynamically with the tab lifecycle.

[0067] In one embodiment, the user interaction event sequence includes the click coordinate change rate, the character input interval in the input box, the scrolling acceleration, and the hover duration of page elements.

[0068] In one embodiment, a session key that dynamically changes with the lifecycle of the tab page is generated by combining the process ID of the tab page, including:

[0069] The process ID of the tab page is hashed to obtain a fixed identifier value. The dynamic factor is divided into multiple time segments according to a preset time slice and a feature hash value is generated for each segment.

[0070] Using the fixed identifier value as the initial seed, the feature hash values ​​of each time segment are used sequentially as the iterative perturbation parameters of the chaotic mapping to generate a segmented key corresponding to the number of time slices;

[0071] The weight of the segmented keys is dynamically adjusted by the intensity of real-time interactive behavior during the tab page's lifecycle, forming a session key that is continuously and dynamically updated throughout the entire lifecycle of the tab page, from loading to closing.

[0072] In this embodiment, firstly, the process ID of the tab page (which serves as a unique identifier for the tab page in the browser's process management) is processed using an irreversible hash algorithm to generate a fixed-length hash value as a fixed identifier. This identifier value is unique and cannot be reverse-engineered to derive the original process ID, ensuring the security of the process identifier.

[0073] Simultaneously, the generated dynamic factors (continuous values ​​that change in real time with user interaction) are divided into multiple consecutive time segments (e.g., 500 milliseconds / segment) according to a preset time slice. Each segment corresponds to a set of dynamic factors within a time slice. Each time segment is processed individually using a hash algorithm to generate a feature hash value that corresponds one-to-one with the segment, realizing the segmented quantization of the time-series changes of dynamic factors and providing discretized input parameters for subsequent key iterations.

[0074] Next, based on the nonlinear dynamics of chaotic maps (such as Logistic maps and Lorenz systems), an iterative framework for key generation is constructed: a fixed identifier value is used as the initial seed for the chaotic map to determine the initial state and parameters. Subsequently, the feature hash values ​​of each time-series segment are sequentially input into the chaotic map model as perturbation parameters during the iteration process. Each feature hash value alters the iterative trajectory of the chaotic map, causing a targeted shift in the pseudo-random sequence output by the map. In this way, an independent segmented key is generated for each time-series, and the numerical distribution of the segmented key is strongly correlated with the dynamic factors of user interaction within that time-series. Because chaotic maps are extremely sensitive to initial values ​​and perturbation parameters, even if the feature hash values ​​of two time-series differ only slightly, the generated segmented keys will exhibit significant differences, ensuring the randomness and anti-predictability of the segmented keys.

[0075] Finally, to ensure that the session key reflects the tab's activity level in real time, interaction intensity is introduced as a weighting factor for segment keys: The interaction intensity value is calculated by monitoring parameters such as the frequency and magnitude of user interaction events within the current time slice (a higher intensity value indicates more active user activity). The weight of each segment key in the session key is dynamically allocated based on this intensity value. For example, when the interaction intensity is high, the weight of the segment key in the current time slice increases (e.g., to 60%), while the weight of historical segment keys decreases (e.g., 30% in the previous time slice and 10% in the time slice before that); when the interaction intensity is low, the weight of the current segment key decreases, while the weight of historical segment keys is retained according to a decay rule.

[0076] Through the aforementioned dynamic weighted concatenation mechanism, the session key will be continuously updated throughout the entire lifecycle of the tab, from loading (initial process ID generation) to closing (end of the last time slice), as the intensity of user interaction changes: the key during active periods is mainly determined by the current interaction characteristics, while the key during calm periods is integrated with historical interaction characteristics, ultimately forming a dynamic session key that is deeply bound to the tab's lifecycle and responds to the interaction status in real time.

[0077] In one embodiment, the structured and unstructured data of the tag page are encrypted separately based on an adaptive encryption strategy, including:

[0078] For structured data, each field is classified; high-sensitivity fields are encrypted in real time using the SM4 algorithm combined with a dynamically changing session key, medium-sensitivity fields are encrypted using the AES-CTR algorithm combined with time-slice segmented key encryption of the session key, and low-sensitivity fields are encrypted using lightweight XOR encryption.

[0079] For unstructured data, it is divided into n data fragments according to the data block size. At the same time, the session key is split into n key fragments, and a one-to-one mapping relationship between data fragments and key fragments is established. The i-th data fragment is encrypted with the i-th key fragment, and the mapping relationship is dynamically obfuscated by the hash value of the tab process ID. During decryption, the integrity of the data fragments and the consistency of the mapping relationship must be verified at the same time.

[0080] In this embodiment, for structured data (such as form fields, user information entries, key-value pairs returned by APIs, etc.) in the tab page, the fields are first classified according to preset sensitivity assessment rules. The classification criteria include, but are not limited to: the type of privacy information included in the field (such as account passwords being highly sensitive information), the risk level of data leakage (such as payment-related fields having a higher risk level than ordinary text fields), user-defined privacy tags, etc., and finally the fields are divided into three sensitivity levels: high, medium, and low.

[0081] Highly sensitive fields are encrypted using the national standard SM4 block encryption algorithm, combined with a dynamically updated session key. Because the SM4 algorithm offers high security and resistance to differential attacks, and the session key dynamically changes throughout the tab's lifecycle, the encryption strength and real-time performance of core sensitive data are ensured.

[0082] Medium-sensitivity fields (such as user nicknames and shipping addresses) are encrypted using the AES-CTR stream encryption algorithm, combined with time-slice key segments of the session key (i.e., staged keys generated according to preset time slices). The efficiency of the AES-CTR algorithm is suitable for batch processing of medium-sensitivity data, while the introduction of segmented keys can reduce the computational overhead of full key updates while ensuring security.

[0083] Low-sensitivity fields (such as page titles and plain text descriptions) employ lightweight XOR encryption, using the lower-order byte of the current session key as the XOR factor. This method significantly improves encryption efficiency while meeting basic encryption requirements, avoiding page response delays caused by overly complex algorithms.

[0084] For unstructured data (such as image cache, audio clips, binary files, rich text content, etc.) in the tab page, it is first processed into fragments according to a fixed data block size (such as 1MB / block) to obtain n consecutive data fragments. Each fragment includes a part of the original data and is appended with a fragment sequence number and an integrity check code (such as CRC32 value).

[0085] Simultaneously, the Shamir secret sharing algorithm is used to split the session key into n key fragments, satisfying the characteristic that "any k (k≤n) key fragments can restore the complete session key, while fewer than k fragments cannot" (the value of k can be dynamically configured according to the importance of the data). Based on this, a one-to-one mapping relationship is established between data fragments and key fragments: the i-th data fragment can only be decrypted by the i-th key fragment, and the mapping relationship needs to be dynamically obfuscated using the hash value of the tab process ID. Specifically, the hash value of the process ID is used as an obfuscation factor to replace the correspondence between fragment sequence numbers and key fragment indices.

[0086] During the decryption process, two verifications must be completed simultaneously: first, the integrity checksum of the data fragment confirms that the fragment has not been tampered with; second, the mapping relationship is reversed using the hash value of the process ID to verify the sequence number matching between the currently used key fragment and the data fragment. Only when both verifications pass can the complete unstructured data be successfully decrypted and reassembled. Through the dual mechanism of fragment encryption and dynamic obfuscation mapping, the risk of overall data leakage caused by the leakage of a single fragment or the cracking of the mapping relationship is significantly reduced.

[0087] In one embodiment, the encrypted data is stored in association with a timestamp credential of the session key, and decryption is only allowed to be performed in the memory of the tag page process that generated the session key. The session key is not stored locally, including:

[0088] The encrypted data is used to generate a data fingerprint according to the data type. The timestamp certificate of the session key is used to generate an association certificate with the data fingerprint. An invisible watermark of the tab process ID is embedded in the association certificate.

[0089] An independent encryption operation area is allocated in the memory of the tab page process that generates the session key. The encryption operation area only receives data decryption requests with the associated credentials, and the session key exists in the form of temporary electrical signal storage during the decryption process, without generating disk cache or memory snapshot.

[0090] When storing encrypted data, the hidden watermark in the associated credential is verified to match the process ID of the current storage partition. Only encrypted data that matches can be written to the preset storage area, and the storage area does not include metadata that can be reversibly derived from the session key.

[0091] In this embodiment, for the encrypted data, a unique data fingerprint is first generated using the corresponding hash algorithm based on its data type (such as structured data or unstructured data). For example, a hash algorithm is used to calculate the hash value for structured data, and a merged hash value based on fragment verification is used for unstructured data to ensure that the data fingerprint can uniquely identify the integrity of the encrypted data.

[0092] Simultaneously, a high-precision timestamp credential (used to mark the valid time range of the key) is extracted from the session key generation time. This timestamp credential is then fused with the aforementioned data fingerprint using an elliptic curve cryptography (ECC) algorithm to generate an associated credential. During the generation of the associated credential, an invisible watermark of the tab's process ID is embedded synchronously. Specifically, the low-order bits of the process ID hash value are inserted into the ECC-encrypted private key parameters, making the watermark information invisible but extractable through a dedicated algorithm without affecting the normal verification function of the associated credential. This scheme binds the encrypted data, key timestamp, and process identifier through the associated credential, laying the foundation for subsequent access control for storage and decryption.

[0093] Within the memory of the tabbed process that generates the session key, a separate encryption computation area is defined using the operating system's memory page table isolation mechanism. This computation area is marked as "non-swapable" memory (i.e., it will not be written to the disk swap partition by the operating system) and can only be accessed by the CPU core hosting the current tabbed process; memory mapping requests from other processes or threads are prohibited.

[0094] The decryption permission in the encryption processing area is strictly bound to the associated credential: the processing area will only initiate the decryption process when it receives a data decryption request carrying the associated credential generated in the first step. During decryption, the session key always exists in the registers and cache of the processing area as a temporary electrical signal. Specifically, it is manifested as a dynamic combination of high and low voltage levels, without forming any persistent binary data, and therefore no disk cache file or memory snapshot is generated (even if the operating system triggers a snapshot mechanism, it cannot capture valid key information). After decryption, the processing area immediately overwrites the electrical signal trace of the key by level toggling, further eliminating the risk of key residue.

[0095] Before writing the encrypted data to the storage medium, a verification mechanism for the associated credentials is initiated: a dedicated watermark extraction algorithm is used to parse the process ID information included in the hidden watermark from the associated credentials, and this information is compared with the process ID whitelist preset in the current storage partition. Only when the two match completely (i.e., the encrypted data belongs to the current tab process) is it allowed to write the encrypted data to the preset storage area (such as the encrypted partition of the browser's local database or a separate encrypted file system).

[0096] The storage area's structural design strictly excludes any metadata that could potentially be reverse-engineered to derive the session key: for example, it does not record the initial parameters for key generation, does not store configuration details of the encryption algorithm, and does not retain the direct mapping relationship between data and keys; it only retains the encrypted data body and auxiliary information used for integrity verification (such as data length and number of fragments). Simultaneously, the storage area employs an access control list (ACL) based on process ID, allowing only the tab process that generated the session key to read the data. Other processes, even if they obtain the storage path, cannot access it, thus forming a secure closed loop across the entire chain of generation, encryption, storage, and decryption.

[0097] In one embodiment, the encrypted data is stored in association with a timestamp credential of the session key, and decryption is only allowed to be performed in the memory of the tag page process that generated the session key. The session key is not stored locally, including:

[0098] A unique data digest is generated from the encrypted data. The timestamp credential of the session key and the data digest are XORed with each other based on the process ID to generate an association tag. The association tag embeds a tag lifecycle stage identifier.

[0099] In the memory of the tag page process that generates the session key, a hardware-isolated encryption operation sandbox is partitioned. The encryption operation sandbox only accepts decryption requests with the associated tag, and the session key exists in the form of a dynamic electrical signal stream during the decryption process. Static residency is avoided by refreshing the memory address offset in real time. The session key only participates in the decryption operation within the encryption operation sandbox and does not generate disk logs or memory snapshots. Only the decrypted usable data can be obtained outside the sandbox.

[0100] The encrypted data is stored in the encrypted partition of the browser's local storage, and the associated tags are stored in a separate credential partition. The two partitions are associated through an implicit hash mapping of the tag page process ID. Data reading can only be triggered when the process ID, associated tag, and lifecycle stage identifier match.

[0101] In this embodiment, a hash algorithm is used to generate a unique data digest for the encrypted data (this digest is irreversible and uniquely identifies the original content and encryption state of the data). Simultaneously, a high-precision timestamp credential (used to define the valid time range of the key) is extracted from the session key generation time. This timestamp credential and the data digest are then XORed based on the process ID. Specifically, the hash value of the tab's process ID is used as the XOR key, and the two information are fused through a bitwise XOR operation to generate an associated tag.

[0102] During the generation of associated tags, the lifecycle stage identifier of the tab is embedded synchronously (such as loading initialization, active interaction, background suspension, etc., automatically marked by the browser kernel based on the tab state). This identifier exists in the associated tag as a binary hidden field and can only be extracted using a dedicated parsing algorithm combined with the process ID. This approach does not affect the integrity of the associated tag and provides a stage matching basis for subsequent permission verification. This method strongly binds encrypted data, key timestamps, process identifiers, and lifecycle stages through associated tags, building a multi-dimensional authentication foundation.

[0103] Within the memory of the tab process that generates the session key, a hardware-isolated cryptographic sandbox is created using the CPU's Trusted Execution Environment (TEE) or memory encryption extensions (such as Intel SGX). This sandbox is completely isolated from other memory areas of the process, and its access permissions are directly controlled by the hardware. Only the kernel thread hosting the current tab process is allowed to enter, and memory read or injection operations by any external process (including the browser's main process) are prohibited.

[0104] The decryption permission of the encryption sandbox is strictly bound to the associated tag: the sandbox will only initiate the decryption process when it receives a decryption request carrying the associated tag generated in the first step. During the decryption process, the session key exists in the form of a dynamic electrical signal stream. Specifically, it is rapidly switched between multiple memory addresses within the sandbox in a random timing sequence (i.e., the memory address offset is refreshed in real time), avoiding static residence at fixed addresses, which would prevent memory scanning tools from capturing complete key information.

[0105] The session key's computational scope is strictly limited to within the sandbox: it only participates in the logical operations of the decryption algorithm within the sandbox, without outputting any form of key copy outside the sandbox, nor generating disk logs, memory snapshots, or debugging information. After decryption, the sandbox only returns the decrypted usable data (such as text, images, etc. required for rendering) to the tab process, ensuring zero key leakage throughout the entire process.

[0106] The encrypted data body is stored in the encrypted partition of the browser's local storage (this partition is encrypted in its entirety using the AES-XTS algorithm, and the key is dynamically generated by the browser's security kernel), while the associated tags are stored separately in a separate credential partition (this partition is controlled by read-only permissions, allowing only addition operations and prohibiting modification or deletion).

[0107] The two partitions are linked through an implicit hash mapping of the tab's process ID: the hash value of the process ID is used as the mapping key to generate an address mapping table between the encrypted partition and the credential partition. This address mapping table is stored only in the browser's security kernel memory and not on the physical memory. When a data read request is triggered, the system must verify three pieces of information simultaneously: first, the ID of the requesting process matches the process ID bound to the encrypted partition; second, the associated tag in the credential partition matches the tag carried in the request; and third, the lifecycle stage identifier in the associated tag matches the actual state of the current tab (e.g., if the tab is in an active interaction stage, only associated tags matching that stage identifier are valid). Only when all three verifications pass can the corresponding data be located and read through the implicit hash mapping, ensuring that encrypted data can only be accessed by legitimate tab processes within their valid lifecycle.

[0108] In one embodiment, it further includes:

[0109] Throughout the lifecycle of the tag page, real-time data on the dynamic changes in user biometrics during page interactions is collected.

[0110] When the deviation between the dynamic change data of biometrics and the historical baseline exceeds a preset threshold, the current session key is automatically frozen and the session key regeneration process is triggered. During the freeze period, only the metadata of the encrypted data is allowed to be read, while decryption operations are prohibited.

[0111] In this embodiment, throughout the entire lifecycle of the tab page, the browser uses an integrated biometric acquisition module (such as a pressure-sensitive touchscreen or a camera-assisted behavior capture component) to capture real-time dynamic changes in biometric features generated during user interaction with the page. These biometric features include, but are not limited to: pressure change curves when a finger clicks or touches the screen (reflecting fluctuations in pressure over time), dynamic changes in the touch contact area (such as the rate of expansion of the area when the fingertip presses), and acceleration of the finger movement trajectory during input operations (such as the acceleration and deceleration characteristics of the fingertip during swiping). The acquisition module samples these features at millisecond intervals, generating a continuous dynamic feature sequence and synchronously associating it with the timestamp of the user interaction and the corresponding page element information, forming a complete dataset including biometric change trends and interaction scenarios, providing a real-time benchmark for subsequent deviation detection.

[0112] Biometric data collected during the initial interaction phase (such as the first three valid operations after the tab is first loaded) is used to construct a historical baseline model for the user. This model includes statistical parameters such as the mean, fluctuation range, and change patterns of biometrics, serving as a benchmark for determining the legitimacy of subsequent operations. During subsequent interactions on the tab, the collected dynamic changes in biometric data are compared in real time with the historical baseline model, and deviation values ​​are calculated (such as the Euclidean distance of the pressure curve, the standard deviation of the contact area change rate, etc.). When the deviation value exceeds a preset threshold (this threshold can be dynamically adjusted according to the stability of user operations, such as 5% in sensitive operation scenarios and 10% in normal scenarios), it is determined that the current interaction may pose a risk of unauthorized access, and the session key freezing mechanism is immediately triggered.

[0113] Lock all computation permissions for the current session key, prohibiting it from participating in any decryption process;

[0114] Only grant read access to encrypted data metadata (such as non-sensitive information like data size, storage time, number of fragments, etc.), while all requests to decrypt core content are rejected.

[0115] Synchronously initiate the session key regeneration process: clear the memory traces of the original key, and regenerate a new session key based on the latest collected biometric data (which needs to be verified for legitimacy through secondary verification) and the current process ID, ensuring that the key is bound to the latest biometric data of the legitimate user.

[0116] Through the above mechanism, real-time response to abnormal interactive behavior is achieved, cutting off the possibility of unauthorized access at the key layer and further strengthening the security protection level of tab data.

[0117] In one embodiment, the method further includes:

[0118] Extract sensitive data from the data in the browser tab page;

[0119] Get the URL of the browser tab page, and remove duplicate characters from it to get the deduplicated string; based on the total number of characters in the URL, mutate the deduplicated string to get the mutated string;

[0120] Obtain a preset mapping table; the mapping table includes the original data column and a one-to-one corresponding mapped data column; add the data in the mapped data column to each node of the preset binary tree structure to obtain a data binary tree; connect the first and last nodes of the data binary tree, forming a node connection;

[0121] Obtain all other nodes that the given node continuously traverses, and use them as target nodes; distribute the mutated string to each target node to obtain a redistribution binary tree;

[0122] The new data of each node in the redistribution binary tree is replaced in the mapping data column to obtain the replacement mapping table, which is used to perform mapping and desensitization processing on sensitive data.

[0123] In this embodiment, all data within the browser tab (including structured data such as form fields and cookie information, and unstructured data such as page text and input content) is scanned and extracted using preset sensitive data identification rules. The criteria for sensitive data identification include, but are not limited to: data type (such as data containing phone numbers, email addresses, etc., conforming to a specific format), user-marked privacy fields, and a built-in sensitive keyword library. The extracted sensitive data forms a set, which serves as the target for subsequent de-identification processing.

[0124] Next, obtain the complete URL of the current tab page, and perform deduplication on all characters in the URL (including characters in the protocol, domain, path, parameters, etc.). That is, keep the first occurrence of the character and remove subsequent recurring identical characters to obtain the deduplicated string.

[0125] Subsequently, based on the total number of characters in the original URL (i.e., the total number of characters before deduplication), a mutation operation is performed on the deduplicated string. For example, mutation rules can be determined based on the total number of characters (e.g., if the total number of characters is even, the string is reversed and replaced with alternate characters; if it is odd, the character ASCII code is offset and segments are reassembled), generating a mutated string with a different structure but a related character set than the original deduplicated string. This process generates unique mutated strings through URL feature transformation, providing differentiated input parameters for subsequent data allocation.

[0126] The system invokes a pre-defined mapping table containing two sets of one-to-one corresponding column data: the original data column and the mapped data column. Using each data item in the mapped data column as a basic element, a binary tree structure is constructed: the mapped data is sequentially inserted into each node of the binary tree according to a pre-defined sorting rule (such as character length or alphabetical order), forming a complete binary tree containing a root node, intermediate nodes, and leaf nodes. After the binary tree is constructed, pointers are used to connect the first node (root node) and the last node (last leaf node), forming a closed node connection, giving the binary tree a circular structure with its head and tail connected. Based on the formed node connection, all nodes continuously traversed by the connection in the binary tree (including other nodes along the connection path, excluding the first and last nodes) are traced, and these nodes are marked as target nodes. The number of target nodes is determined by the depth of the binary tree and the path of the node connection, ensuring coverage of the core branches of the binary tree. The generated mutated string is segmented according to the number of target nodes (e.g., if the mutated string is 10 characters long and there are 5 target nodes, each segment consists of 2 characters). The segments are then distributed sequentially to the target nodes according to the order of their positions on the connecting lines, replacing or appending the original mapping data to the target nodes. Other nodes not marked as target nodes retain their original mapping data, ultimately forming a redistributed binary tree with partially updated node data.

[0127] From the obtained redistribution binary tree, extract the current data of all nodes (including the updated target node data and the data of other nodes that have not been updated). Refill these data into the mapping data columns according to the order of the original mapping table, replacing the original mapping data to form a new replacement mapping table. For each piece of sensitive data, find its matching item in the original data column and call the corresponding mapping data in the replacement mapping table to replace it, thus protecting the privacy of sensitive data. Because the replacement mapping table is dynamically generated based on URL features, the mapping relationship in each de-identification process is unique, reducing the risk of the de-identification rules being reverse-engineered.

[0128] In one embodiment, the method further includes:

[0129] After extracting sensitive data from browser tab page data, a dynamic desensitization rule base is generated based on the field type of the sensitive data. The dynamic desensitization rule base includes character replacement rules, length compression rules, and format conversion rules, and the rule priority is dynamically adjusted according to the access frequency of sensitive data.

[0130] The subdomain of the tag page URL is obtained as a seed, and a domain feature value is generated. The domain feature value is moduloed with the field length of the sensitive data to obtain a rule index value. Based on the rule index value, the matching main desensitization rule is called from the dynamic desensitization rule library.

[0131] The query parameters of the URL are split into key-value pairs and a parameter feature vector is generated. The parameter feature vector is then input into a preset rule perturbation model to dynamically adjust the parameters of the main desensitization rule, thereby obtaining a personalized desensitization rule that adapts to the current sensitive data.

[0132] When processing sensitive data using the personalized de-identification rules, a de-identification traceability code is generated simultaneously. The de-identification traceability code contains URL feature values, rule index values, and de-identification timestamps, and can only be parsed by the verification algorithm in the memory of the tab process that generated the traceability code. It is used to reverse verify the integrity of the data before de-identification in authorized scenarios.

[0133] In this embodiment, firstly, sensitive data is extracted from browser tab page data, and then the field type of each piece of sensitive data (such as mobile phone number, email address, etc.) is analyzed. Based on the field type, a dynamic desensitization rule base is constructed. This rule base contains three core rules: character replacement rules (such as replacing some characters with *, applicable to hiding the middle four digits of a mobile phone number), length compression rules (such as truncating some characters and adding a verification code, applicable to desensitizing long text summaries), and format conversion rules (such as converting numerical data into hash values).

[0134] The rule base's priority mechanism is linked to the access frequency of sensitive data: It tracks the access frequency of sensitive data for each field type in real time. For field types with higher access frequency, the priority of their corresponding rules is dynamically increased (e.g., for frequently accessed fields like phone numbers, character replacement rules have higher priority than other rules), ensuring that frequently accessed sensitive data always uses the current optimal de-identification strategy. Simultaneously, when the access frequency of a certain type of data falls below a preset threshold, the priority of its corresponding rules is automatically reduced, allocating more lightweight de-identification resources to low-frequency data.

[0135] Retrieve the subdomain from the current tag page URL, and convert the subdomain into a fixed-length domain feature value using a hash algorithm (ensuring that different domains generate unique identifiers). Simultaneously, extract the field length of sensitive data, and perform a modulo operation between the domain feature value and the field length (i.e., divide the domain feature value by the field length and take the remainder) to obtain the rule index value.

[0136] The rule index value serves as a retrieval identifier for the dynamic data masking rule base. Based on this value, the matching primary data masking rule is retrieved from the rule base. For example, an index value of 3 retrieves the character replacement rule, while an index value of 5 retrieves the format conversion rule. The matching process of the primary data masking rule is secondary-bound to the field type of the sensitive data to ensure that the rule corresponding to the index value is compatible with the field type (e.g., the mobile phone number field only matches the character replacement primary rule), avoiding data masking failure due to rule mismatch.

[0137] The URL query parameters are parsed, splitting them into key-value pairs according to their ASCII codes. Each key-value pair is then converted into a numerical vector (e.g., the hash value of the key and the length of the value), and these are merged to form a parameter feature vector. This feature vector is input into a pre-defined rule perturbation model (trained based on a neural network; the input is the feature vector, and the output is the adjustment coefficients for the rule parameters). The model generates dynamic adjustment parameters for the main desensitization rule based on the vector's distribution characteristics. For example, for character replacement rules, the position and number of replacement characters are adjusted; for length compression rules, the truncation ratio and checksum generation method are adjusted. Through parameter adjustments, the main desensitization rule adapts to the specific scenario of the sensitive data (e.g., the same mobile phone number field displays different replacement styles under different query parameters), ultimately forming a personalized desensitization rule.

[0138] Next, when using personalized de-identification rules to de-identify sensitive data, a de-identification traceability code is generated simultaneously. This traceability code contains three parts: a URL feature value (generated from a second-level domain hash), a rule index value (used to locate the main de-identification rule), and a de-identification timestamp (accurate to the millisecond level, marking the time when the de-identification was executed). These three parts are combined into an invisible binary code through an XOR operation and appended to the de-identified data.

[0139] The parsing permissions for the anonymized traceability code are strictly limited: only the process memory of the tab that generated the traceability code can parse the original information through a preset verification algorithm (bound to the process ID). In authorized scenarios (such as when a user needs to view complete data after verifying their identity), the verification algorithm parses the traceability code, checks the matching of the current process ID with the URL feature value, and the validity of the timestamp. After confirming that there are no errors, it can reverse-engineer the integrity of the data before anonymization (such as verifying the consistency of the data format before and after anonymization), but it cannot directly restore the original data, thus achieving a secure anonymization closed loop that is verifiable but not reversible.

[0140] In the above embodiments, this application incorporates some existing algorithms and technical features for explanation and description to make the specification more detailed, clear, and complete, thus complying with the provisions of the Patent Law. However, this is not achieved by using a series of complex steps and algorithmic formulas, nor by complicating the technical solution, nor by combining or stacking conventional or simple features. The existing algorithms and technical features listed are for the purpose of disclosing the specific implementation methods of each step of this application (not to limit this application) and to avoid situations where this application cannot be implemented.

[0141] Reference Figure 2 In another embodiment of the present invention, a browser tab page data storage device supporting data encryption is also provided, comprising:

[0142] The generation unit is used to monitor the interactive behavior of browser tab pages in real time to generate dynamic factors, and combine them with the process ID of the tab page to generate a session key that changes dynamically with the life cycle of the tab page.

[0143] The encryption unit is used to encrypt the structured and unstructured data of the tag page separately based on an adaptive encryption strategy; among them, the structured data is encrypted according to the sensitivity of the fields, and the unstructured data is encrypted through the mapping and binding of keys and data.

[0144] The storage unit is used to associate and store the encrypted data with the timestamp credentials of the session key, and the decryption operation is only allowed to be completed in the memory of the tag page process that generates the session key; the session key is not stored on the ground.

[0145] The clearing unit is used to simultaneously clear the session key and decrypted data in the process memory when the tab page is closed.

[0146] In this embodiment, the specific implementation of each unit in the above device embodiment is described in the above method embodiment, and will not be repeated here.

[0147] Reference Figure 3 This invention also provides a computer device, which can be a server, and its internal structure can be as follows: Figure 3 As shown, the computer device includes a processor, memory, display screen, input device, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores the data corresponding to this embodiment. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements the above-described method.

[0148] Those skilled in the art will understand that Figure 3 The structures shown are merely block diagrams of some structures related to the present invention and do not constitute a limitation on the computer devices on which the present invention is applied.

[0149] An embodiment of the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. It is understood that the computer-readable storage medium in this embodiment can be a volatile readable storage medium or a non-volatile readable storage medium.

[0150] In summary, the browser tab page data storage method supporting data encryption provided in this embodiment of the invention includes: real-time monitoring of browser tab page interaction behavior to generate dynamic factors; combining the tab page's process ID to generate a session key that dynamically changes with the tab page's lifecycle; encrypting the structured and unstructured data of the tab page based on an adaptive encryption strategy; wherein, the structured data is encrypted hierarchically according to field sensitivity, and the unstructured data is encrypted through a mapping and binding between the key and the data; the encrypted data is associated with and stored as a timestamp credential of the session key, and decryption is only allowed in the memory of the tab page process that generated the session key, with the session key not being stored locally; when the tab page is closed, the session key and the decrypted data in the process memory are simultaneously cleared. In this invention, browser tab page interaction behavior generates dynamic factors, which, combined with the tab page's process ID, generate a session key that dynamically changes with the tab page's lifecycle; simultaneously, the encrypted data is associated with and stored as a timestamp credential of the session key, and decryption is only allowed in the memory of the tab page process that generated the session key, with the session key not being stored locally, overcoming the current shortcomings of not being able to dynamically generate keys and not being able to prevent keys from being stored locally.

[0151] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the present invention and embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM, etc.

[0152] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0153] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for storing browser tab page data that supports data encryption, characterized in that, Includes the following steps: Real-time monitoring of browser tab page interaction behavior generates dynamic factors, which, combined with the tab page's process ID, generate a session key that dynamically changes with the tab page's lifecycle. An adaptive encryption strategy is used to encrypt both structured and unstructured data on the tab page. Structured data is encrypted according to the sensitivity of each field, while unstructured data is encrypted through a mapping between a key and the data. The encrypted data is associated with and stored as a timestamp credential of the session key, and decryption is only allowed within the memory of the tab page process that generated the session key; the session key is not stored locally. This association of encrypted data with the timestamp credential of the session key, and the restriction to decryption within the memory of the tab page process that generated the session key, with the session key not being stored locally, is specifically implemented through Method 1. Method 1 includes: generating a data fingerprint from the encrypted data according to its data type; generating an association credential between the timestamp credential of the session key and the data fingerprint; embedding an invisible watermark of the tab page process ID in the association credential; dividing the memory of the tab page process that generated the session key into an independent encryption operation area; this area only receives data decryption requests with the association credential, and the session key is temporarily stored as an electrical signal during decryption, without generating a disk cache or memory snapshot; when storing encrypted data, verifying the matching of the invisible watermark in the association credential with the process ID of the current storage partition; only encrypted data that matches can be written to a preset storage area, and the storage area does not include metadata for reverse-derived session keys. When the tab is closed, the session key and decrypted data in the process memory are cleared simultaneously.

2. The browser tab page data storage method supporting data encryption according to claim 1, characterized in that, Real-time monitoring of browser tab page interaction behavior generates dynamic factors, including: Obtain the sequence of user interaction events within the tab page; Temporal features are extracted from the user interaction event sequence to obtain a multidimensional feature vector including the event interval standard deviation and the operation intensity entropy value; Through nonlinear transformation, the multidimensional feature vector is mapped into a dynamic factor that is updated in real time as the time window slides, and the difference in dynamic factors between adjacent time windows is positively correlated with the activity level of interactive behavior.

3. The browser tab page data storage method supporting data encryption according to claim 2, characterized in that, The user interaction event sequence includes the click coordinate change rate, the character input interval in the input box, the scrolling acceleration, and the hovering duration of page elements.

4. The browser tab page data storage method supporting data encryption according to claim 1, characterized in that, Combine the tab page's process ID to generate a session key that dynamically changes throughout the tab page's lifecycle, including: The process ID of the tab page is hashed to obtain a fixed identifier value. The dynamic factor is divided into multiple time segments according to a preset time slice and a feature hash value is generated for each segment. Using the fixed identifier value as the initial seed, the feature hash values ​​of each time segment are used sequentially as the iterative perturbation parameters of the chaotic mapping to generate a segmented key corresponding to the number of time slices; The weight of the segmented keys is dynamically adjusted by the intensity of real-time interactive behavior during the tab page's lifecycle, forming a session key that is continuously and dynamically updated throughout the entire lifecycle of the tab page, from loading to closing.

5. The browser tab page data storage method supporting data encryption according to claim 4, characterized in that, An adaptive encryption strategy is used to encrypt both structured and unstructured data on the tab page, including: For structured data, each field is classified; high-sensitivity fields are encrypted in real time using the SM4 algorithm combined with a dynamically changing session key, medium-sensitivity fields are encrypted using the AES-CTR algorithm combined with time-slice segmented key encryption of the session key, and low-sensitivity fields are encrypted using lightweight XOR encryption. For unstructured data, it is divided into n data fragments according to the data block size. At the same time, the session key is split into n key fragments, and a one-to-one mapping relationship between data fragments and key fragments is established. The i-th data fragment is encrypted with the i-th key fragment, and the mapping relationship is dynamically obfuscated by the hash value of the tab process ID. During decryption, the integrity of the data fragments and the consistency of the mapping relationship must be verified at the same time.

6. The browser tab page data storage method supporting data encryption according to claim 1, characterized in that, The encrypted data is associated with and stored as a timestamp credential of the session key, and decryption is only allowed to be performed in the memory of the tag page process that generated the session key. The session key is not stored on the ground. This implementation method one is replaced by method two, which includes: The encrypted data is used to generate a data digest. The timestamp credential of the session key and the data digest are XORed with the process ID to generate an association tag. The association tag embeds a tag lifecycle stage identifier. In the memory of the tag page process that generates the session key, a hardware-isolated encryption operation sandbox is partitioned. The encryption operation sandbox only accepts decryption requests with the associated tag, and the session key exists in the form of a dynamic electrical signal stream during the decryption process. Static residency is avoided by refreshing the memory address offset in real time. The session key only participates in the decryption operation within the encryption operation sandbox and does not generate disk logs or memory snapshots. Only the decrypted usable data can be obtained outside the encryption operation sandbox. The encrypted data is stored in the encrypted partition of the browser's local storage, and the associated tags are stored in a separate credential partition. The two partitions are associated through an implicit hash mapping of the tag page process ID. Data reading can only be triggered when the process ID, associated tag, and lifecycle stage identifier match.

7. The browser tab page data storage method supporting data encryption according to claim 1, characterized in that, Also includes: Throughout the lifecycle of the tag page, real-time data on the dynamic changes in user biometrics during page interactions is collected. When the deviation between the dynamic change data of biometrics and the historical baseline exceeds a preset threshold, the current session key is automatically frozen and the session key regeneration process is triggered. During the freeze period, only the metadata of the encrypted data is allowed to be read, while decryption operations are prohibited.

Images