Luciq PII Masking

How the SDK masks personal identifiable information (PII) on-device — across screenshots, session replay, and network logs — before any data leaves the user’s device.

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 MaskingAdditional 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