Privacy notice

Version 2026-10-20-remembered-browser-v1 · October 20, 2026

IhsanBaraka is Al-Ihsan’s staff finance application. This notice describes the staff finance service operated for the community education centre in British Columbia, Canada. Hanna Meyer is the privacy lead and monitors the finance privacy mailbox. Privacy questions go to finances@ihsan.ca.

What the app handles

• Staff accounts: usernames, any configured profile details, password hashes, roles, active status and sign-in records. Passwords are checked by Django and are not stored as plain text.
• Two-step verification: encrypted authenticator setup secrets, hashes of single-use recovery codes, per-account verification attempt counters, factor versions and security events. A short-lived server session holds an encrypted setup key during enrollment. Recovery codes are shown once and are not retained as readable codes. QR codes are generated locally; the app does not send them to Microsoft, Google or a QR service. Your chosen authenticator app may have its own device or cloud-sync settings.
• Remembered personal browsers (optional): after successful MFA, you may explicitly choose “Remember this device for 30 days.” A random opaque token is kept in a Secure, HttpOnly, SameSite browser cookie; the server keeps only its hash, account/security binding, coarse browser label, creation/last-used/expiry dates and revocation state. No password or authenticator secret goes into browser storage, and no device fingerprint authenticates you. You still sign in normally with Google or your assigned password. Trust expires 30 days after creation without automatic extension. Expired or revoked trust cannot authenticate; minimal security metadata follows the existing authentication review process rather than optional analytics retention. Forget this browser or all remembered browsers in Account security. Normal sign-out ends the session but retains an explicitly remembered browser; account/access or security changes invalidate its trust. Security changes and new bot consent still need fresh MFA. Remembering a browser does not enable optional diagnostics.
• Financial work: organization settings, accounts, funds, journal descriptions, amounts, dates, draft revisions, staff attribution and reversals. Annual reporting also stores category mappings, description rules, reviewed line classifications, report notes, issued versions and saved figures, with staff attribution.
• Statement imports: original CSV and RBC monthly PDF bytes, source checksums, parsed rows, statement controls, cheque serials and image-page references, staff attribution and links to journals. Original PDFs may contain account details, cheque images, signatures, handwritten payee names or memos. Authorized statement-import staff can download these files; the app does not confirm handwriting. Source originals are stored privately in the database and included in protected backups, and are not returned through the read-only Grok connection. A file may contain personal details even when its name does not.
• Audit records: financial and setup changes, exports, sign-in/sign-out, and command-line account changes. History can include descriptions, staff IDs and correction reasons.
• Necessary technical data: session/CSRF cookies, temporary notification cookies, request information, sign-in attempt counters and per-staff report-operation counters. Report counters store the staff account, fixed operation type, window start and attempt count; they do not store financial text or connection IPs. The sign-in counter stores a keyed hash of the connection IP, a window start and attempt count; that hash is not anonymous data.

These records support access control, bookkeeping, source verification, corrections, reporting, security and recovery. Staff supply the records; there are no bank feeds. Tuition balances require a staff-confirmed obligation, verified opening credits and complete reviewed payment evidence. Unknown amounts remain unresolved. Official tax receipt issuance, payroll execution, payment initiation and a parent/learner portal are not implemented.

Payment reporting and enrollment reconciliation

When configured by Al-Ihsan, the app reads PayPal transaction reports and Stripe balance, payment, refund and dispute reports, and accepts provider CSV evidence. It stores allowlisted source identifiers, dates, statuses, currencies, exact gross/fee/net amounts, descriptions, payer names/emails, reference hints, source observations and staff review decisions. Original uploaded CSVs may contain optional exporter fields; download only needed columns. Refund/dispute case records are distinguished from cash movements, and transfers remain separate from course income. Credentials stay in protected operator/provider secret files and are excluded from portable financial backups. The app does not initiate charges, refunds, transfers, payroll or payouts.

A dedicated read-only connection can retrieve selected identity/program/cohort/email/status columns from the existing Al-Ihsan Course Enrollments Google Sheet, using a service account shared only to that spreadsheet. Notes are read transiently only to detect explicit synthetic-record markers and are not returned or stored. Results are transient; historical payment allocations store external enrollment/student IDs, program/cohort, source fingerprints and staff decisions. The app does not replicate the enrollment roster or write the spreadsheet. Google sign-in credentials are separate. The obsolete LMS enrollment lookup remains disabled. Finance decisions may additionally store an approved tuition amount, discount evidence reference, billable period, opening credit, coverage attestation and reviewer. A reviewed individual iComp plan records original registration date, upfront or four-month choice, dated instalments and separately reviewed payment/refund attribution. Dates, credits and payment status remain unresolved until required evidence is recorded. These are accounting references, not a second enrollment roster or issued invoices. These do not replace the enrollment master. Full balances remain unavailable until the required evidence is confirmed. A separately authorized read-only LMS finance connection displays finance projections only through verified student bindings. It does not copy the enrollment master or permit financial writes. Missing or unreviewed balances remain unavailable; the obsolete enrollment lookup stays disabled.

An optional signed handoff can stage limited Interac deposit-confirmation evidence from finances@ihsan.ca: immutable message/reference IDs, a message checksum, reported date/type/status/currency/amount and necessary payer/reference hints. The existing v1 review endpoint does not accept raw email bodies or attachments. A separately activated v2 original-evidence endpoint can receive a bounded original Gmail RAW result, independently verify supported Interac DKIM or trusted direct Google ARC evidence, and parse the completed RBC deposit and exact enrollment reference. The original is processed transiently; Baraka stores its hash, fixed verification method, normalized receipt and review trail, not raw message bytes. The protected original stays in the existing mailbox/producer evidence store. A shared-bot signature or verified flag alone never establishes bank proof. Original evidence remains in the producer's restricted mailbox/storage. A signature alone cannot verify funds: intact bank evidence, accounting review and explicit student matching are required before allocation. The actual Finances Bot producer runs manually in Grok’s shared account runtime, with original email evidence and a separate signing key retained there. Signed delivery and duplicate-safe retries have been verified. Other bots sharing that account/runtime may use its staging identity; Its existing identity submits evidence; it cannot directly allocate payments or post journals. When separately activated under a reviewed category policy, Baraka itself can apply independently verified exact-reference iComp principal to a current approved obligation with reconciled coverage/opening credits. Unknown identities, stale evidence, overpayments, unsupported/refund notices and PTIS remain held. Fees/net are separate and never invented. A protected daily allocation/exception report is available to finance reviewers; The prepared dedicated finances@ Gmail reader/sender stays off until separate OAuth consent and hosted installation. Its read-only/send scopes technically permit mailbox-wide reading and sending; code narrows intake to recent supported Interac originals and sends only a generic daily protected-report link from finances@ to Hanna at hmeyer@ihsan.ca. It does not mark/delete messages or send student communications. Unknown sends are not automatically repeated; exact Sent Message-ID metadata can be reconciled. Earlier bank-mail backfill and other mail purposes are not activated. Existing unresolved deposits remain unverified/unmatched unless the required original or statement evidence and exact enrollment review are completed. Preparing this code does not activate original uploads or automatic matching.

PayPal and Stripe reporting are deployed, with history retrieved from January 1, 2026. Stripe’s actual API/report samples agree. The September PayPal sample retains a genuine source-status discrepancy; a separate October actual-report comparison passes. The dedicated Sheet reader and manual deposit producer are active. Both Stripe and PayPal retrieval run daily on Render at 14:17 UTC, with recent-history refreshes and rolling historical sweeps. A real run and a controlled failure were verified; failure notices are delivered to the Render administrator mailbox, media@ihsan.ca. Review-queue email notices are separate. Optional Hanna review emails contain only a generic notice and private queue link; email delivery has not been configured. PayPal, Stripe, Google and any approved mailbox/email provider process the limited information needed under their own terms and locations.

Feedback and optional usage information

Optional diagnostics are off until an explicit, separately saved opt-in. They contain fixed feature names, broad outcomes, duration ranges and counts linked to your staff account, not anonymous data. No typed content, financial details, URLs or raw errors are included. Declining or withdrawing in Usage & feedback leaves bookkeeping and feedback available. Each diagnostic bucket and user feedback report expires after exactly 180 days from creation; updates do not extend expiry. App reads exclude expired rows; daily operations remove them in bounded batches. Historical buckets without timestamps use a conservative recorded-day expiry. Minimal anti-replay receipts, consent/security audits and business records remain separate. Feedback is visible to its author and assigned reviewers. See usage and feedback privacy for exact fields, cleanup, choices and backup limitations.

Before sign-in and browser storage

The server receives connection and HTTP request information when you open a page, before you sign in or accept anything. The sign-in form uses a CSRF cookie to prevent forged requests. Google or assigned-password verification starts a session for the ten-minute authenticator setup or verification step. A fully signed-in session is granted only after authenticator or recovery-code verification; the fictional local sample is exempt. Temporary notices may use a cookie or the server session. These are necessary service functions. There is no advertising tracking. Optional privacy-filtered usage collection can be controlled in Usage & feedback.

Sessions are configured for a one-hour server lifetime and browser-session cookies. Browser restore features can retain session cookies; use Sign out on shared devices. Sign-out invalidates the current session but does not delete your records, audit history or downloads. Expired database session rows are not automatically purged. The CSRF cookie may remain for about a year. No financial records are intentionally stored in localStorage, IndexedDB or an offline service worker.

Google sign-in

You can use your approved Al-Ihsan Google account instead of an assigned IhsanBaraka password. The active Google sign-in uses a dedicated Baraka Google Identity Services web client. Google processes your sign-in, email address, account identifier and connection information. The browser verifies Google identity directly and Baraka then requires its own authenticator; the active path does not request an LMS authenticator. A legacy Firebase/LMS fallback remains in source for operator rollback but is not the configured hosted sign-in path. The browser sends a short-lived signed identity token to IhsanBaraka for verification; the app does not save that token in financial records, audit logs or browser storage. Google/Firebase sign-in does not grant access to courses or finance records by itself. IhsanBaraka checks its existing active staff account and requires its own authenticator or recovery code before granting a session. No ledger records or statement contents are sent to Google for sign-in.

Statement organization and budgets

Authorized finance staff can import transaction CSV/Excel files and matched original RBC CSV/PDF evidence, save explicit sorting rules and monthly category budgets, and review accounting reports. Original files remain private in the database and existing encrypted backups. Spreadsheet parsing runs in an isolated child process and does not send contents to an AI classifier. Saved rules reflect staff choices, not student identity verification; uncertain transactions remain for review. Reviewed PayPal movements can be linked to accounting entries with gross amounts, fees and net amounts kept separate. Provider retrieval remains read-only; this does not charge, refund or transfer money. Budgets do not initiate payments.

Recovery copies

An authenticated encrypted finance/staff backup has been stored in the restricted finances@ihsan.ca Google Drive folder and verified through download and an isolated restore. Backups include original statement evidence and encrypted MFA records, but exclude sessions, OAuth tokens and provider credentials. The separate backup decryption key was sent, with the owner’s approval, to the designated recovery custodian Hanna through Al-Ihsan Gmail. Anyone obtaining that key and a matching backup can read its contents. Staff authenticator recovery also requires separately held server MFA keys. The owner reports that Hanna verbally acknowledged custody. Daily encrypted uploads are configured on the existing Render reporting job; an actual scheduled upload and isolated restore have been verified. The job has restricted access to its own Drive backup files and holds the matching backup key; actual staff MFA decryption keys remain separate. Google’s Drive and Gmail locations, retention and administrative access depend on Al-Ihsan’s account configuration; Canadian-only storage is not asserted.

Who can access information

Access depends on current staff roles within one shared organization. Authorized finance staff share the ledger; this is not private storage for each staff member. Board viewers see aggregate reports. System operators with machine or database access can access records beyond the web interface. Exports and backups require careful handling and may be copied outside the app.

Optional Grok connection

An authorized finance administrator may connect Grok through a read-only MCP interface after staff sign-in, authenticator verification and explicit OAuth consent. Grok can then request shared accounts, funds, journal descriptions and amounts, parsed statement rows, annual categories and reports, plus staged PayPal/Stripe/e-transfer evidence, source coverage, historical course-payment allocations and review queues when configured. Exact canonical student/enrollment reads additionally expose approved tuition and discounts, opening credits, conservative balances, reviewed payment history and instalment-policy verification status. Reviewed individual dates and payment attribution can be returned; unrecorded or stale evidence stays unverified; the app does not issue tuition invoices. Stripe and deposit reads can include necessary payer names/emails and reference hints for reconciliation; PayPal tools exclude payer emails. Original CSVs/email bodies, live roster listings and credentials are excluded. Those records may contain personal information. The connector does not expose passwords, authenticator secrets, original statement files, feedback or account-management tools, and cannot change financial records.

Grok/xAI processes requested records under the connected Grok account’s terms, retention and privacy settings, which Al-Ihsan must review before approving access. Do not assume processing stays in Canada or that data has a particular training or retention exemption. The app does not control copies already sent to Grok. Grok installs personal connectors account-wide: other bots on that account can use the connection. This app cannot isolate access to named bots. Approve the connection only if that account-wide access is authorized.

OAuth access tokens last at most 15 minutes and cannot outlive their approval. For new approvals, the authorized approver chooses 7, 30 (default), 90 or 180 days. Existing approvals keep their original expiry and permissions unless their owner explicitly selects continuing renewal for that operational connection. Optional continuing renewal keeps the same read-only approval active until disabled, potentially indefinitely, through cycles of 7, 30, 90 or 180 days. The existing daily maintenance job can renew selected valid approvals near their deadlines during quiet periods; normal successful client refresh also renews when due. Renewal does not revive expired or revoked approvals or credentials. The retained refresh credential still has its own inactivity limit and may require one private owner recovery. Enabling renewal alone does not change the present deadline. The owner choice, security-binding digest, cycle, last renewal, old/new deadlines and known failure codes are recorded. Disabling renewal stops future extensions; revoking access stops access immediately. External provider consent and separate LMS grants are not extended. Different clients have independent approvals. Baraka has no safe MCP draft, publishing, sending or financial-write grant. Stored access, refresh and registration tokens are hashed. Delegations store the approving staff account, OAuth client metadata, factor version, a password-derived authentication hash, dates and revocation state. Separate pending consent forms store a random interaction ID, owner/client references, a request-binding digest and a ten-minute expiry/consumed marker; they store no OAuth code or raw callback URL. Up to 100 unexpired form records per approver are allowed, and expired form metadata is removed on the next authorized consent-page preparation. Audit records log fixed read tool names, token issue/refresh events, approval deadlines and staff/client IDs, excluding tokens, query text and returned record contents. Fixed request counters limit connector use. Finance administrators can revoke connections in Grok connections; password changes, authenticator resets, deactivation and loss of required roles also prevent access. Signing out does not revoke a delegation. Revocation cannot recall records already shared. OAuth credentials are excluded from portable financial backups and require reconnection after restoration.

The app has no advertising, external analytics or bank feed. Optional provider reporting, enrollment lookup, deposit evidence and review notifications are described above; the app does not execute money movements. Manually sharing an export or sending a privacy email is a separate action with that service’s own processing.

Storage, providers and location

The service stores records in its configured database. A hosted deployment uses its separately configured PostgreSQL database; the local sample and QA use separate local databases. Static fonts and logos are served locally. Original statements are stored in the database; manually created backups and exports are separate files. Operating-system backups, disk encryption, shared folders and device synchronization have not been verified. This notice does not promise that every device copy stays in Canada.

The app is hosted on Render, with a separate Neon PostgreSQL database, both configured in Oregon, United States. Provider infrastructure processes records outside Canada. GitHub holds private application source; financial records are not intentionally uploaded to the source repository. Encrypted backups are separate from the live database. The daily reporting job uploads encrypted copies to an owner-only automated folder inside the restricted finance Drive backup folder. The finance/privacy mailbox uses Al-Ihsan Gmail; its configured storage location and retention have not been verified. Email and user-chosen external services may process information outside Canada and be subject to foreign lawful access. Provider arrangements and notices must be reviewed before production use.

Retention and corrections

There is currently no automatic deletion schedule for live financial records, statements, audits, logs, sign-in counters or report-operation counters. Automated backup rotation keeps the newest 35 verified daily copies, plus protected or held copies, and preserves the original verified manual backup. Older eligible automated copies are moved to recoverable Google Drive Trash; Google’s own Trash lifecycle applies. The backup process does not delete original records from the live app. Sign-in counts reset after a five-minute window when another attempt occurs; report counts reset after a one-minute window when another request occurs. The stored rows remain. Records persist until an authorized operator performs a reviewed action. Optional diagnostic buckets and feedback reports follow the separate 180-day expiry and daily cleanup described above. Authentication-audit and closed privacy-case reviews retain their separately adopted schedules; the ordinary signed-in session lifetime is unchanged. Optional remembered-browser trust uses its separate fixed 30-day cookie and does not alter financial, enrollment or recording retention.

Posted financial entries are corrected through reversing entries rather than erased through the app. Legal recordkeeping duties, unresolved transactions, investigations and holds may limit deletion. Where registered-charity requirements apply, CRA rules distinguish financial/source records from other record categories; the operator must classify them before disposal. Backups and downloaded copies need separate review, and restoration can bring back previously retained records. Account deactivation removes access but preserves linked history.

Safeguards and choices

The build uses session authentication, role checks, CSRF protection, sign-in attempt limits, exact accounting validation and audit records. No system is risk-free. Staff accounts require authenticator MFA; an explicitly remembered personal browser can satisfy the normal sign-in MFA check for up to 30 days after primary sign-in, while security actions require fresh verification. The hosted build uses externally configured encryption/signing keys, PostgreSQL TLS certificate verification and secure browser cookies. Each account holder must complete enrollment on their own device. Backup restoration, device security and operating procedures require ongoing operator checks. Use only the records you are authorized to handle and protect downloaded copies.

You may request access to your personal information, correction, an explanation of use/disclosure, withdrawal of consent where applicable, or review of retention/account closure. Requests are handled manually and are subject to applicable rights and exceptions; there is no instant deletion button. See Privacy requests. Questions or suspected incidents: finances@ihsan.ca. You may also contact the Office of the Information and Privacy Commissioner for BC.

Changes

We will revise this notice when features or practices change. Actual staff must accept the versioned Use terms and acknowledge this Privacy notice before core browser use, including existing users on their next use. The server records the document versions and acceptance time. Optional diagnostics have a separate unchecked choice and consent record; required acknowledgement is not blanket consent. Material changes require a new versioned review. Existing read-only service grants retain their protections and expiry.

The Al-Ihsan Workspace navigation opens ordinary links to the organization website, LMS and Office. It does not send sign-in tokens or silently sign you into another app; each app enforces its own access.