Sundial Enterprise IT & Security Review

Last Modified: May 2, 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 & Storage: Only accesses Google Calendar and Gmail when explicitly triggered by the user. Only stores user's email address and basic usage data (e.g. which features the user's uses and how often). No event details or email content are stored. Processing is ephemeral and nothing is stored persistently.
  • Secure Processing & Encryption: All communication is encrypted via HTTPS/TLS 1.2+; OAuth tokens are short-lived and not stored.
  • Optional Gmail Meeting Time Extraction: Organizations can disable the feature that detects meeting times in email content and overlays them on Google Calendar.
  • Enterprise SSO: Supports SAML 2.0 for enterprise single sign-on and SCIM for user management.
  • 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.
  • 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:

  • Cloud 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: Email address from authentication.
  • 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.
  • Cloud 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 feature; no event details stored.
  • Gmail Data: User-selected email body content and its sent datetime are processed via Llama 3.1 8B only upon user action; no storage or AI training usage.

2.4 Data Residency

  • Cloud 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

  • Google OAuth 2.0: Primary authentication method required to use Sundial.
  • 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:
    • Cloud 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: Sundial follows data minimization principles. Users retain full control over their data and can request deletion at any time.
  • CCPA: No user data is sold or shared with third parties.
  • SOC 2: While Sundial is not formally certified, it stores only the user’s email address. All infrastructure runs on Google Cloud, which complies with SOC 2 best practices.
  • HIPAA: Sundial does not store or retain any PHI. Email content used to detect meeting times is processed ephemerally, triggered only by the user. This feature can be disabled entirely by organizations.

5.2 Privacy & Security Certifications

  • Google Chrome Web Store Security Review: Ensures compliance with best practices.
  • Penetration Testing: A formal third-party penetration test has not yet been conducted. However, Sundial follows Chrome extension security guidelines, least-privilege access principles, and secure coding practices. We are open to customer-led security assessments or can coordinate third-party testing upon request.

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.