Privacy and Public-Site Data Practices

Direct answer

What the public site processes

Ordinary public browsing sends the information required for a web server to deliver the requested page. That can include the requested URL, source IP address, request headers, browser and device metadata exposed by the browser, timestamps, and a request identifier generated by the application.

The public repository does not include third-party analytics, advertising networks, tracking pixels, session-replay software, social-media widgets, or embedded third-party runtime scripts. This is a statement about the packaged source. It is not proof of the configuration of an unobserved hosting layer, reverse proxy, or future deployment.

Data inventory

Public interactions and their observable data paths

The table distinguishes repository behavior from infrastructure behavior that the source package cannot independently observe.

Interaction	Data involved	Where it is handled	Repository-supported boundary
Read a public page	URL, request headers, apparent source IP, browser-exposed metadata, request time, generated request ID	Browser, web server, reverse proxy or host, Flask request handling	The repository does not persist a visitor profile from ordinary page views. Hosting logs are environment-dependent.
Use a public lab or simulation	Selected inputs, current view, and generated synthetic state	Mostly in the browser and bounded same-origin public endpoints	Public scenarios reject protected inputs and terminate in synthetic, non-operational state. Some preferences can be stored locally in the browser.
Use the contact form	Name, work email, optional organization, topic, message, timestamps, request ID, status, keyed source-IP hash	First-party browser form and configured application database	Information is supplied voluntarily. The form is not a confidential or classified channel.
Sign in to private administration	Administrator credentials and first-party session state	Private administrative route, session cookie, configured database	No public signup exists. This page does not describe private operator data beyond repository-visible controls.
Follow an external link	Information sent by the browser to the destination, subject to browser and destination behavior	External site	External sites have their own privacy practices and are outside Evulgare's public repository controls.
Download a file	Requested file path and ordinary request metadata	Browser and serving infrastructure	The file may contain its own public evidence or source references; downloading does not create an Evulgare account.

Cookies and browser storage

First-party session state and optional local preferences

The application configures a first-party session cookie named evulgare_session. Repository configuration marks it HTTP-only, SameSite=Lax, and secure in production. A browser session can be used where server-validated state is required, including CSRF protection for the public contact form and private administration.

Several interactive public surfaces use localStorage for optional browser-local preferences or progress. The current repository includes keys for human-judgment lab state, simulation-learning progress, and whether Simulation Workbench keyboard shortcuts are enabled. The tools are designed to continue when browser storage is unavailable.

Browser-local data remains in that browser profile until the page code, visitor, browser policy, or browser controls remove it. The repository does not transmit those local values to a third-party analytics service.

Repository-defined local keys

evulgare.lab.human-judgment.v1 evulgare.simulation-learning-progress.v2 evulgare.simulation.shortcuts.enabled

Key names show the intended local function. They do not prove the current contents of a visitor's browser.

Third-party services

No third-party runtime analytics are declared by the package

The public templates load first-party styles, scripts, fonts, images, and same-origin API requests. The security policy in the repository limits scripts, styles, connections, fonts, and forms to the same origin, with narrowly declared image and WebXR behavior.

The repository does not include Google Analytics, advertising tags, Meta pixels, Hotjar, Clarity, session replay, or equivalent public-site instrumentation. External links are ordinary links, not embedded external runtime components. A hosting provider, DNS provider, TLS endpoint, network service, or operator-configured layer can still process requests outside the source package.

Analytics scripts: NOT PRESENTNo third-party analytics library or tag is referenced by public templates or assets.
Advertising: NOT PRESENTNo advertising network or ad-serving component is declared in the repository.
Tracking pixels: NOT PRESENTNo third-party tracking-pixel endpoint is declared in the repository.
External embeds: NOT PRESENTPublic pages use links rather than embedded third-party media or widgets.
Infrastructure services: ENVIRONMENT-DEPENDENTProduction hosting and network controls cannot be established from source alone.

Voluntary communications

Contact messages are different from passive browsing

When a visitor submits the contact form, the visitor intentionally provides the form fields for review. The application record includes the selected topic and status so the inquiry can be routed and tracked. A keyed hash derived from the apparent source IP is stored; the raw source IP is not a field in the contact-submission model.

Do not include passwords, tokens, private keys, confidential infrastructure details, classified material, target data, customer datasets, or sensitive personal information that is not necessary to the request.

Open the public contact route

Logs and retention

Configured controls are not the same as verified production practice

Ordinary hosting infrastructure may create access, security, proxy, database, or application logs. The repository does not establish which logs a production host currently keeps, who can access them, or how long they remain. Those facts require actual-host inspection.

The application defines a configurable contact-retention window with a default of 365 days and a manual command that can delete closed contact submissions older than the configured cutoff. This is a repository control, not proof that a production operator has run the command or adopted that default as a verified retention policy.

Retention facts established by source

The retention window is configurable through CONTACT_RETENTION_DAYS.
The packaged default is 365 days.
The purge command is explicit and operator-invoked.
Only closed submissions older than the cutoff are selected for deletion.
No broader production retention schedule is claimed.

Changes and questions

How privacy changes will be surfaced

This explanation is repository-owned and versioned with the application. Material changes should appear on this page and in the release history. A production operator may also need to update the page when hosting, logging, contact, or third-party-service behavior changes.

Privacy questions can be routed through the verified public contact form using the “Privacy questions or requests” topic. Do not add unrelated sensitive information to the request.

Route a privacy question Read the public-use terms

Evidence and change history

Inspect the claims behind Privacy

Review claim class, support status, source identity, observation environment, scope, limitations, known defeaters, and append-oriented change events. The ledger does not convert a repository statement or target into deployment, certification, compliance, or external validation.

Open Privacy evidence