FTH Social Hub privacy policy

Who operates the product

FTH Digital Marketing operates FTH Social Hub and is responsible for the data handling described here. Registration details and address are at the foot of this page.

Whose data is in the system

Three categories, and the third is the one most privacy policies leave out:

• The agency's own users — email address, name, a password fingerprint, sign-in details from an external provider if one was used, plus invitations and roles.
• The agency's clients — workspace and organisation names, a billing email address, the client's social account name, handle and avatar, and encrypted access tokens.
• The audience — people who never signed up with us. When someone comments on a client's page or messages it, we store their display name and the full text of their message. The competitor feature also stores third-party display names, avatars, biographies, follower and post counts, engagement figures, and the captions of their posts.

Stated plainly: the third category is people who have no relationship with us, were never told their data is here, and have no ordinary way to reach us. That is the reality of the system today, not a footnote.

If you are in that category and have found this page, write to us at privacy@fth.marketing to ask what we hold about you, or to ask us to delete it.

Roles

For the agency's own data, FTH Digital Marketing is the controller. For client and audience data, the agency is the controller and FTH Digital Marketing processes that data on its behalf.

That arrangement normally calls for a written data-processing agreement. No such agreement exists today, and we do not imply that one does. Anyone who needs one should ask for it before subscribing.

Who else processes the data

These are the parties the data passes through or rests with, named one by one:

• The hosting provider — the servers the product runs on, where the database and files are stored. The provider is Contabo.
• Cloudflare — terminates the connection's encryption in front of the product, which means it sees the traffic in the clear before it reaches us.
• Anthropic — the AI provider. What leaves for it is set out in the next section.
• The payment provider — receives invoice details when you subscribe. We do not store card details.
• The social platforms themselves — Meta, LinkedIn, TikTok, X and YouTube, which are both the source of the data and its destination.
• Google, a second time — the product is built to offer sign-in with a Google account, which would make Google a processor of your sign-in details. That path is NOT configured today, so nothing reaches Google that way at present. We list it rather than omit it because it is built and one credential away from working, the same as the AI features above. It is a different role from YouTube, and nobody reading “the social platforms” would think to count it.

The product sends no automated email of any kind, and there is no mail provider on this list. Invitations are copied by hand as a link.

What leaves for the AI provider

The AI features send content to Anthropic in order to generate a response.

Specifically: the text you typed, free-text brand context, the fetched page content when a link is turned into posts, and the assistant's whole conversation including tool results — which carry real analytics figures, top-post text, connected account names and their follower counts, and competitor names and engagement. Your clients' account names and post content do leave.

One limit is worth stating on its own, because it is the one that matters most. The text of messages and comments from the audience never enters an AI request. The AI features do not read the inbox at all. Your clients' account names and post content do leave; third parties' private messages do not.

We set no geographic region parameter on those requests.

As things stand today the AI features are not enabled: no key is configured at any level, nothing has ever been metered, and nothing has ever left for Anthropic. We state that as a fact about today and not as a promise, because it is one entry in our own admin console away from changing. When it is enabled, what leaves is exactly what is described above.

Where the data is held

The database runs inside a container on a single virtual server, bound to the local interface only, so it is not published to the internet. Uploaded files sit on that same server's disk. The server is rented from Contabo, a company registered in Germany, and Cloudflare terminates the encryption in front of it from whichever of its own locations is nearest to you. Put plainly: your data is processed outside the Kingdom. We do not name a country on this page, because the only authoritative record of which data centre the server sits in is our hosting account, and we will not print a country we have not read off it.

Backups are on that same server, encrypted to a key the owner keeps off the machine. There is no off-site backup, which means losing the disk loses everything since the last dump. We do restore from them as a check rather than assuming they work: the most recent drill restored every table and matched the live system row for row.

How long we keep it

There is no cleanup or expiry job in the system. Nothing is removed because time has passed: inbox messages, analytics, post text and competitor data stay indefinitely. Deleting things yourself is a different matter — scheduled posts, categories, uploaded files, competitors, invitations and assistant conversations can all be deleted from inside the product, and a social account can be disconnected. What has no control of its own is deleting an account, and deleting data about the audience.

The one automatic deletion anywhere in the system is the hourly sweep of sign-in tokens — and even that removes a token only once it is both finished with and more than seven days old.

For that reason we commit to no retention period on this page. Committing to one the system does not enforce would be an empty promise; deletion happens on request, as the data-deletion page explains.

Who can see the data

Our team, including personnel working remotely from outside the Kingdom, accesses live data in the course of running and supporting the product. We say so plainly, because in practice it means data is read across borders.

What we do not record

There is no audit log of access anywhere in the system. Nothing records that a person on our side, or an automated process, read a customer's data or an audience member's message. Request logging inside the application is switched off in production, so the web server's own logs are the only record, and they carry no account or user identity. We say so because of what follows from it: if you ask us who has looked at your data, we cannot answer you from a record. We can only tell you who has access.

Security — what we can honestly say

These measures are actually in place:

• Traffic is encrypted while it crosses the network.
• The database and cache are bound to the local interface only and are never published to the internet.
• Row-level security is enabled and enforced on 34 of the 35 tables, with per-tenant isolation policies. The one exception holds no personal data: it records when each connected account last synchronised, and whether that failed.
• Platform access tokens and connector credentials are encrypted where they are stored, with AES-256-GCM.
• Passwords are stored as scrypt fingerprints, with a random salt and a constant-time comparison.
• A sign-in token expires after eight hours. Refresh tokens rotate, and a per-user cutoff ends every active session at once, so signing out takes effect immediately.
• Role-based permissions within each customer account.
• The admin console sits on a separate hostname, with its own type of token.

One more limit, stated because it is real and not because anyone asked: an uploaded file is served from a link that carries its own key, rather than by checking who is signed in — so anyone holding that link can open the file. No files have been uploaded to the system to date.

And what we do not claim: we hold no security certification of any kind. Encryption where data rests covers secrets at the column level only — the database disk itself is not encrypted. You will not find marketing phrases about encryption strength on this page.

Your rights

You can ask what we hold about you, ask us to correct it, ask us to delete it, and object to our processing of it.

Requests go to privacy@fth.marketing. We handle them by hand, and we confirm to you when they have been carried out.

How deletion actually works

You also have the right to complain to the competent supervisory authority in the Kingdom.

Updating this page

This page was written from an examination of the system on 2026-08-29. When the system changes, this page changes with it — not the other way round.