Privacy policy

What social sindy stores, why, for how long, and who else sees it. Last updated 28 July 2026.

The short version. This tool reads your Buffer posting schedule and turns it into subscribable feeds — calendar feeds (ICS) and content feeds (Atom/RSS). It stores your Buffer credential encrypted, caches your posts briefly so it does not exhaust your Buffer API quota, and never publishes anything, sells anything, or runs advertising. The only measurement is a cookieless pageview count on the interface pages. Deleting your account erases everything it holds.

Who runs this

social sindy is an independent tool. It is not made by, affiliated with, or endorsed by Buffer or Google. This deployment is operated by Brandon Lucas Green, who is responsible for the data described below. Questions go to hi@bgreen.lol.

What it stores

Only what is needed to build your feeds:

Your Buffer account details — account ID, email address, name, and time zone, as returned by Buffer when you connect. The email identifies your account here and is shown to you when signed in.
Your Buffer credential — encrypted with AES-256-GCM before it is written to the database, using a key held only in this deployment's server secrets. It is never written to logs, never shown back to you, and never sent anywhere except Buffer's own API.
Your sindy settings — which organization and channels you chose, the format (ICS or Atom), event length, refresh interval, date window, and which post statuses to include.
A session cookie — a random identifier that keeps you signed in for 30 days. It is not used for tracking and carries no personal data.
Sync bookkeeping — timestamps of the last fetch, how many events or items were produced, and any error message, so the dashboard can show whether syncing works.

Your post content

Building a calendar means handling the text of your scheduled posts. Post content is cached, not permanently stored:

Fetched posts and the rendered calendar are held in a temporary cache for at most your chosen refresh interval, so that repeated polling by your calendar app does not exhaust your Buffer API quota.
One most-recent successful calendar is kept for up to 7 days as a fallback. If Buffer is unreachable, that copy is served instead of an empty calendar — without it, your calendar app would interpret the gap as every event having been deleted.
Nothing else retains post content, and it is never written to logs.

Your calendar feed URL is public

This is the most important thing to understand. Calendar apps cannot send a password when they fetch a subscription, so the feed URL has to work without one. It contains a long random token instead, which is the only thing protecting it.

Anyone who has that URL can read the posts in that calendar. Treat it like a password: do not post it publicly or paste it into a shared document. If it leaks, use “Replace URL” on the calendar page — the old URL stops working immediately. Feed responses are served with noindex and no referrer, so search engines will not index them and the URL is not leaked to sites you visit.

Google Calendar sync, if you enable it

Connecting Google is optional and off by default. If you turn it on:

The only permission requested is calendar.app.created, which allows creating a calendar and managing events on calendars this tool created. It cannot see, read, or change your existing calendars, including your primary one.
A Google refresh token is stored, encrypted the same way as your Buffer credential, plus the email address of the Google account and the identifier of the calendar created for you.
Only events created by this tool are ever modified or deleted. Events you add to that calendar yourself are invisible to the sync and are never touched.
Disconnecting Google, or turning push off, erases the stored token and stops all syncing. The Google calendar and its events are left in place for you to keep or delete — removing a calendar from your account is not a decision this tool makes for you.

social sindy's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements. Data from Google is used only to create and maintain the calendar you asked for. It is never sold, never transferred to anyone except as needed to provide that feature, never used for advertising, and never read by a human except with your explicit permission or where required by law.

Who else sees your data

Buffer — every request for your schedule goes to Buffer's API using your own credential, and is subject to Buffer's privacy policy.
Cloudflare — this tool runs on Cloudflare Workers, with data in Cloudflare D1 and KV. Cloudflare processes requests and stores this data on the operator's behalf, and records standard request logs including IP addresses.
Google — only if you enable Calendar sync, and only for the calendar this tool creates.
coolLabs Fonts — pages load the SN Pro typeface from fonts.coollabs.io, a privacy-friendly replacement for Google Fonts. Your browser contacts coolLabs' servers rather than Google's when you load a page; nothing else about you is sent, and this happens on the interface pages only, never on the calendar feed itself.
GoatCounter — the interface pages load a small script from gc.zgo.at that counts pageviews, so the operator can see which pages get used. It sets no cookies, assigns no persistent identifier, and does not track you across sites. What is recorded is the page you loaded, the referring page, your browser and screen size, and a country derived from your IP address; the IP itself is not stored, and repeat visits are recognised via a temporary hash built from a salt that rotates regularly, so the link back to you does not persist. The counts are aggregate and are not linked to your account. See GoatCounter's privacy policy. As with fonts, this runs on the interface pages only, never on the calendar feed itself.

Apart from that pageview count there is no analytics, no advertising, no third-party trackers, and no other embedded services. Nothing profiles you, and your data is never sold or shared for marketing.

Deleting your data

“Delete account and stored key” on your calendars page erases your account record, your encrypted Buffer credential, any Google credential, every calendar you created here, and all associated sessions. Feed URLs stop working immediately. Cached copies expire on their own within 7 days at the latest.

Deleting your account here does not touch anything in Buffer. To revoke this tool's access from Buffer's side, delete the API key in Buffer → Settings → API. To revoke Google access, use your Google account permissions.

Security

Credentials are encrypted at rest with AES-256-GCM, which also detects tampering. The encryption key lives in server secrets, never in the database or the source code. Session cookies are HttpOnly and SameSite=Lax, and marked Secure over HTTPS. Form submissions are checked against their origin. No credential is ever logged.

No system is perfectly secure, and a Buffer API key grants broad access to your Buffer account. If that concerns you, that is a reasonable position — the connect page says so too.

Changes

If this policy changes in a way that affects what is collected or who sees it, the date at the top of this page changes with it.

This document describes what the software does. It is not legal advice, and it is not a contract.