What each tool on this site protects against, and what it does not. If a tool's own page and this page ever disagree, this page is the more careful, more conservative source, and the tool's page is wrong.
Every tool on obscuraos.com runs client-side, in your browser tab. That is a strong claim, and it is checkable: open your browser's network tab, run any tool, and watch nothing leave your machine. But "your files never leave your browser" answers only one question, who else's servers might see your data. It says nothing about the dozen other ways a document, a photo, or a secret actually leaks. This page states, tool by tool, what each one protects against and, just as importantly, what it does not.
What running in the browser does not mean: it does not mean the code is open to inspection today (see Open Source, below). It does not mean the device you are using is trustworthy, malware, a compromised browser extension, or a keylogger on the machine can see everything regardless of where computation happens. It does not mean the person you send a file to afterward will handle it carefully. Client-side execution removes one actor (us, and any server) from the list of parties who could see your data. It does not remove every other actor.
Built for: people who need to send, store, or produce a document without handing a copy to a third-party server, freelancers redacting a client contract, journalists checking a leaked document for hidden authorship, someone scrubbing GPS data before posting a photo, a small business splitting a credential so no one employee holds it alone.
Not built for: anyone facing a nation-state adversary, an adversary with physical access to your device, or a legal proceeding where the other side already has subpoena power over your device or cloud accounts. Nothing client-side JavaScript can do defeats a compelled device search, a hardware keylogger, or a state-level intercept upstream of your browser. If that is your threat model, this is the wrong tool.
Protects against: the single most common redaction failure, a black rectangle drawn over live text that remains copy-pasteable underneath. SEAL rasterizes the page to an image and burns the redaction into the pixels, so any extraction tool returns nothing where the box is.
Does not protect against: redacting the wrong region (human error in selecting the box), or metadata elsewhere in the same PDF that is not part of the visible page content, run X-RAY on the same file for that.
Protects against: nothing by itself, it is a read-only scanner. What it tells you: real author name, total editing time, tracked-changes text that was "deleted" but is still in the file's XML, leftover comments, and template or company metadata.
Does not protect against: anything once you have already sent the file, it has to be run before you send it, on your own copy.
Protects against: authorship and editing-history leakage, author, last-saved-by, revision count, timestamps, company or manager fields, template path, custom properties, session identifiers, comments, and text that was deleted under tracked changes but persists in the saved file's XML even after changes are "accepted."
Does not protect against: hidden worksheets or links to outside servers, which SCRUB reports rather than removes, because deleting either can silently break a document the owner still needs, that decision is left to a human.
Protects against: GPS coordinates and other EXIF data embedded in a photo file.
Does not protect against: anything visible in the photo itself, faces, license plates, backgrounds, reflections. That is a different problem CLOAK does not attempt to solve.
Protects against: macros, ActiveX, OLE embeds, DDE fields, external template and image references, and PDF-side JavaScript, launch actions, and embedded files, the mechanisms a malicious document uses to phone home or execute code on open.
Does not protect against: a threat already embedded in a format DISARM does not parse, or content-based social engineering such as a convincing but harmless-looking attachment.
Protects against: accidentally shipping credentials in a text file or Office document, API keys, connection strings, card and SIN numbers, tokens, and high-entropy strings that look like secrets.
Does not protect against: a secret it has no pattern for, or one deliberately obfuscated to avoid detection. This is pattern matching, not a guarantee of completeness.
Protects against: pasting raw personal data into a third-party AI tool, by swapping it for placeholders you can reverse locally with a key file.
Does not protect against: the AI provider's own logging of whatever you do send them, or a mis-detected entity that ALIAS's pattern rules miss, it is not a perfect named-entity recognizer.
Protects against: a file passing through a third-party server's storage in transit, via direct WebRTC between two browsers.
Does not protect against: a compromised endpoint on either side, or network-level metadata about the fact that a transfer happened.
Protects against: any single share holder reconstructing a secret alone. Fewer than the threshold number of shares reveal zero information about the secret, not "some", zero.
Does not protect against: collusion among enough shareholders to meet the threshold, or a weak secret chosen in the first place.
Protects against: a file sitting in cleartext at any storage point between you and the recipient.
Does not protect against: the recipient being careless with the decrypted result, or forgetting the passphrase. There is no recovery mechanism, deliberately, because a recovery path is also an attack surface.
Protects against: needing the recipient to have any particular software, real encryption packed into a single file that decrypts in a browser, including offline.
Does not protect against: a weak passphrase (the strength meter is advisory, not enforced) or the file size limit. A capsule is visibly a capsule, it does not hide that the file is encrypted.
Protects against: a casual viewer noticing that a cover image carries a hidden payload.
Does not protect against: statistical steganalysis by someone specifically looking for the technique's artifacts, this raises the bar against casual inspection, it is not undetectable to a dedicated analyst.
Protects against: a casual inspection of a lost or stolen device revealing your real workspace, a second PIN opens a decoy instead.
Does not protect against, and must not be used against: compelled disclosure in a legal process, a border search, or any context where refusing to unlock is itself the risk being managed.
Protects against: needing a network connection or a USB drive, itself a malware vector, to move data to or from an air-gapped machine.
Does not protect against: a camera or screen in the room capturing the codes, or a file exceeding practical throughput.
Protects against: not knowing which copy of a leaked document is whose, a unique invisible marker per recipient survives copy-paste into most places.
Does not protect against: a leak via photograph or OCR of the visible text, which strips the marker, or a recipient who retypes the content rather than copying it.
Protects against: missing a substantive change buried in a long document, by surfacing a change count and flagged differences.
Does not protect against: providing legal judgment about which changes matter, it flags, a human decides.
Protects against: needing third-party e-signature infrastructure for a basic signed record, a signature, an appended signature page, a device-clock timestamp, a hash of the pre-signature document, and a separate verifiable certificate.
Does not protect against: a dispute over whether the signer was who they claimed to be, there is no identity verification step, and this makes no legal-compliance claim about signature standards.
All Record Suite tools are free to build and free to verify by design, a record only has value if the other side does not have to pay to check it.
Protects against: not being able to prove a file set is unchanged later, a hash per file, verified against a later snapshot as unchanged, altered, missing, or new.
Does not protect against: proving when the manifest was made to a third party without an independent timestamp authority, the manifest proves internal consistency, not external, trusted timing.
Protects against: losing track of what you have, in what order, and with what hash, disclosure schedules, custody logs, sworn-style statements, chronologies, exhibit binders, and message-export compilations.
Does not protect against: a document's authenticity being challenged in a proceeding with formal evidentiary rules. None of these tools should be described as "court-ready" or "compliant" with any specific evidentiary regime, that determination belongs to a lawyer in the relevant jurisdiction, not to a browser tool.
Trusted timestamping, third-party attestation, and several other ideas were considered and rejected because they need a server, a network peer, or a third party to make the claim true, a static, client-side page cannot honestly back a "trusted timestamp" or "peer witnessed this" claim without one. A signature product originally specified as making a formal compliance claim was scaled back to what PACT actually delivers: a real signed record, honestly described, with no legal-standard claim attached.
The client-side JavaScript that runs every tool is already delivered to every visitor's browser, nothing about "view source" is hidden today. The repository itself is not yet public. Publishing it would give away no code that is not already shipped to every visitor, and it is the single highest-trust move available for a tool that asks people to trust it with sensitive documents: it would make every claim on this page independently checkable rather than asserted. This is a live decision, not yet made.
If something on this page and a tool's actual behavior ever disagree, that is exactly the kind of report this page exists to receive. Email [email protected] or say so in the Discord.