Cookie Policy

Cookies and similar browser storage

A cookie is a small value a website asks a browser to store and return with later requests. Local storage is a browser-side key/value store that JavaScript can read. Session storage is similar but generally lasts only for a browser tab session. A browser can also keep cached resources and other state. These technologies can support sign-in, security, accessibility, preferences, and optional analytics or advertising. The current inventory below is based on application code, not on a promise about every hosting provider or future integration.

First-party storage is set by the site the visitor is using. Third-party storage may be set by an embedded or externally loaded provider. Providers can change their behavior, so the operator must re-check the inventory whenever a new script, ad network, analytics tool, or identity integration is added.

Essential session cookie

seoptiz.sid is the application session cookie. It supports sign-in, CSRF state, CAPTCHA state, and other session-bound operations. It is configured as HttpOnly, so client-side scripts cannot read it, and SameSite=Lax to reduce some cross-site request exposure while retaining ordinary site navigation. By default it is a browser-session cookie. Selecting Remember me makes the authenticated cookie persistent for up to thirty days. The Secure attribute is enabled in production only when the corresponding setting is enabled; production operators must use HTTPS and configure it correctly.

When PostgreSQL is configured, session data is stored in the database-backed session store. When it is not, the framework's in-memory store is used and is not a durable multi-process production solution. If a visitor blocks or deletes this cookie, sign-in, verification flows, and other session-dependent functions may not work. This cookie is required for those functions and is not an advertising preference.

Thirty-day notice dismissal

When a visitor closes the cookie notice, the browser stores seoptiz_cookie_notice_dismissed for thirty days and also attempts to store an expiry timestamp in local storage under seoptiz_cookie_notice_dismissed_expires. The second mechanism helps the notice remain dismissed when browser cookie behavior is restricted. It records the visitor's preference to hide the notice; it is not a record of consent to optional cookies, advertising, or analytics.

Removing the cookie or local-storage key can make the notice appear again. Browser privacy settings, private browsing, storage quotas, and embedded browsing contexts can affect whether either mechanism persists. No other preference center is currently provided.

Analytics and advertising

No external analytics provider is configured by default. The client has a guarded optional event hook for a separately supplied analytics script; that hook is not itself a vendor integration. If an owner adds an analytics provider, the owner must identify its name, cookies or storage keys, purposes, retention, and consent behavior here before enabling it.

The administrator can configure Google AdSense placements, publisher verification, and an ads.txt response. Google reCAPTCHA can also be enabled for account and contact forms. These Google services are disabled unless configured. When reCAPTCHA is enabled, its browser widget contacts Google and may use third-party cookies or similar storage and receive browser/request information; inspect the actual browser behavior and applicable terms before activation. If an ad is enabled, the advertising provider may use cookies or similar technologies and may process device, browser, page, and ad-delivery information under its own terms. The notice's Close button does not give advertising consent. A certified or otherwise suitable consent-management mechanism may be required for visitors in the EEA, UK, Switzerland, or other jurisdictions. The current application does not include such a mechanism, so the owner must not serve ads in a consent-required region until it is in place.

Ads can be blocked or withdrawn by a visitor's browser settings. The exact third-party cookie behavior depends on the provider, browser, region, account settings, and ad format. This policy intentionally does not invent vendor cookie names or lifetimes.

Verified storage inventory

• seoptiz.sid: first-party session cookie for authentication and session-bound protections; browser-session duration by default or up to thirty days when Remember me is selected; HttpOnly, SameSite=Lax, Secure only when enabled in production configuration.
• seoptiz_cookie_notice_dismissed: first-party dismissal preference; thirty days; Path=/; SameSite behavior varies by whether the page is served over HTTPS; Secure is set for the HTTPS cross-site/embedded case.
• seoptiz_cookie_notice_dismissed_expires: local-storage expiry timestamp for the same thirty-day dismissal preference; not sent to the server with each request.
• Third-party advertising storage: not configured by default; possible only after an administrator activates an ad placement. Vendor-specific names and durations must be confirmed from the provider and updated before activation in regions where disclosure or consent is required.
• Third-party analytics storage: no vendor is configured by default. Any future vendor must be documented before use.

This inventory reflects the application code checked for this revision. Browser extensions, external website resources, hosting infrastructure, and future changes may add storage beyond the list; the operator must audit the deployed page, not rely solely on this static list.

Consent and changing preferences

Essential session storage is used to provide the account and security functions a visitor requests. Where law requires prior consent for optional analytics or advertising, that consent must be collected before the optional technology is loaded. The current close-only notice is not a consent-management platform, does not record affirmative choices, and does not transmit a consent signal to AdSense. The advertising setting therefore must remain off for affected regions until a compliant preference mechanism has been implemented and tested.

A visitor can remove first-party cookies and local storage through browser controls. They may also block third-party cookies or use privacy protections. Blocking the session cookie can prevent account operations; deleting the dismissal preference only causes the notice to return. Browser controls do not necessarily withdraw consent already recorded by an external provider, so visitors may also need to use the provider's own privacy or ad settings.

How browser storage works and how it is categorized

A session cookie ordinarily expires when its configured session ends, while a persistent cookie remains until its expiry or deletion. An application can set a persistent cookie with a maximum age; the browser can still remove it earlier. Local storage is usually available to scripts running on the same site and is not automatically attached to each HTTP request. Cookies are sent with requests that match their domain, path, security, and same-site rules. This difference affects both privacy and security: an HttpOnly session cookie cannot be read by page JavaScript, while local storage has no HttpOnly equivalent.

“Essential” describes a function needed to deliver a service requested by a visitor, such as holding an authenticated session. It is not an unrestricted permission to store any information. “Preference” storage remembers a choice such as closing a notice. Analytics storage measures use; advertising storage can support ad delivery, frequency controls, measurement, or personalization. A provider's legal category depends on purpose, configuration, jurisdiction, and law—not just the name assigned in a user interface.

The current first-party dismissal preference records that the visitor wants to hide the notice. It does not record a positive selection between essential, analytics, or advertising technologies. The application does not currently offer separate toggles, granular choices, consent history, or a preference-reset link. The operator must not describe the banner as a consent manager.

Storage during anonymous and signed-in use

An anonymous visitor may receive the session cookie because the application keeps session state for public interactions, including its three-test guest allowance and login CAPTCHA state. The guest allowance is held in the browser session, not counted by an IP address. Separately, the Privacy Policy describes visitor-location records that use public IP addresses; those records are not used as the guest-test counter. If a visitor deletes the session or uses a different browser profile, the application may not recognize earlier anonymous tests. This behavior is separate from the thirty-day banner-dismissal preference.

A signed-in visitor uses the same session cookie for account continuity and protections. Account data itself is stored in the configured database rather than in the cookie; the browser cookie contains the session identifier, not a readable password or full account profile. If a database is absent, the framework uses an in-memory fallback that can lose session state on process restart and is not a suitable durable production setup. The operator should not rely on that fallback for production accounts.

No accessibility preference, language selection, or theme preference is currently persisted by a dedicated cookie in the application. If a feature is added that stores such a preference, the operator should name the key, purpose, scope, and lifetime here and should avoid storing sensitive information in browser storage.

Third-party cookie boundaries and optional services

The application does not bundle an analytics vendor by default. Its browser code can call an optional analytics object if a separate script supplies one, but that hook is not a vendor and does not establish a third-party cookie inventory. An administrator must not assume that a third-party analytics cookie exists merely because an event hook is present.

Manual ads can display an administrator-supplied image and link without loading an advertising network. AdSense can load third-party resources after its account and placement settings are configured. That may allow Google or its partners to access browser, request, page, and ad-interaction information under their terms. The exact cookies and storage keys can vary by account, consent mode, region, browser, and provider updates; this application does not hard-code or verify a complete Google cookie inventory. The owner must review the provider's current documentation and test the actual production pages before activation.

Third-party resources can be blocked by browser settings, extensions, network filters, or privacy protections. A missing ad or analytics request may be expected in that environment. No service should be designed to bypass a visitor's browser privacy choice.

Consent rules for optional technologies

Some jurisdictions require consent before placing or reading optional cookies or similar technologies. Others allow limited exceptions or rely on different legal standards. The site owner must determine the rules for the visitor and the service, and must not use geolocation or a general banner as a substitute for an appropriate legal analysis.

The current close-only notice has one action: dismiss. It does not provide an accept button, reject button, vendor list, purpose-level controls, or a way to withdraw optional consent. It does not send a consent string or other preference to an advertising vendor. Because the application has no integrated consent-management platform, an owner should leave advertising disabled for any visitor group where prior consent is needed until a suitable, tested consent mechanism is installed and the actual provider respects it.

If a consent tool is added, it should default optional categories off until the visitor makes a valid choice where required, offer an equally accessible reject option when required, record the choice in a durable and auditable way, allow withdrawal as easily as acceptance, and prevent optional tags from loading before consent. The policy and inventory should state which vendors and purposes are involved. Closing this current banner is not that choice.

Examples of storage purposes and what is not stored

The session identifier lets the application associate a request with a temporary session; it is not intended to encode a password or store a complete profile in the browser. The notice-dismissal preference stores an expiration value so the page can decide whether to show the same notice again. Neither key measures how long a person reads an article, records the contents of a tool submission, or establishes a marketing preference. The browser may keep unrelated cached page assets, but those are not a cookie inventory and should not be described as a tracking technology without evidence.

The current application does not persist a location preference, advertising opt-out, consent string, language setting, or accessibility preference through its own dedicated cookie. It also does not set a named third-party analytics cookie by default. An optional provider or external script can change these facts; the owner must inspect and document the actual browser behavior after such a change.

Cookie duration describes the browser's configured lifetime, not the time a server retains related account data, a provider's logs, or a backup. Deleting a browser cookie does not automatically delete an account, report, server log, or third-party record. The Privacy Policy describes those separate data-retention considerations.

Auditing the inventory and updating this policy

A static code review cannot reveal every browser technology introduced by an external provider. Before each production release that adds an integration, the operator should inspect the page in a clean browser profile, record cookies and local/session storage before and after relevant interactions, examine network requests, identify the script owner, and compare the results with provider documentation. Repeat the review for anonymous and signed-in views and for each ad or consent state.

For each observed storage item, document the exact key, domain, first- or third-party status, purpose, category, session or persistent behavior, configured duration, and the provider's stated retention if known. If a value varies by region or consent choice, record those conditions. Remove stale entries when a provider is removed. Do not guess a name or duration from a similarly named cookie found on another site.

Policy changes should identify the revision date and describe material additions in plain language. If the change involves optional tracking, use an appropriate notice and collect new consent where required before activating it. Visitors can ask general questions using the owner-confirmed inbox listed on the Contact Us page. No dedicated privacy, abuse, or copyright alias is confirmed.

Anonymous and signed-in use

The session cookie can exist for an anonymous visitor as well as a signed-in account. It supports session-level state such as the three free tool tests available before registration is requested. The application does not use an IP address as the key for that anonymous test counter; it is associated with browser session state. Separately, the Privacy Policy describes public-IP location records collected for approximate visitor-location reporting. Clearing browser storage can reset the guest counter. A signed-in visitor may have account records stored in PostgreSQL when the database is configured.

The cookie banner is shown on public pages and its dismissal is shared through the site's first-party storage scope. Logged-in status does not automatically change the banner's meaning or grant optional-ad consent.

Browser controls and limits

Most browsers allow visitors to inspect, block, or delete cookies and local storage. The exact controls vary by browser and device. Blocking all cookies may prevent account sign-in or other essential session functions. Blocking local storage may cause the close-only notice to reappear after a page change in browsers that also block the preference cookie. These outcomes are consequences of browser settings, not evidence that the site has stored a new consent record.

Do Not Track and similar signals do not have one uniform technical meaning across every provider. Seoptiz does not claim that a specific signal changes the behavior of an external ad provider unless the configured provider supports and receives that signal.

Policy changes and contact

The operator should update this policy whenever the inventory changes, including when adding a new identity provider, CAPTCHA provider, analytics script, ad network, chat widget, or consent tool. The revision date identifies the version currently published. Visitors can ask general questions from the Contact Us page, which lists the owner-confirmed general inbox. Dedicated privacy, abuse, and copyright aliases remain unconfirmed.