guide

BPM Counter Privacy in a Browser-Local Session

Inspect one session's local data boundary

Temporary tally intervals contained within one browser-local data board

Reviewed concrete example

What “local” means here

BPM counter privacy starts with data flow. In the launch tool, a supported focused action creates a timestamp in active JavaScript memory. Neighboring differences and statistics are calculated in the same page. The values are not sent to a product API, user account, database, analytics vendor, or cloud project.

“Local” does not mean a hosted page makes no network requests. It means tap inputs and results are excluded from the site’s authorized network data path.

Focused controls, not device monitoring

Space and Enter work only while the counter region is focused. The page does not install a device-wide listener, read keys in other applications, or capture typed content. Key auto-repeat is ignored. Pointer and touch handling accept one intentional activation and suppress duplicate paths.

The tool does not request microphone permission, system audio, camera, motion sensors, files, clipboard access, or media URLs.

Active memory and disappearance

Timestamps, intervals, window settings, and results can remain while the page is active. Reset clears them. A timeout replaces the old sequence with a new origin. Reload, tab closure, browser memory management, or a crash may erase them.

No account recovery exists. Do not treat the page as a notebook. If a summary matters, copy only non-sensitive fields to an approved location.

Browser storage distinctions

The launch code does not write cookies, localStorage, or sessionStorage. Browser cache may retain site resources, and history may record the visited route. Those mechanisms are separate from a saved tap sequence.

Extensions, developer tools, screenshots, clipboard managers, shared-device monitoring, or malware can observe what appears on a device. Browser-local design reduces operator collection; it does not secure an untrusted device.

Hosting requests

Vercel must receive ordinary HTTP requests to serve pages and assets. Infrastructure may process IP address, time, path, status, user agent, referrer, and security information. Exact logging settings and retention depend on the host account and applicable obligations; the privacy policy does not claim an unverified fixed period.

The contract forbids placing tap values, labels, settings, or results into URLs, metadata, JSON-LD, event payloads, or network requests.

Support email is separate

Emailing support@bpmcounter.click voluntarily sends the message and headers to the operator and email providers. Use synthetic intervals. Do not attach recordings, passwords, health information, unpublished projects, or unnecessary identifiers.

The operator cannot retrieve an erased browser-memory session. A request may still concern correspondence or ordinary hosting records.

A practical inspection

Use a clean browser profile and developer tools. Load the counter, record four taps, and inspect Network plus Cookies, Local Storage, and Session Storage. Expected behavior is ordinary page-resource traffic, no site-authored storage entries, and no tap sequence in requests.

Reset and verify that visible session fields clear. Reload and confirm defaults return. Repeat after material site changes; one browser check does not cover future dependencies.

Minimize what you enter

The counter needs deliberate timing events, not a name, title, URL, or note. Tool textareas expect numeric millisecond values. Optional A/B labels should remain generic, such as “A” and “B.”

Do not encode sensitive information into interval patterns or labels. Privacy-friendly design works best with data minimization.

Limits and future features

This guide describes the current site, not every possible future version. Accounts, synchronized history, analytics, remote processing, or persistent preferences would materially change the data flow and require updated policies, consent where applicable, appropriate safeguards, and new browser checks.

The policy effective date and change notice must reflect actual behavior.

Shared-device workflow

On a shared computer, use a fresh tab, avoid meaningful labels, record only synthetic or non-sensitive events, copy no values unless required, press Reset, close the tab, and follow local browser-clearing policy. These steps reduce visible remnants but cannot override administrator logging, extensions, screen capture, or operating-system monitoring.

What a privacy report should contain

If you observe unexpected persistence, record the route, browser version, storage category, key name, request host, and a minimal reproduction using synthetic taps. Do not email a full storage dump containing unrelated tokens. A focused report helps the operator distinguish product behavior from extensions or shared infrastructure.

Privacy claims should be tested again after adding any dependency, embed, monitoring service, or storage feature. A clean result today does not authorize future code silently.

Frequently asked questions

Does the counter hear what I am tapping to?

No. It has no audio or microphone access.

Are keyboard presses sent to the server?

The supported focused action creates a local timestamp; tap values are not authorized in network payloads.

Can Reset delete hosting logs?

No. Reset clears product memory, not ordinary infrastructure records.

Why repeat the browser check after a site change?

Hosting settings and dependencies can change observable storage or network behavior. A fresh check tests the public site you are actually using.

## Verify the boundary yourself

Use synthetic taps in a clean profile, inspect storage and requests, reset, reload, and report any unexpected persistence with browser and route details.

Continue on this site