Sundial Enterprise IT & Security Review

Last Modified: March 13, 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.
  • Optional Gmail Meeting Time Extraction: Organizations can disable the feature that detects meeting times in email content and overlays them on Google Calendar.

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. Organizations can disable the feature.

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.