Attaché is built around one rule: a delegate should only ever see and do what you have allowed. This page explains how we protect your accounts, your calendar data and those permissions. The privacy policy covers what data we collect and why.
Your accounts stay yours
- You connect Google, Microsoft and Zoho accounts through each provider’s own OAuth 2.0 sign-in page. Attaché never sees your password for those accounts.
- Apple iCloud and other CalDAV servers have no such sign-in page, so you connect them with an app-specific password: a password created for Attaché alone and revocable by you at any time, at your provider (how to create one for iCloud). Attaché never asks for your Apple Account password, and its iCloud form accepts only the app-specific password’s 16-letter shape; a server that has no app-specific passwords takes the account’s own password.
- Delegates sign in to Attaché as themselves. They never receive your passwords, app-specific passwords or tokens, and everything they do goes through Attaché’s permission checks.
- We ask providers only for the calendar permissions Attaché needs to work, and we use an app-specific password only to read and change your calendars.
Encrypted token vault
- Provider refresh tokens, app-specific passwords and the links of calendars you subscribe to are encrypted with AWS Key Management Service (KMS) envelope encryption: each is encrypted with a unique data key, and that data key is encrypted with a KMS key that never leaves AWS KMS.
- Each encrypted token, password or link is bound to its account and connection by a KMS encryption context, so it can’t be decrypted outside that context.
- The web-facing API can only encrypt them. Only the background workers that sync and update your calendars can decrypt them.
- The KMS key is rotated automatically.
- Tokens, passwords and calendar links are never sent to browsers or devices, including your delegates’, and Attaché doesn’t show a calendar’s link again after you add it.
Permissions enforced on our servers
- Every read and write passes through Attaché’s permission engine on our servers. Events are redacted before they leave our servers, so a delegate’s app never receives details you haven’t shared, even if someone modifies the app.
- Events hidden by your filters can’t be edited or deleted by delegates.
- In propose → approve mode, nothing is written to your Google, Microsoft, iCloud, Zoho or CalDAV calendar until you approve it.
- Calendars you subscribe to by link are read-only for everyone, you included.
Encryption in transit and at rest
- In transit: every connection to Attaché uses HTTPS with TLS, and so do our connections to Google, Microsoft, Zoho, Apple iCloud, the CalDAV servers you connect and the calendar links you subscribe to.
- We connect only to servers on the public internet, over HTTPS: a server address or calendar link that points to a private or internal network is refused, so it can’t be used to reach our own systems.
- At rest: our database, its backups and our file storage are encrypted.
Infrastructure and access
- Attaché runs on Amazon Web Services in the United States (us-east-2, Ohio).
- Least-privilege access: each part of the system gets only the AWS permissions it needs, scoped to specific resources.
- The database accepts only encrypted connections (TLS), and every part of Attaché checks its certificate before signing in. Each part signs in with its own database account, which may do only what that part needs, and row-level security keeps each person’s requests to the calendars they own or help manage.
- Deployments use short-lived credentials instead of long-lived access keys, and application secrets are stored encrypted, never in source code.
- A web application firewall with rate limiting protects the production service.
Append-only audit log
- Every action taken in your calendars through Attaché, by you or by a delegate, is recorded: who acted, what changed, when, and copies of the event before and after the change so that it can be undone.
- The log is append-only: nobody using Attaché can change or delete its entries. A daily job deletes entries 12 months after they were recorded, and only once our tamper-proof archive holds them and their integrity checks out (retention and deletion).
Backups and recovery
- The production database has automated, encrypted backups with point-in-time recovery, kept for 35 days.
- When you delete your account, your data leaves our backups as they expire (see retention and deletion).
Reporting a vulnerability
If you believe you have found a security vulnerability in Attaché, please email security@tryattache.com with a description, the steps to reproduce it and any proof of concept. We will acknowledge your report within three business days, keep you updated while we investigate, and credit you once it is fixed if you would like us to.
When you research Attaché, please:
- test only against accounts you own or have permission to use;
- never access, change or delete other people’s data;
- avoid degrading the service: no denial-of-service testing, spam or high-volume automated scanning;
- don’t use social engineering or physical attacks; and
- give us reasonable time to fix the issue before you disclose it publicly.
If you follow these guidelines in good faith, we will not pursue legal action against you for your research, and we will work with you to understand and fix the issue. We don’t offer a paid bug bounty at this time. Our contact details are also published in security.txt.