# Cookies

FindIP Shield stores two random IDs in the visitor's browser, both first-party: a session ID and a visitor ID. Neither contains personal data.

## `_fip_sid` (Session)

| Property | Value |
|----------|-------|
| Purpose | Session continuity |
| Duration | 30 minutes (rolling) |
| Value | Random opaque ID, e.g. `sess_abcd1234` |
| Contains | No IP, email, or personal data |

## `_fip_vid` (Visitor)

| Property | Value |
|----------|-------|
| Purpose | Repeat visitor detection |
| Duration | 7–30 days (configurable) |
| Disabled in | `strict` privacy mode |
| Value | Random opaque ID, e.g. `vis_abcd1234` |
| Also stored in | `localStorage`, key `_fip_vid` (SDK 1.11.0 and later) |

### The `localStorage` copy of the visitor ID

From SDK 1.11.0 the visitor ID is kept in two places with the same lifetime: the `_fip_vid` cookie and a `localStorage` entry of the same name (`<visitor id>.<expiry time>`). On each page the SDK reads whichever still holds the ID, the cookie first, and writes both again. A visitor whose cookie was removed, or whose browser refuses the cookie, keeps the same visitor ID as long as the `localStorage` entry is there.

- Clearing all site data in the browser removes both and starts a new visitor.
- In `strict` privacy mode neither is written or read.
- When a visitor who had agreed withdraws consent (`FindIP.setConsent(false)` after an earlier grant), the SDK deletes both and stops sending the visitor ID. Agreeing again starts a new one.

If your cookie notice lists the storage your site uses, list the `_fip_vid` `localStorage` entry next to the cookie.

## When Cookies Are Blocked

Session ID:

1. `sessionStorage`
2. The tab's `window.name` (SDK 1.11.0 and later), see below
3. A link token, only when you switch on `linkSession` (SDK 1.11.0 and later), see below
4. In-memory session ID, for the current page only
5. When nothing in the browser keeps the ID, Shield derives one for the visit from the request (IP address, browser and language, for one UTC day) and the SDK uses it. Nothing is stored in the browser for this.

Visitor ID:

1. `localStorage` (not in `strict` mode)
2. When neither the cookie nor `localStorage` can be written, the SDK sends no visitor ID. Shield derives one the same way as the session ID, except in `strict` mode.

Sessions from such browsers are marked "Cookies blocked" in the dashboard, with what held the session together instead (for example "Cookies blocked · window name"). The session and event details show it in full under "Recognised by". The SDK continues working without cookies.

### The session ID in `window.name`

When the browser refuses both the cookie and `sessionStorage`, the SDK keeps the session ID in the tab's `window.name`, as `_fip_sid=<site key>.<session id>.<last seen time>`. It stays for the pages of one visit in that tab and ends when the tab closes.

- It expires like the session cookie (`sessionCookieDurationMinutes`).
- It names your site key, so a session written on one site is never read on another. The value is a random ID with no personal data; a page the visitor navigates to next in the same tab may be able to read it, as with any `window.name`.
- The SDK only writes an empty `window.name`. If your page or the window that opened it gave the window a name, the SDK leaves it alone and falls back to the next step.
- The SDK removes its value once the cookie or `sessionStorage` works again.

### The session ID in a link token (`linkSession`, off by default)

`window.name` belongs to one tab, so a link opened in a new tab starts a new session, and a window that already has a name cannot be used at all. With `FindIP.init({ linkSession: true })` the SDK also carries the session ID in the link itself, for visitors whose session cookie does not work:

- When the visitor clicks a same-origin link, the SDK adds `_fip=<session id>.<time>` to that link's address. The link in your page is put back right after the click.
- The page that opens continues the session and removes `_fip` from the address bar as soon as the SDK starts.
- A token is accepted for two minutes, and only on a page reached from the same origin. A pasted, shared or bookmarked address starts no session.
- Nothing is added to links on other origins, downloads, in-page jumps, or clicks your own code handled (`preventDefault`), such as a single-page app's router.

What to check before switching it on: your server receives the `_fip` parameter on that one request (caches keyed on the full URL will see it as a new address), and an analytics script that reads the address before the Shield SDK starts can record it. Load the SDK early, or exclude `_fip` in those tools.

## Configuration

```js
FindIP.init({
  sessionCookieDurationMinutes: 30,
  visitorCookieDurationDays: 30,
});
```

## Troubleshooting

- No `_fip_vid` cookie or `localStorage` entry in strict mode is expected behavior
- A session ID starting with `sess_cl_` or a visitor ID starting with `vis_cl_` was derived by Shield for a browser that keeps nothing
- Check browser privacy settings if `_fip_sid` is missing — sessionStorage fallback still works

---

Canonical page: https://www.findip.net/docs/shield/cookies · Markdown: https://www.findip.net/docs/shield/cookies.md · All Shield docs in one file: https://www.findip.net/llms-full.txt