Privacy Policy

Last updated:

YURIKA, K.K. ("we," "us," or "our") describes how we handle user information in "Simple Memo - for Obsidian" (also known as "Simple Memo - for Obsidian," hereinafter the "Service").

1. Information We Collect

We may collect the following information:

(A) Information you provide

  • Recipient email address ("To")
  • Subject and signature settings
  • Memo content (to the extent necessary to send the email)

(B) Device and usage information

  • Basic device/OS information
  • Operational logs (send timestamps, status)
  • Usage events (screen views, interactions, and send outcomes), a random device-level identifier, session IDs, send IDs, and diagnostics such as whether app launch completed
  • Technical data for abuse prevention and rate limiting (IP address, request metadata)

Usage events do not contain email addresses or memo text, but a send ID can link them to the recipient email hash in our delivery records. We therefore treat these events, device identifiers, and diagnostics as data that can be linked to the user.

(C) Subscription and Refund Notifications From Apple

To understand subscription operations and billing failures, we verify signed notifications from Apple and record subscription starts, renewals, changes to automatic renewal, failed renewals, expirations, refunds, and related events. Stored fields include notification and transaction identifiers, subscription product identifiers, notification types and subtypes, production or test environment, dates such as purchase, expiration, revocation, signing and receipt, and revocation reasons supplied by Apple. These Apple identifiers are not treated as fully anonymous information. These notification records contain no email addresses, memo content or installation identifiers. We do not retain a mapping from Apple transaction identifiers to installation identifiers or recipient email addresses. Section (D) describes matching notifications during processing to create separate analytics records. We cannot locate the original notification records from an email-address-only deletion request.

(D) Subscription State and Retention Analytics

When this analytics feature is enabled in a supported app, we receive signed purchase and renewal information from Apple through the device, verify it, and store subscription facts with an installation identifier for comparison with usage-retention events. Recorded fields include the subscription product, purchased or family-shared ownership, price and currency, dates such as purchase, expiration, revocation, signing, observation and receipt, automatic-renewal status, billing retry, grace period, expiration reason, production or test environment, and the app's runtime environment. During processing, Apple transaction identifiers are used to match the notifications described in (C); counts and latest dates by notification type available at that time are also recorded. Apple transaction identifiers and raw signed information are not retained alongside these analytics records. The records also exclude email addresses and memo content, but installation identifiers, products, dates and prices can be linked to usage information and are not treated as anonymous.

Scheduled cleanup deletes these analytics records more than 90 days after receipt. Deletion through a supported app removes records associated with the deletion information retained on that device and rejects delayed uploads under the erased information. This does not collectively delete the original Apple notification records in (C), another device's records, or records held by external analytics services. We may be unable to identify the affected records if, for example, the device's deletion information has been lost.

2. How We Use Information

We use collected information for the following purposes:

  • Providing email sending features (send, outbox/pending management, resend, history)
  • Operating, maintaining, and improving the Service
  • Excluding internal test devices from usage aggregates and avoiding repeated guidance for Obsidian features that are already configured
  • Preventing abuse and ensuring security (cooldowns, server-side rate limits, etc.)
  • Responding to support inquiries
  • Complying with legal obligations

3. Plan Differences

Data handling is generally the same for Free and Premium plans. Premium is primarily offered to remove the Free daily sending limit. Safety and infrastructure limits (e.g., cooldowns and server-side caps) may still apply to both plans.

4. Handling of Memo Content (Important)

  • Memo content is sent as an email based on your action.
  • For delivery, memo content and recipient details may pass through our sending infrastructure (including third-party providers).
  • We do not intend to store or view memo content on an ongoing basis except where necessary for legitimate purposes such as legal compliance, abuse prevention, or troubleshooting.

5. Email Reminder Feature (Optional)

To help you build a memo-writing habit, we offer an optional reminder email feature for users who explicitly opt in.

(A) Consent

  • This feature is disabled by default. We send reminder emails only after you explicitly enable it on the verification screen or in Settings.
  • You can disable it at any time from Settings (one tap), or from the unsubscribe link in any reminder email.

(B) Information We Store

  • A hash (SHA-256) of your email address — stored on our servers (Cloudflare D1).
  • Your consent state (enabled/disabled), last memo send timestamp, and total send count.
  • Reminder send history (timestamps for sent/delivered/opened/clicked/bounced events).
  • The raw email address itself is NOT stored on our servers. It lives only in the contact API of our email delivery provider (Resend).

(C) Sending Frequency

  • Reminders are sent at most once per stall window: 24 hours, 72 hours, and 7 days after your last memo send.
  • Per-user cap: max 2 reminders per 7 days. Service-wide cap: max 80 reminders per day.

(D) Automatic Opt-out

  • If a reminder email bounces or generates a complaint, we immediately stop sending to that address and disable the consent flag.

(E) Service Provider

Reminder email delivery and contact management are handled by Resend, Inc. (USA) under appropriate Data Processing Agreement and compliance with international email regulations (CAN-SPAM, GDPR, the Japanese Act on Regulation of Transmission of Specified Electronic Mail, etc.).

6. Sharing With Third Parties

We do not share personal information with third parties except in the following cases:

  • With your consent
  • As required by law
  • To protect vital interests (life, property, etc.)
  • To service providers to the extent necessary (see Section 7)

7. Service Providers

We may use third-party vendors for email delivery, operations, maintenance, and analytics. In such cases, we appropriately supervise these providers.

8. Security

We take reasonable measures to protect information against leaks, loss, and damage.

9. Retention

We aim not to retain information longer than necessary for the stated purposes. Scheduled cleanup deletes usage events and the subscription-state analytics records in Section 1(D) older than 90 days, and send ID-to-recipient-hash records older than 35 days. Daily cleanup deletes the original Apple subscription and refund notification records more than 180 days after receipt. Each run has a processing limit, so a backlog continues in subsequent daily runs. Other logs may be retained for limited periods for security and operational purposes.

10. Updates

We may update this Policy as needed. The updated version will be posted on the Service or our website.

11. Contact

support@simplememofast.com

12. Technical notes on encryption (for reference)

To protect user privacy, the Service implements the following technical measures. These are oriented toward "data minimization" and "on-device protection" rather than promising blanket security.

  • On-device storage: The offline pending-send queue (Outbox) and send history are encrypted on-device with AES-GCM-256 via Apple's native CryptoKit, and stored with file protection class completeFileProtectionUntilFirstUserAuthentication.
  • Key management: A 256-bit symmetric key is stored in Apple Keychain Services (kSecClassGenericPassword) with protection that allows access after the first unlock following a restart and prevents migration to another device. The app reads the key for encryption and decryption. Key copies included in backups are protected by a device-specific key and cannot be used on another device (Apple's explanation). Before changing devices, confirm that important memos have reached their destination, such as your mailbox or Obsidian vault.
  • Transport: API communication uses TLS (HTTPS). The memo-sending URLSessionConfiguration.ephemeral avoids persisting that session’s caches, cookies, and credentials to disk. This is separate from analytics storage and transmission, and from external SDK networking.
  • Email body handling: Memo bodies transit through our Relay API (Cloudflare Workers) and the external delivery infrastructure (Resend) for the sole purpose of sending email. We do not persistently store them on our infrastructure, and they are not written to logs (except in DEBUG builds during local development).
  • Email address storage on the server: Cloudflare D1 stores a mapping between send IDs and recipient email hashes derived from SHA-256. These delivery records are created regardless of reminder opt-in. Reminder contacts are managed through Resend's Contact API.
  • Dependencies on the data path: Memo body encryption (CryptoKit), key storage (Keychain Services), and network transport (URLSession / Network.framework) are all Apple-native — no third-party SDK sits in the data path.
  • Sign-in and abuse-prevention SDKs: Optional email auto-fill from a Google account uses GoogleSignIn-iOS and Firebase Authentication. Firebase App Check initializes at launch and uses Apple App Attest to protect backend API access.
  • First-party usage analytics: We send events to our /v1/analytics/event endpoint to understand usage and improve quality. Fields include a random installation identifier, session identifier, event type, event identifier and time, app version and build, language, and allowed attributes such as send outcomes. The payload is designed to exclude raw email addresses, memo text, and verification codes, but send IDs can link events to recipient email hashes.
  • AppsFlyer acquisition and usage analytics: We start the AppsFlyer SDK and send events for first successful memo send, successful verification, paywall views, plan selection, and successful purchases. Fields set by the app include purchase price, currency, subscription period, and the originating screen category where applicable. We set the same installation identifier used in first-party analytics as AppsFlyer’s Customer User ID, allowing acquisition and usage records to be linked. Event fields set by our app do not directly include email addresses, memo text, or verification codes. This describes fields explicitly set by the app, not an exhaustive list of technical information collected by the SDK. Identifiers and linkable records are not treated as fully anonymous information.

Note: The Service is not End-to-End Encrypted (E2EE). Memo bodies are delivered through standard SMTP so you (the recipient) can read them in your normal mail client. For workloads requiring true E2EE, consider purpose-built services such as Standard Notes, Signal, or ProtonMail.

These notes are restated as a route map for Obsidian users on the Privacy Architecture page.