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. Section 12 describes where the device identifier is stored and what happens to it after the app is deleted.

(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.

(E) Usage Analysis Choice in Supported App Versions

In app versions with a “Usage analytics” choice in Settings, the regular in-app usage-event stream and device-originated subscription-state analytics are off by default. These streams begin only when the user selects “Agree and turn on”; they do not begin if the user declines. This choice is separate from email reminder consent and Apple's device-level App Analytics sharing setting. Withdrawing it in the app stops new collection for these streams and attempts to remove their unsent events on that device. The app reports a cleanup failure when deletion cannot be confirmed, and events created under an earlier grant are not replayed after a later grant. An upload already in progress may complete, and withdrawal alone does not delete records already received by us. Measurement of action order and delivery outcomes in the internal Capture pilot is part of this same usage-analysis and quality-improvement purpose. Participation also requires a separate, scope- and time-bound pilot consent; this choice alone does not enroll anyone. Withdrawing this choice stops new pilot measurement. To erase pilot records already stored, use the pilot's participation-withdrawal and deletion control. App versions without this choice send the usage events described in Section 12 and the subscription observations described in (D) as part of app operation. We are removing the server restriction introduced on September 28, 2026 that prevented storage of requests using the original contract, and accept analytics requests from both types of app version. Previously uncollected events are not reconstructed. Versions that retain the choice continue to start or stop collection according to their in-app setting. AppsFlyer acquisition and usage measurement is described in Section 12.

This choice does not authorize AppsFlyer acquisition measurement. Versions with “App discovery measurement” start the SDK only with the separate choice in (F) and iPhone tracking permission. Usage-consent versions without that separate choice keep the SDK stopped. Section 12 describes the handling in app versions without this choice.

(F) Acquisition measurement in supported app versions

“App discovery measurement” is optional and off by default. Only when you agree to this choice and allow iPhone tracking, AppsFlyer receives app launches, acquisition source and campaign, advertising identifier, IP address, device model, OS and app version, and SDK identifiers to measure which download links lead to the app. We do not provide our first-party usage-analysis identifier as a Customer User ID. We do not send memo text, email addresses, purchase events or ordinary in-app usage events for this purpose. Sharing with advertising partners and advertising personalization are disabled, as are SKAdNetwork, IDFV and Apple Ads measurement in this path. Records containing identifiers are not treated as anonymous.

Declining preserves all app features. Withdrawal in Settings stops new measurement and removes local attribution evidence. An in-progress request may complete. Withdrawal does not erase data already received by AppsFlyer or change your iPhone tracking setting. This choice is independent of Usage analytics, email reminder consent and Apple's App Analytics sharing setting.

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.
  • If you have not enabled reminders, we may send one email asking whether you would like to receive them, once your email address is verified and you have not sent a memo for a while (roughly 72 hours after your last send). We send no reminders unless you choose to receive them.
  • 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. This installation identifier is stored in the device's Keychain. Because of how iOS works, Keychain items may remain on the device after the app is deleted; in that case, the same identifier is used again after reinstalling (the legacy AppsFlyer integration below also uses it as Customer User ID).
  • AppsFlyer acquisition and usage analytics: In app versions without the choice described in Section 1(E), 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. Usage-consent versions keep the SDK stopped; versions supporting (F) start acquisition measurement only after both its separate permission and iPhone tracking authorization.

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.

13. Analytics on our website

Our website (simplememofast.com) uses the following analytics to understand how its pages are used and to improve them. This is separate from the app (Service) usage data described above.

(A) Google Analytics (Google LLC, United States)

  • Google Analytics stores a random identifier for your browser in first-party cookies (such as _ga) to distinguish users and sessions.
  • It collects information such as the pages you view, the referring site, approximate location, browser and device type, and interactions on our pages (such as views and clicks of links to the App Store). Google states that Google Analytics 4 does not log or store IP addresses.
  • Google processes this information. See How Google uses information from sites or apps that use our services.
  • To opt out, use the Google Analytics Opt-out Browser Add-on or disable cookies in your browser settings.

(B) Ahrefs Web Analytics (Ahrefs Pte. Ltd., Singapore)

  • We use it to count page views. Ahrefs states that this tool does not use cookies and does not store raw IP addresses.

(C) AppsFlyer OneLink (AppsFlyer Ltd., Israel)

  • Some App Store buttons on our website (such as the top button on the Obsidian integration page) open the App Store through an AppsFlyer link (simplememofast.onelink.me). AppsFlyer records a click only when you press such a button. Viewing a page alone sends nothing to AppsFlyer.
  • AppsFlyer receives information such as your IP address, browser, OS and device type (user agent), the time, the link and campaign name, and the referring site (our domain only).
  • AppsFlyer matches the click with a later first launch of the app (measured by the AppsFlyer SDK described in Section 12) to count installs from these buttons.
  • We receive aggregated reports from AppsFlyer, such as click and install counts per link. Section 12 describes how the app handles the acquisition source category it receives.
  • See the AppsFlyer Services Privacy Policy for how AppsFlyer processes this information. AppsFlyer also offers an opt-out. If you prefer not to be recorded, use another App Store link on the page or search for the app in the App Store.