1. Core privacy position
Do Easy PBD is built as an offline-first app.
- Most teaching records stay on your device unless you choose a hosted, support, or transfer feature.
- We do not intentionally sell personal data.
- We do not run advertising SDKs in the current build.
- We do not intentionally run classroom-behavior analytics SDKs in the current build.
Manual archive export and import remain user-controlled. Signed-in Pro accounts may synchronize supported data and attachments according to their cloud-storage allowance, installation eligibility, and service availability. Free teaching data stays on the current device. Local work remains available when synchronization is interrupted.
Teaching-record metadata such as classes, forms, attendance, grades, notes, and entitlement state is handled through the app's offline-first local storage plus hosted services when account features are used. Attachment blobs such as photos, screenshots, PDFs, and similar evidence files may use object storage services when sync, backup, or support-upload features are active.
4. What we may receive when account or hosted features are used
We receive only the data needed to operate account access, sync, support, and related hosted functions.
4.1 Account and sign-in data
If you sign in, we may process:
- your email address
- your Supabase account identifier
- authentication provider information, such as whether you use email/password or Google sign-in
- your public in-app user ID, if you create or claim one
- linked-provider state and related account metadata
- entitlement, account-access, and signed-in device-overview data
- app-generated device identifiers or labels used for account-linked device management, entitlement refresh, or sync safety checks
4.2 Support and account-access data
If you contact us or use hosted account features, we may process:
- the contact details you use to reach us
- your support messages, screenshots, or bug details
- account-access status, sync eligibility, signed-in device overview state, and related server audit metadata
- timestamps and audit notes related to account recovery, device review, sync troubleshooting, or support actions
- account-deletion or account-recovery status metadata when you use those flows
4.3 Purchase, billing, and access records
If you use website-backed billing, billing history, entitlement restoration, or store-linked purchase recording flows related to Edu N App, we may process:
- selected product, plan, or entitlement identifiers
- payment or billing status
- order, purchase, checkout session, or external transaction reference IDs
- payment timestamps and access-refresh timestamps
- provider names and limited verification metadata needed to confirm access
We do not intentionally process full payment card numbers or CVV values through the app itself.
4.4 Operational security data
To operate the service safely, we may also process limited technical metadata such as:
- app version and platform details
- entitlement-refresh results
- device-count or device-eligibility state
- backend error/access logs needed to investigate failures or abuse
- local or hosted request metadata reasonably needed to troubleshoot authentication, sync, support, billing, or account-integrity issues
4.5 Online Sync reliability telemetry and diagnostics
When Online Sync features are used, we process limited sync-operations telemetry so support can diagnose restore or convergence failures without reading more teaching content than is necessary.
This telemetry may include:
- push batch size and pull batch size
- latest pushed and pulled revision numbers
- pull bootstrap source, such as mutation replay versus canonical entity bootstrap
- sync failure category, such as access denied, invalid request, or server error
- pull/apply duration and related timing metadata
- per-device sync state metadata, such as device label, last seen, last pushed, and last pulled
- metadata submitted by the app for sync troubleshooting, such as platform, app version, and device identifier or label
Telemetry is used for reliability, support triage, abuse prevention, and service hardening. It is not used for ad profiling or classroom-behavior analytics.
Sync telemetry is designed to avoid storing full teaching-record payload content in diagnostics tables where possible. Teaching content may still exist in the product data stores required for sync and storage features when those features are active for your account.
4.6 Identity-free reliability monitoring
The web app sends a small set of categorized reliability signals so Code N Gram can detect failed startup, browser or Content Security Policy errors, unexpected account-service failures, slow restoration, sync queue problems, and attachment transfer failures. These signals contain only the app version, browser-engine family, a predefined outcome and failure category, a coarse duration bucket, and a coarse queue-size bucket.
The reliability endpoint rejects unknown fields. It does not accept or store names, Forms, classes, students, notes, records, attachments, field values, email addresses, account or device identifiers, IP addresses, URLs, search parameters, user-agent strings, cookies, tokens, raw error messages, or stack traces. Request origin is used only to classify production, preview, or local environment and is not stored. Aggregated counters and probe history are kept for 30 days; content-free incident state is kept for 180 days.
Reliability reporting is time-bounded and fail-open. A monitoring outage does not prevent the app from starting, authenticating, saving, restoring, or synchronizing. These signals are not used for advertising, session replay, classroom-behavior analytics, or user profiling.
4.7 Attachment, backup, and support-upload data
When Online Sync, support evidence uploads, or other hosted file-transfer features are active, we may process:
- attachment object metadata such as object key, hash, size, MIME type, and upload/download state
- signed upload or download requests needed to transfer attachment blobs securely
- the attachment file bytes themselves when you choose a feature that uploads or restores those files through a hosted flow
- evidence images or similar support attachments you choose to upload for a problem report
Structured teaching metadata and attachment blobs are handled separately. Hosted account and sync metadata are coordinated through backend services, while uploaded object storage may be handled through Cloudflare R2 or a similar storage provider configured for the service.