Trust
Security and data handling
PolyglotMedia runs on one machine, holds credentials for accounts the company owns, and touches no one else's data. The design goal is simple: hold as little as possible, and make what is held useless to anyone who is not the operator.
Where everything lives
There is no server. The application, its database, its task queue and its video files all live on the operator's own computer. There is no hosted instance to breach, no shared tenancy, and no customer records of any kind — because there are no customers.
Credentials
| Item | Purpose | How it is kept |
|---|---|---|
| Long-lived platform credential | Obtaining permission to publish to a connected account | Encrypted with AES-256 in the local database |
| Short-lived access token | Authorising a single publish request | Generated at publish time, held in memory, never written to disk |
| Account identifier | Making sure a video goes to the intended destination | Stored in plain text — it identifies a public profile |
| Service API keys | Transcription, translation and speech synthesis | Encrypted with AES-256, masked in the interface |
Credentials are masked everywhere in the panel. A saved value is displayed as dots, and submitting the masked placeholder does not overwrite what is stored — so an accidental save cannot wipe a working connection.
Passwords
PolyglotMedia never asks for, receives or stores a platform password. Authorisation happens on the platform's own sign-in page; the application only ever receives the authorisation code the platform hands back afterwards.
What is never collected
- No content belonging to other users — no videos, comments, or messages.
- No follower lists, audience demographics or engagement analytics.
- No device contacts, location or browsing data.
- No cookies or tracking of any kind on this website.
Third-party processing
Producing a translated version requires sending the recording's audio to a speech-to-text provider, its transcript to a translation model, and the translated script to a speech synthesis provider. All three happen during production, before any platform API is contacted.
Those providers receive the company's own video content. They never receive platform credentials, account identifiers or anything obtained from a social platform.
Revoking access
Authorisation can be withdrawn at any time from the platform side, without involving the application. On TikTok this is under Settings and privacy → Security and permissions → Manage app permissions; Facebook, Instagram and YouTube each have an equivalent connected-apps screen.
Revocation invalidates the stored credential immediately and the application loses its ability to publish. Removing the channel inside the panel has the same practical effect from the application's side: the encrypted credential is deleted from the local database.
Failure handling
A failed publish is recorded with the reason the platform gave, and stays visible in the panel rather than being retried blindly. When a platform accepts an upload but has not yet confirmed publication, the application waits for a final status instead of assuming success.
This matters for accuracy of the record: the operator needs to know which of the day's fifteen posts actually went live, and a queue that reports optimistically is worse than no queue at all.