Privacy and compliance integration
For mainland China deployments, the host product provides privacy notices, authorization flows and user-rights entry points. Manage system permissions, classroom permissions and product privacy authorization separately. See Data collection and Host permissions and networking.
Notice and initialization
Identify the operator, contact, purposes, methods, data categories, retention and rights procedures. Establish the appropriate legal basis; where processing relies on consent, obtain it before collection and provide withdrawal. See PIPL Articles 13–19.
Implement this sequence in the host:
- Provide readable, accessible privacy notices and an inventory of the SDKs actually used.
- Where consent is required, record the choice, policy version and time; do not preselect agreement.
- Control SDK creation, initialization and provider startup. Initialization can generate device identifiers and diagnostics. Provide notices and obtain any required authorization before those collection paths start.
- Request device permissions for the feature the user is using. Stop the corresponding collection after refusal or withdrawal, and test other authorized features.
- Recheck notices, initialization and refusal paths after SDK upgrades or collection changes.
Record privacy authorization separately from SDK initialization results and OS permission state. Inspect network traffic and local storage for first launch, refusal, withdrawal, restart, background recovery and account changes. See the CAC app data-collection assessment rules for app self-review.
Features and permissions
| Feature | Request timing | Explain | Refusal/stop checks |
|---|---|---|---|
| Camera | User enables video or starts a camera test | Classroom video or local preview | Do not start capture without authorization; confirm the device and media state stop when closed |
| Microphone | User unmutes or starts a microphone test | Classroom speech or local volume testing | Stop recording; preserve feasible listening/text features |
| Screen sharing | User selects a sharing source | Screen, window or application scope | Cancellation does not start sharing; ending releases capture |
| Files and courseware | User selects a file to upload/import | Upload, conversion, storage and classroom visibility | Do not scan unrelated directories; cancellation does not submit the file |
| Bluetooth/other devices | Required by an enabled audio-device feature | The specific device use | Do not make unnecessary permissions a prerequisite for every classroom feature |
iOS camera/microphone descriptions belong in the host App's Info.plist. On Android, check the merged manifest and runtime request paths. Web and mini programs also require checks for browser/platform permissions, domains and host lifecycle. SDK configuration does not replace these declarations.
Third-party SDKs and services
Record each enabled component's name, version, provider, purpose, information categories, invocation timing and privacy-policy URL. OpenIM's recipient depends on deployment. List recipients and purposes separately for RTC, whiteboard, conversion, storage and diagnostic services. See TRTC's personal information rules for that component; the host product's notice must cover all components and services it uses.
Review actual roles, agreements and applicable notices/procedures for entrusted processing, provision to other controllers and cross-border flows. See PIPL Articles 21, 23 and 38–40. Include webhook receivers and logging systems in the deployment inventory.
Children and sensitive information
Processing information about children under fourteen requires guardian consent and dedicated rules. Sensitive information requires review of necessity, strict safeguards and applicable consent requirements. See PIPL Articles 28–31.
Provide age verification and guardian-authorization flows appropriate to the product, confirming age separately from classroom roles. Camera permission covers device capture; recording, public display and other uses require their own notices and applicable authorization. Define participant visibility and download access for recordings, exports, screenshots and shared teaching results.
Retention, deletion and requests
Define retention, deletion entry points and backup treatment separately for profiles, chat, courseware, boards, recordings, diagnostics and received events. Disabling webhooks does not delete events already stored by the receiver. After disabling a user, clearing page caches or destroying an SDK instance, apply the deletion procedure to data held by each service.
Document how access, correction, deletion and withdrawal requests are handled across business databases, IM, storage, logs and backups. Keep completion records, restrict administration and audit exports/deletions. Remove tokens, signing secrets, complete signed URLs and unnecessary message content from diagnostic materials.
Release checks
| Check | Evidence to retain |
|---|---|
| Notices match actual processing | Policy version, dependency list, enabled features and recipients |
| Initialization respects authorization | Requests and local-storage observations before consent, after refusal, after consent and after withdrawal |
| Device permissions are requested as needed | Permissions in production builds and per-platform grant/refusal results |
| Exit/close stops capture | Camera, microphone, screen-sharing and background-transition results |
| Retention and deletion are executable | Owner, retention, deletion and backup procedures for each store |
| Receiver access is scoped | Subscriptions, signatures, application isolation, deduplication and log redaction |
| Child/sensitive-information scenarios are addressed | Applicable notice, authorization and access-control records |