SilverQR — Cookie & Tracking Notice
Version 2026-07-30.
This notice covers what SilverQR stores on a device. It is deliberately short, because the platform stores very little: there are no advertising cookies, no third-party analytics, and no cross-site tracking anywhere in the Service.
Two contexts matter, and they are governed differently.
1. The dashboard (silverqr.com/dashboard)
For account holders who sign in.
| What | Type | Purpose | Lifetime |
|---|---|---|---|
| Access token | localStorage |
Keep you signed in between requests | 15 minutes |
| Refresh token | localStorage |
Renew the session without re-entering a password | 30 days, rotated on each use |
| Active venue selection | localStorage |
Remember which venue you were working on | Until cleared |
All three are strictly necessary for a signed-in application and require no consent. Clearing browser storage signs you out. No dashboard storage is used for analytics or advertising.
2. Venue mini-sites ({venue}.silverqr.com)
For guests who scan a QR code. The venue is the controller for everything in this section — see the Privacy Policy §2 and the DPA.
| What | Type | Purpose | Consent needed? | Lifetime |
|---|---|---|---|---|
sqr.guest.id |
localStorage |
Random identifier so the venue recognises a returning device | Yes in most EU jurisdictions | Until cleared or erased |
| Device-traits hash ("signals hash") | Computed per visit, not stored on device | Recognise the same device after storage is cleared | Yes — this is fingerprinting | Sent to the server; retained per Privacy Policy |
sqr.guest.contact |
localStorage |
Pre-fill name/email a guest already typed | Functional; needed for the feature | Until cleared |
sqr.visit.sent |
sessionStorage |
Send the visit beacon once per tab, not per page view | Strictly necessary | Tab session |
sqr_va |
httpOnly cookie | Proof of entry to a protected venue's mini-site | Strictly necessary | 12 hours |
sqr_vc |
httpOnly cookie | Holds a scan of a passcode-protected venue while the guest types the venue's access code | Strictly necessary | 15 minutes |
2.1 The fingerprinting item, stated plainly
The signals hash is derived from GPU/renderer string, screen metrics, platform, touch capability, device memory, and a canvas rendering. Its explicit purpose is to recognise a device after browser storage has been cleared or in private browsing. Under Art. 5(3) of the ePrivacy Directive as applied by national regulators, and under Art. 6 GDPR, this ordinarily requires prior informed consent. It is not covered by a strictly-necessary exemption and, in our assessment, is not safely covered by legitimate interests alone.
Consequences for venues. If you operate a venue on SilverQR:
- you are responsible for obtaining consent before recognition signals are collected, and for keeping the record of it;
- every theme ships with a guest notice component that names what is collected and links to this notice and to the venue's controller identity;
- recognition can be switched off per venue in the dashboard, which stops both
sqr.guest.idand the signals hash from being collected while leaving the mini-site, menu and service requests fully functional; - if you cannot obtain valid consent, switch recognition off. Running it without a basis is a breach of the Acceptable Use Policy §2 and is indemnified back to you under the DPA §2.3.
2.2 Refusing or withdrawing
A guest may:
- decline recognition where the venue's notice offers the choice;
- clear browser storage at any time, which removes the stored identifier;
- use private browsing, which prevents the identifier persisting — note the signals hash is specifically designed to survive this, which is why consent is the operative safeguard rather than browser settings;
- request erasure at
/legal/data-request, which removes stored signals server-side.
Blocking storage entirely does not break a mini-site. Menus, layout, and service requests all continue to work; the venue simply will not recognise a return visit.
3. Third parties
None. Mini-sites and the dashboard load no third-party scripts, fonts from external origins, advertising pixels, social widgets, or analytics SDKs. Our emails are plain text with no open or click tracking.
Cloudflare, as our CDN, may set its own strictly-necessary cookies for security and DDoS mitigation at the network layer. See Cloudflare's own documentation for those.
4. Changes
Material changes raise the version string above. The current text is always at
/legal/cookies.
Royal SoftWorks DOO Kragujevac · [email protected]