Privacy Policy

1. Introduction and Scope

Coptic Leader (the "Service") is a ministry-coordination application created, owned, and operated by St. Mark Coptic Orthodox Church of Washington, D.C. (the "Church," "we," "us," or "our"). The Service is a ministry of the Church. It is not operated by a separate business entity, no such entity has been formed for it, and the Church is accountable for its operation.

This Privacy Policy (this "Policy") describes the categories of personal information the Service collects, the purposes for which that information is processed, the parties to whom it is disclosed, the safeguards applied to protect it, and the rights available to the individuals to whom it relates. This Policy applies to the Service in each form in which it is made available, including the iOS application, the Android application, and the associated web properties.

This Policy does not apply to the independent practices of any third party, including the identity providers identified in Section 6, whose own policies govern their handling of information they collect directly from you.

2. Definitions

The following terms have the meanings set out below.

• "Authorized User" means an adult volunteer or leader to whom a Coordinator has issued an account for the purpose of serving in a ministry.
• "Child Record" means information concerning a minor served by a ministry, entered into the Service by an Authorized User.
• "Coordinator" means an Authorized User who holds administrative responsibility for a ministry, including responsibility for creating and deactivating accounts.
• "Personal Information" means information that identifies, relates to, describes, or is reasonably capable of being associated with an identified or identifiable individual.
• "Service Provider" means a third party engaged to process Personal Information on our behalf, on our instructions, and for no purpose other than performing the service we have requested of it.

3. Persons Covered by This Policy

The Service is used exclusively by adults. Children do not hold accounts, do not sign in, and do not otherwise interact with the Service. Information concerning children is entered into the Service by Authorized Users acting on behalf of their ministry, as described in Section 7.

Each church that uses the Service determines what information is collected concerning its own community and the purposes for which that information is used. At present, the Church is both the sole church using the Service and the operator of the Service, and therefore holds both roles concurrently. Section 8 describes that allocation of responsibility and the circumstances in which it would change.

4. Information We Collect

4.1 Account information concerning Authorized Users. We collect the following categories of Personal Information in connection with an Authorized User account: name; email address; mobile telephone number; residential address; date of birth; ministry role and class assignment; the sign-in methods linked to the account; device push-notification tokens; and authentication records comprising the time of each sign-in, a device label, and a truncated network address.

4.2 Ministry information concerning children. A Child Record may contain the following categories of Personal Information: name; date of birth; grade or class; sex; photograph and the status of any photograph permission; allergies and medical notes; general notes; residential address; the child's own telephone number where the ministry records one; and the name, relationship, and contact details of each parent or guardian.

4.3 Content and activity records. The Service stores the records created by Authorized Users in the ordinary course of ministry administration, including messages and their attachments, attendance records, lesson assignments and lesson materials, outreach logs, event responses, polls, transportation plans, and comparable records.

4.4 Technical information. We collect the device type and application version, application log data, and the technical information required to deliver push notifications to a registered device.

4.5 Sources of information. Personal Information is obtained from three sources: directly from the Authorized User to whom it relates; from Authorized Users acting on behalf of their ministry, in the case of a Child Record; and from Apple or Google, in the form of a verified identity assertion, where an Authorized User elects to sign in using one of those providers.

4.6 Categories we do not collect. We do not collect biometric identifiers, government-issued identification numbers, or financial account or payment-card information. The Service contains no advertising software, no attribution software, and no behavioral-analytics software.

5. Purposes of Processing

We process Personal Information for the following purposes, and for no other purpose without providing notice:

1. to authenticate Authorized Users and to establish and maintain their accounts;
2. to operate the ministry-coordination functions of the Service, including scheduling, attendance, lesson administration, messaging, outreach, and transportation coordination;
3. to deliver service communications, reminders, and notifications;
4. to maintain the security, availability, and integrity of the Service, and to detect, investigate, and prevent misuse; and
5. to comply with applicable law and to respond to lawful requests from public authorities.

We do not use Personal Information to train machine-learning models, and we grant no third party the right to do so.

6. Disclosure of Information

6.1 Service Providers. We disclose Personal Information to the Service Providers identified below, each of which is engaged under terms requiring it to protect the information disclosed to it and to process that information solely for the purpose of providing its service to us. No Service Provider is authorized to use Personal Information for its own purposes.

• Supabase — database and file storage. Receives all stored records. Information is transmitted over TLS 1.2 or higher and is encrypted at rest, together with backups and replication streams, using AES-256 under keys the provider manages. The fields identified in Section 9.2 carry an additional layer of AES-256-GCM encryption applied by the Service before transmission, under a key the provider does not hold.
• Vercel — application hosting. Receives request traffic in transit over TLS and retains no copy of ministry records.
• Apple (Apple Push Notification service) and Google (Firebase Cloud Messaging) — delivery of push notifications. Each receives a device token and the text of the notification, transmitted over TLS. Notification text is kept brief and non-sensitive as a matter of design.
• Apple and Google — verification of identity, and only where an Authorized User elects to sign in using one of those providers. Each receives an identity token, transmitted over TLS, whose signature we verify against the provider's published keys.
• Resend — delivery of one-time sign-in codes by email. Receives the recipient email address and the code, transmitted over TLS. We retain the code only in the one-way hashed form described in Section 9.3.
• Sentry — diagnostic and error reporting. Receives filtered diagnostic data only, as described in Section 6.3.
• United States Census Bureau — conversion of a street address into map coordinates, as described in Section 6.2. Receives a street address alone, transmitted over HTTPS.

6.2 Address geocoding. The transportation feature of the Service plots pickup locations on a map, which requires converting a street address into geographic coordinates. That conversion is performed by a single provider: the public geocoding service of the United States Census Bureau, a service of the federal government that operates without an account relationship and retains no profile associated with us.

Two properties govern this disclosure. First, the address is transmitted alone: no name, date of birth, class, record identifier, or other field accompanies it, and the provider receives no information that would permit it to determine to whom the address relates. Second, we do not authorize the provider to retain, reuse, sell, or disclose a submitted address, or to use it to improve its own products; we store only the coordinates returned.

No other provider performs this lookup. Where the Census service is unable to match an address, or does not respond, no address is submitted onward to any other party; the record is simply listed to a Coordinator as lacking coordinates.

6.3 Diagnostic and error reporting. Diagnostic reports are filtered before transmission. Request bodies, cookies, headers, and address parameters are removed, and a report is discarded in its entirety, rather than redacted, where the underlying error arises on any part of the Service that handles Child Records, parent or guardian contact details, or photographs. Screenshot capture, session replay, and interface-hierarchy capture are disabled on all platforms. A report identifies an Authorized User by an internal numeric identifier and a ministry, and never by name.

6.4 Legal and safety disclosures. We may disclose Personal Information where we determine in good faith that disclosure is required by law, is necessary to comply with legal process, or is necessary to protect the safety of any person. In the event of a transfer of the operation of the Service to a different operator, we would notify the affected church before its information is transferred.

6.5 No sale and no advertising. We do not sell Personal Information, and we do not share Personal Information for cross-context behavioral advertising, as those terms are commonly defined under United States privacy legislation. We have not sold or shared Personal Information for such purposes at any time, and we do not permit any Service Provider to do so.

6.6 No artificial-intelligence or machine-learning processing. No message, ministry record, or photograph held in the Service is transmitted to any artificial-intelligence or machine-learning provider. The Service contains no functionality capable of making such a transmission. This position is stated affirmatively rather than by omission: were such a capability to be introduced in future, this Policy would be revised to disclose it before that capability were made available.

7. Children's Information

The Service is designed for use by adults. A Child Record is created and maintained by an Authorized User who attests, at the time of enrollment, that the ministry holds the authority and any parental or guardian consents required to enter that information.

We apply the following safeguards to Child Records irrespective of whether a particular children's-privacy statute applies to a given church:

1. Minimization. Only information the ministry requires for its purposes is collected.
2. No advertising and no sale. Child Records are never used for advertising and are never sold or shared for advertising purposes.
3. No artificial-intelligence processing. No Child Record is transmitted to any artificial-intelligence or machine-learning provider, as stated in Section 6.6.
4. Retention limits. Child Records are retained in accordance with Section 10 and are not retained indefinitely.
5. Least visibility. An Authorized User has access to the children in the classes to which that user is assigned, and not to the ministry's full roster. A child who has not been placed in a class is visible to Coordinators only.
6. Field-level encryption. The categories identified in Section 9.2 are individually encrypted by the Service.

A parent or guardian may request access to, correction of, or deletion of information concerning their child by contacting the church that controls that information. We assist the church in responding to such requests.

8. Allocation of Responsibility

Each church that uses the Service determines what information is collected concerning its community and for what purposes, and is accordingly responsible for that information as its controller. The operator of the Service holds and processes that information on the church's instructions, in the role of a processor or service provider.

At present those two roles are held by the same body. St. Mark Coptic Orthodox Church of Washington, D.C. both operates the Service and is the only church using it, and is therefore simultaneously the controller of the information and the operator of the software. The roles are described separately because they carry distinct obligations, and because the distinction becomes operative upon the admission of any further church: that church would control the information concerning its own community, and the Church would hold and process that information only on that church's instructions and under a written data-processing agreement.

This Policy describes the practices of the operator of the Service. The notices and policies of a particular church may also apply to that church's community.

9. Information Security

We maintain administrative, technical, and organizational measures designed to protect Personal Information against unauthorized access, disclosure, alteration, and destruction. Because the Service holds information concerning minors, those measures are applied in layers, such that the failure of any single measure does not by itself result in disclosure. The principal measures in place are described below.

9.1 Encryption in transit. All traffic between client devices and our servers is encrypted using HTTPS with TLS 1.2 or higher. Neither mobile application permits a fallback to unencrypted HTTP: on iOS, App Transport Security remains at its secure default and no arbitrary-loads exception is declared; on Android, cleartext traffic remains disabled for the software development kit level the application targets and no network-security exception is configured. Connections between our application servers and our database are likewise encrypted using TLS. Web responses are served with HTTP Strict Transport Security set to a maximum age of two years and applied to subdomains, together with a Content Security Policy, MIME-type sniffing protection, and framing protection.

9.2 Encryption at rest. Stored information is protected by two independent layers of encryption.

The first layer is applied by our database provider, which encrypts all stored data, backups, and replication streams using AES-256 under keys that it manages.

The second layer is applied by the Service itself, before information is written to the database, and remains effective if the first layer is compromised. Its properties are as follows:

• Algorithm and mode: AES in Galois/Counter Mode, an authenticated encryption mode.
• Key length: 256 bits. A key of any other length is rejected at startup.
• Initialization vector: 96 bits, drawn from a cryptographically secure random source for each individual value and never reused.
• Authentication tag: 128 bits, verified on every read. Altered or truncated ciphertext fails verification and is rejected rather than decrypted into incorrect plaintext.
• Stored format: a version marker followed by the initialization vector, ciphertext, and authentication tag. The version marker permits a future change of key or algorithm without rendering stored values unreadable.
• Key custody: the key is held only in our hosting provider's encrypted environment store and is supplied to the application at run time. It is not held in the database, in any backup of the database, in source control, or by our database provider.

Because the initialization vector is generated independently for each value, two identical values — for example, the address of two siblings — are stored as unrelated ciphertexts, and no information may be inferred by comparing stored values to one another.

The following categories are encrypted in this second layer:

1. each child's name (first and last), date of birth, residential address, and telephone number;
2. each parent and guardian record in its entirety, comprising name, telephone number, email address, and notes; and
3. each Authorized User's date of birth and residential address.

Accordingly, a copy of the database obtained without the corresponding key, an over-broad query, a compromised administrative credential, or a misconfigured access policy yields ciphertext for those categories rather than readable values.

An Authorized User's own email address and telephone number are deliberately excluded from the second layer. Both are used as sign-in and lookup identifiers and are matched by equality and by pattern; a ciphertext generated under a per-value random initialization vector can match neither, and encrypting those fields would render the Service inaccessible to every user. Both remain protected by the first layer, by role-based access control, and by database row-level security.

9.3 Authentication and account protection. The Service maintains no passwords and no personal identification numbers, and accordingly holds no such credential capable of being stolen, reused, or obtained by phishing. One-time sign-in codes are stored solely as one-way cryptographic hashes; the transmitted code is never persisted, and the stored value cannot be reversed into a usable credential by any party, including the operator. Codes expire after ten minutes and are subject to a limited number of verification attempts. Failed attempts are rate-limited both per account and per network address, with lockout periods that increase with each additional group of failures. Where an Authorized User signs in using Apple or Google, that sign-in inherits whatever multi-factor protection the user has enabled with that provider. A mobile telephone number recorded in the Service is ministry contact information only; it is not a credential and cannot be used to sign in.

Accounts are created by a Coordinator. There is no public registration, and an unrecognized email address is directed to contact a Coordinator without being informed whether an account associated with that address exists.

9.4 Session management. Sessions may be revoked, and revocation takes effect across every device. Signing out, deactivating an account, or deleting an account invalidates all existing sessions, and a revoked session cannot be renewed by a token refresh. On mobile devices, an Authorized User may additionally require biometric authentication or the device passcode upon each launch of the application.

9.5 Access control. Access to information is restricted by ministry role and by class or group assignment. Authorization is enforced on our servers for every request and is enforced independently at the database layer through row-level security policies. Photographs and file attachments are authorized individually upon each request against the requesting user's own access rights, and are not merely concealed within the interface. All files are held in private storage with no publicly accessible address, and the access links generated by the Service are of limited duration.

9.6 Separation between ministries. The rosters, messages, calendars, and records of each ministry are isolated from those of every other ministry. That isolation is verified by an automated test suite that authenticates as a member of each ministry and confirms that no record belonging to another ministry is reachable.

9.7 Logging, monitoring, and audit. Privileged and administrative actions are recorded in an audit log. Authentication events are recorded with the network address truncated, so that the identifying portion is discarded. Anomalous patterns of failed sign-in attempts generate automatic alerts to the operator.

9.8 Secure development and maintenance. Source repositories are private. Third-party dependencies are scanned automatically for known vulnerabilities and are updated accordingly. Keys and secrets are held in managed secret stores and are not committed to source control. Every change is required to pass an automated verification suite before release, including tests written specifically to detect the reintroduction of previously identified data-isolation defects. The database is backed up daily.

9.9 No guarantee of absolute security. No method of transmission over the internet, and no method of electronic storage, is completely secure. While we apply the measures described above, we cannot and do not guarantee absolute security. In the event that we become aware of a breach of security affecting Personal Information, we will notify the affected church and the affected individuals as and to the extent required by applicable law.

10. Retention of Information

We retain Personal Information for so long as is necessary to provide the Service and to fulfil the purposes described in Section 5, after which it is deleted or anonymized.

Where an Authorized User ceases to serve, the account is deactivated, all sessions are revoked across every device, and any linked sign-in identities are removed, so that the account cannot subsequently be reached through a previously linked identity provider. Where a church ceases to use the Service, the information concerning its community is deleted or returned in accordance with our agreement with that church. We may retain information for a longer period where retention is required by applicable law.

11. Your Rights and Choices

Depending upon your place of residence, you may have the right to request access to, correction of, deletion of, or a portable copy of the Personal Information we hold concerning you, and to request that we limit certain processing. You may exercise those rights as follows:

1. by deleting your account from within the application, using the option provided on the profile screen; or
2. by submitting a request to the address given in Section 14, which we will action within the period required by applicable law.

Name and email address are not self-editable. Each identifies an Authorized User both to the ministry and to the authentication system. Changes to either are made by a Coordinator and are recorded in the audit log. This is an integrity control and not a limitation upon the right of correction; a request to correct either field is honored through that route.

Because each church controls the information concerning its own community, certain requests are fulfilled by, or in coordination with, your church. We will not discriminate against any individual for exercising a right described in this Section.

12. Geographic Scope

The Service is intended for use within the United States and is offered on that basis. This Policy does not describe rights or obligations arising under the laws of other jurisdictions. Should the Service be made available to a church outside the United States, this Policy will be revised before that church is admitted.

13. Changes to This Policy

We may revise this Policy from time to time. Where we do so, we will post the revised Policy with an updated Effective Date. Where a revision materially affects the manner in which we handle Personal Information, we will additionally require that you review and accept the revised Policy upon your next use of the application.

14. How to Contact Us

Questions, requests, and complaints concerning this Policy or the handling of Personal Information may be directed to your ministry Coordinator or to the Church:

St. Mark Coptic Orthodox Church of Washington, D.C.
Attention: Coptic Leader — Privacy
11911 Braddock Road
Fairfax, Virginia 22031
copticleader@stmarkdc.org