Privacy and data handling

Personal data handling specification for .com Assist.

This page describes what colleague data is used by the current concept, why it is used, how it is transported and stored, and what should be reviewed before any wider staff deployment.

Purpose

.com Assist is intended to help pickers send structured product-location requests to the dotcom back office when an item appears available in store stock data but is not present on the shop floor.

The app uses a pseudonymous requester code to show which app/requester submitted a request, allow the picker to view only their own sent requests, and allow BackOffice users to distinguish between active requesters without exposing colleague names in the hosted queue backend.

The requester code is generated from the active store number and a random app-installation identifier created by the app. It is not based on a hardcoded phone identifier, IMEI, serial number, phone number, Android hardware ID, Tesco username, or colleague name.

Scope of this document

Applies to the current local-store concept/demo system.
Covers employee identifiers and request records.
Does not replace Tesco security, privacy, legal, HR, or DPIA review.
Identifies production controls that should be implemented before wider use.

Privacy at a glance

Queue records do not store colleague names.
Queue records do not store Tesco usernames or Tesco email addresses.
Queue records do not store Tesco OAuth/OIDC login tokens.
No permanent hardware device identifiers are used.
Device/requester identity is pseudonymous and app-installation based.
App uninstall or app-data clear removes the local generated identifier.
Request records are deleted daily, so retained queue data is limited to current-day operational data during normal use.
In a database-only compromise, the attacker would see operational queue data and pseudonymous identifiers, not Tesco login tokens, colleague names, Tesco usernames, or Tesco email addresses.

Data Processed

Colleague identifier	The hosted queue backend does not store the Tesco username, colleague name, or other directly identifying end-user personal data. The app uses Tesco OAuth/OIDC login to prove the user is authorised, then sends a pseudonymous requester code to the queue service, for example `P6269-A7F3B2`. This code identifies the app installation/requester within the queue workflow but does not contain a colleague name, Tesco email address, or login username. The queue workflow is pseudonymous by design to mitigate privacy risk during local concept testing.
App-installation identifier	The app creates a random UUID when app data is first created. This is a temporary app-installation identifier, not a permanent hardware identifier. It is not the phone IMEI, serial number, Android ID, phone number, SIM identifier, or any other hardcoded device ID. If the app is uninstalled or its app data is cleared, this identifier is removed and a fresh install generates a new identifier.
Store code	The active store number is used to isolate requests so one store does not see another store's BackOffice queue.
Product request details	Product name, barcode/product code, shelf location, image URL/reference, quantity requested, request status, notes, stock-override notes where a picker chooses to send despite zero/unknown stock data, and timestamps.
Device notification token	Firebase Cloud Messaging notification tokens are stored so request updates can be pushed to the relevant picker or BackOffice device. These are notification routing identifiers for the app installation; they do not contain readable colleague names, Tesco usernames, phone numbers, IMEI values, serial numbers, or email addresses. In the current hosted concept they are stored server-side, with a private file fallback used if the hosted MySQL account cannot create the notification-token table.
Audit/history data	The backend records request creation, quantity changes, status changes, cancellation, completion, pseudonymous requester codes involved, and timestamps.

Transport Security

App-to-server communication uses HTTPS/TLS. This encrypts pseudonymous requester codes, authorisation tokens, and request data while in transit between the Android device and hosted backend.

The current concept is hosted on Fasthosts UK web-hosting infrastructure. Fasthosts is a UK-based hosting provider with UK data centres, ISO 27001-certified infrastructure, SSL-supported hosting services, platform monitoring, and UK GDPR/privacy obligations.
The Android application is configured to submit queue requests to the HTTPS backend endpoint.
For production, certificate management should be handled by the approved hosting/security team.
Certificate pinning could be considered if required by Tesco mobile security standards.

Storage Security

The current backend stores queue data in MySQL. The database is accessed only by the server-side PHP backend. The Android app does not and cannot connect directly to the MySQL database, and no MySQL access credentials are stored in the application.

Database credentials are held in a private server-side config file outside the public web directory and are not publicly accessible.
The public API config file has been removed from the web-accessible queue folder and is not publicly accessible.
The database user has been restricted to runtime permissions: SELECT, INSERT, UPDATE, and DELETE.
Notification-token fallback storage, where used by the hosted concept, is held in a private server-side file outside the public web directory.
Direct browser access to setup, config, schema, maintenance, and internal documentation files is blocked.

Access Controls

Access to the queue service is restricted through the Tesco OAuth/OIDC login process. Tesco OAuth/OIDC tokens are transmitted securely over HTTPS to authorise queue actions. They are used transiently by the backend to confirm that the app request comes from an authenticated Tesco user. The token is not stored as part of the queue record, and the queue does not store colleague names, Tesco usernames, or Tesco email addresses. Stored queue records use a pseudonymous requester code instead.

For external compromise risk, in a database-only compromise, the attacker would see queue/request data and pseudonymous identifiers, not Tesco login tokens, colleague names, Tesco usernames, or Tesco email addresses. This keeps the practical risk low for colleague identity exposure in the current local concept.

Picker access	Pickers authenticate through the Tesco login flow before queue access is granted. The backend requires a valid Tesco/OIDC bearer token before accepting queue requests. Pickers can view their own submitted requests only; they cannot view other pickers' requests. Picker request visibility is filtered by pseudonymous requester code and active store.
BackOffice access	BackOffice mode requires store-specific admin credentials. The BackOffice queue is isolated by store code.
Download access	The Android APK download is protected by a username/password page for controlled testing.
Operational/Deployment notes	Technical operational notes and deployment information are behind a separate protected login page.

Retention

Request records are deleted daily after the trading day changes. This applies to all request records, including records containing pseudonymous requester codes, request history, status changes, quantities, and timestamps.

In normal use, when the app is opened by any user at any time after midnight, the backend automatically clears all previous-day request records. This means only the current day's request records are retained during normal daily operation, minimising the compromise window even for pseudonymous requester data.

Because the queue does not store names, Tesco email addresses, login usernames, or permanent hardware IDs, a compromise of current-day request records would expose operational queue data and temporary app-installation identifiers rather than permanent colleague identity records.

Firebase notification device identifiers are removed automatically if they have not been seen for 45 days. This removes inactive device registrations without requiring manual cleanup.

Current concept behaviour

Daily request cleanup is enforced when the queue API is accessed after midnight.
This provides automatic previous-day deletion during normal store use where the app is opened each day.
Only current-day queue data is expected to remain available during normal daily operation.
Shared/scale hosting may not provide true `00:01` cron scheduling.

For official deployment, a scheduled retention task should run at 00:01 or another approved time, independently of app usage.

Privacy Risks and Mitigations

Employee name exposure	Risk: Tesco usernames can include personal names. Current mitigation: the hosted queue backend does not store Tesco usernames, colleague names, or other directly identifying end-user personal data. Queue ownership uses a pseudonymous requester code generated by the app, for example `P6269-A7F3B2`. That code is derived from the store number and a random app-installation UUID; it is not a hardcoded phone identifier. Tesco OAuth/OIDC tokens are transmitted securely over HTTPS to authorise queue actions. They are used transiently by the backend to confirm that the app request comes from an authenticated Tesco user. The token is not stored as part of the queue record, and the queue does not store colleague names, Tesco usernames, or Tesco email addresses. Request records are stored server-side in MySQL, are returned only to the submitting pseudonymous requester or authorised BackOffice users for the active store, and pickers cannot view other pickers' requests. Database access is restricted to the PHP backend and the Android app does not store MySQL credentials. Previous-day request records are deleted automatically on first queue use after midnight, so only the current day's pseudonymous request data is retained during normal use. In a database-only compromise, the attacker would see queue/request data and pseudonymous identifiers, not Tesco login tokens, colleague names, Tesco usernames, or Tesco email addresses. Recommended hardening for official deployment: use a Tesco-approved pseudonymous staff/session identifier, staff ID, or pickstick session identifier according to approved privacy and operational requirements.
Permanent device identification	Risk: permanent hardware identifiers would create unnecessary device traceability. Current mitigation: the app does not send IMEI, serial number, phone number, SIM identifier, Android hardware ID, or other hardcoded device identifiers to the queue backend. The app uses a random app-installation UUID and a Firebase notification token. Clearing app data or uninstalling the app removes the locally generated UUID; a future reinstall creates a new app-installation identifier for this queue system. Recommended hardening for official deployment: continue avoiding permanent hardware identifiers unless there is a formally approved business, security, and privacy basis for using managed-device identity.
Excessive retention	Risk: old request records could build up. Current mitigation: all previous-day request records are automatically cleared after the day changes, including records containing pseudonymous requester codes, request history, quantities, status updates, and timestamps. The cleanup runs automatically when the queue API is first accessed after midnight by any app user. Recommended hardening for official deployment: enforce the same daily deletion policy through a scheduled platform job and include retention status in operational monitoring.
Database compromise	Risk: stored request records could be exposed if hosting/database credentials are compromised. Current mitigation: database credentials are held in a private server-side config file outside the public web directory, public config access is blocked, the database user is restricted to runtime permissions only, and retained request data is limited by daily deletion. Recommended hardening for official deployment: host the service on approved internal infrastructure with managed secrets, central logging, backup controls, and database access restricted to the approved application network.
Unauthorised BackOffice actions	Risk: a user could alter another store's queue. Current mitigation: BackOffice credentials are checked per store, and request visibility/actions are filtered by active store code. Recommended hardening for official deployment: bind BackOffice permissions to Tesco-approved role/group membership, store assignment, and formal permission/access-control rules.
Notification tokens	Risk: push-notification device identifiers could be misused if exposed. Current mitigation: these identifiers are used only to send app notifications to the correct device, are stored server-side in MySQL or private server-side fallback storage, are not shown to app users, and are automatically deleted after 45 days of inactivity. Recommended hardening for official deployment: register devices through Tesco-approved mobile-device and push-notification services, monitor failed notification delivery, and automatically remove stale or invalid device registrations.
Out-of-stock override	Risk: a picker may occasionally need to ask BackOffice to check an item even where current stock data shows zero or unavailable. Current mitigation: the app asks the picker to confirm before sending, stores the request as an explicit stock-override note, and flags the request visually in both picker and BackOffice queues so it is not confused with a normal in-stock request. Recommended hardening for official deployment: define an approved operational policy for when override requests should be used and include override events in formal audit reporting.

Official Deployment Recommendations

Host the backend on Tesco-approved infrastructure.
Use Tesco-approved identity and access management for picker and BackOffice roles.
Use an official client ID/app registration assigned specifically to `.com Assist`.
Minimise stored colleague data to the least identifying value needed.
Implement formal audit logs, access review, alerting, and retention enforcement.
Complete Tesco privacy/security review before wider staff use.

Current Status

This is for local informal concept development and testing. It demonstrates the workflow using HTTPS transport, server-side storage, private configuration, restricted database permissions, store-based access controls, Tesco/OIDC login checks, and automatic daily request-record deletion. It is suitable for controlled local concept testing, but wider deployment would require further hardening and modification to meet group-wide security expectations, platform standards, and approval processes.

For feedback, comments and suggestions: david@maxprovider.net