Privacy policy

What Tap & Play reads, what it stores, where it keeps it and how to get rid of it. Last updated 20 September 2026.

Who we are

Who runs Tap & Play

PLACEHOLDER — the legal entity has not been decided yet

Address

PLACEHOLDER — no registered address yet

Privacy questions and support

tapnplay@falvey.net

What this policy covers

The pages on tapnplay.me; the public cards served at <organisation>.tapnplay.me; the card editor and administration pages on those same addresses; and the operator area we use to create and support organisations.

An organisation decides who among its people gets a card; we store and serve that on the organisation’s instruction. Which of us is the controller and which the processor, for which data, is settled by the agreement between us and is not decided by this page.

What a public card shows, and who can see it

A published card is public. It needs no sign-in, so anybody who has its address can read it. It can show the cardholder’s name, work email address, job title, department, office telephone number and extension, office location, photograph, mobile number, LinkedIn address, pronouns and a short description, together with the organisation’s name, logo and colours.

• A mobile number is shown only when the cardholder has marked that number public.
• The .vcf file and the QR code offered on a card are generated from the same fields, so they show no more than the page does.
• Where an organisation has given us a photograph or logo hosted somewhere else, the page carries that address and a visitor’s browser fetches the image from that other website. Nothing else on a card page comes from anywhere but us.

A card is not public until it is published

A new card is created unpublished. An unpublished card, the card of somebody whose account has been suspended, and an address nobody has all return the identical response, byte for byte, so it is not possible to learn from outside that a person exists or once existed.

A cardholder can publish and unpublish their own card at any time. An administrator of the organisation can publish or unpublish any card in it.

When an organisation’s Google Workspace directory is connected

An organisation’s directory is the only thing Tap & Play reads from a customer’s Google Workspace, and it is read only for an organisation that has a directory connection. A connection comes about in one of two ways, and they are genuinely different: different people grant the access, different credentials hold it, and disconnecting takes back different amounts of it. Both are described here, and both are in use. An organisation’s own administrators can see which one their organisation is on, on their directory page.

Route one: an administrator connects it

An administrator of the organisation clicks Connect and approves one read-only directory permission, admin.directory.user.readonly, together with Google’s two basic sign-in scopes, openid and email. Those two say which administrator is consenting and which Workspace domain the account belongs to; the directory permission is the only one that reads anything about anybody else. The consent screen therefore lists three items. The administrator who approves it must be a Google Workspace super administrator of one of the organisation’s own domains; a consent from any other domain is refused and the grant is handed straight back to Google without anything being stored. The directory permission is one Google reviews before an app may offer it to the public, so until that review is complete this route is open only to an organisation whose own administrators have marked our application trusted in their Google Admin console.

Route two: domain-wide delegation, configured by us

The route that needs no review by Google, and no consent screen. Nothing is asked of Google on a screen: the organisation’s own Google Workspace super administrator enters our service account’s client ID and that same single scope, admin.directory.user.readonly, in the domain-wide delegation screen of their Google Admin console, and creates a dedicated account in their domain for us to read the directory as. We record the domain and that account’s address — in plain text; it is a name, not a secret — and set the connection up with an operator command. Three things follow from that, and each is a difference a reviewer should know about rather than find out:

• The credential is ours and is shared. Reading is done with a Google service account belonging to us, whose private key is held in Google Secret Manager and is the same key for every organisation connected this way. There is no per-organisation token, and none of the per-organisation sealing described below applies to it.
• We set it up; the organisation can stop it, and only the organisation can withdraw it. It is arranged by us at the organisation’s request, so nobody there starts it from our pages. Stopping it and withdrawing it are different, and both are available: an administrator can press Disconnect on their own directory page, which deletes the connection and ends the nightly sync immediately, while the grant itself lives in that organisation’s Admin console, where a super administrator can withdraw it. Until they do, the grant still exists and the directory could be read again by reconnecting — which is what Disconnect tells them at the time.
• Two checks the Connect route makes are not available here. No consent is recorded, and there is no connecting administrator whose super-administrator status can be re-checked before each sync. Whether the account we read as can see the whole domain is something the organisation and we have to get right between us.

What is read

• Google’s answer to a directory read carries the whole user record. Three things are taken out of it and nothing else is parsed, stored or shown: the primary email address, the full name, and whether the account is suspended.
• People are read one at a time, by address. Adding people reads only the addresses on the list the organisation has given us, and the nightly check reads only the people already added; neither lists the directory.
• The permission does allow the whole directory to be listed, and two things do list it. When a directory is connected on the Connect route, one listing request for a single record is made to check that the permission really works, and the record it returns is discarded. And an operator command we run to investigate a connection, on either route, pages through the directory and prints each account’s primary email address, name and suspension state to our own terminal. Neither stores anything, and neither gives anybody a card: only the explicit list does that.
• On the Connect route, about the administrator who connected the directory, two things are stored: their directory user id and their primary email address. Before every sync that could change anybody, whether that account still exists, is still active and is still a super administrator is read and not stored; if it is not, the sync stops for that organisation rather than act on a reduced view of the directory, and nobody’s card changes. On the delegation route there is no such account: what is stored instead is the organisation’s domain and the address of the dedicated account we read the directory as, and neither is re-checked at Google.
• Nothing in a directory is ever created, changed or deleted: every request made with this permission is a read. The only request that changes anything at Google is the one that withdraws a Connect permission when a directory connected that way is disconnected; on the delegation route nothing we send changes anything at Google at all. Beyond that permission and the two sign-in scopes above, no Google permission — mail, calendar, files, groups or anything else — is ever asked for.

What is stored as a result

A person’s full name and work email address on their card, and whether they are active or suspended. Job titles, telephone numbers, photographs, group memberships and reporting lines are not taken from the directory. The name and the address are written when the person is added and are not re-read afterwards: the nightly check only ever changes whether somebody is active or suspended, so a name that changes in the directory stays as it was until somebody here adds that person again by hand.

The credential that keeps it working

The nightly check needs a long-lived credential from Google, and which credential that is depends on the route.

On the Connect route it is a token Google issues for that one organisation, and it is stored only in encrypted form: each one is sealed with its own key, that key is sealed with a key held in Google Secret Manager and never present in the database, and the sealing is tied to the organisation it belongs to, so a copy of the row in another organisation’s place will not open. A copy of the database, or a backup, yields nothing but ciphertext. The table it lives in is readable by no part of the application: three narrow database functions reach it, one for saving, one for deleting and one for the nightly job, each available to one component only.

On the delegation route no token is stored at all — the database will not accept one for a connection of that kind. Access rests on two things instead: the grant in the organisation’s own Admin console, and the private key of our service account, which is held in Google Secret Manager, is used to sign each request, and is the same key for every organisation connected this way. It is a credential of ours rather than of any one organisation, so none of the per-organisation sealing above protects it and deleting an organisation does not change it. What limits it is the grant: the scope the organisation approved, the one account it lets us act as, and the organisation’s own power to withdraw it.

Disconnecting

An administrator can disconnect from the organisation’s own administration page, on either route. The connection record is deleted and the sync stops immediately; no card is deleted. What happens at Google is not the same on the two routes, and the page says which has just happened rather than leaving it to be assumed.

On the Connect route the stored token and the connection record are deleted together, and the permission is then withdrawn at Google. If the same Google account has connected another organisation, the permission is left in place — withdrawing it would break that one too — and the page says so, and says that it can be removed from Google’s own account page. If Google does not confirm the withdrawal, the page says that too, and where to do it by hand.

On the delegation route there is nothing for us to withdraw. There is no token, and the grant is not ours: it is the entry in the organisation’s own Admin console. Disconnecting stops the sync and deletes the connection, and until a super administrator deletes that entry we could still read the directory. The page says this in as many words when a connection of that kind is disconnected, because it is the difference between the sync stopping and access ending.

Withdrawing the access at Google’s end, rather than here, stops the sync either way, and no card is changed or taken offline because of it: a directory that cannot be read changes nobody. What differs is what is then shown. On the Connect route the organisation’s administration page says a reconnection is needed, and an administrator can reconnect there. On the delegation route the nightly run for that organisation simply fails and that failure comes to us; there is nothing for the organisation to click, because the connection was ours to make.

Signing in

Signing in to a card editor, to the administration pages or to the operator area is done with a Google account. Google tells us a stable identifier for the account, the email address, whether Google has verified that address, and the Workspace domain the account belongs to. We never see a password. A signed cookie then keeps that session; it is restricted to the address it was issued on.

Cookies, tracking and other companies

• This page and the home page set no cookies, run no JavaScript, and request nothing from any other website.
• A public card page sets no cookie and runs no script either. The only thing it may fetch from elsewhere is a photograph or logo that the organisation itself pointed us at.
• Cookies are used only for signing in and for the steps that lead to it. There are five, and this is all of them: a session cookie for the card editor and administration pages, and a short-lived one that holds a sign-in in progress; a short-lived one during a directory connection; and, for the operator area on its own address, a session cookie and its own short-lived sign-in one. The short-lived ones exist so that a sign-in or a connection that comes back from Google can be matched to the request that started it, and they are discarded as soon as it is.
• There is no analytics, no advertising, no tag manager, no cross-site tracking and no profiling anywhere in this product.
• Google is the only other company that handles the data: Google Cloud hosts it, and Google is the identity provider organisations sign in with. The domain’s registrar and DNS provider is a separate company, and it is worth naming even though it holds none of this data: it answers the question “which address is this service at”, and so sees the addresses themselves and the fact that somebody looked one up. There is no analytics provider, advertising network or customer-relationship system in this deployment.

Where the data is kept

In Google Cloud in europe-west1 (St. Ghislain, Belgium): the application on Cloud Run, the data in Cloud SQL for PostgreSQL, behind a load balancer that terminates TLS. The database is backed up daily by Cloud SQL. Secrets are held in Google Secret Manager with replication set explicitly to europe-west1 and europe-west4 — both in the EU — rather than the worldwide default.

Credentials and tokens are never written to our logs; that is checked by the test suite rather than assumed. Google Cloud keeps the ordinary request and application logs of the services above; we have not set a retention period for them, so Google’s own default applies.

Keeping and deleting

• Somebody leaves. When a directory is connected and an account is suspended or removed, the nightly check marks that person suspended here and their card goes offline within a day. The record is not deleted: reinstating the account brings the same card back at the same address, because printed QR codes and email signatures already point at it.
• Disconnecting a directory deletes the connection, and the stored Google token where the route had one. It does not delete anybody or any card, and where the access rests on a grant in the organisation’s own Admin console it is that organisation that ends it.
• Closing an organisation’s account deletes the organisation and everything belonging to it — its people, their cards, its domains and any directory connection.
• One exception, stated plainly. A record of what an operator did — who acted, what they did, the outcome, when, the organisation’s short name, and a short note of what changed — is append-only and is deliberately kept when an organisation is deleted, so that the record of a deletion survives the deletion. That note is the part worth being exact about, because it is where personal data can be: it holds the work email address of a person added to an organisation, of an administrator granted or revoked, and of the account a directory delegation reads as, along with domain names and counts. No other field of a card is in it — no job title, telephone number, photograph or description — but a work email address is a field a card shows, so this record does keep one kind of personal data about people at an organisation after that organisation has been deleted. It is kept knowingly: a record of a deletion that did not say who was affected would not be a record of it.
• Erasing one person on request is done by hand today. There is no self-service route for it; write to the address above and we will do it and tell you what was removed.

Asking us about your own data

Write to tapnplay@falvey.net for a copy of what is held about you, a correction, or deletion. If your card came from your employer’s directory, your employer decides which of its people have cards and what those cards may show, so asking them is usually the faster route — and we will tell you if that is the case rather than leaving you waiting.

Changes to this policy

This policy describes how the product behaves today, 20 September 2026. It is changed in the same commit as the behaviour it describes, and the date above changes with it.