Security

The short version

Markloom has no copy of your documents. They live in your Google Drive or your GitHub repository, and they stay there — while you use Markloom, after you stop, and if Markloom disappears. What we store is routing metadata: a few hundred bytes per published site saying which folder a public URL points at.

Most of the questions on a vendor security questionnaire — residency, retention, export, breach exposure — have unusually short answers here, because the thing being asked about was never on our servers.

Where your content lives

• At rest — your storage, not ours. Documents stay in the Google Drive or GitHub repository you signed in with. Markloom has no document database and writes no copy.
• In transit — TLS, and our server’s memory. A save or load passes file content through our server to reach your storage provider. It is held in memory for the duration of that request and is never written to disk, to a cache, or to a log.
• Published sites are rendered on demand by reading your folder, and the rendered page is cached at the edge for up to five minutes. That cache holds the same content the page already shows the public.
• Images on published pagesare streamed through our origin rather than hot-linked, and cached longer than pages are — up to an hour in a visitor’s browser and thirty days at the edge. Be aware of what that means: if you un-share an image, copies already cached can keep being served for up to that long. The page stops showing it within minutes; the direct image URL is the part that lingers.

What we do store

Two things, both small and neither containing document content.

• A session cookie — encrypted, holding your name, email, and the OAuth access token for your storage provider. It lives in your browser and is decrypted on our server only to proxy your own requests. Signing out deletes it.
• Publishing pointers, in a hosted Redis (Upstash), if you publish a site: your chosen handle, which folder ID each public URL serves from, and any custom share-link names. Our last measurement of a live publisher’s complete footprint was about 320 bytes — four rows of routing metadata. No file names, no document text.

What we can reach in your storage

• Google Drive — the drive.file scope. Only files Markloom created, or files you explicitly opened with it. The rest of your Drive is invisible to us. This is Google’s narrow per-file scope, chosen deliberately over the broader ones that would let an app read everything.
• GitHub — only installed repositories. The Markloom GitHub App reaches the repositories you install it on, typically one.
• Revoke either at any time, from your Google account permissions or your GitHub installations. Your files are unaffected — they were always yours.

What a breach would expose

The honest version, because it is the question worth asking of any vendor. If Markloom’s infrastructure were fully compromised, an attacker would reach:

• Publishing pointers — handles and folder IDs for published sites. Those sites are already public by definition.
• Active session cookies, and through them the OAuth tokens inside. This is the real exposure: a stolen session grants the app’s own scope — the files you opened in Markloom — until the token expires or you revoke access. Revoking from your provider ends it immediately.
• No document archive, because none exists. There is no historical corpus to exfiltrate; only what a live session could have reached anyway.

Published sites are public

Publishing a folder sets Google Drive’s “anyone with the link” permission on it and serves the pages anonymously. That means a published site is genuinely public, and a site with two or more pages is indexable by search engines.

There is no private or access-controlled publishing today. If your content should not be world-readable — an internal handbook, runbooks, anything under NDA — do not publish it as a collection yet. We would rather say so plainly than have you find out. Unpublishing removes the Drive permission and the public URLs stop resolving.

Subprocessors

• Vercel — hosting and edge caching. Sees requests and cached public pages.
• Upstash — hosted Redis for publishing pointers. Sees handles and folder IDs; no content.
• Google / GitHub — your own storage, reached with your own credentials.
• Sentry — error reporting, configured with personally identifiable information disabled and no performance tracing.
• Vercel Web Analytics — cookieless page counts. No advertising identifiers, no cross-site tracking, no access to documents.

Application security

• No passwords. Sign-in is OAuth against Google or GitHub; we never see or store a credential.
• Response headers — Content-Security-Policy, Strict-Transport-Security, X-Frame-Options: DENY, nosniff, a strict Referrer-Policy, and a Permissions-Policy denying camera, microphone and geolocation.
• Ownership checks on every route that writes. Storage-backed routes are scoped by your own OAuth token, so they can only reach what your own account can. The publishing namespace is separate — handles, collection pointers and custom link names live in our Redis, not in your Drive — so those routes compare the signed-in account against the stored owner before writing, and the check lives inside the storage functions themselves rather than being repeated at each route. An automated suite covers the refusals, not just the successes.
• Continuous integration gates every change on lint, type-check, unit tests, end-to-end tests and a production build.

Leaving

There is no export step, because there is nothing of yours to export. Stop using Markloom and your documents remain exactly where they always were, in your own Drive or repository, in plain Markdown. Revoke access and the connection ends. Published sites stop resolving once unpublished, and the folder’s public permission is removed with them.

What we don’t have yet

Stated plainly, so you can judge the rest of this page as accurate rather than promotional.

• No SOC 2 or ISO 27001 certification, and none in progress.
• No SAML or SCIM. Sign-in is Google or GitHub OAuth only, and there is no organisation or team concept — every account stands alone.
• No private or access-controlled sites, as described above.
• No formal SLA, and no 24/7 on-call. Markloom is operated by one person.
• No independent penetration test to date.

Reporting a vulnerability

Email support@markloom.app with enough detail to reproduce. We will acknowledge within three working days and tell you what we intend to do. Please give us a reasonable chance to fix an issue before disclosing it publicly; we will not pursue anyone who reports in good faith.

For anything else, see Privacy and Terms.