Last Modified: March 28, 2025
Summary
Sundial is a Chrome extension that enhances scheduling efficiency in Google Calendar. Privacy and security are top priorities:
- No Passive Monitoring: No tracking, logging, or collection of any user activity outside of explicit Sundial interactions.
- Minimal Data Access: Only accesses Google Calendar and Gmail when triggered by the user; no event details or email content are stored.
- Scoped Authentication: Uses Chrome Identity to identify users; Google OAuth 2.0 is required only for the Bulk Delete Calendar Holds feature.
- Secure Processing & Encryption: All communication is encrypted via HTTPS/TLS 1.2+; OAuth tokens are short-lived and not stored.
- No Persistent Data Storage: Processing is ephemeral; no calendar events, meeting times, or email content are stored.
This document outlines Sundial’s permissions, authentication, compliance, and security architecture for enterprise assessment.
For inquiries, contact ryland@trysundial.ai.
1. Permissions & Data Access
1.1 Chrome Permissions
- storage: Saves user preferences.
- background: Maintains extension functionality without tracking user activity.
- identity: Associates users with preferences via Chrome Identity Email/ID.
- activeTab: Temporarily grants permissions for Google Calendar access.
- scripting: Injects scripts to enhance scheduling features.
1.2 Host & API Permissions
Host Permissions
- calendar.google.com: Reads and modifies Google Calendar upon user request.
- mail.google.com: Extracts meeting times from Gmail email content only upon user action.
API Permissions:
- Firestore: Stores user preferences and feature usage.
- Calendar API: Manages calendar events upon user request.
- OAuth 2.0: Authenticates API calls securely.
- Llama 3.1 8B via Groq API: Extracts meeting times from Gmail email content upon user action.
2. Data Security & Storage
2.1 Data Collection
- User Identifiers: Chrome Identity Email/ID, Google Calendar Email, Name, and Locale for feature personalization.
- Usage Data: Feature interactions to improve functionality.
2.2 Storage & Encryption
- Local Storage: Stores user preferences and temporary UI states to retain user actions during a session.
- Firestore: Stores non-sensitive preferences and usage data.
- OAuth Security: Tokens are short-lived and auto-refreshed; not stored.
2.3 Data Processing
- Google Calendar Data: Processed only for Bulk Delete Calendar Holds; no event details stored.
- Gmail Data: Temporarily processed Gmail email content via Llama 3.1 8B only upon user action; no storage or AI training usage.
2.4 Data Residency
- Firestore: Stored in nam5 region; no event details or Gmail email content retained.
- Llama 3.1 8B Processing: Hosted on Render.com (Oregon, U.S.), forwarding Gmail meeting time detection requests to Groq API for real-time processing.
- No Logging or Long-Term Storage: All processing is ephemeral.
2.5 Data Deletion Policy
- User Requests: Users can request data deletion via ryland@trysundial.ai.
- Enterprise Deletion Requests: Organizations may request full deletion of their users’ data.
3. Authentication & User Identity
3.1 Authentication Methods
- Chrome Identity API: Primary authentication method for associating users with preferences.
- Google OAuth 2.0: Used only for Bulk Delete Calendar Holds.
3.2 Authorization & Access Control
- Least Privilege Principle: Access is restricted to necessary actions only.
Scoped API Access:
- Google Calendar API: Accessed only when explicitly invoked by the user.
- No Background Data Collection: Actions are explicitly user-initiated.
4. Application Architecture
4.1 System Components
- Chrome Extension Frontend: Injects scripts into Google Calendar and Gmail only upon explicit user interaction.
- Backend Services:
- Firestore: Stores user preferences.
- Google Calendar API: Used exclusively for Bulk Delete Calendar Holds.
- Llama 3.1 8B: Processes meeting time extraction from Gmail email content ephemerally.
- No Proprietary Backend: Relies on Google Cloud infrastructure.
4.2 Secure Communication
- HTTPS/TLS Encryption: All communications use TLS 1.2+.
- OAuth Token Security: Tokens are short-lived and not stored.
- No Passive Data Interception: No tracking, logging, or collection of any user activity outside of explicit Sundial interactions.
5. Compliance & Privacy Considerations
5.1 Regulatory Compliance
- GDPR: Data minimization, user control over data, and deletion upon request.
- CCPA: User data is not sold or shared with third parties.
- SOC 2: While Sundial is not certified, Google Cloud infrastructure follows best security practices.
- HIPAA: No storage or retention of PHI; detecting meeting times from Gmail email content is ephemeral and user-initiated.
5.2 Privacy & Security Certifications
- Google Chrome Web Store Security Review: Ensures compliance with best practices.
- Penetration Testing: Not conducted yet, but follows Chrome extension security best practices.
5.3 Incident Response
- Monitoring & Response: Security vulnerabilities are proactively addressed.
- User Reporting: Contact ryland@trysundial.ai for security concerns.
- Breach Protocol: Immediate notification and remediation if a breach occurs.