Privacy Policy

1. Scope and operator

Mokjang is operated by Dongha Yoon as an individual, primarily for church communities in the United States. This policy explains information handled for sign-in, group activities, posts, files, notifications, and support. The Korean and English versions describe the same practices.

Prayers, attendance, and photos may reveal sensitive information about religion, health, or family relationships. Check the intended audience and encryption limits below, and share only what is needed. Respect other people’s wishes and rights when posting their information or images.

2. Information and purposes

• Account and sign-in: We use the account identifier, email, name, profile photo supplied by Google, and login sessions to identify and authenticate members. Mokjang does not receive your Google password through this sign-in flow.
• Birthdays: We store an optional month and day, without a birth year. You and your current shepherd (목자) can edit it. You, your current shepherd (목자), assigned village leader (초원지기), and church pastors can view birthdays within their current responsibilities. Reminders are off by default; eligible recipients choose the times and groups and turn them on themselves. Your name, group, and month/day appear in app notifications and permitted device pushes. Pending deliveries and delivery history support retries and duplicate prevention. Administration or prayer-reader permission alone does not grant birthday access.
• Profiles and group administration: We use your chosen name and photo, registration and approval status, group and role, membership history, guest attendance records, and any withdrawal reason to manage access and group activities.
• Organization relationships: We use church, village and group affiliations, church pastor rosters, village pastor and village leader (초원지기) assignments, and role display titles for community administration. Server administrators manage organization relationships and appointments.
• Pastoral journals: Member account and guest identifiers, groups, record dates, authors, recipients, comment and addendum timestamps support retrieval and access control. Notes, prayers, comments, addenda and directly attached photos are encrypted on the user’s device before storage. Linked gallery originals use the server access controls described below and are not end-to-end encrypted. Imported historical opinions are distinguished from comments written by current assignees. Visitors and VIPs can be linked to an explicitly selected or created group guest profile. Guest names are visible to group members; journal content is never copied into guest notes. Linking an existing account does not grant that account journal access.
• Activity records: We use bulletins, notices, comments, prayers, attendance responses, poll votes, reactions, photos, videos, and metadata such as authors, timestamps, and recipients to provide these features. Section 4 explains which content is encrypted.
• Media: Uploaded originals, thumbnails, previews, captions, and capture dates may be stored. Original photos and videos may retain embedded metadata, including location; the app does not remove all metadata from originals.
• Notifications: We use device push endpoints and subscription keys, notification preferences, legacy per-post comment subscriptions, in-app notifications and read status, and prayer reminder settings to deliver notifications.
• Support and reports: We use the title, description, optional image, reporter identity, status, and administrator notes to investigate and respond. Do not include your recovery passphrase or unnecessary sensitive information.
• Administrator operating policies: Policy values, change times, and the administrator’s account identifier and name at the time are recorded for operational review and accountability and are visible to administrators.
• Encryption and operations: We store public keys, a private-key backup encrypted with your recovery passphrase, and related recovery metadata. The app and its providers may process access, error, and security logs, page visits, and device and performance statistics to operate and improve the Service.

3. Who can access information

Ordinary posts, comments, attendance, and media are available to members with access to the relevant group. Access depends on current membership, membership periods, role, and content type. Shepherds (목자) and co-leaders may have member and content management powers and access to a broader range of records. Co-leader, Mokbu and Moknyeo are display titles with identical permissions.

The Share button on a notice or bulletin creates a signed link that lets anyone with the link, including messaging preview services, see that post’s title. Reading its body, prayers or photos still requires sign-in and the original access rights. The app provides the title preview for up to 30 days and stops serving it from an older link when the title changes or the post is deleted. Previews already cached by external messaging services may not update or disappear immediately.

The operator manages access, roles, support, reports, and service issues. People with operational access can process plaintext server records and account and activity metadata. An “anonymous poll” hides voter names in ordinary result views; it does not remove the account association from stored votes.

Being a pastor or village leader (초원지기) does not grant access to a group’s entire bulletins, notices or photos. New prayers marked “Request intercession” are also shared with the group’s village leader (초원지기), all pastors in its church, and the prayer readers explicitly appointed for that church at creation. Administrators may appoint approved accounts without a group. Church or group membership alone does not make someone a prayer reader, and this appointment does not grant journal access. Each shepherd (목자) manages group membership, roles and community sharing. This division of responsibilities does not waive the operator’s legal privacy or security obligations. An administrator can set an assignment date to share intercession prayers from that date within the current church or meadow. This does not expand access to ordinary posts.

Saved private journal drafts are encrypted for their author alone. A shepherd (목자) may submit an entry before a village leader (초원지기) or pastor has registered, been assigned or set up encryption. Submission shares only with ready recipients. An assigned account without a key is recorded as the fixed pending target. Other member drafts remain private. These recipients can read existing records while their accounts remain active; replacements do not inherit access automatically. Only the original author can explicitly share with a reviewed pending target or fill a role that originally had no recipient. Assignment changes do not replace original recipients or fixed pending accounts. An existing or deleted-account recipient is never replaced; private drafts are excluded. Being a co-leader (including Mokbu or Moknyeo), the subject member or a server administrator does not grant journal access through the app. A former shepherd (목자) retains their own earlier records and drafts after a role change. Metadata such as dates, member identifiers, linked bulletin, saved revision and publication status is processed on the server separately from encrypted content.

Weekly sheet imports read files on the device and encrypt private drafts with the account matches reviewed by the user. Historical records are shared only after explicit publication, with the recipients shown then. External photo links do not import the photos themselves; the original Google Sheet and its sharing settings remain unchanged. Bulletin references use attendance responses and account-linked bulletin prayers already accessible to the shepherd (목자), and never import private one-to-one prayers.

Profile images and report attachments stored at public URLs can be opened by anyone who has the URL. Authorized viewers may download or capture group media, and issued temporary file links may remain usable until they expire. The Service cannot recall copies already obtained.

4. Prayer and journal encryption and recipients

Titles and contents newly written using encryption on the Prayer Requests screen are encrypted on your device before storage. The bulletin prayer section, records copied from it, and older plaintext prayers are outside this end-to-end encryption feature. Each bulletin prayer can be shared with “Request intercession” or “Group only.” Only items using the first scope are visible on the prayer screen to the village leader (초원지기), church pastors and designated prayer readers included at creation or additionally authorized by an assignment date; this grants no access to the full bulletin. Older private plaintext prayers are shown only to their author but remain plaintext on the server.

Journals encrypt notes, prayers, imported opinions and explicitly mapped source meeting details, roles and attendance together. Directly attached weekly photos, new comments and addenda are encrypted separately. Submitted originals cannot be edited; their original author can append separate corrections or updates. Posted addenda also cannot be edited. Direct attachments preserve the selected file bytes inside ciphertext and are not uploaded to the ordinary gallery. Files exceeding processing limits are rejected instead of resized; existing resized encrypted photos are retained. Private drafts contain a content-key envelope for their author alone; submission adds envelopes only for ready recipients. One person holding multiple roles is treated as one account. Prayers and journals share encryption keys and a recovery passphrase, and both have the public-key and device trust limitations described below.

Member prayer references separately enforce each prayer’s existing scope, original recipients and membership rules; they are not automatically copied into the journal. New gallery selections reference stable original photo identifiers without creating another file. Linked originals and previews are not end-to-end encrypted: the server checks journal access and the exact photo link on each request. Existing encrypted copies are not automatically converted or deleted. Weekly photo links are fixed after the first member submission. Later recipients receive access only after explicit sharing completes, without access to the rest of the gallery. Submitted village leader (초원지기) and pastor comments are immutable; only the author of a comment may append a separate correction or update.

New prayers default to “Request intercession”: approved current group members, the group’s village leader (초원지기), all pastors in its church and designated church prayer readers at creation. The composer shows the additional readers, and a changed list must be reviewed before saving. “Group only” includes approved current members alone. For “1:1 with shepherd (목자),” a member shares with the current shepherd (목자) and themselves; a shepherd (목자) shares with one selected current member and themselves. Saving stops if a required encryption recipient key is unavailable.

A saved prayer’s scope and original recipients do not change when its text is edited or appointments change. Existing records are not automatically expanded to include pastoral teams. Access as a group member still requires current membership and the applicable membership periods. The original village leader (초원지기), pastors and designated prayer readers retain access to that prayer while their accounts are approved; successors do not inherit it automatically. An administrator may additionally share intercession prayers on and after a chosen assignment date within the current church or meadow. Ordinary members’ group and intercession prayer access follows the group membership periods managed by the shepherd (목자); there is no separate member prayer assignment date. The administrator’s external assignment setting does not change one-to-one recipients or members’ group membership periods. Leaving or changing roles cannot recall copies already received.

For encrypted prayer history, an existing recipient’s unlocked device adds a key for the new reader. The original content and existing recipients’ keys remain unchanged; decrypted content and private keys are not sent to the server. Access is pending until this connection completes. The operator cannot recover it if the existing keys are unavailable. Additional prayer access continues to require the current assignment and date for external appointees, or current membership and the applicable group membership periods for ordinary members. Once an originally empty journal role is connected, it remains a recipient of that record and is not replaced by another assignee.

Unlike encrypted content, metadata such as author, group, timestamps, recipient identifiers, sharing mode, and answered status is processed by the server. Administrator status alone does not provide an automatic decryption feature. However, this design trusts the app code and public-key directory supplied by the Service; it does not provide independent recipient key-fingerprint verification. It cannot prevent disclosure through a compromised device or app, or a recipient who shares the content again.

5. Recovery passphrase and device keys

Your recovery passphrase itself is not sent to the server. A copy of your private key encrypted with that passphrase is stored on the server for recovery on another device. This does not mean that no private-key-related material exists on the server.

“Lock prayers and journals” in Settings removes this account’s shared prayer and journal key from the current tab and remembered device storage. It also notifies open tabs in the same browser to lock and close opened content and unsaved input. Successfully saved encrypted drafts can be reopened with the same key. Closing after a failed save or while offline may lose unsaved input. The journal screen also closes opened content when it detects sign-out or an account change. Downloaded copies and screenshots cannot be erased.

Newly set up or unlocked keys stay in the current app’s memory by default, so refresh or closing requires the recovery passphrase again. Choosing “Remember on this trusted device” also stores the key in browser device storage. Keys already saved by older versions may remain, too. Remembered keys survive sign-out, so do not use that option on a shared device. After locking, use your recovery passphrase on the prayer or journal page to reopen your records. A browser may block messages between tabs, or an older app version may still be open, so close other tabs after using a shared device too. This action or clearing browser data is separate from deleting server ciphertext or its encrypted key backup.

If you lose access to every usable private key and your recovery passphrase, the operator cannot recover earlier ciphertext for you. Replacing an existing key with a new one does not restore old content, and the Service does not provide that overwrite as a recovery option. Keep usable devices and your recovery passphrase safe.

6. Providers and processing locations

The Service uses the providers below. Depending on enabled features and deployment settings, information may be processed outside your country of residence. Provider locations and retention settings differ; this document does not guarantee storage within a particular country. Contact the operator for information about the relevant configuration.

• Google: Account sign-in and profile information. Google’s own privacy policy applies to use of your Google account.
• Supabase: Login sessions and accounts, database, file storage, and realtime features.
• Vercel: App hosting, request processing, and operational logs. When Web Analytics and Speed Insights are enabled for a deployment, page URLs, referrers, device and browser information, approximate region, and page performance may be processed for statistics.
• Cloudflare R2: Storage and delivery of photos, videos, and other media when R2 storage is enabled.
• Browser and operating-system push providers, such as Google, Apple, and Mozilla: Relay notifications using device subscriptions.

7. Browser storage and notification choices

The browser may store login cookies, language and display settings, device notification choices, and installation or help status. Section 5 describes device-key storage. Blocking necessary login cookies or clearing site data may require you to sign in and unlock your key again.

Push delivery depends on browser permission and device and account settings. Comment alerts are on by default. Choose All, Mentions only or Off in account settings. Off stops new comment notifications and push alerts, including mentions. Existing explicit opt-outs are preserved; past notification records are not automatically deleted. Legacy per-post subscriptions do not change the personal scope.

Notification titles and messages may appear on a device lock screen. Encrypted prayer content is not included in prayer-post notifications, but other notifications, such as ordinary comments or notices, may include titles or excerpts.

Saving a journal draft sends no notification. Submission, later-sharing, addendum and new-comment notifications omit member names, journal content, prayer requests and photos. All of these in-app and push alerts follow the pastoral journal notification setting, independently of ordinary comment alerts. Existing notification history remains. Encrypted journal comments do not support mention alerts. Event types, recipient accounts, record identifiers and delivery status are stored on the server for retries. Notifications may be delayed or duplicated.

Storage monitoring records provider byte usage, measurement times and file-count, type and usage summaries by church and group. It does not decrypt notes, prayers or comments; summaries are visible to administrators. Unavailable and estimated values are identified, and projected capacity dates are not guarantees. The Service does not sell personal information or share it for cross-context behavioral advertising. A DNT (Do Not Track) signal alone does not separately switch the app’s logging or analytics features. A provider’s statement that its analytics do not use cookies is separate from the app’s use of login cookies.

8. Retention, withdrawal requests, and deletion limits

Account and preference data supports account operation and may remain until withdrawal is actually processed. Community posts and media currently have no universal automatic expiry period. They may be retained while needed to provide the Service or for a lawful retention purpose. The absence of automatic expiry is not itself a legal basis for indefinite retention; deletion requests and the necessary retention scope are reviewed individually.

“Request Withdrawal” in settings sends a request for administrator processing. Submitting it does not immediately delete the account, and you can cancel before processing. After account deletion succeeds, the account and profile and linked records such as comments, attendance, and push subscriptions are deleted. Some community records, including bulletins, notices, prayers, and photos, may remain with the account association removed.

Administrator policy history has no automatic expiry. The account identifier, name at the time, policy values, and change time remain after the administrator’s account is deleted. Ordinary administration screens cannot edit or delete this history; contact the operator about a separate deletion request.

Removing an author association does not guarantee that the content is anonymous. Names in text, people in photos, quotations, attachments, or identifiers in ciphertext may still identify someone. Account deletion also does not immediately erase uploaded files, every copy, or server backups. Ordinary deletion of journal-linked photos and their albums is blocked to protect connected records. Links can be removed from unsubmitted drafts. The operator reviews requests affecting submitted records and their connections in light of applicable obligations; a technical deletion restriction is not a basis for refusing a lawful deletion request. If you want specific content or attachments deleted, identify those items when contacting the operator.

Provider logs, backups, and file storage may follow separate retention and deletion processes. Deleting an account or an item from the app does not erase all of these records at the same moment. Remaining data and reasons for retention are checked when a request is handled; applicable legal retention and deletion duties still apply. The Service cannot delete copies that other users downloaded or stored separately.

9. Requests and rights

Use the available app controls to edit your profile, change notifications, manage your own posts, and request withdrawal. For other access, correction, deletion, copy, or restriction requests, email the contact below. Provide only what is needed to identify the account and relevant records; do not send passwords or your recovery passphrase.

We will check your identity or authority to act and the rights of others, and explain the scope and handling of the request. Additional rights and deadlines may apply under the laws relevant to your location and the Service. This policy does not limit those rights or your ability to contact a supervisory authority.

10. Children, safeguards, and changes

The Service is not directed to children under 13. It does not provide automated age verification or a parental-consent collection process. Contact the operator if you believe a child’s account or personal information is involved. We will review parental requests and applicable law to determine necessary steps such as restrictions or deletion.

The Service uses access checks, protection in transit, and encryption for the prayers described above, but does not guarantee prevention of every disclosure or failure. Protect your account and device and avoid sharing unnecessary sensitive information.

When features or data practices change, this policy will be revised and its update date displayed. Additional notice or consent may be required under applicable law.

11. Contact

Operator: Dongha Yoon

Email: cs.donghayoon@gmail.com