| Component name | storage |
|---|---|
| In the visitorId | yes |
| structuredId group | browser (engine and build) |
| Hashing | plain value; a digest only when longer than 128 characters or not printable ASCII |
| Excluded under | no browser class |
| Inner timeout | 1000 ms |
| Added in | signalsVersion 1 |
Web pages can usually keep small amounts of data in the browser (local storage, session storage, a database called IndexedDB, and cookies). Some users and browsers turn these off. WhiskerJS checks only whether each one is available, as four yes-or-no answers. It never stores or reads anything.
What it reads
- whether
window.localStorage,window.sessionStorageandwindow.indexedDBcan be reached and are truthy; - whether
navigator.cookieEnabledistrue.
How the technique works
Each storage property is looked up on the window inside a try block. A truthy object gives 1; a missing property, a falsy value or a throw (browsers throw a SecurityError where storage is blocked) gives 0. The property is never called, read from or written to. The cookie flag is 1 only when navigator.cookieEnabled is exactly true. The value is local=<0|1>,session=<0|1>,indexed_db=<0|1>,cookies=<0|1>.
Why it helps
Most browsers report all four as available, so the common value says little. The less common values (cookies off, storage blocked by a setting or policy) are stable per browser setup and separate those setups from the crowd.
On your server it also explains other behaviour: if your own login flow relies on a cookie and cookies=0, you know why the session did not stick. A browser that reports storage blocked in a top-level page, where normal browsers allow it, is an unusual setup worth weighing.
Stability
Stable unless the user changes their cookie or site data settings, or the page is loaded in a context where storage is blocked (some sandboxed or third-party frames). A page that sometimes runs WhiskerJS in such a frame and sometimes not would see two values.
Browser support and what blocks it
All current browsers have these APIs. Values of 0 come from settings, policies and frame contexts, not from missing support. The component always reports ok. No browser class excludes it. See the browser pages.
Privacy
Four yes-or-no answers about settings. WhiskerJS does not touch the stored data itself, does not set a cookie and keeps nothing between calls: each collect() starts from nothing. The test suite records every storage and cookie access on a fake browser to check this.
How WhiskerJS handles noise and failures
| Status | ruleId | When |
|---|---|---|
ok |
always when it runs | |
excluded |
caller_excluded |
you excluded it |
timed_out |
timeout, aborted |
budget or abort |
Throws while reading a storage property are caught and reported as 0 inside the value. Never hashed.
Example value
All three headless test browsers in the container reported local=1,session=1,indexed_db=1,cookies=1, the most common value.
Questions and answers
Does WhiskerJS store anything or read cookies?
No. This component only looks up whether the storage properties exist and reads navigator.cookieEnabled. It never reads, writes or sets a cookie or any stored value.
Why would a storage API be reported as 0?
The property is missing, empty, or reading it throws, which browsers do when storage is blocked for the page, for example by a site data setting or in some sandboxed frames.