Privacy Policy and Data Inventory

Version 2026-08-12.1
Effective August 12, 2026 · Technical inventory verified August 5, 2026

Publisher and privacy-request channel

Pasianssia is published by MB „NM Media“. No verified privacy-request channel with a tracked response workflow is currently configured: an operator and counsel must establish and verify that workflow and the required public wording before this notice can advertise that privacy requests may be submitted. The complete controller identity/address, jurisdiction-specific legal bases, rights wording and response deadlines also remain unverified.

Current data practices

The entries below disclose the fields, purpose, provider, activation condition, retention, deletion path and transfer status observed in the current application.

On-device game and preference data

Saved games

Active

Technology / records: localStorage · solitaire:game:v1 · playsolitaire:game:draw2:v1 · playsolitaire:game:freecell:v1 · playsolitaire:game:spider:v1 · playsolitaire:game:daily:v1 · playsolitaire:game:turn3:v1 · playsolitaire:game:turn3-legacy:v1 · playsolitaire:game:spider2:v1 · playsolitaire:game:spider4:v1 · playsolitaire:game:golf:v1 · playsolitaire:game:yukon:v1 · playsolitaire:game:russian:v1 · playsolitaire:game:alaska:v1 · playsolitaire:game:pyramid:v1 · playsolitaire:game:tripeaks:v1 · playsolitaire:game:scorpion:v1 · playsolitaire:game:wasp:v1 · playsolitaire:game:fortythieves:v1 · playsolitaire:game:crescent:v1 · playsolitaire:game:canfield:v1 · playsolitaire:game:eightoff:v1 · playsolitaire:save-envelope:v2:* · playsolitaire:save-quarantine:v2:* · playsolitaire:save-exit:v1:* · sessionStorage: playsolitaire:save-exit-owner:v1
Provider: Your browser (first-party storage)
When it activates: Each non-demo game writes a rollback-compatible raw record plus a validated versioned sidecar. When a dirty page is hidden or closed, it first stages one local page-exit snapshot before the same checked dual writer runs. A later load resumes that snapshot only through its exact predecessor checkpoint, or uses the existing cross-tab conflict recovery if another tab advanced first. Unsupported or damaged records are marked in local quarantine, writes to that game slot stop, and automatic recovery restores a compatible copy or removes an unusable pair before reloading.
Fields: game variant and rules mode
deal seed or FreeCell deal number
card positions, stock, waste, foundations and other variant-specific piles
move count, status, start time and final time when won
full undo history, with a quota fallback that keeps the latest 20 entries or removes the history while retaining the current board
daily date key or onboarding metadata when applicable
save format version, rules version, monotonic revision and update time
pseudonymous deal and attempt identifiers derived from the game slot, seed, rules and start time
a bounded pending-replacement journal containing predecessor lifecycle summaries (variant/mode, finite first-action category, status, move/final totals and pseudonymous identifiers), plus a crash-completion marker while the rollback copy catches up
one temporary page-exit snapshot per document for the game slot, its creation time, a session-scoped opaque document owner identifier, an opaque random per-stage journal generation identifier, its expected revision and non-cryptographic hashes of the predecessor records; if storage quota rejects the full snapshot, undo history is reduced to the latest 20 entries or removed while the current board is retained
quarantine reason, detection time, record size and a non-cryptographic diagnostic hash (the damaged record remains in its original key until recovery)
Purpose: Resume the current game
Undo moves
Restore the requested variant and deal
Preserve the latest move when a page exits while another tab holds the save lock
Validate migrations and preserve rollback compatibility
Prevent damaged, newer or conflicting cross-tab records from overwriting a known-good compatible copy
Retention: Compatible save pairs remain until replaced by another save for that game or until you clear site data. The document owner identifier remains for the tab/session. Each page-exit snapshot is removed after that state is durably accepted or its conflict is resolved; an invalid or abandoned snapshot can remain until a later load cleans it up or until you clear site data. Automatic recovery normally clears a quarantine marker immediately; if browser storage rejects that update, the marker remains until a retry succeeds or you clear site data.
Deletion / control: Automatic recovery keeps a valid compatible copy when one exists; otherwise it removes the unusable slot and starts fresh. If browser storage rejects the repair, use Try again or clear site data in your browser.
Transfer: After account creation or sign-in, a validated board copy can be sent automatically to the first-party account API from a durably fenced import while the guest copy is still authoritative. A valid exact-predecessor page-exit snapshot may supply that board copy, but full undo history, onboarding state, the journal identifier and record, predecessor hashes, and quarantine metadata remain in the browser. The account namespace activates only after the final receipt and local activation state are durable, and a guest namespace already linked to another account is not sent again. (verified in source code)
Verification: All legacy keys, versioned sidecars, central dual writes, quarantine blocks and automatic recovery were traced. (verified in source code)
Legal-review status: The bounded account-transfer behavior is verified in code and the factual disclosure is owner-accepted for launch. This technical inventory is not legal advice or a claim of counsel approval.

Settings and interface preferences

Active

Technology / records: localStorage · solitaire:settings:v3 · solitaire:customThemeVars:v1 · sd-hint-1tap-seen · playsolitaire:hintDebug · solitaire:whatsNew:v1
Provider: Your browser (first-party storage)
When it activates: The main settings and theme cache are written when settings change, and the one-tap flag is written when its instructional hint is acknowledged. The hint-debug flag is only read when someone manually places the value 1 in browser storage. The what’s-new marker is written when the updates page is visited or its menu indicator is shown or expires.
Fields: theme and custom palette values
card and text size
sound, motion, contrast and control preferences
Klondike draw/winnable-deal settings and FreeCell settings
whether the one-tap hint was already shown
whether manually requested hint decisions should be logged to the browser console
which product-update announcement was last acknowledged and on which days its indicator appeared
Purpose: Restore the interface you selected
Avoid repeating an introductory hint
Enable local hint diagnostics when manually requested
Retention: The main settings record and theme cache remain until replaced or reset. The one-tap-seen and manually supplied hint-debug flags remain until individually removed or all site data is cleared; the in-game reset does not delete those auxiliary flags.
Deletion / control: The in-game reset restores the main settings and theme cache to defaults but does not delete the one-tap-seen or hint-debug flags. Clear site data in your browser to remove every record listed here.
Transfer: After account creation or sign-in, the documented gameplay and accessibility preference subset, including card size, can be uploaded automatically to the account API from the durably fenced guest import before the account browser namespace activates. The guest namespace remains authoritative until the final durable receipt and local activation state are stored. A guest namespace already linked to another account is not sent again. Consent, experiments, PWA state, hint state and shuffle history remain device-only. In the current bounded implementation, after a setting is successfully committed, a separate consent-gated GA4 event may report its name and a finite category; custom colours report only an edited-slot category. (verified in source code)
Verification: Settings, pre-paint restoration, and hint acknowledgement writes were traced. (verified in source code)
Legal-review status: The purpose statement is code-verified; the legal classification of each preference is pending counsel review.

Local progress and statistics

Active

Technology / records: localStorage · IndexedDB database: playsolitaire-progress · playsolitaire:stats:v1 · playsolitaire:daily:v1 · playsolitaire:daily:challenge:v1 · playsolitaire:recentlyPlayed:v1 · solitaire:timer:v1 and variant-scoped timer keys · localStorage capability probe: playsolitaire:daily:probe
Provider: Your browser (first-party storage)
When it activates: On the first meaningful action, the legacy localStorage statistics and daily records are frozen as an immutable historical baseline in IndexedDB and a unique methodology-v2 start event is appended. One terminal event may then be appended for that attempt. Challenge links, clocks and recent games continue to use their listed localStorage records. The daily gate writes and removes its probe before using localStorage so it can detect whether durable local progress is available.
Fields: per-variant games played, wins, streaks, best time and fewest moves
historical localStorage aggregate snapshots, retained as a baseline and no longer mutated by methodology v2
pseudonymous attempt, deal and event identifiers derived from the game slot, rules, deal and start time
append-only start and terminal events with variant/mode, first-action category, outcome, move count and elapsed-time summary
daily date, streak, completion, time and moves
incoming daily challenge date, challenger target time and challenger move count
recent game identifiers and timestamps (maximum eight)
played-time snapshot keyed to the current game start
temporary value used only to test whether localStorage can be written
Purpose: Show local records and daily progress
Restore the played-time clock
Show recently played games
Test localStorage availability before writing durable daily progress
Retention: The historical baseline and append-only progress events remain until you clear this site’s browser data; methodology-v2 events are not overwritten or calendar-expired. Other progress records remain until overwritten by newer records or site data is cleared. The daily storage-capability probe is written and synchronously removed during its check.
Deletion / control: Clear site data in your browser.
Transfer: After account creation or sign-in, the first-party account API can automatically receive a cumulative lifetime/daily projection of the verified local event ledger, up to eight recent game keys, and the elapsed-time value stored with each synchronized current or saved game. This durably fenced import may transfer before the account browser namespace activates; the guest copy remains authoritative until the final receipt and local activation state are stored. New automatic handoffs leave raw progress events in the guest browser namespace and retain only the bounded cumulative projection. A guest namespace already linked to another account is not sent again. Ongoing synchronization likewise retains only the latest cumulative rollup, event count and hash-chain checkpoint per browser namespace. A frozen legacy import that was already staged by an older release may retain up to 10,000 validated immutable raw progress events until the account is deleted. Daily challenge links and the browser timer records themselves remain device-only. Consent-gated analytics are disclosed under GA4. (verified in source code)
Verification: Each local record shape and writer was traced. (verified in source code)
Legal-review status: The technical separation between local records and analytics is verified; legal-basis wording is pending counsel review.

PWA install offer state

Active

Technology / records: localStorage · playsolitaire:pwaInstallOffer:v2 · beforeinstallprompt and appinstalled browser events
Provider: Your browser (first-party storage)
When it activates: After EXP-3 settled on the install-chip treatment, the contextual offer is the shared product behavior on eligible free Klondike and Turn 3 pages. A valid browser install-prompt event is intercepted only after the prompt-state record can be written and read back; storage denial, failed readback, malformed events, installed display modes and excluded pages retain browser-default behavior. The state is updated for the bounded win-count fallback, first offer eligibility, explicit dismissal and a dismissed native prompt outcome. Daily games and other variants do not show the offer.
Fields: record version and product-state creation timestamp
install-offer snooze-until timestamp after explicit or native dismissal
at most two distinct pseudonymous credited-attempt identifiers when lifetime Klondike statistics cannot be read
first offer-eligible timestamp used to avoid reporting the eligibility stage twice
Purpose: Offer installation only after two credited Klondike wins
Honor the 14-day dismissal period without falling back to native promotion
Keep eligibility and dismissal behavior stable across page loads and tabs
Avoid duplicate install-offer eligibility reporting across page loads
Retention: The product record remains until you clear site data. An explicit or native dismissal suppresses the offer for 14 days. The record stores at most two fallback attempt identifiers and one first-eligible timestamp; later writes merge these bounded fields rather than growing an activity history.
Deletion / control: Clear this site’s browser data.
Transfer: The creation, snooze and eligibility timestamps and fallback attempt identifiers remain on-device. After analytics consent, separate bounded GA4 events can send the Klondike mode, install-offer stage and finite prompt outcome without an experiment arm; the local timestamps and attempt identifiers are never sent. (verified in source code)
Verification: Eligibility, fail-open prompt interception, EXP-3 state migration, two-win fallback, cross-tab convergence and snooze are registered to one browser-state writer. (verified in source code)
Legal-review status: The local/consent-gated technical separation is code-verified; product-state necessity, proportionality and analytics-consent wording remain pending counsel review.

First-game continuity record

Active

Technology / records: localStorage · playsolitaire:firstGame:v2 · sessionStorage: playsolitaire:firstGame:pagehide:v1 · localStorage capability probe: playsolitaire:firstGame:probe · sessionStorage capability probe: playsolitaire:firstGame:sessionProbe · first-party cookie: ps_first_game (fallback only)
Provider: Your browser and the Pasianssia origin for the fallback cookie
When it activates: The storage probes run before first-game assignment to test localStorage and sessionStorage availability. The continuity record is then created for first-game assignment, a short-lived session marker is written on pagehide when sessionStorage works, and the fallback cookie is used only when the localStorage probe fails.
Fields: random assignment identifier
variant and draw mode
golden-deal flag, optional seed, pool index and pool version
reserved/started/won/abandoned status
first-seen, start, end and return timestamps
analytics-sent flags
move and played-time summaries in localStorage only (omitted from the fallback cookie)
pagehide refresh marker containing the assignment identifier and pending-session end time in sessionStorage
temporary values used only to test whether localStorage and sessionStorage can be written
Purpose: Keep the first-game assignment and lifecycle idempotent across refreshes
Distinguish an immediate refresh from an abandoned session
Avoid duplicate first-session analytics
Test storage availability and decide whether the fallback cookie is required
Retention: The localStorage record has no calendar expiry. The sessionStorage refresh marker is cleared after a matching refresh or when the tab/session ends. Each storage-capability probe is written and synchronously removed during its check. The fallback cookie has a maximum age of 365 days. These records also disappear when you clear the relevant browser data.
Deletion / control: Clear this site’s local storage, session storage and cookies.
Transfer: The ps_first_game fallback cookie is sent in the Cookie header on same-site requests and therefore traverses Bunny CDN and the Hostinger origin as disclosed under site delivery. The localStorage record and sessionStorage refresh marker remain on-device. (verified in source code)
Verification: Record fields, sessionStorage refresh marker, cookie compaction and registry-fixed Secure/Lax 365-day maximum age were traced. (verified in source code)
Legal-review status: Whether the fallback cookie qualifies as strictly necessary in each jurisdiction is pending counsel review.

Legacy compatibility records

Active

Technology / records: localStorage · solitaire:settings:v2 · solitaire:settings:v1 · playsolitaire:firstGame:v1 · solitaire:stats:v2 · solitaire:stats:v1 · solitaire:results:v1 · solitaire:recordedWins:v1 · solitaire:installPrompt:v1 · playsolitaire:consecutiveLosses:v1 · playsolitaire:ab:stats:v1 · playsolitaire:ab:pwaInstall:v1 · playsolitaire:pwaInstallPrompt:v1 · playsolitaire:ab:gameShell:v1 · playsolitaire:ab:gameShell:v2
Provider: Your browser (first-party storage)
When it activates: Older settings/statistics/first-game keys are read only when migrating settings or deciding whether a visitor has prior play history. The settled PWA install experiment arm is never read and the current install-offer module attempts to remove it during initialization. When the v3 game-shell enrollment gate is active and no v3 record exists, the settled July 2026 game-shell v1 and v2 keys receive presence-only reads; their contents are never parsed or migrated, and they have no current writer. The registered older install-prompt and consecutive-loss keys also have no current reader or writer.
Fields: older settings
older statistics/results/win markers
first-game-used flag
legacy install-prompt and consecutive-loss records if an older release wrote them
settled personal-best experiment arm (stats or control) if a 2026-07 release assigned one
settled PWA install experiment arm (install or control) and v1 prompt state until migration cleanup succeeds
settled game-shell v1 or v2 assignment and first-assignment timestamp if a July 2026 release wrote one
Purpose: Preserve rollback compatibility
Avoid treating an existing player or prior game-shell participant as a first-time visitor
Disclose registered legacy keys even when the current release has no writer for them
Retention: The settled PWA install assignment and v1 prompt state are removed best-effort after the prompt state migrates to the separate v2 product key. Inert game-shell assignment records and other existing values remain until browser data is cleared.
Deletion / control: Clear site data in your browser.
Transfer: The compatibility reads do not upload the legacy record contents. (verified in source code)
Verification: Only migration and prior-play reads remain for these keys. (verified in source code)
The older install-prompt, consecutive-loss and settled personal-best experiment keys remain registered without current writers; the retired PWA experiment key has a removal-only owner, and game-shell v1/v2 have only explicit presence readers in the dormant v3 gateway. (verified in source code)
Legal-review status: Retention proportionality for legacy values is pending counsel/product review.

Share sheet and clipboard actions

Active only after your interaction

Technology / records: Web Share API (navigator.share) · Clipboard API (navigator.clipboard.writeText) · legacy document.execCommand copy fallback
Provider: Your browser for clipboard operations; the application or person you choose in the operating-system share sheet for native sharing
When it activates: Only after you press a share or copy control. Touch-device result sharing can open the native share sheet; desktop result sharing and deal/guide citation controls copy to the clipboard.
Fields: result or challenge text, including applicable game/variant, time, moves, streak or daily result
Pasianssia page, challenge or numbered-deal URL
FreeCell deal number embedded in a copied URL
guide/citation text selected by the copy control
Purpose: Let you share a result or challenge through a destination you choose
Copy a deal URL, result, guide snippet or citation for reuse
Retention: Pasianssia does not retain a separate copy of the shared or copied payload. Clipboard history and a chosen share target may retain it under browser, operating-system or destination controls.
Deletion / control: Replace or clear your clipboard using browser/operating-system controls. For native sharing, use the chosen destination’s controls; Pasianssia cannot delete a payload after you send it there.
Transfer: Clipboard-only actions remain within browser/operating-system clipboard handling. Native sharing transfers the displayed payload only to the application or person you select; Pasianssia does not choose or receive that destination. (vendor or contract verification pending)
Verification: Every native-share and clipboard payload construction path was traced. (verified in source code)
Clipboard history and selected native-share destination retention depend on the browser, operating system and destination. (vendor or contract verification pending)
Any required legal wording for user-directed native sharing remains pending counsel review. (counsel review pending)
Legal-review status: The code-level user interaction and payload fields are verified; legal characterization of a user-selected destination remains pending counsel review.

Offline and performance caches

Active

Technology / records: Cache Storage · playsolitaire-precache-<service-worker-content-hash> · playsolitaire-runtime-<service-worker-content-hash>
Provider: Your browser (service worker)
When it activates: Created when the service worker installs and as same-origin pages or static assets are requested. Before a production guest import can freeze browser state, the active controlling worker must answer the version-1 guest-state protocol and there must be no waiting replacement worker.
Fields: site HTML
offline page
card images, fonts, icons and other static assets
request URL/path needed as the cache key
fixed guest-state protocol version and an ephemeral request identifier used only for the page/worker readiness exchange
Purpose: Provide offline recovery
Make repeat navigation and static assets faster
Prevent a guest import from starting under an older or overlapping service-worker protocol generation
Retention: Old Pasianssia cache versions are deleted when a new service worker activates. The current caches remain until replaced, evicted by the browser, or site data is cleared.
Deletion / control: Clear this site’s cached data/service worker storage in your browser.
Transfer: Cache Storage remains on-device. API responses and local game-save payloads are not cached by this service worker. (verified in source code)
Verification: Cache prefixes, allowlist, API bypass, old-version deletion and the guest-state protocol response were traced. (verified in source code)
Legal-review status: Any jurisdiction-specific storage disclosure classification is pending counsel review.

Site delivery and security

CDN, origin hosting and request handling

Active

Technology / records: Bunny CDN · Hostinger VPS · Caddy · Astro Node server · first-party POST /api/csp-report report-only collector · systemd journal for bounded normalized CSP reports
Provider: Bunny.net and Hostinger; NM Media-operated application runtime
When it activates: Every request to the site and its first-party API routes.
Fields: IP address and connection metadata
requested URL, method and request headers including browser user agent and referrer when supplied
daily-share URL query fields when a recipient opens a result link: t (elapsed seconds), m (move count), and optional s (streak length)
response status and timing metadata
Cookie request headers when attached by the browser, including the compact ps_first_game record, ps_analytics_denied state, and consented _ga / _ga_* identifiers
edge-derived two-letter country code for /api/geo
Bunny request-log fields if current zone logging and IP anonymisation are confirmed: masked IP, URL/path, country, user agent, referrer and status
normalized Content Security Policy report fields: release/environment, policy version, document origin/path without query or fragment, effective and violated directive, disposition, response status, blocked target category/origin/path, source origin/path, and line/column numbers
Purpose: Deliver the site
Route and secure requests
Return a fail-closed regional consent verdict
Observe required-origin violations before deciding whether the report-only Content Security Policy can be enforced
Retention: Bunny documentation describes raw-log retention of 3 days, but current zone logging, anonymisation and forwarding settings require acceptance verification. Production journald is configured for at most 7 days, 1 GB total and 1-day files; the active Caddy configuration has no file access-log directive and no Caddy files were present under /var/log/caddy when checked on 2026-07-15. Hostinger platform/network-level retention remains externally unverified.
Deletion / control: Normalized CSP reports expire under the verified journald limits. Other records expire under the stated provider limits only if the pending settings are confirmed. No verified monitored privacy-request channel is currently configured; an operator must establish a working request workflow before provider/origin deletion requests can be handled. Available deletion will depend on the record and applicable law.
Transfer: Requests pass through Bunny CDN and the Hostinger-hosted origin. This includes daily-share t, m and optional s query fields when a recipient requests a shared result URL. Exact processing locations and transfer mechanisms are pending contract and provider-console verification. (operator verification pending)
Verification: The /api/geo data minimisation and no-store response were traced. (verified in source code)
The CSP collector accepts only bounded CSP media types, strips queries, fragments, samples, referrers and original policies, emits normalized one-line journal records, rate limits requests and returns no-store responses. (verified in source code)
Staging/production acceptance must capture current Bunny zone logging, IP anonymisation, forwarding, permanent-storage and extended-logging settings; the documented raw-log retention is 3 days. (operator verification pending)
Production acceptance on 2026-07-15 confirmed journald SystemMaxUse=1G, SystemMaxFileSize=100M, MaxRetentionSec=7day and MaxFileSec=1day; the active Caddy configuration had no access-log directive and /var/log/caddy contained no Caddy log file. (verified in the current deployment)
Hostinger platform/network logging and retention still require provider-console or contract verification. (operator verification pending)
Processor roles and international-transfer wording require contract and counsel review. (counsel review pending)
Legal-review status: Controller/processor roles, lawful basis, and transfer mechanism are not approved in this inventory and remain pending counsel review.

User-initiated third-party content

External publisher and metadata links

Active only after your interaction

Technology / records: ordinary browser links to registered HTTPS destinations · non-fetching HTML and JSON-LD references to registered metadata destinations · https://nmmedia.lt/ · https://nmmedia.lt/ · https://schema.org/
Provider: NM Media when you choose its publisher link; Schema.org is referenced only as the structured-data vocabulary
When it activates: The publisher and schema URLs can appear as inert HTML or JSON-LD metadata, which does not itself contact the named destination in the browser. A browser navigation to NM Media opens only after you activate its link.
Fields: publisher and schema URLs embedded in page metadata without an automatic browser request
destination URL selected by you
IP address and browser/request headers, including a referrer when the browser supplies one, after HTTPS navigation
Purpose: Declare the publisher and structured-data vocabulary without automatically loading those destinations
Open NM Media publisher information after you choose its link
Retention: Pasianssia does not retain a separate operational record of ordinary outbound navigation. Any destination request is controlled and retained by the selected browser and destination under their own terms.
Deletion / control: Use the selected destination controls. Pasianssia cannot delete a request held by a destination you chose.
Transfer: Metadata references remain values in the delivered page and do not themselves make a browser request. Only your activation navigates to a registered HTTPS destination, which then receives normal request metadata. (vendor or contract verification pending)
Verification: Every shipped external navigation and metadata destination is parsed from built output and matched to its typed registry. (verified in source code)
Destination logging, retention, account linking and deletion behavior are controlled by each selected destination. (vendor or contract verification pending)
Any jurisdiction-specific notice or lawful-basis wording for user-directed external navigation remains pending counsel review. (counsel review pending)
Legal-review status: The interaction gate and destination set are code-verified; destination processing and legal characterization are not presented as counsel-approved.

Local data and browser controls

Clearing cookies alone does not remove localStorage or Cache Storage. Use your browser’s “site data” control to remove saved games, settings, local statistics, privacy choices, service-worker caches and first-party cookies together. The game does not currently provide an account or server copy of those local records.

Requests and applicable rights

No verified monitored channel for access, correction, deletion, restriction, objection, portability or other privacy requests is currently configured. Establishing that workflow and response process is an open operator/counsel item, not a service this notice claims is available today. Some on-device data can only be controlled through your browser because we do not receive the complete local record. Exact statutory rights, exemptions and response deadlines are pending counsel verification and are not expanded or limited by this technical notice.

Advertising, accounts and sale of data

The current application has no active advertising, account, subscription or data-sale integration. This is a source/deployment statement, not a legal certification about future processing. Those features require a separate launch gate and a new version of this notice before activation.

Changes

A material data-practice change must update the typed inventory, its regression tests, this notice version and effective date before release. Historical Git versions provide the change record.