MaskIt Technical Security Overview

Version: 2.3
Date: 2026-04-12

Executive summary

MaskIt is built as a local-first redaction system with server-side metadata persistence for account, quota, and history features. The core objective is to reduce sensitive data exposure by performing all redaction operations — including NLP inference — in the browser, while preserving operational controls needed for SaaS usage.

1) Architecture overview

1.1 Local processing layer

• The redaction engine executes entirely in-browser with a multi-stage pipeline: regex detection → NLP detection → validation → conflict resolution → placeholder replacement.
• NLP inference uses a multilingual BERT NER model (Xenova/bert-base-multilingual-cased-ner-hrl, q8 quantized, approximately 30–50 MB on disk) running in a dedicated Web Worker thread via Transformers.js with ONNX Runtime Web. On supported browsers (Chrome, Edge with WebGPU), inference runs on the GPU for faster processing; older browsers automatically fall back to CPU-based WASM execution. Model execution is isolated from the main UI thread.
• For long texts, content is split into overlapping sentence-boundary chunks of approximately 250 words and processed sequentially through the NLP pipeline, with offset correction and overlap deduplication.
• Large-file safeguard: documents exceeding 50,000 words automatically skip NLP inference and use regex-only detection, preventing multi-minute processing times on large log or dump files.
• File parsing (including PDF text extraction via pdf.js) runs client-side. The TXT/LOG adapter uses adaptive block sizes (200-line blocks for files ≥ 1,000 lines) to reduce processing overhead.
• Placeholder mapping is deterministic within session context, supporting repeatable replacements.

1.2 Batch processing

• Multi-file batch uploads are processed sequentially in the browser.
• Cumulative quota checks are enforced before each file to prevent overuse.
• Per-file results (redacted text, entity list, metadata) are held in browser memory via a Zustand store, surviving in-app navigation but not tab closure.
• No file content or batch results are transmitted to MaskIt servers.

1.3 SaaS control plane

The application stores operational records for:

• Identity and access (Supabase Auth)
• Workspace membership and authorization boundaries (row-level security)
• Subscription/usage enforcement (Stripe + Supabase RPC)
• Job history metadata and analytics views
• Detection policy presets (category toggles and confidence thresholds)

2) Redaction pipeline controls

The core flow is:

1. Deterministic detection — regex-based patterns for 23 PII categories organized in four tiers:

   • Core Identity: EMAIL, PHONE, PERSON, ORG, LOCATION, SSN, DOB
   • Financial: CARD, IBAN, SIRET, SIREN, SWIFT_BIC (8/11 char bank codes with false-positive filtering), ROUTING_NUM (US 9-digit with ABA checksum validation)
   • Technical: IP (IPv4), IPV6 (full/compressed/loopback formats), UUID, URL, MAC_ADDRESS (6-hex-pair with colon/hyphen separators)
   • DevOps & Secrets (Pro+): AWS_KEY (AKIA... 20 char), GCP_KEY (AIza... 35+ char), GITHUB_TOKEN (ghp_... 36 char), JWT (3-part Base64 structure), CRYPTO_WALLET (Bitcoin legacy/P2SH/Bech32 and Ethereum addresses)

   Patterns include locale-specific support for French phone numbers, SSNs, IBANs, SIRET/SIREN business identifiers, dates of birth, postal codes, numberless street addresses (rue / chemin / route without a leading house number), and lieu-dit keyword addresses. DevOps patterns include strict validation (e.g., SWIFT codes reject high-vowel-count words like LINKEDIN/FACEBOOK, routing numbers must pass ABA checksum) to minimize false positives.

2. Contextual NLP mapping — when enabled, multilingual BERT NER model detects PERSON, ORG, and LOCATION entities. Includes a name extension heuristic for ALL-CAPS tokens common in French CVs.

3. Validation — false-positive control including Luhn check for credit cards, word-boundary snapping for NLP entities, a technical term whitelist (common developer tools and frameworks) to suppress spurious PERSON/ORG/LOCATION detections, and per-category confidence thresholds.

4. Resolution and replacement — overlap handling via category-weight ordering (e.g. SSN above CARD so a valid French sécu is not misclassified as a credit card when spans collide), tie-breakers, then stable deterministic placeholders (e.g., [PERSON_1], [EMAIL_2]).

Security objective: convert sensitive spans into deterministic placeholders while preserving output usability for downstream consumers.

3) NLP model security

3.1 Model provenance

The model (Xenova/bert-base-multilingual-cased-ner-hrl) is an open-source Hugging Face model converted to ONNX format for browser execution and served in q8 quantized form. MaskIt does not modify the model weights.

3.2 Download and caching

The model binary (approximately 30–50 MB for the quantized artifact) is downloaded from Hugging Face's CDN on first use. The download URL is controlled by a Content Security Policy (CSP) directive in next.config.ts. After download, the model is cached in the browser and all subsequent inference runs offline.

3.3 Inference isolation and acceleration

NLP inference runs in a dedicated Web Worker thread, isolating it from the main UI thread and preventing blocking of user interactions. ONNX Runtime Web executes the model using WebGPU when available (modern Chrome, Edge) for GPU acceleration, with automatic fallback to WASM (CPU-based) on browsers without WebGPU support. No document text is transmitted to any external service during inference.

3.4 Initialization, timeouts, and retries

Controls are layered between model lifecycle and scan execution:

• Initialization: model load and worker setup use a 120-second overall timeout. Failure surfaces a clear error and may trigger fallback behavior depending on configuration.
• Inference (nlpService level): each inference attempt uses a 30-second timeout. On timeout, one additional retry is performed for that attempt before the caller treats the attempt as failed.
• Scan-time resilience (redactionStore level): during an active scan, failed NLP operations are retried up to 3 attempts with a 2-second delay between attempts.

If initialization or all scan-time retries fail, MaskIt falls back to regex-only detection and surfaces a visible warning indicating which detection mode was actually used.

4) Batch processing security

Batch uploads are designed so that all files are processed strictly sequentially in the browser. Only one file’s content is actively held in the redaction pipeline at a time for a given batch operation; per-file state is isolated in the client store. This design reduces cross-contamination risk: outputs, entity lists, and placeholders from one file are not merged into another’s processing path until the user explicitly chooses unified export or review flows that operate on already-separated results.

Cumulative quota and entitlement checks run before each file. Raw file bodies and per-file redaction outputs are not transmitted to MaskIt servers; only the user-initiated metadata patterns described elsewhere in this document apply at the control plane.

5) Stripe integration security

Billing uses Stripe with server-side enforcement of subscription state and usage limits. Key controls:

• Webhook authenticity: Stripe webhooks are accepted only after cryptographic signature verification using Stripe’s signing secret. Unsigned or invalid payloads are rejected.
• Server-side authority: subscription and checkout state used for entitlements are derived from verified Stripe events and server-side session retrieval — not from client-supplied claims alone.
• Metadata hygiene: no PII is placed in Stripe metadata or custom fields; identifiers are limited to opaque internal references (e.g., customer or subscription IDs) as required for billing operations.
• Direct session verification: the /api/checkout/verify endpoint supports server-side verification of a Checkout Session (e.g., after redirect), confirming payment and subscription state before the application unlocks paid capabilities.

Client-side Stripe.js usage is limited to Elements and Checkout redirects as appropriate; sensitive billing operations do not rely on tamperable browser state.

6) Data handling model

6.1 Data classes

Class	Sensitivity	Location
Document content (text/file bodies)	High	Browser memory only
NLP model weights	Low	Browser cache (downloaded from Hugging Face CDN)
Batch processing results	High	Browser memory (Zustand store)
Review decisions	Medium	Browser memory (not persisted to server)
Account/workspace metadata	Low	Server (Supabase)
Job history metadata	Low	Server (Supabase)
Detection policy presets	Low	Server (Supabase)

6.2 Persistence boundaries

• Raw content and detection results are never transmitted to or stored on MaskIt servers.
• Job history stores metadata and aggregate summaries only (category counts, processing times, file names).
• Batch results in the Zustand store survive in-app navigation but are cleared on tab close or explicit dismiss.
• Audit export bundles are generated client-side and contain metadata only (no raw PII values).

6b) Advanced output modes security

Pro+ users can choose between three output rendering modes (Placeholder, Black Box, Synthetic Data). All modes enforce the same zero-egress guarantee:

• Output mode is a display-time transform only. The engine internals always use canonical [CATEGORY_N] placeholders. The transform is applied at export/copy time in browser memory — never on any server.
• Black Box mode replaces placeholders with █ characters matching original PII length. No original text is embedded; only the character count is used for length matching.
• Synthetic Data mode generates fake-but-valid replacement values using @faker-js/faker (loaded dynamically, client-side only). Synthetic values are seeded for deterministic output and contain no correlation to the original data. The faker library never receives original PII as input.
• Tokenization Vault exports the reversible placeholder-to-original mapping as a standalone JSON file with SHA-256 integrity verification. The vault file is generated entirely client-side and is the only way to reverse the redaction. Without it, redaction is mathematically irreversible. The integrity hash (SHA-256 over the serialized mappings array) detects any post-export tampering.
• All three output modes plus the vault export are gated behind Pro+ entitlements and enforce the same audit trail as standard placeholder mode.

7) Human review security model

The Review Queue operates entirely in browser memory:

• Review items (detection metadata, decisions, notes) are held in a Zustand store.
• Decisions are not transmitted to the server unless the user explicitly exports an audit bundle.
• Batch review merges entities from multiple files; each item is tagged with its source file name for filtering.
• The audit trail (decision log) tracks who made each decision, when, and any category overrides — for compliance evidence without exposing PII values.

8) Access control and isolation

• Row-level security (RLS) policies on Supabase enforce workspace-scoped data access.
• All history, usage, and analytics queries are filtered by workspace membership.
• Public routes (FAQ, docs, landing page) require no authentication.
• Dashboard, review, history, and settings routes are behind authentication middleware.

9) Transport and platform security

• Browser ↔ backend communication uses HTTPS/TLS.
• Content Security Policy (CSP) restricts resource loading to known domains (app origin, Supabase, Hugging Face CDN, Stripe).
• Managed platform controls (Supabase Auth, Supabase Database, Stripe) provide baseline security infrastructure.

10) Analytics security

The Analytics & History page computes statistics from job metadata only. A parallel lightweight query fetches aggregate data (entity counts, processing times, category summaries) across all matching jobs without pagination limits (up to 2,000 rows). No PII content is included in analytics data.

11) Compliance positioning (practical)

MaskIt helps organizations reduce downstream risk by redacting sensitive content before sharing. It is a compliance enabler (GDPR/CCPA/SOC2/HIPAA workflows), not an automatic compliance certification by itself.

Key compliance-supporting features:

• Local-first architecture (no PII on servers)
• Human review with audit trail
• Per-category confidence thresholds
• Policy presets for organizational consistency
• Audit export bundles (metadata-only, JSON/CSV)
• Configurable history retention by plan tier

12) Known boundaries

• File names and operational metadata are persisted for history/governance UX. Organizations should define internal policies for acceptable metadata content.
• NLP detection accuracy depends on model capabilities; it is not 100% for all languages or entity types. Human review is recommended for high-stakes use cases.
• PDF support is limited to text-based PDFs (not scanned images/OCR).
• The NLP model is a third-party open-source artifact; MaskIt does not control its training data or potential biases.
• Final compliance posture depends on deployment configuration and organizational controls.

13) Recommended enterprise controls

• Security review of detection policies before production rollout.
• Periodic audits of history metadata fields and retention settings.
• Define naming conventions for uploaded files (avoid PII in filenames).
• Mandate human review for highly regulated data categories.
• Incident response runbook for auth/storage misconfiguration.
• End-to-end tests for critical flows (upload → redact → review → export → history).

14) Trust-center publishing checklist

Before publishing this document publicly, verify:

• Privacy policy language matches actual implementation behavior.
• Product UI labels do not overclaim (e.g., "zero data stored") if metadata is retained.
• Security claims map to controls that are currently implemented and testable.
• NLP model provenance and license terms are documented.
• Batch processing and review workflow data flows are accurately described.
• Stripe webhook handling and /api/checkout/verify behavior match production configuration.