Privacy Policy
1. Who we are
CalendarGuardian is operated by DealDoctor PLLC ("DealDoctor," "we," "us," or "our"). We provide calendar-security and calendar-spam protection tools that can detect, flag, report, block within CalendarGuardian, quarantine or remove suspicious calendar invitations according to user settings and provider capabilities.
2. Information we process
Account and authentication data
When you connect a Microsoft account, we may receive basic profile information made available through Microsoft Graph, such as your account identifier, display name, email address or user principal name, together with OAuth access and refresh tokens. When you connect Google Calendar, we may receive your Google OpenID Connect identifier, display name, email address, and OAuth access and refresh tokens. We do not receive or store your Microsoft or Google account password. On Apple and Android devices, the native app requests operating-system Calendar permission and reads calendars already exposed by EventKit or Android Calendar Provider. It does not collect the password for Apple, Google, Microsoft, Yahoo, or another account synchronized onto the device.
Email-and-password sign-in
Where enabled, you can create a CalendarGuardian account with your email address and a separate password. We verify email ownership before creating that sign-in. We store a salted, computationally expensive password hash, not your password in readable form. Verification and reset links expire after 30 minutes and work once; the service stores a hash of each token. Reset requests do not change your password. Completing a reset signs out existing CalendarGuardian browser and linked-device sessions. Account sign-in does not authorize calendar or mailbox access.
When account email is enabled, the configured Postmark or Resend service receives the recipient email address and verification or reset message, including its one-time link, to deliver account email. After a provider connection is verified and saved, connection security notifications can include the connected address, provider, time, verification method, and a link to manage access. Calendar events, mailbox scan content, and CalendarGuardian passwords are not included in those messages.
Calendar data
To provide protection, CalendarGuardian may retrieve or locally process calendar-event information such as event ID, subject, organizer, organizer email address and domain, attendees, start and end time, all-day status, recurrence, location, response status, event body or preview, links contained in the invitation, calendar source, and related event metadata. CalendarGuardian may apply or remove an Outlook category, Google event color, or provider-supported private marker so a flagged event and the user's later review decision remain visible and synchronized inside the calendar.
CalendarGuardian is designed to process allowed events transiently for scoring. When an event is flagged, reported, or removed, CalendarGuardian may retain an event snapshot and the reasons for the decision so you can review the event, understand why it was flagged, and where technically possible restore available event information. The Apple and Android clients can operate locally or be linked by a single-use code to an existing CalendarGuardian service profile. During a linked scan, selected invitation content is sent over HTTPS to the CalendarGuardian service so the same service-side scoring engine and rules can be used; the service returns the score and reasons. Each app retains a bounded device-local history of up to 100 removed events so the user can restore a copy.
Rules and protection settings
We store your service-side protection settings and CalendarGuardian rules, including trusted and blocked organizer addresses or domains, user-selected review keywords or phrases, sensitivity thresholds, and automatic-action preferences. A linked Apple or Android client synchronizes supported rules and user decisions with that profile; an unlinked native client stores supported rules locally on the device. Provider-specific platform rules may limit which actions can be automated.
Service storage and tenant separation
The hosted web application, Outlook add-in, Google connector, linked Apple or Android client, and related service use a shared PostgreSQL database. Records are assigned to the applicable CalendarGuardian account or service tenant and are separated using tenant identifiers and database row-level access controls. The service also maintains a restricted JSON safety mirror during the PostgreSQL migration period so a failed migration can be rolled back without losing account state. Calendar selections remain local to the native device. When a native client is linked, supported native rules, decision history, and limited detection records are synchronized; allowed invitation content sent for scoring is processed transiently and is not retained as an event snapshot solely because it was allowed.
Service and security data
We may process limited technical information needed to operate and secure the service, including session identifiers, error information, timestamps, subscription or notification-channel status, webhook processing records, diagnostic information, and the time, method, and legal-document versions associated with connection consent. CalendarGuardian uses a strictly necessary session cookie to maintain your authenticated session. The service is not designed to use advertising or cross-site behavioral tracking cookies.
Subscription and payment data
When you subscribe through the CalendarGuardian website, Stripe processes the payment information you provide. CalendarGuardian receives and stores limited billing records such as a Stripe customer and subscription identifier, subscription status, billing-period dates, cancellation status, and payment or checkout status. When you subscribe in the Apple or Android native app, Apple App Store or Google Play processes the payment and provides the app with signed transaction or purchase information needed to verify whether the annual native entitlement is active, pending, canceled, revoked, or expired. For account activation and ongoing entitlement checks, the app sends signed Apple transaction information or a Google Play purchase token to CalendarGuardian over HTTPS. The server verifies the purchase with Apple or Google and stores purchase identifiers or encrypted verification credentials, an account-binding identifier, product, status, environment, expiry and verification timestamps. Purchase verification does not include calendar content. When an account is deleted, retained purchase tombstones prevent reuse or delayed provider notifications from restoring the deleted account; recoverable purchase credentials are removed. CalendarGuardian does not receive or store your full payment-card number or card security code. Stripe, Apple, and Google process payment information under their own privacy terms.
3. How we use information
- record affirmative connection consent and authenticate and connect an authorized calendar account or native calendar store;
- detect and score suspicious invitations;
- apply trusted and blocked sender/domain rules and user review keywords;
- record user reports and, where a Calendar Provider exposes a supported production reporting mechanism, submit a provider report when authorized;
- flag, review, quarantine, remove, dismiss, or restore event information according to your instructions, settings, and provider capabilities;
- maintain Microsoft Graph subscriptions and Google Calendar notification channels and process calendar-change notifications;
- provide support, prevent abuse, investigate errors, and secure the service;
- administer subscriptions and billing where applicable; and
- comply with law and enforce our agreements.
4. Automated detection and actions
CalendarGuardian uses automated rules and risk scoring to evaluate invitations. The current core detection engine is rules-based and does not require sending calendar content to a third-party generative-AI model provider. Where enabled, CalendarGuardian downloads vetted threat-intelligence feed files to its own server cache and locally compares domains found in invitation links. Calendar invitation data is not sent to those feed providers for lookup. Feed availability, licensing, coverage, and accuracy vary, and a feed match can be wrong or stale. Automated detection can make mistakes. Depending on your settings and provider capabilities, CalendarGuardian may take automated action on high-confidence events or events from sources you expressly block. User review keywords raise matching invitations for review but do not remove them by themselves. Some platforms may require explicit user interaction before CalendarGuardian modifies a calendar event.
"Block" within CalendarGuardian means adding a sender or domain to CalendarGuardian's internal protection rules so future matching invitations can be recognized and acted upon. It does not necessarily create an Exchange, Microsoft, Google, Apple, email-server, or network-level block unless the product expressly states otherwise.
5. Calendar providers
CalendarGuardian uses provider-specific interfaces. Microsoft connections use Microsoft identity and Microsoft Graph, including calendar read/write access and mailbox-settings access used to define CalendarGuardian's colored Outlook categories. CalendarGuardian does not request Microsoft Mail permissions for the core calendar-protection service. Google connections use Google OAuth/OpenID Connect and the Google Calendar API, including Calendar push-notification channels where enabled. Apple-native clients use EventKit, and Android-native clients use Android Calendar Provider, to access calendars for which the user grants the required operating-system permission. These device stores may surface local, iCloud/CalDAV, Exchange, Google, Yahoo-synchronized, and other configured calendar sources. Microsoft, Google, Yahoo, Apple, and other Calendar Providers process information under their own terms and privacy practices. Provider reporting, deletion, restoration, notification, and background-processing capabilities differ by platform.
Optional email invitation scanning and cleanup
Invitation cleanup disclosure updated September 14, 2026. Cleanup requires a separate, versioned opt-in.
Email scanning is separate from calendar access and off by default. Choose a mailbox and Inbox and/or Junk/Spam, then expressly authorize scanning. Microsoft and Google use separate mailbox OAuth grants. Yahoo and iCloud use provider-generated app passwords encrypted on our server. Those credentials can permit broader access, including sending; CalendarGuardian does not send email using them. Provider availability and release restrictions are shown in the product.
Scanning uses a selected window of 7, 30 or 90 UTC calendar days, including today; the default is 30 days. Initial scans, manual scans and requested cleanup stay within that window. Automatic scans use the last successful scan with a one-day overlap, bounded by the selected window. Enabling cleanup never starts an all-history scan. Unresolved findings from earlier scans remain in the review queue until handled. We read metadata, including sender, subject, identifiers and MIME structure; Microsoft and Gmail responses can include message bodies. Calendar attachments identified by text/calendar or an .ics filename are retrieved up to 1 MB each. Other attachment files are not retrieved. Email bodies and attachments are processed transiently and are not retained in review results, sent to generative AI services, or submitted to threat-feed providers.
Invitation cleanup requires a separate affirmative permission recorded with its version and timestamp. Microsoft requires Mail.ReadWrite; Gmail requires gmail.modify. Yahoo and iCloud use their existing app-password connection. Provider permissions may be broader than our invitation-only behavior. Cleanup moves existing and future invitation emails matching your saved sender, domain or invitation-content block rules to Trash or Deleted Items in selected folders. This includes rules saved before cleanup was enabled. We re-read a message before moving it; ordinary messages, messages with unrelated invitations, and explicitly approved invitations are left in place. This does not create provider-wide sender blocks, prevent delivery, send replies, RSVP or accept invitations. Calendar removal is a separate action governed by calendar permissions and protection settings.
Scans run on the server daily (every 24 hours) while product access and scanning remain enabled. On-demand scans and block actions also initiate work. Timing, folder coverage and processing limits can leave a scan incomplete; failures are reported. Moves are recorded separately from saved rules, so a saved block does not mean removal succeeded. Up to 500 pending invitation records retain identifiers, subjects, sender addresses, content hashes and scores so prepared cleanup can resume after an interrupted scan. Up to 1,000 email action records retain invitation subjects, message identifiers, sender addresses, mailbox, outcome and timestamps; the latest 100 are shown in the activity view. The latest scan retains invitation subjects, identifiers, folder, scores, reasons and counts. Up to 1,000 approval fingerprints prevent repeated review of unchanged approved invitation content.
You may turn cleanup off while keeping read-only scanning. You may turn scanning off to stop further work and clear stored mailbox credentials, findings, approval fingerprints and email removal records. Disconnecting the connection or deleting your CalendarGuardian account also clears these records. An already transmitted provider request cannot be recalled. Provider grants and app passwords must be revoked at the provider to invalidate them there. Shared CalendarGuardian block rules remain until removed or the account is deleted. Unblocking does not restore previously moved email. Use the mailbox Trash/Deleted Items controls to restore email before the provider's retention period expires. CalendarGuardian does not permanently purge Trash.
CalendarGuardian uses Google API data only for the requested invitation scanning, review and cleanup features. Its use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including Limited Use requirements. Gmail data is not used for advertising, model training, unrelated products or third-party data sales.
6. Sharing and subprocessors
We do not sell Personal Data and do not share Personal Data for cross-context behavioral advertising. We disclose information only as necessary to provide and secure CalendarGuardian, interact with the Calendar Provider you authorize, process payments or Marketplace transactions, comply with law, protect rights and safety, or complete a business transaction subject to appropriate protections. CalendarGuardian may download public or licensed threat-feed data from identified security-intelligence providers, but does not send calendar invitations, organizer addresses, or event content to those providers for lookup. Current service providers and intelligence sources are listed at CalendarGuardian Subprocessors and in the in-product feed status.
7. Data retention
We retain information only for as long as reasonably necessary for the purposes described in this Policy, to provide the service, and to meet legal obligations. Server-side OAuth credentials are retained while the corresponding provider connection remains active and are deleted when the associated CalendarGuardian account data is deleted. Protection rules and settings are retained while your account is active unless you delete them. Under the initial production configuration, unresolved flagged/reported event snapshots are automatically removed after approximately 90 days, resolved review/removal snapshots after approximately 30 days, and detection-history records after approximately 90 days, unless a shorter period is applied or a longer period is reasonably required for security, dispute, fraud-prevention, or legal purposes. These periods may be changed as the service evolves, with this Policy updated when a material retention practice changes.
The native apps retain at most 100 device-local removal-history records until the app's local data is cleared or the app is uninstalled. When you use the service-side account deletion function, CalendarGuardian first closes recorded Stripe checkout sessions and immediately cancels active CalendarGuardian website subscriptions. If Stripe cannot confirm closure, account deletion stops and reports an error; prior charges are not automatically refunded. Apple App Store and Google Play subscriptions are managed separately. CalendarGuardian then disconnects every provider account linked to the CalendarGuardian profile, deletes the applicable service-side account records, stored OAuth token material, settings, rules, review/removal records, and detection records, and attempts to remove the applicable CalendarGuardian provider subscriptions or notification channels. A one-way hash of prior Stripe resource identifiers may remain for up to approximately 90 days solely to reject delayed billing webhooks; it cannot be used to recover the deleted identifiers. Service-side deletion does not clear a separately installed native app's local data and does not delete your Microsoft, Google, Yahoo, Apple, or other provider account. Limited service information may remain temporarily in ordinary-course backups, security logs, or records we are legally required to retain.
8. Security
CalendarGuardian is designed to use encrypted HTTPS connections in production. Stored server-side OAuth token material is encrypted at the application layer using AES-256-GCM. Production service records are stored in a shared PostgreSQL database with tenant-scoped record keys and row-level access controls; database credentials and application encryption keys are maintained separately from source code. Application secrets are intended to be maintained outside source code in protected environment configuration. Native Calendar permission and app-private local storage are mediated by the operating system; Android backup is disabled for the current native app so its stored removal history is not included in Android application backup. We use least-privilege access principles and request only permissions needed for supported features. See Security for additional information.
9. Legal bases and international use
Where the GDPR, UK GDPR, or similar laws apply, we process Personal Data as necessary to perform our contract with you, based on legitimate interests in providing and securing the service, to comply with legal obligations, and based on consent where required. DealDoctor PLLC is based in the United States, and information may be processed in the United States or other locations used by our service providers or authorized Calendar Providers. Where required, we use or support legally recognized transfer mechanisms.
10. Your rights and choices
Depending on applicable law, you may have rights to access, correct, delete, restrict, object to processing of, or obtain a copy of Personal Data. You can pause the calendar filter, disable malicious-link intelligence for your account, change trusted/blocked rules, disconnect the calendar and withdraw consent, remove CalendarGuardian in provider application-permission settings, change Apple or Android Calendar permissions in device settings, clear the native app's local storage or uninstall it, or permanently delete the CalendarGuardian account and service data. Requests may also be sent to privacy@dealdoctor.pro. We may need to verify your identity before fulfilling a request.
11. California disclosures
CalendarGuardian may process identifiers, internet or electronic-network activity information, professional or employment-related information contained in calendar events, and other information you choose to include in calendar content. We use these categories for the business purposes described above. We do not sell Personal Data and do not share Personal Data for cross-context behavioral advertising as those terms are defined by California law.
12. Children
CalendarGuardian is not directed to children under 18, and we do not knowingly offer the service to children.
13. Changes
We may update this Policy as CalendarGuardian evolves, including when new calendar providers, native clients, permissions, or material processing activities are added. Material changes will be posted here and, where appropriate, communicated through the service or account email.
14. Contact
DealDoctor PLLC
Privacy: privacy@dealdoctor.pro
Legal: legal@dealdoctor.pro
Support: support@dealdoctor.pro
Automatic invitation blocking and content rules
Optional automatic email blocking creates sender blocks for high-risk invitations scoring at least 90/100 and saves a hash of sufficiently detailed invitation content. Matching content is recognized even when the sender changes. Exact matching normalizes spacing, letter case and common tracking tags. Conservative near-duplicate matching also requires substantial shared invitation text and a shared campaign link host; common calendar-service link hosts cannot establish that match. Short text and subject-only matches do not create content rules. Manual invitation blocks also save eligible content rules, independently of the automatic-blocking setting. Content rules synchronize across your protected connections. Approved invitations and trusted senders are excluded from automatic email blocking and cleanup. Ordinary email is excluded. Lower-confidence findings remain available for review. Turning automatic blocking off stops new automatic rules; saved rules continue until removed in Rules. Cleanup remains separately controlled, and moved email can be restored from Trash before the provider deletes it under its retention policy.