Privacy & Security (Plain-Language Guide)

This page is the plain-language privacy and security guide. For legal/store compliance text, see the Legal Privacy Policy.

What data Skeeditor stores

Skeeditor stores some data in your browser's extension storage (browser.storage.local) to keep you signed in and remember your preferences. Specifically:

• OAuth sessions and account state. For each account you sign in with, Skeeditor stores the OAuth access and refresh tokens issued by Bluesky's authorization server (bsky.social), plus the minimal metadata needed for multi-account support (such as the list of sessions and which account is currently active).
• Per-account service configuration. For each DID, Skeeditor stores the URL of the personal data server (PDS) you use.
• Editor settings. Your local preferences (for example, the edit time limit) so the editor behaves the same way each time you use it.
• Pending labeler consent. A short-lived flag indicating whether Skeeditor should prompt you to opt in to the optional Skeeditor labeler.
• DPoP key material. Public/secret key pairs used to generate OAuth DPoP proofs, stored only in extension storage and used solely as required by the OAuth protocol.

Extension storage is isolated per-extension and per-browser-profile. It is not accessible by web pages, other extensions, or any server.

No plaintext passwords

Skeeditor never asks for, receives, or stores your Bluesky password. The OAuth flow runs entirely between your browser and the Bluesky authorization server.

---

What Skeeditor does not collect

• No analytics. There are no tracking scripts, no telemetry endpoints, no crash reporters. The extension makes zero outbound network requests to any analytics provider.
• No analytics or ad-tech services. The extension does not call telemetry, tracking, or ad endpoints. It only calls Bluesky infrastructure plus clearly documented extension services (Skeeditor labeler and Slingshot read acceleration).
• No browsing history. Skeeditor only activates on bsky.app. It does not read your history, open tabs list, or any other site's data.
• No clipboard access. The editor pre-fills from the on-page post text. The extension never programmatically reads or writes your clipboard.
• No analytics or ad profiling. We do not build user profiles, run ad targeting, or collect behavioral analytics data.
• No sale of user data. We do not sell or broker user data.

---

Network connections

When you use Skeeditor, your browser makes requests to:

• Your Bluesky auth server (typically bsky.social) /oauth/authorize for initial OAuth authorization
• Your Bluesky auth server /oauth/token for token exchange and refresh
• Your PDS (typically bsky.social or *.bsky.network) /xrpc/com.atproto.repo.getRecord and /xrpc/com.atproto.repo.putRecord for record reads/writes
• https://slingshot.microcosm.blue/xrpc/com.atproto.repo.getRecord for edited-post read acceleration
• https://labeler.skeeditor.link/xrpc/tools.skeeditor.emitLabel for label emits after successful edits
• wss://labeler.skeeditor.link/xrpc/com.atproto.label.subscribeLabels for real-time edited-label updates (the extension currently opens this connection on background startup, even if the user has not subscribed to the labeler in Bluesky)
• https://plc.directory/<did> for did:plc document resolution in DID helper flows
• https://public.api.bsky.app/... and https://api.bsky.app/... for fallback DID→handle lookups
• https://docs.skeeditor.link/oauth/client-metadata.json for OAuth client metadata
• https://docs.skeeditor.link/callback.html for the hosted OAuth callback page

When labeler integration is active, Skeeditor sends the OAuth access token in an Authorization: Bearer header to the labeler emit endpoint so the labeler can validate the token with the user's PDS before accepting an emit. Skeeditor does not send refresh tokens to the labeler.

All requests go over HTTPS/WSS to the hosts above. There are no analytics endpoints, hidden relay proxies, or advertising SDK calls.

When notifying the labeler after a successful edit, Skeeditor forwards your OAuth access token in the Authorization: Bearer header so the labeler can verify your identity against your PDS. Your refresh token is never sent to the labeler or to any server other than your Bluesky authorization server.

Data controller / retention summary

• Skeeditor is an extension that processes data primarily in your browser and sends required requests to Bluesky and the documented service endpoints above.
• We do not run a telemetry pipeline for extension usage events.
• Any data handling by third-party services (for example, Bluesky infrastructure) is governed by their own policies.

For Firefox distribution, Skeeditor declares built-in data collection consent categories in the manifest for:

• authenticationInfo — OAuth token exchange plus authenticated requests to your PDS and the Skeeditor labeler
• personalCommunications — the post text you choose to edit and send back to Bluesky

---

Security model

OAuth 2.0 + PKCE

Authentication uses the OAuth 2.0 Authorization Code flow with PKCE. A fresh code_verifier/code_challenge pair is generated locally for every sign-in, preventing authorization code interception attacks.

Token storage

Access and refresh tokens are stored in browser.storage.local. This storage is sandboxed to the extension and is not accessible from content scripts (scripts injected into bsky.app pages) or from the page itself.

The background service worker handles all token usage and refresh. Content scripts communicate with the background only via typed runtime messages — they never touch tokens directly.

CID-based optimistic locking

When saving an edited post, Skeeditor uses the record's CID (content identifier) as an optimistic concurrency check. If the record changed between when the editor was opened and when Save is clicked, the write is rejected — not silently overwritten.

---

Open source

Skeeditor is fully open source under the MIT licence. You can read every line of code at github.com/selfagency/skeeditor and verify these claims yourself.