Cookie Policy

Draft for deployment review. A useful storage notice must describe what the actual installation does, not merely what a theme can support. Before publication, the operator must inspect the deployed site, identify its cookies and browser-storage records, confirm purposes and lifetimes, and review applicable consent requirements. This draft explains the relevant categories and controls without inventing a provider inventory or claiming that unknown hosting and plugin behavior has been audited.

Cookies and other browser storage

A cookie is a small record a website can ask a browser to store and return with certain requests. Cookies can support session state, preferences, security, or measurement, depending on their purpose. Some disappear when a browsing session ends, while others have an expiry time. The presence of a cookie does not by itself establish whether it is necessary, optional, personal, or used for tracking. Those questions require examining its actual use.

Local storage is different: it stores values for an origin in a browser profile and is accessed by scripts rather than automatically attached to every request like a cookie. Session storage has a more limited browsing-session scope. Both can still affect privacy and can be subject to storage-access rules. A notice should not ignore a preference or identifier simply because it uses local storage instead of a cookie.

Tool settings and checklist progress

Where supported by a tool, the toolkit may save preferences, preset settings, or checklist progress locally so the user does not have to repeat the same choices. These records are not a game-account backup and do not synchronize through this site’s OAuth service, because no such service is provided. Saved values can become unavailable if site data is cleared, the browser profile changes, or privacy settings block access.

Do not rely on local storage for the only copy of an important filter. Download a reviewed file and keep a known-good version separately. On a shared device, another person using the same browser profile may be able to view saved choices. Use the tool’s reset or clear control where available and the browser’s site-data controls when you want to remove remaining records. Confirm that the intended data disappeared instead of assuming that closing a tab cleared it.

Essential functionality and security

Some storage or request state may be needed to perform an action the user requests, protect a form, remember an appropriate privacy choice, or maintain a logged-in administrative session. The legal classification depends on purpose and applicable rules, not on an operator calling everything essential. The public tools should not require advertising or audience-measurement consent merely to perform their core local analysis.

WordPress administrative and authenticated sessions can involve core cookies that ordinary public visitors do not receive in the same way. Hosting, security, or cache layers may add their own records. The operator must test public logged-out pages separately from the dashboard and must not extrapolate a clean test of one page to the entire installation. Contact-form token refreshes and server-side rate-limit records also deserve documentation, even where they are not persistent browser cookies.

Optional analytics and related services

Analytics is off in the supplied default configuration. If the operator enables a provider later, the inventory must name that provider, describe the information sent, specify relevant storage and expiry behavior, and explain how a visitor can make or withdraw a choice. A service that markets itself as cookieless may still process network addresses, request details, or other information. Absence of cookies is not equivalent to absence of personal-data processing.

Optional anti-abuse services, advertising, embedded media, and additional plugins may introduce third-party requests or browser records. Their addition requires a fresh review. A provider should not load before the applicable choice merely because a consent banner is visible. The operator must test network and storage behavior in a fresh browser profile, after acceptance, after rejection, and after withdrawal where those choices are offered.

Consent choices and withdrawal

Where consent is the required basis for nonessential storage or related processing, the choice must be meaningful and tied to the actual purposes. A visitor should be able to decline optional features without the site misrepresenting a refusal as an error. The wording, prominence, and available controls require legal and usability review for the intended audience. This draft does not assert that a particular banner design satisfies every jurisdiction.

If a privacy-preferences control is displayed on the deployed site, use it to revisit the available choices. Withdrawing permission should stop future optional loading where technically applicable, but it may not delete information already received by a third party. Separate deletion rights or provider controls may apply to that information. Clearing browser data can also remove the site’s record of a choice, which may cause the preference prompt to appear again.

Browser controls and their limits

Most browsers provide settings to inspect or remove site data and block some or all cookies. Menu names and available controls differ by browser and device, so consult the browser’s own help rather than relying on fixed instructions that may become outdated. Restricting storage can affect saved presets, checklist progress, administrative sessions, or other requested functions. It should not be described as a security failure merely because a preference cannot be saved.

Private browsing changes local retention behavior but does not make network requests invisible to the host, network provider, or destination services. Likewise, deleting cookies does not remove a downloaded filter, a contact email, or operational records already stored elsewhere. The Privacy Policy must describe those other processing activities and retention practices after the operator has verified the actual providers.

Inventory and change management

Before launch, record each observed storage key or cookie name, the setting party, its purpose, when it is created, and its expiration or deletion behavior. Include anonymous visitor pages, contact submissions, optional integrations, and authenticated areas where relevant. Avoid publishing a guessed list copied from another WordPress installation. Plugins and host configuration can make two sites running the same theme behave differently.

Repeat the inventory after changing providers or enabling features. Update this notice when purposes or records change materially, and seek a new choice where required. Questions about a particular record can be directed through Contact once the operator has configured a working recipient. Include the record’s name and the page where it appeared, but do not send its full value if it could contain a session identifier or other sensitive information.