Luciq PII Masking

How the Luciq SDK masks personally identifiable information on-device, across screenshots, session replay, and network logs, before upload.

1. Core Principles

All PII masking in the SDK happens client-side, on the device, before any data is written to encrypted local storage or transmitted to the backend. The masking model rests on a few non-negotiable principles:

• Masking is on-device. Sensitive regions are painted over in the bitmap itself, and network values are stripped at capture time. The SDK never persists a raw, un-masked image.

• The backend never decodes anything. The backend receives data that is already masked. There is no server-side step that could reverse masking — the unmasked value simply never exists off-device.

• Developers decide what is masked. Masking is driven by SDK configuration and per-view marking in app code, supplemented by an automatic safety net.

• Two surfaces are covered. Visual content (screenshots, repro-step images, session replay frames) and network logs (headers, query parameters, payloads).

Where it applies: Screen masking covers repro-step screenshots, bug-report screenshots, user steps, and Session Replay frames. Network masking covers all captured network logs. Auto type-based masking applies to screenshots only (not screen recordings).

Masking & Privacy Controls

Screen & Screenshot MaskingUser Steps Privacy APIServer-Driven UI (SSUI) Setup

Network Log MaskingRepro Steps ControlAdditional Privacy Control

---

2. Best Practices & Pre-Production Checklist

DO

• Always mask financial information (credit cards, bank accounts, CVV).

• Mask personal identifiers (e-mail, SSN, national IDs).

• Mark authentication screens private (passwords, PINs, OTPs, security questions, etc.).

• Mask health and medical information.

• Test masking before every production release.

DON'T

• Don’t rely on grayscale alone for privacy.

• Don’t assume any backend masking exists — masking is client-side only.

• Don’t enable Session Replay for all users without a consent flow where required.

• Don’t capture screens displaying sensitive documents.

2.1 Verification steps

• Mark views as private in code.

• Trigger a session in the app.

• Navigate to the screen containing the private views.

• Open the session/replay in the dashboard.

• Confirm masked areas appear as solid black rectangles.

• Validate with every new screen added in the app that has private data.

2.2 Pre-production privacy checklist

• All text input fields are automatically masked.

• Login / authentication screens are marked private.

• Payment screens are marked private.

• Personal-information screens are marked private.

• Sensitive network requests are obfuscated or omitted.

• User-consent flow is implemented where required.

• Privacy policy mentions session recording.

• QA has verified masking works correctly.

• Legal / compliance has approved.

2.3 Known limitations & troubleshooting

• Android: hardware-accelerated views may produce blank screenshots; a media-projection capture API exists (prompts the user to allow recording).

• iOS: custom NSURLSession needs enableLoggingForURLSessionConfiguration; AFNetworking/Alamofire need helper classes; SSL pinning requires the auth-challenge handlers.

• Flutter: very rapid animations may occasionally not mask correctly due to the nature of the fluter framework

• Network logs are capped at 1,000 per report.

3. Platform support matrix

Capability	iOS	Android	Flutter	React Native
Auto type-based screenshot masking	Yes	Yes	Yes	Yes
Manual private views	Yes	Yes	Yes	Yes
Private views in declarative UI (Compose / SwiftUI)	Yes	Yes (Compose)	n/a	n/a
Auto network header/query masking	Yes	Yes	Yes	Yes
Manual network obfuscate / omit	Yes	Yes	Yes	Yes
Grayscale screenshot mode	Yes (Only supported in SessionReplay)	Yes (Only supported in SessionReplay)	Yes (Only supported in SessionReplay)	Yes (Only supported in SessionReplay)
Secure-window control (FLAG_SECURE)	n/a	Yes	n/a	n/a
Private views in screen recording	Yes	No — use FLAG_SECURE	No	No