Sundial Enterprise IT & Security Review

Last Modified: March 28, 2025

Table of Contents

Summary

Sundial is a Chrome extension that enhances scheduling efficiency in Google Calendar. See how it works here. 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 calendar 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.
  • Enterprise SSO: Supports SAML 2.0 for enterprise single sign-on and SCIM for user management.
  • Secure Processing & Encryption: All communication is encrypted via HTTPS/TLS 1.2+; OAuth tokens are short-lived and not stored.
  • Data Deletion: You may request deletion of associated user data by contacting us at ryland@trysundial.ai.

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.
  • Enterprise SSO: Supports SAML 2.0 for enterprise single sign-on integration and SCIM for user provisioning and deprovisioning.

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.