Principles
The scanner is built around four rules: inspect the delivered bytes rather than the editing interface; distinguish evidence from inference; treat incomplete coverage as a result; and never call a file safe.
Every finding has a stable rule ID, severity, confidence, location, evidence excerpt, and remediation. Reports also contain the file’s SHA-256 fingerprint so the result can be tied to the exact bytes that were scanned.
Verdict language is intentional. The clean result says “No obvious hidden content found,” not “Safe.” A scanner can establish that it did not find a known indicator. It cannot establish the absence of every possible disclosure.
PowerPoint inspection
PowerPoint files in the modern Open XML family are ZIP packages. Safe to Send validates the package, verifies CRC-32 values, enforces decompression limits, then inspects relationships and XML parts directly.
| Area | Evidence checked |
|---|---|
| Speaker notes | Notes-slide relationships and text stored under ppt/notesSlides/. |
| Hidden material | Slides with show="0", hidden object properties, and objects positioned entirely outside the slide canvas. |
| Collaboration | Classic and modern comment parts, authors, people records, and retained collaboration data. |
| Embedded content | Files under ppt/embeddings/, custom XML parts, VBA projects, and external data relationships. |
| Images | Crop rectangles, extractable source-image metadata, camera fields, author fields, and GPS coordinates in supported JPEG, PNG, and WebP metadata. |
| Identity | Core, extended, and custom document properties such as creator, last editor, company, manager, template, and internal custom fields. |
| Package integrity | Unsafe paths, duplicate names, case collisions, encryption, unsupported compression, size mismatches, CRC failures, and excessive expansion ratios. |
Microsoft’s own guidance recommends running Document Inspector on a copy before sharing because presentations can retain hidden data and personal information. Safe to Send complements that workflow by inspecting the final package independently. See Microsoft’s Document Inspector guidance.
PDF inspection
PDF is a programmable document format, not a flat image. Safe to Send scans structural markers, document dictionaries, annotations, actions, forms, optional-content layers, revision chains, and supported content streams.
False-redaction heuristic
Supported content streams are tokenized and interpreted with a bounded graphics-state model. The scanner estimates text boxes and filled rectangle geometry. It warns when recoverable text appears substantially covered by a dark opaque rectangle rather than removed.
This is a heuristic. Complex transforms, clipping paths, forms, nested graphics, unusual fonts, and unsupported filters can create false positives or false negatives. Findings therefore carry confidence and the report discloses undecoded streams.
Other PDF checks
- Invisible text rendering modes and likely off-page text.
- Comments, annotations, saved form values, embedded files, JavaScript, launch actions, and submit actions.
- Optional content groups and multiple cross-reference or end-of-file markers consistent with incremental saves.
- Authoring metadata in the information dictionary and decoded streams.
Adobe separates redaction from sanitization: redaction removes marked visible content, while sanitization addresses metadata, embedded content, scripts, and other non-visible material. See Adobe’s redaction and sanitization guidance.
Sensitive-value checks
Pattern checks are run only against content already classified as concealed, recoverable, or package-level—not against ordinary visible slide or page text. This reduces noisy findings.
Rules cover private-key markers, major token formats, database connection strings, credential-like assignments, internal URLs, email addresses, US Social Security number patterns, validated IBANs, and payment-card candidates that pass the Luhn checksum. Evidence is shortened before it is written to a report.
Severity and confidence
| Level | Meaning | Typical response |
|---|---|---|
| High | Clear recoverable content, executable material, embedded files, notes, GPS data, or a condition that makes sharing unsafe without review. | Do not send yet. |
| Medium | Material that may disclose identity, working data, comments, hidden objects, links, or data depending on context. | Review and remove if unintended. |
| Low | Useful context or a weak signal with limited standalone risk. | Confirm intent. |
| Info | Format or coverage information that is not itself a disclosure. | Record or investigate as needed. |
Confidence describes the strength of the inference, not the impact. A high-severity, medium-confidence false-redaction finding means the potential impact is serious but the geometric inference should be verified.
Coverage model
A scan is marked incomplete when encrypted content, unsupported filters, malformed parts, resource limits, or other conditions prevent an enabled check from reading relevant bytes. An incomplete scan never produces the clean verdict, even when no high-risk finding is present.
Defensive limits include maximum file size, ZIP entry count, per-entry expansion, total inflated bytes, compression ratio, XML size, decoded PDF stream size, stream count, and image-metadata size.
Known limitations
- PDF rendering is not fully implemented. Font metrics, nested form XObjects, clipping, transparency, unusual encodings, image-only content, and uncommon filters can evade geometric checks.
- Text inside scanned images is not read. The project intentionally has no OCR or remote vision dependency.
- Password-protected Office files must be decrypted before package inspection.
- Legacy binary
.pptfiles are not supported. - Image metadata support currently covers EXIF in JPEG/WebP and selected PNG text or EXIF chunks.
- Application behavior changes. A current source application may retain information not yet represented by a rule.
Do not use the tool as the only control for legal, regulatory, national-security, medical, or similarly consequential disclosure. Use source-application inspection, true redaction, sanitization, manual review, and an approved delivery process.
Security model
The browser build contains no analytics, advertising, remote fonts, remote scripts, upload endpoint, or external API. The page’s Content Security Policy sets connect-src 'none'. Scanning runs in a dedicated worker using the same dependency-free core as the CLI.
Untrusted files are handled with explicit bounds. ZIP paths are never written to disk by the browser scanner. The CLI reads files but does not extract archive paths. Reports may contain excerpts from concealed material, so exported reports should be protected accordingly.
Security reports should follow the process in SECURITY.md.