How we secure the Butterfly app.

Butterfly intentionally avoids storing passwords on our servers. Authentication is handled through a single path: .edu email magic links.

• Students enter their school email. We send a one-time link from a verified sender.
• Clicking the link inside our app verifies the device and creates the session.
• Links expire in 15 minutes and are single-use.
• Sessions are device-scoped. Compromising a device compromises only that device's session.
• Sessions can be revoked from inside the Butterfly app under Settings → Devices.

• In transit: All traffic between the Butterfly iOS app and our backend uses TLS 1.2+ with HSTS. Modern cipher suites only — no SSLv3, no RC4, no weak DH.
• At rest:User content, account data, and backups are encrypted at rest using AES-256 via our cloud provider's managed encryption.
• Backups: Encrypted, retained for 30 days, then deleted. Backup access is logged and limited to designated infrastructure engineers.

Note: Butterfly chats are not end-to-end encrypted. We can read message content if presented with a valid legal request, and we read content during moderation reviews triggered by user reports. We don't browse chats otherwise.

Butterfly runs on managed services from Google Firebase, in U.S. regions. Specifically:

• Firebase Authentication for email-link verification flow.
• Cloud Firestore for user profiles, class data, and message storage.
• Firebase Cloud Messaging for push notifications.
• Firebase Crashlytics for diagnostic data when the app crashes.
• Cloud Functions for server-side logic.

Google Cloud's underlying infrastructure carries SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018, and other certifications. Butterfly itself is not yet SOC 2 audited; we plan to pursue Type I in the next 12 months.

• Least privilege. Production access is granted on a need-to-know basis. Most engineers can read aggregated metrics; very few can access raw user content.
• SSO + 2FA on Google Workspace, GitHub, and Firebase consoles. Hardware key required for production access.
• All production access is logged. Audit logs are retained for at least 1 year.
• Background checks for employees and contractors with access to user data.
• Annual access review to revoke unnecessary permissions.

• Code review required on every change to production code. No solo merges.
• Automated dependency scanning via Dependabot. Critical CVEs are patched within 72 hours; high within 7 days.
• Static analysis on every pull request.
• Secrets management via Google Secret Manager. No credentials in source code or CI logs.
• Mobile-specific: certificate pinning, jailbreak detection on session-sensitive operations, no sensitive data persisted in iOS UserDefaults or unencrypted local files.

We classify data into three tiers and apply controls accordingly:

• Tier 1 — Account & identity: .edu email, name, school. Encrypted at rest, access logged, exportable on request, deletable on request.
• Tier 2 — User content: Messages, photos, profile fields. Same controls as Tier 1, plus retention timers tied to your account.
• Tier 3 — Operational: Aggregated metrics, anonymized usage data. Used for product analytics. Not personally identifiable.

We welcome reports from security researchers. If you've found a vulnerability in the Butterfly iOS app, our backend, or our website, send a write-up to security@butterflyapp.co.

Safe harbor

If you act in good faith, follow the rules below, and don't access user data beyond what's necessary to demonstrate the issue, Butterfly will not pursue legal action against you for the research. We commit to:

• Acknowledging your report within 3 business days.
• Providing an initial assessment within 10 business days.
• Keeping you informed as we triage and patch.
• Crediting you publicly (if you'd like) once the issue is fixed.

Scope

Disclosure timeline

Standard 90-day coordinated disclosure window. We may request an extension for complex issues. We ask that you don't publicly disclose a vulnerability until we've had a chance to fix it.

Bounty

Butterfly does not currently run a paid bug bounty. Significant findings may receive a thank-you, swag, or hall-of-fame credit. We expect to launch a paid program as we grow.

If we discover a security incident affecting users, our response process is:

1. Contain. Stop the bleeding — revoke credentials, isolate affected systems, deploy patches.
2. Investigate. Determine scope, root cause, and which users (if any) were affected.
3. Notify. If user data was accessed without authorization, we notify affected users and regulators within the timelines required by law (typically 72 hours under GDPR; varies by U.S. state).
4. Remediate. Apply fixes, harden controls, document lessons learned.
5. Disclose. Publish a public post-mortem for material incidents on our blog.

For sensitive reports, you may encrypt your message to security@butterflyapp.co. PGP key fingerprint and full key are available on request — email security@butterflyapp.co with the subject “PGP key request.”

• CCPA / CPRA: compliant. See Privacy → California section.
• GDPR / UK GDPR: compliant. See Privacy → EU/UK section.
• COPPA:we don't knowingly collect data from anyone under 13.
• FERPA: Butterfly is independent of universities and does not receive education records covered by FERPA.
• SOC 2: targeting Type I in the next 12 months. Not currently audited.
• App Store privacy nutrition label: reflects our actual data practices and is updated when our practices change.

Law enforcement requests should go to legal@butterflyapp.co. We accept service of process by email and post. We require valid legal process (subpoena, court order, or search warrant) for non-public user information. We give users notice of legal requests when permitted by law. We publish an annual transparency report.

Butterfly Social Network, Inc.
A Delaware corporation

• Security: security@butterflyapp.co
• Legal: legal@butterflyapp.co
• Privacy: legal@butterflyapp.co