Privacy Policy and Data Inventory
Version 2026-07-18.1
Effective July 18, 2026 · Technical inventory verified July 18, 2026
Publisher and privacy-request channel
PlaySolitaire.io is published by MN Media s.r.o.. A contact form at /contact delivers messages to the operator's mailbox once the deployment's SMTP transport and destination settings are configured; the release gate requires this notice and that configuration to stay consistent, and live delivery is confirmed during release acceptance. The form is a general contact channel. 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:freecell:v1 · playsolitaire:game:spider:v1 · playsolitaire:game:daily:v1 · playsolitaire:game:turn3: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:*- Provider
- Your browser (first-party storage)
- When it activates
- Each non-demo game writes a rollback-compatible raw record plus a validated versioned sidecar. The same dual writer runs when the page is hidden or closed. Unsupported or damaged records are marked in local quarantine and all further writes to that game slot stop until you use the visible recovery control.
- 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
- undo history (normally compacted to the latest 20 entries during lifecycle flush)
- 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
- 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
- Validate migrations and preserve rollback compatibility
- Prevent damaged, newer or conflicting cross-tab records from being silently overwritten
- Retention
- Compatible save pairs remain until replaced by another save for that game or until you clear site data. A quarantine marker remains until you explicitly recover that save slot or clear site data.
- Deletion / control
- Use the saved-game recovery control when shown, or clear site data in your browser. Recovery keeps a valid compatible copy when one exists; otherwise it removes the unusable slot and starts fresh.
- Transfer
- The raw save, versioned sidecar and any quarantine metadata remain in browser storage and are not uploaded. (verified in source code)
- Verification
-
- All legacy keys, versioned sidecars, central dual writes, quarantine blocks and visible recovery were traced. (verified in source code)
- Legal-review status
- The local-only technical behavior is verified in code; its treatment under storage and privacy law remains pending counsel review.
Settings and interface preferences
Active- Technology / records
localStorage · solitaire:settings:v2 · 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
- The settings record remains local. 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. Historical pre-cutover analytics are disclosed under GA4 below. (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
- These complete local records are not uploaded. Consent-gated analytics can send selected gameplay summaries plus stable pseudonymous event, attempt and deal join identifiers, 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.
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 PlaySolitaire 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.
Analytics consent and opt-out choices
Active- Technology / records
localStorage: ps:consent:v1 · localStorage: ps:optout:v1 · sessionStorage: ps:analytics-denied:session:v1 · first-party cookie: ps_analytics_denied · BroadcastChannel: playsolitaire:privacy:v1- Provider
- Your browser and the PlaySolitaire origin
- When it activates
- Read on every page. Written when you accept, reject, or use the analytics opt-out control.
- Fields
- analytics allowed/denied
- decision timestamp
- whether a non-GDPR geo result supplied an implied acceptance
- opt-out/denial flags
- Purpose
- Enforce your analytics choice
- Make rejection win across tabs and page reloads
- Retention
- The localStorage choice lasts until changed or cleared. The denial cookie has a maximum age of 365 days. The session flag ends with the browser tab/session.
- Deletion / control
- Change the choice through Cookie settings or the analytics opt-out page, or clear site data. Withdrawing consent also clears GA and Hotjar cookies that are visible to the site.
- Transfer
- The ps_analytics_denied 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 consent script calls the first-party /api/geo endpoint without browser credentials when no choice exists. (verified in source code)
- Verification
-
- The denial-dominant state machine, registry-fixed cookie value/retention/security, storage and cross-tab paths were tested. (verified in source code)
- Legal-review status
- Regional consent requirements and any lawful basis for non-consented operational processing are pending counsel review.
Transient analytics-decision event queues
Active- Technology / records
in-memory JavaScript eventQueue · in-memory JavaScript pwaEventQueue- Provider
- Your browser memory before an analytics decision; Google only after the state resolves to granted
- When it activates
- An attempted GA4 or PWA event is held in memory when the analytics decision is still unknown or the consented Google tag has not finished loading.
- Fields
- queued event name
- queued event parameters from the gameplay, settings, first-game, CTA, sharing, video and PWA fields disclosed under Google Analytics
- temporary PWA session-tracked flag
- Purpose
- Wait for the privacy decision before sending
- Preserve event order while the consented Google tag loads
- Prevent duplicate PWA session reporting
- Retention
- Memory only until the decision/navigation ends: denial clears both queues immediately; grant flushes queued events to GA4 and removes them from the arrays; a page unload discards remaining memory.
- Deletion / control
- Reject or withdraw analytics to clear the queues immediately, or leave/reload the page to discard page memory.
- Transfer
- No queued event is transferred while the decision remains unknown. If the decision becomes granted, queued fields are sent to Google under the GA4 entry; denial discards them without that transfer. (verified in source code)
- Verification
-
- Unknown, denied, granted, flush and page-lifetime queue paths were traced. (verified in source code)
- Legal-review status
- The pre-decision memory behavior is code-verified; any legal classification of transient in-memory processing remains pending counsel review.
Legacy compatibility records
Active- Technology / records
localStorage · 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- 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 registered install-prompt and consecutive-loss keys have no current reader or writer. Current code does not write any key in this entry.
- 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
- Purpose
- Preserve rollback compatibility
- Avoid treating an existing player as a first-time player
- Disclose registered legacy keys even when the current release has no reader or writer for them
- Retention
- No automatic expiry or deletion is implemented. 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 install-prompt, consecutive-loss and settled personal-best experiment keys remain registered but have no current reader or writer. (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
- PlaySolitaire 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
- PlaySolitaire 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; PlaySolitaire 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; PlaySolitaire 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.
- Fields
- site HTML
- offline page
- card images, fonts, icons and other static assets
- request URL/path needed as the cache key
- Purpose
- Provide offline recovery
- Make repeat navigation and static assets faster
- Retention
- Old PlaySolitaire 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 and old-version deletion 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; MN 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.
Analytics and error monitoring
Google Analytics 4
- Technology / records
Google tag G-L22FHX4NDQ · www.googletagmanager.com/gtag/js · www.google-analytics.com/g/collect and region1.google-analytics.com/g/collect · GA4 web stream 4800998831 · Google Analytics property 361367397 · cookies such as _ga and _ga_*- Provider
- When it activates
- Loads only when the site’s denial-dominant privacy state machine resolves to granted on the production hostname. With no saved choice, a verified edge country outside the code’s GDPR-region set creates an implied grant; a configured-region or unknown result shows the banner. Staging, automated browsers and explicit rejection remain silent.
- Fields
- page URL, referrer, session and device/browser information collected by the Google tag
- network-derived approximate location and request metadata processed by Google
- Google user/session pseudonymous identifiers and consented GA cookies
- the Enhanced Measurement umbrella switch is on, but pageChangesEnabled, scrollsEnabled, outboundClicksEnabled, siteSearchEnabled, videoEngagementEnabled, fileDownloadsEnabled and formInteractionsEnabled are absent/default false; the configured q, s, search, query and keyword parameter list does not collect site-search events while siteSearchEnabled is false
- game variant, mode, suit/draw mode, deal number/seed where emitted, move count, elapsed-time summaries and outcome/reason
- methodology version plus stable pseudonymous event, attempt and deal identifiers derived from game state for BigQuery lifecycle joins and deduplication
- first-game random assignment ID, pool/experiment metadata and lifecycle timestamps/status
- two-suit Spider deal_pool, deal_difficulty, pool_version, pool_index and rollout_arm; rollout_arm remains raw-export-only and is not registered as a GA4 custom dimension
- exact custom event parameter names: abandoned, action_type, already_won, assignment_id, attempt_id, beat, cta_id, cta_location, day_key, deal_difficulty, deal_id, deal_mode, deal_number, deal_pool, draw_mode, event_id, first_game_move_count, first_game_played_ms, first_game_status, first_session_duration_ms, freshness, game, game_variant, goal, golden_deal, has_result, ineligible_reason, kind, length, locale, message, method, methodology_version, mode, move_count, new_best, outcome, page_type, played_ms, pool_index, pool_version, promo_id, pwa_display_mode, pwa_is_standalone, pwa_precached, pwa_service_worker_supported, reason, reply, rollout_arm, scenario_id, seconds_to_goal, setting_key, setting_value, shown_count, source, start_seconds, streak_length, suit_mode, surface, their_t, trigger, variant, video_id, win_streak, won
- daily/share fields include day_key, freshness, has_result, already_won, beat, their_t (the friend target time in seconds), method, outcome, kind, surface, streak_length and reply
- content and navigation fields include page_type, goal, scenario_id, seconds_to_goal, cta_id, cta_location, video_id, game, locale and start_seconds
- deadlock and promotion fields include trigger, shown_count and promo_id; rows sent while the settled 2026-07 personal-best experiment ran also carry ab_stats, retained in the BigQuery export
- PWA fields include pwa_display_mode, pwa_is_standalone, pwa_service_worker_supported and pwa_precached
- after the bounded setting-analytics cutover, successfully committed setting name and finite category are sent as setting_key and setting_value, with source; custom colours report only the edited slot and customized or reset_default
- historical setting_changed rows collected before the cutover, and legacy rows potentially emitted afterward by already-open or stale cached clients, may contain joined raw custom-palette colour values including picker-change events; the separate BigQuery export can retain those rows indefinitely
- deck-integrity action_type and bounded diagnostic message (up to 200 characters)
- Purpose
- Measure pages and game usage
- Evaluate product experiments and content interactions
- Detect aggregate gameplay/integrity problems
- Retention
- GA4 event and user data retention in the GA interface is configured to 14 months, reset on new activity. That setting does not expire the separate BigQuery export disclosed below. Cookie lifetime is controlled by the Google tag and browser; the exact live cookie expiry still needs a browser verification.
- Deletion / control
- Reject or withdraw through Cookie settings or the opt-out page to stop later events and clear visible GA cookies. No verified monitored privacy-request channel is currently configured for requests about data already received by Google; establishing that workflow remains an operator/counsel action.
- Transfer
- Consented analytics is sent to Google. Exact processing locations, Google entity/roles and international-transfer mechanism are pending contract and counsel review. (counsel review pending)
- Verification
-
- The single consent-gated event gateway and all code-level event producers were traced. (verified in source code)
- GA4 Admin API: active web stream 4800998831 / G-L22FHX4NDQ. enhancedMeasurementSettings returns streamEnabled=true and searchQueryParameter=q,s,search,query,keyword; pageChangesEnabled, scrollsEnabled, outboundClicksEnabled, siteSearchEnabled, videoEngagementEnabled, fileDownloadsEnabled and formInteractionsEnabled are absent/default false, so configured search parameters are not currently collected as site-search events. Standard property; FOURTEEN_MONTHS event/user retention; reset-on-new-activity true; Google Signals ENABLED with consent state CONSENTED; property timezone America/Los_Angeles. (verified through an administrative API)
- Live GA cookie expiry and exact Google processing/subprocessor facts need browser and contract verification. (vendor or contract verification pending)
- The bounded setting-analytics and lifecycle-methodology cutover was activated at 2026-07-15T12:50:26Z in production release a34baa34ca6cdae2eb69e2e5d09d5c2dd2efa096. The event-scoped methodology_version custom dimension was registered in GA4; the high-cardinality lifecycle identifiers were not registered. (verified in the current deployment)
- GA4 Admin API: the existing event-scoped pool_index dimension was renamed from Golden pool index to Deal pool index; event-scoped deal_difficulty was registered; rollout_arm was intentionally left unregistered for raw BigQuery analysis only. (verified through an administrative API)
- Monitor the post-cutover stale-client tail for legacy raw palette-shaped setting_value rows after export latency has elapsed. (operator verification pending)
- Consent scope, Google Signals, legal basis and transfer mechanism require counsel review. (counsel review pending)
- Legal-review status
- The Admin API facts are operational facts only; they do not establish lawful basis or legal approval. Google Signals being enabled requires explicit counsel/product review.
GA4 BigQuery export
- Technology / records
Google Cloud BigQuery · stilldeck-analytics:analytics_361367397 (EU dataset) · daily events_* and pseudonymous_users_* tables- Provider
- Google Cloud, in the MN Media-managed stilldeck-analytics project
- When it activates
- GA4 exports collected analytics rows to BigQuery. Because source GA4 collection is gated, explicit rejection prevents new PlaySolitaire events from entering the export.
- Fields
- exported GA4 event rows and event parameters
- pseudonymous user identifiers and pseudonymous_users records
- event time, page, session, device/browser, approximate geo, traffic-source and consent metadata supplied by the GA4 export schema
- the custom game, PWA, settings, experiment, CTA, video and diagnostic fields listed in the GA4 entry
- Purpose
- Run product and traffic analysis outside the GA interface
- Join and audit pseudonymous event lifecycles
- Preserve historical measurement series
- Retention
- The EU dataset has no default table expiration, and inspected daily events and pseudonymous-user tables have no expiration time. Exported rows are therefore retained indefinitely until someone with project access manually deletes them or adds an expiry.
- Deletion / control
- There is no automatic expiry. Deletion requires an authorised operator to delete or rewrite the relevant BigQuery tables/rows. No verified monitored privacy-request channel is currently configured; establishing that workflow remains an operator/counsel action.
- Transfer
- The export is stored in a Google Cloud BigQuery dataset configured in the EU. Google Cloud roles, subprocessors and any onward-transfer mechanism remain pending contract and counsel review. (counsel review pending)
- Verification
-
- BigQuery dataset analytics_361367397 is in the EU and has no defaultTableExpirationMs; sampled events_20260712 has no expirationTime; daily events and pseudonymous_users tables are present. (verified through an administrative API)
- Google Cloud project access, deletion procedure, audit logs, DPA and subprocessor facts need an operator/contract review. (vendor or contract verification pending)
- Indefinite retention proportionality, lawful basis, rights handling and international-transfer wording require counsel approval. (counsel review pending)
- Legal-review status
- The EU dataset location is verified, but it does not itself establish a lawful basis or eliminate all international-transfer questions. Indefinite retention is an operational fact, not an approved legal conclusion.
Sentry error monitoring
Active- Technology / records
@sentry/node · Sentry browser SDK loaded from browser.sentry-cdn.com only after a client error · ingest.de.sentry.io project endpoint- Provider
- Sentry
- When it activates
- Server SDK initializes for valid production/staging deployment identities. The browser SDK is fetched only after an error or unhandled rejection; its default browser integrations then apply to later captured events on that page.
- Fields
- error message, exception type and stack trace
- page URL and default browser SDK, runtime, release and environment context
- server request method and URL path after query strings and fragments are removed
- server RequestData collection is disabled; beforeSend also removes request bodies/data, parsed cookies, every request header, query values, request environment fields and Sentry user fields before transmission
- browser request IP address, user agent and connection metadata processed by the Sentry CDN and ingest endpoints
- default browser SDK breadcrumbs after initialization: navigation, console activity, fetch/XHR URLs and DOM interaction metadata
- unexpected values that an application or dependency explicitly places in an error message, stack, breadcrumb or other event field
- Purpose
- Detect, diagnose and repair application failures
- Separate staging and production errors by release/environment
- Retention
- Not defined in application code; current project retention requires Sentry-console verification.
- Deletion / control
- No verified monitored privacy-request channel is currently configured for requests about Sentry records. Establishing a working request workflow remains an operator/counsel action; deletion will also depend on record availability and applicable law.
- Transfer
- Errors go to the configured Sentry DE ingest endpoint. Storage location, subprocessors and any onward transfer remain pending vendor/contract verification. (vendor or contract verification pending)
- Verification
-
- Client/server initialization, browser defaults, release/environment separation, disabled server RequestData integration and the beforeSend request/user scrub were traced and regression-tested. (verified in source code)
- Staging/production acceptance must verify the exact Sentry release/environment identities emitted by each deployed SHA and confirm that staging events do not appear as production. (operator verification pending)
- Project retention, location and deletion settings require a Sentry-console and contract audit. (vendor or contract verification pending)
- The lawful basis for error monitoring outside the analytics-consent gate requires counsel approval. (counsel review pending)
- Legal-review status
- The server request scrub materially limits request-carried data, but error messages, stack traces and later browser breadcrumbs can still contain unexpected personal data. Lawful-basis wording is pending counsel review.
Hotjar behavior analytics
- Technology / records
Hotjar site 6689617 · static.hotjar.com/c/hotjar-6689617.js loader · script.hotjar.com vendor modules and in.hotjar.com ingest endpoints, plus further vendor-internal *.hotjar.com / *.hotjar.io and WebSocket endpoints · cookies such as _hjSession_6689617 and _hjSessionUser_6689617- Provider
- Hotjar (a Contentsquare company)
- When it activates
- Loads only when the denial-dominant privacy state machine resolves to granted on the production hostname, and even then only after the window load event plus a browser idle callback, so the script never competes with page rendering. Staging, automated browsers and explicit rejection remain silent. Withdrawal tears down Hotjar globals, script elements and visible _hj* cookies.
- Fields
- page URL, referrer, viewport and device/browser information collected by the Hotjar script
- mouse movement, click, tap and scroll interaction coordinates used for heatmaps and session recordings
- Hotjar pseudonymous user/session identifiers and consented _hj* cookies
- network-derived approximate location and request metadata processed by Hotjar
- text typed into form fields is suppressed by Hotjar default masking; recordings capture interaction shape, not keystroke content, subject to vendor-console verification below
- Purpose
- Understand how the interface is used through aggregated heatmaps
- Review consented session recordings to find usability problems
- Retention
- Vendor-side recording and heatmap retention is controlled in the Hotjar console and requires vendor-console verification. Cookie lifetime is controlled by the Hotjar script and browser; the exact live cookie expiry still needs a browser verification.
- Deletion / control
- Reject or withdraw through Cookie settings or the opt-out page to stop later collection and clear visible _hj* cookies. No verified monitored privacy-request channel is currently configured for requests about data already received by Hotjar; establishing that workflow remains an operator/counsel action.
- Transfer
- Consented behavior data is sent to Hotjar. Exact processing locations, the Hotjar/Contentsquare entity roles and the international-transfer mechanism are pending contract and counsel review. (counsel review pending)
- Verification
-
- The consent-gated, load-plus-idle-deferred loader and the withdrawal teardown of Hotjar globals, scripts and cookies were traced. (verified in source code)
- Production acceptance must confirm no Hotjar request is emitted before consent and that the loader appears only after the granted decision on the live site. (operator verification pending)
- Hotjar console settings — retention, masking/suppression configuration, recording sampling and DPA facts — require a vendor-console and contract audit. (vendor or contract verification pending)
- Consent scope for session recordings, proportionality, lawful basis and transfer mechanism require counsel review. (counsel review pending)
- Legal-review status
- Session-recording collection is limited by consent gating and vendor default masking, but recordings can still capture unexpected on-screen content. Lawful-basis and retention wording is pending counsel review.
Contact delivery and abuse controls
SMTP contact delivery
Active only after your interaction- Technology / records
/contact form · POST /api/contact · SMTP_HOST · SMTP_PORT · SMTP_USER · SMTP_PASS · CONTACT_TO · Nodemailer- Provider
- The operator-configured SMTP mailbox provider that receives messages for the site mailbox
- When it activates
- Data leaves the browser only after you fill in the form at /contact and press send. The endpoint processes a request only when every required SMTP runtime entry is configured and, on deployed hosts, the edge attestation headers match; otherwise it refuses before reading the body.
- Fields
- email address
- message
- locale
- mail transport metadata
- Purpose
- Deliver your contact message to the site mailbox and answer it by email
- Retention
- The delivered email remains in the receiving mailbox until the operator deletes it; the application server stores no copy.
- Deletion / control
- Ask for deletion in the message itself or in a reply; the operator deletes the mailbox copy.
- Transfer
- Submitting the form sends your message from the application server to the operator-configured SMTP provider over an authenticated connection for delivery to the site mailbox. (operator verification pending)
- Verification
-
- The form at /contact posts to /api/contact, which validates, rate-limits and forwards the message via the configured SMTP transport; with incomplete SMTP settings the endpoint returns 503 before parsing the request body. (verified in source code)
- Production release acceptance must confirm the required SMTP and destination variables are present in the protected production profile and that a monitored end-to-end submission is delivered to the configured mailbox. (operator verification pending)
- Legal-review status
- The reply-only purpose is stated next to the form. Provider, retention, DPA and transfer documentation must be kept current with the configured SMTP provider; formal privacy-request workflow wording remains pending counsel review.
User-initiated third-party content
External publisher, reference, licence and contributor 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 · mailto link for the published copyright address · https://creativecommons.org/licenses/by/4.0/ · https://en.wikipedia.org/wiki/Klondike_(solitaire) · https://mnmedia.io/ · https://www.linkedin.com/in/ · https://www.serrae.net/ · https://www.upwork.com/ · https://www.youtube.com/ · mailto:hello@mnmedia.io · https://creativecommons.org/licenses/by/4.0/ · https://mnmedia.io/ · https://schema.org/- Provider
- The destination you choose, including MN Media, Creative Commons, Wikipedia, LinkedIn, Upwork or a credited contributor site
- When it activates
- Registered publisher, reference, licence 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 or mail composer opens only after you activate the corresponding link.
- Fields
- publisher, profile, schema, reference and licence 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
- message fields only if you choose to compose and send an email through your mail application
- Purpose
- Declare publisher, schema, licence and reference relationships without automatically loading those destinations
- Open publisher information, source references, licence terms or contributor profiles
- Let you initiate a copyright email in your own mail application
- Retention
- PlaySolitaire does not retain a separate record of ordinary outbound-link activation. Any request or sent email is controlled and retained by the selected browser, mail application and destination under their own terms.
- Deletion / control
- Use the selected destination or mail provider controls. PlaySolitaire cannot delete a request or email 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 destination or opens the mail composer. An HTTPS destination then receives normal request metadata; an email is transferred only if you choose to send it. (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.
YouTube privacy-enhanced player
Active only after your interaction- Technology / records
youtube-nocookie.com embed · YouTube watch and channel links · non-fetching JSON-LD references to YouTube embeds, watch pages and i.ytimg.com thumbnails- Provider
- Google / YouTube
- When it activates
- Structured data can name a launched video, channel, privacy-enhanced embed URL and thumbnail without making a browser request. No player iframe loads on page render. A preconnect can occur on pointer hover or touch intent, and the privacy-enhanced iframe loads only when you press play or choose a video chapter. Following a YouTube link is also your action.
- Fields
- video, channel and thumbnail identifiers present in structured metadata without an automatic browser request
- IP address and browser/request metadata after interaction
- video identifier and playback request
- cookies or browser storage that Google/YouTube may set after interaction
- Purpose
- Describe the launched tutorial in structured metadata without automatically loading YouTube
- Play the tutorial video you requested
- Open the requested video/channel on YouTube
- Retention
- Controlled by Google/YouTube after interaction; exact cookie and account/activity retention is not defined in this repository and requires vendor verification.
- Deletion / control
- Use browser controls and any Google/YouTube account controls that apply. No verified monitored privacy-request channel is currently configured for requests relating to PlaySolitaire-controlled records.
- Transfer
- Structured metadata values do not themselves request YouTube. Interaction sends later preconnect, playback or navigation requests directly from your browser to Google/YouTube. Processing locations and transfer mechanisms are pending vendor and counsel review. (vendor or contract verification pending)
- Verification
-
- Facade, preconnect trigger and click-to-create iframe were traced. (verified in source code)
- Cookies/storage, retention, processing location and account-linking behavior require a current vendor/browser audit. (vendor or contract verification pending)
- Role, lawful basis and international-transfer wording require counsel review. (counsel review pending)
- Legal-review status
- “Privacy-enhanced” is the configured YouTube mode, not a claim that Google receives no data after interaction.
Configured code paths that are currently inactive
These integrations must not be described as active processors. Their source and protected-profile contract was checked on July 18, 2026; current live production absence remains pending release acceptance wherever the row below says so. Activation requires an inventory and notice update first.
None in this release — every inventoried integration above is active, consent-gated or interaction-gated. This section returns whenever a code path is again required to stay inactive by the protected release profile.
Analytics choice and withdrawal
Google Analytics loads only when the site’s current privacy state resolves to granted. An explicit
rejection or opt-out wins over an earlier acceptance or a regional result. With no saved choice,
a verified country outside the regional set currently configured in /api/geo creates
an implied grant; a configured-region or unknown result shows the banner. The legal accuracy and
legal basis of that regional behavior remain pending counsel review. You can reopen
at any time, or use the analytics opt-out page. Withdrawal denies later GA
collection, clears queued GA/PWA events and visible GA or Hotjar cookies, and saves the
current game before any necessary reload.
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. The contact form delivers general messages to the operator's mailbox when its SMTP transport and destination are configured, but it is not a verified privacy-request workflow with tracked response deadlines. 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.
Open verification and counsel items
These items remain explicit instead of being filled with assumptions:
- Operator / counsel: Configure and verify a monitored privacy-request channel, publish it in this notice, define the response workflow, and only then advertise that requests can be submitted. The /contact form is a general contact channel and is not presented as that verified workflow.
- Counsel / owner: Confirm the full controller identity, registered address, jurisdiction-specific lawful bases, rights wording and response deadlines.
- Operator / counsel: Verify current DPAs, provider roles, processing locations, international-transfer mechanisms and retention/deletion controls for Bunny, Hostinger, Google/YouTube and Sentry.
- Operator: Verify Bunny zone logging/anonymisation/forwarding, Hostinger platform/network retention, and Sentry release/environment identity plus project retention during acceptance. Recheck production journald and Caddy logging whenever their configuration changes.
- Product / counsel: Review Google Signals and the indefinite GA4 BigQuery export, both currently enabled, before treating the present analytics configuration and retention as legally approved.
- Release gate: Update this inventory and policy before activating another vendor, accounts, ads or subscriptions.
- Release gate / Batch 8: Keep each conditional integration absent in production until production inventory facts, notice rendering, and live acceptance support activation. Staging enforces its own host-local protected profile and is not presented here as production evidence.
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.