If I meet someone and I scan a QR code with my phone and that goes to an app I've written with WEB Core and identifies them, how can I have the app query my phone to know WHO I AM? What kind of scenario would be needed to do something that would enable my app to identify the person's phone without having to login each time? Maybe if everybody first scans a code that asks to login, and it drops a cookie or something that's good for some specified time period, like 1-3 hours, to provide a context (class, event, etc.) where any other scans that bring up the app would be able to query the user's phone and know it's them / their phone?
I'd guess each scan would bring up the same browser, and as long as you don't close the browser then it could drop a cookie with an ID and a timeout on it and any other scan could find it and know whose phone it was?
Are there other ways?
To uniquely identify a smartphone and user accessing your web application, there are both technical and ethical/legal considerations. Here's a breakdown:
1. User Identification (Who)
To uniquely identify the user, the best practices are:
Recommended (Consensual & Secure):
- Authentication (Login System):
- Use email/password or OAuth (Google, Apple, Facebook).
- Optionally add Multi-Factor Authentication (MFA).
- User ID:
- Assign a unique, server-side
user_id upon registration.
- Persistent Cookies / JWTs:
- Store session identifiers or tokens in secure cookies or local storage.
- Optional: Fingerprint or Passkey Auth:
- For modern devices, use biometric authentication with WebAuthn.
2. Device Identification (What)
Identifying a specific smartphone (or at least a browser + device combo) is trickier:
Not Possible:
- IMEI / MAC Address / Serial Number – Not accessible from a browser due to privacy restrictions.
Possible (with caveats):
- Browser Fingerprinting:
- Use libraries like FingerprintJS to gather:
- User Agent
- Screen resolution
- Timezone
- Installed fonts/plugins
- Canvas/WebGL fingerprints
- Audio fingerprint
- Limitation: Not 100% reliable, can be blocked or change over time.
- Device ID via PWA (if user installs your app):
- Store a UUID in
localStorage or IndexedDB.
- If the PWA is deleted, this is lost.
- Cookies or Local Storage:
- Store a unique ID when the user first visits.
- Only persists unless cleared by the user.
- Service Workers + Cache:
- Can also be used to persist a device ID, but it's still not guaranteed to be permanent.
Legal & Ethical Considerations
- GDPR / CCPA:
- Fingerprinting and tracking require user consent.
- Always disclose in your Privacy Policy.
- Use Consent Management Platforms (CMPs) if you're tracking users in the EU.
Summary: Best Practice Approach
| Goal |
Method |
| Identify the user |
Auth system (login, OAuth) + secure session/token |
| Identify the device |
Cookie/localStorage-based UUID + optional fingerprinting |
| Persist identity |
Combine user_id with persistent device_id (stored via cookies/etc) |
| Legal compliance |
Ask for consent before tracking/fingerprinting |
1 Like
someone would login initially, probably on their phone, then use it to scan QR-codes or NFC links that go to an app that has access to the DB with their session ID in it to find their data.
I don't need to identify the exact device. A sessionID in a cookie or accessible from such an ID on the DB would be sufficient.
As I'm thinking about it, MQTT might help simplify things as well.
If there is an initial login anyway, your backend could return a JWT token and the client could persist it in local storage and then send this JWT each time the start URL is visited and your backend could determine based on the sent JWT, who the user is.
That makes sense. Where is the JWT stored? In a cookie? Or some other mechsnism? (People can block cookies, so I'm guessing there's a separate mechanism for storing security-related data like this. I've just never really thought much about it.)
I mentioned local storage in my answer. It can be managed with class TWebLocalStorage in TMS WEB Core
You did, sorry, that didn't register. Thanks.