How your data is held

Where your credentials live, what protects them, what leaves your machine, and who can read what. Read this before you import an account you cannot afford to lose.

This describes what the software does, written by reading it. The legal version is the Privacy policy, and this page does not say anything that page contradicts.

Your Clout account has no password

You sign in with Google or Telegram, so we never receive a password and there is none for us to lose. Anyone who can sign in as you can reach everything on the account, which makes that sign-in the thing to protect. If you think somebody else has it, tell us at [email protected].

We never join two accounts because they share an email address. Signing in with Telegram on an address a Google account already holds sends you to Google instead. Merging on a shared address is how accounts get taken over.

The app never asks for your details in its own window. Signing in opens your system browser at app.cloutlabs.co and the browser hands a one time code back. A sign-in form drawn inside an application is the shape every credential phish takes, and there is nothing about it you can check.

The session the app receives is kept in your operating system's keychain.

What is on your computer

Clout keeps its store and your profile directories on the machine.

• The store holds the profiles: fingerprints, proxies, groups, tags, notes, and the launch record each profile is rebuilt from.
• A profile directory holds what the browser writes: cookies, local storage, history, extensions.

A launch writes the credentials the browser needs into that directory as files: the session jar, the account password list, and the proxy user and password. They are cleartext, because a browser cannot be handed a secret it cannot read.

Two things about those files are worth knowing:

• They are created readable by you alone (mode 0600 on macOS and Linux, an owner-only ACL on Windows). Before that was true they were created at the default umask, which on a stock machine means every other account on the computer could read a live session out of a file whose name is a public hash.
• The staged ones are removed when the browser stops. What must persist persists, and what does not is deleted at teardown rather than left behind.

That is the defence against another user or a stray process on the same machine. It is not a defence against somebody with administrator access to your computer, and nothing running on your computer can be.

The machine's own key

A computer that syncs holds an Ed25519 key that identifies it to us. It is generated on the machine, it never leaves it, and it is sealed with the operating system's keychain where there is one (0600 in a 0700 directory where there is not, which the app records and reports rather than implying the stronger one).

If that machine is lost, the answer is to remove it under Devices in the portal. Revocation bites on that machine's next request, and a machine that cannot reach us stops opening anything new an hour after we last heard from it.

What leaves your machine

On a connected computer, the fleet's records sync: groups, profiles, tags, folders, extensions and their attachments, proxies and pools, templates, account settings, and saved logins without their secrets.

Secrets are never in that stream. Passwords, two factor seeds, proxy passwords and session cookies are not part of a sync page. A profile that needs one fetches it, one profile at a time, through a separate path that writes an audit record for every disclosure: which account, who asked, when, and which key was used. The record never contains the secret or its length. The point of the split is one log row per actual use rather than one per sync.

Cookie metadata, but never cookies. So that a second computer can answer "which of my profiles have a cookie for this site", a profile can report the domains and counts from its jar. No cookie name and no cookie value is in that report, ever.

Bandwidth, so a plan that meters traffic can meter it.

Diagnostics only if you turn them on, under Account. They are off by default, and nothing is sent while they are off. When they are on, error reports go to Sentry and usage events to PostHog.

How stored logins are protected, and who can read them

Each secret is encrypted on its own, with its own key. That key is then encrypted with a master key belonging to the service. The database holds neither in readable form, so a copy of the database on its own opens nothing.

We can, technically, read a stored login, and you should know that. The software has to decrypt a login in order to sign a browser in with it, so the master key is a file on the same server as the database. Anyone with administrator access to that server holds both halves. No amount of encryption on our side changes that; only a key we do not hold would, and we do not have that today.

What stops it being an ordinary thing that happens:

• There is no screen and no support tool anywhere in the product that shows us a stored login. There is no button for it, so there is no routine way for a member of staff to read one.
• The few paths that open a secret run on behalf of your own signed in account and check that account's permissions first.
• Every one of those paths writes an audit record.
• Getting at a login any other way means signing in to the server directly and running code there, which is not something the product does.

Everyone on your team can open the profiles they can reach, and a profile that opens is a profile that is signed in. Permissions decide who may see a password in plain text, not who may use it. See Teams.

Exports are plaintext, deliberately

Export writes a profile document. Export cookies writes the session jar. Neither is encrypted, because an encrypted export is an export nothing else can read, and the reason to make one is to move a profile somewhere Clout is not. The app says so before it writes one.

Treat an exported cookie file the way you would treat the password to the account inside it. Move it, use it, and delete it.

Importing from another product

Every vendor studied keeps its cookies in plaintext, or something close to it, on your own disk. That is why cookie migration works at all without asking anybody for a key, and it is a fact about the tools you already run whether or not you ever use Clout.

For Dolphin Anty, GoLogin and Multilogin, importing means handing us access to an account at another company that holds your profiles. Whether we should hold those credentials at all, rather than using them once and forgetting them, is an open question nobody here has answered. Until it is answered, take the conservative reading:

Give us a token you can revoke, revoke it when the import is done, and do not give us your vendor password.

Importing from AdsPower uses the session already signed in on your machine, and importing from Kameleo reads files on your disk, so neither needs a credential from you at all.

Where it all lives

Everything runs on one server in the European Union. Backups are encrypted and copied off that server, kept for 14 days, with one copy a month kept for up to 400 days.

The traffic between you and that server goes through Cloudflare. The public site loads its typeface from Google Fonts, which means Google sees the address your browser connects from when a page loads.

We do not sell anything and we do not share your information for anybody's marketing.