TThe Web Storage API offers a user-friendly way for browsers to store pairs of keys and values, making it a more straightforward alternative to traditional cookies. This API consists of two primary methods: sessionStorage and localStorage.
sessionStorage provides a dedicated storage space for each origin that lasts only for the duration of the page session—essentially, as long as the browser tab remains open, including times when the page is reloaded or restored. In contrast, localStorage functions similarly but retains its data even after the browser is closed and reopened.
Accessing these storage options can be done through Window.sessionStorage and Window.localStorage properties. When one of these properties is called upon, it returns a Storage object instance that allows developers to set, retrieve, or delete data items. It’s important to note that sessionStorage and localStorage maintain separate storage objects for each origin; they operate independently from one another.
Suppose you’re curious about how much storage space is available through these APIs or what occurs when you exceed those limits. In that case, you can refer to guidelines on Storage quotas and eviction criteria.
Both sessionStorage and localStorage are designed to work synchronously. This means that any time data is added, accessed, or removed from these storages, those actions are executed in a way that pauses other JavaScript code until it finishes. While this synchronous nature simplifies some tasks, it can also hinder performance—mainly if large volumes of data are involved or if operations are computationally intensive. Developers should tread carefully when managing substantial datasets within sessionStorage or localStorage to avoid blocking the user interface and slowing down application responsiveness.
In cases where performance might be an issue due to heavy data processing needs, asynchronous solutions like IndexedDB may prove more effective. These alternatives facilitate non-blocking operations, which contribute to smoother user experiences and enhanced application performance.
It’s also worth mentioning that access to Web Storage from third-party IFrames will be restricted if users have opted out of third-party cookies—a consideration worth keeping in mind during development.
Comprehending Third-Party Access To Storage
Understanding how third-party access to storage works is crucial, as each origin maintains its storage—this applies to both web and shared storage. The ability of third-party code, such as that embedded from another source, to access this shared storage is influenced by the browsing context in which it operates. Essentially, the environment where this external code executes dictates its level of access to storage.
Imagine a scenario where you have a primary browsing context labelled publisher.com, which incorporates third-party content. Integrating this external code can be achieved either by inserting a script element or by directing an iframe’s source to a site containing that code. The approach taken for this integration plays a vital role in establishing the browsing context for the third-party code.
When you introduce your third-party script into another website via a script tag, it runs within the embedding site’s browsing context. As a result, if your code invokes Storage.setItem() or SharedStorage.set(), any key-value pairs will be stored in the embedding site’s storage space. From the browser’s viewpoint, there’s no distinction between first-party and third-party scripts when using this method.
Conversely, if your external code is housed within an iframe, it operates under the origin associated with that iframe’s browsing context. Should this iframe code execute Storage.setItem(), any data will be stored in either local or session storage specific to that iframe’s origin. Similarly, if SharedStorage.set() is called from within the iframe, it will save data into that exact origin’s shared storage.
In summary, whether through direct script injection or an iframe setup, understanding these contexts is essential for managing how and where data gets stored across different origins on the web.
Web Storage Interfaces
The Web Storage interfaces, known as Storage, empower users to manage data associated with a particular domain and storage type, whether it be session or local storage. The Web Storage API enhances the Window object, introducing two new properties: Window.sessionStorage and Window.localStorage. These properties grant access to the session and local storage objects of the current domain. Additionally, there’s a storage event handler that activates whenever there’s a change in the storage area—like when a new item is added.
A fascinating aspect of this functionality is the StorageEvent itself; it triggers a document’s Window object whenever there’s an alteration in the storage area. To demonstrate how web storage can be utilised effectively, we’ve crafted an engaging example called Web Storage Demo. Upon entering this demo’s landing page, users encounter various controls designed to personalise elements such as colour, font style, and decorative images. As you make selections, the page refreshes instantly to reflect your choices while simultaneously saving them in localStorage. This way, if you navigate away from the page and return later, your preferences will still be intact.
Moreover, we’ve included an event output page for further interaction. If you open this page in another tab and modify your selections on the landing page, you’ll witness real-time updates of your stored information as the StorageEvent gets triggered.
How Third-Party Access to Storage Works in Maxthon Browser
1. Understanding Storage Options: In Maxthon Browser, various storage types are available for web applications, including cookies, localStorage, and IndexedDB. These allow websites to store data on your device.
2. Third-Party Access Defined: Third-party access refers to the ability of embedded content or ads from one website (the third party) to interact with your browser’s storage while you’re visiting another website.
3. Privacy Settings: To control third-party access, navigate to Settings > Privacy or Security in the Maxthon menu. Here, you can manage how much data third parties can collect and retain.
4. Enabling/Disabling Cookies: Under the privacy settings, you can specifically enable or disable cookies from third parties. This can prevent unwanted tracking by advertisers.
5. LocalStorage and IndexedDB Limitations: Unlike cookies that have timeout mechanisms, localStorage and IndexedDB may not be accessed cross-origin unless explicitly allowed via specific browser settings or by user consent.
6. Viewing Site Data: You can view which websites have stored data by going to Settings > Clear Browsing Data > Site Data. Here, you’ll see a list of sites along with their associated storage information.
7. Regularly Clearing Data: It’s good practice to regularly clear your browser’s cache and site data to protect yourself against potential privacy risks associated with long-term storage by third parties.
8. Using Add-ons for Enhanced Control: To further enhance your online security, consider using privacy-focused add-ons available for Maxthon that specialise in blocking or limiting third-party access.
9. Stay Informed About Updates: Maxthon regularly updates its features related to storage and privacy management; ensure you’re using the latest version for optimal security settings.
