WishCodes

Cookies

A small browser footprint.

This notice describes the cookies and browser storage used by the current WishCodes web app. Last updated September 25, 2026.

At a glance

No ad pixels. No browser replay.

The current app does not load a browser PostHog SDK, run autocapture, record sessions, capture DOM text or send full tokenized URLs to analytics. It uses a small number of first-party mechanisms for session security, the accountless management link and anonymous growth measurement.

First-party mechanisms

Cookies

Gift session cookie

A host-only, HttpOnly, Secure, SameSite=Strict cookie lets a gift-giver continue a short-lived session after a fragment exchange. It expires after approximately two hours and is not used for advertising.

Management session cookie

A separate host-only, HttpOnly, Secure, SameSite=Strict cookie supports the recipient's short-lived management session. It expires after approximately 15 minutes and is not used for advertising.

Operator stats session

__Host-wishcodes_stats is a signed, HttpOnly, Secure, SameSite=Strict operator session cookie. It lasts approximately eight hours, unlocks only the private stats dashboard after a server-side password check, and is not a consumer advertising cookie.

The cookie names are technical legacy identifiers and are not part of the public WishCodes brand. The plaintext share or owner capability is read from a URL fragment and is not placed in a cookie or request URL. Live product-search results are cached server-side; the browser does not receive a search-provider cookie from WishCodes.

Client-side persistence

Browser storage

Private management-link convenience

After a profile is created, the recipient may have the private management link saved in first-party local storage on that device. It is a convenience for an accountless product; it contains the link itself, so treat the device as private. Clearing browser storage removes the convenience copy, not the profile.

Anonymous growth measurement

To learn which outreach actually helps people, WishCodes uses Distrarc, a growth-measurement service run by the same operator. Its script keeps a random visitor identifier and, if you arrived through a Distrarc link, that link's short code in first-party local storage, with per-tab session storage as a fallback when local storage is unavailable (distro_vid, distro_ref, and, after first activation, distro_activation to keep the first link or direct status fixed; plus a per-tab distro_visit marker in session storage). It records only four things: a visit, that you started a WishCode or gift brief, that a WishCode or set of gift directions was delivered, and which of those two paths it was. It sends the referring site's origin but never page URLs, names, answers, gift preferences, profile IDs, recommendations or capability tokens, and it sets no cookies. Clearing site data removes the identifier.

In-memory product analytics identifier

Separately, the client creates an in-memory pseudonymous event identifier when explicit product analytics are sent. It is not saved in a cookie or local storage, and it is not a name, answer, profile or capability.

No advertising storage

The current implementation does not use advertising cookies, third-party tracking pixels or cross-site ad identifiers.

Need details?

Questions

For the broader data boundary, vendors and rights information, read Privacy or How we use data. Contact work@atharv.me with a privacy question.

Questions about this page? Write to work@atharv.me.