Cookies and tracking

Under the EU ePrivacy Directive (Art. 5(3)), consent is required before a site stores or reads non-essential information on your device — and that covers browser localStorage, not just cookies. Our first-party analytics writes an anonymous device ID and a few page-view counts to localStorage, so we treat it as non-essential and gate it behind your consent. If you’re accessing from the UK, the same rules apply under the UK PECR.

On your first visit you’ll see a small banner with Allow analytics and Decline given equal weight. Until you choose Allow, the analytics is completely inert — no device ID is generated, nothing is written to your browser, and nothing is sent to our server. You can change or withdraw your choice at any time:

Either way, there are still no third-party trackers: the audience is nurses, nursing communities are sensitive to predatory patterns, and we committed to “first-party analytics only” from the start. That commitment held through the build.

We may, in the future, introduce a small number of strictly-functional cookies. If we do, they will fall into the “strictly necessary” category under the ePrivacy Directive (i.e., required for the service to operate, not for tracking), and we will list them here.

Examples we might add:

• Session token — if we add account login on the Website (today, login lives only in the App). HttpOnly, Secure, SameSite=Lax.
• CSRF token — if we add server-side forms beyond the current PHP endpoints, to prevent cross-site request forgery.
• Rate-limit hash — already used without a cookie via an SHA-256 hash of your IP stored server-side for one hour.

If we ever add a non-essential cookie (e.g., an analytics provider), we will ship a real consent banner with reject-all-by-default, granular controls, and an audit trail of your choice — and we will update this page first.

The Website uses localStorage and sessionStorage for browser-local app state such as dismissal preferences, anonymous web device ID, sign-in display state, and first-party attribution/session IDs. Do not enter PHI into website tools.

For verification, this site does not load resources from any of these common tracking origins:

• Google Analytics, GTM, AdSense, DoubleClick
• Facebook / Meta Pixel
• Hotjar, Crazy Egg, Mouseflow
• Segment, Mixpanel, Amplitude, Heap, FullStory
• Intercom, Drift, HubSpot tracking
• TikTok Pixel, LinkedIn Insight, Twitter conversion
• Cloudflare Analytics (non-essential mode)
• Sentry (we may add this for App-side crash reports only)

On our marketing and reference pages, the only third-party domain referenced in the HTML is www.w3.org — the SVG XML namespace declaration, not a network request. The optional web-app sign-in screen additionally loads Google and Apple sign-in SDKs; see the next section.

The web-app sign-in screen (/login and /app) offers optional Sign in with Google and Sign in with Apple. To provide those, the page loads Google Identity Services (accounts.google.com) and Apple’s sign-in SDK (appleid.cdn-apple.com).

These are authentication SDKs, not advertising or analytics trackers — but they are third-party, they may set their own cookies, and Google/Apple receive your IP address and the request when the sign-in screen loads. Their handling of that data is governed by Google’s and Apple’s privacy policies. If you never open the web-app sign-in screen, neither SDK loads and neither company is contacted. We do not use these for tracking, and no other page on the site loads them.

Standard web-server access logs at our hosting provider record your IP address, user-agent, requested URL, and response time. These logs are used for security and abuse-prevention, retained for 90 days, then rotated. They are not tied to any advertising or behavioural-tracking system.

Sensible browser hygiene that helps regardless of what any site does:

• Use Firefox, Safari, or Brave with default tracking protection on.
• Install uBlock Origin (or your browser’s equivalent) — it’ll show you we don’t trigger it.
• On iOS, enable App Tracking Transparency “Ask Apps Not to Track” — we won’t request the IDFA anyway.
• For DNS-level tracking blocking, NextDNS or Pi-hole work well.

If we ever start using cookies or any client-side storage that touches personal data, we will update this page before deploying the change, post a notice on the homepage for 14 days, and (if the data is non-essential under ePrivacy) ship a real consent banner.

See also our privacy policy for the full data-handling posture, and /data-requests for how to exercise your data-subject rights.

Email support@rnpocketpal.com with subject [COOKIES] for any cookie-related question. Last updated July 7, 2026.