Windows · macOS · Linux · automatic post-change monitoring
ZSEC Antivirus 0.3 combines a full Windows desktop dashboard with automatic post-change folder monitoring, deterministic local scans, signed data-only rules, encrypted quarantine, reports, health evidence and replacement-readiness interlocks.
Clear boundary: the Windows Community 0.3 graphical client is implemented, packaged, installed and hash-verified from source, with animated local operation status and a reduced-motion control. It remains unsigned and detects after filesystem changes rather than blocking at the kernel boundary, so it is not a protected service or primary-provider integration. Keep the current Windows Security provider or native platform controls active.
Exact delivery status
Version 0.3 packages the same auditable core for each desktop and adds foreground post-change monitoring. Windows now has a source-available graphical Community client; the public macOS and Linux evaluation archives remain self-contained command-line builds. None is a protected background service or primary provider.
Community 0.3: modern dark protection-centre layout with a persistent navigation rail, rounded evidence cards, animated local-operation status and reduced-motion support; full surfaces for scans, monitoring, quarantine, signed feeds, reports, health, security/YubiKey status, replacement gates and settings; plus reversible logon monitoring and CurrentUser DPAPI key protection. Inspect the immutable GUI source.
Community 0.3: native tar archive with a reversible per-user LaunchAgent, FSEvents monitoring, bounded evidence and no root requirement. Native activation still requires macOS validation.
Community 0.3: x86-64 tar archive with a hardened systemd-user companion, inotify monitoring, resource bounds and network denial. Native activation still requires Linux validation.
zero-security replacement-readiness --json returns exit code 2, keep_existing_protection and no override in Community 0.3. Keep the existing antivirus and native security controls active; ZSEC does not uninstall providers or create exclusions.
Automatic protection model
Routine cryptographic key handling happens without password prompts. Community 0.3 keeps quarantine enablement and restore visible because automation must not hide consequential actions.
Start zero-security protect PATH for the directories you want monitored. The native observer starts before the mandatory baseline scan.
Create, modify and move-in events are debounced and checked locally; periodic reconciliation reduces missed-event risk.
When --quarantine is explicit, the implementation authenticates metadata and encrypts a verified recovery object before source removal.
Entries remain inspectable. Restore refuses unsafe paths and never overwrites an existing destination.
Community 0.3 deliberately has no purge command. If the original cannot be removed safely, the operation is reported as incomplete rather than presented as successful quarantine.
Authenticated quarantine
Encrypted quarantine is implemented and regression-tested. Its security properties come from established primitives, key management and authenticated metadata—not a proprietary cipher claim.
A random device key is created once. Windows protects it with CurrentUser DPAPI; the macOS/Linux filesystem-key profile is explicitly development-grade key custody.
Each quarantined object receives a new random AES-256 content key instead of reusing one raw encryption key for every file.
AES-256-GCM authenticates file bytes together with canonical identity, path, hash, size and lifecycle metadata as additional data.
Restore reconstructs and authenticates the same metadata before any plaintext is made available at its destination.
Zero Boundary Algebra records typed quarantine, verification and recovery transitions. It is an audit vocabulary, not a substitute for cryptography.
Community 0.3 does not export the raw device root or claim a recovery kit. Lost-key, revocation and hardware-key recovery require their own verified release profile.
Fail-closed architecture
The product architecture separates the unelevated Windows interface, supervisor and hostile-file parsing. Community 0.3 ships the graphical client and user-scoped CLI companion; privileged enforcement and isolated parser workers remain outside this release.
Architecture target · not a claim that every layer ships today
Evidence before claims
A passing test proves a defined path works. It does not establish real-world malware-detection efficacy. ZSEC Antivirus separates implemented Community capabilities from the additional evidence required for primary-provider replacement.
Deterministic on-demand SHA-256 and exact-byte checks, signed data-only feed verification, structured reports and recoverable quarantine in ZSEC Shield.
Automatic AES-256-GCM quarantine, Windows DPAPI key sealing, authenticated ZBA lifecycle records, per-user automatic companions and bounded health evidence.
Real-time protection, memory scanning, EDR, complete antivirus coverage, zero-day prevention, a clean system verdict or guaranteed protection from attackers.
Separate browser layer · Community 0.4
ZSEC Browser Shields Community 0.4 adds optional High-Risk Browsing. When it is enabled with the master protection switch, two local browser rules block top-level plaintext HTTP navigation and third-party scripts, subframes, objects and WebSockets before those requests are sent.
The extension can block only the two disclosed request classes. It does not inspect messages, renderer memory, downloads or the operating system, and it does not decide that a site is malicious or safe.
ZSEC Antivirus Community 0.3 operates later and separately: it observes selected filesystem changes and runs configured local checks after the event. It does not turn the browser rules into malware detection or pre-access file protection.
Neither product detects mercenary spyware, inspects memory, stops an unknown browser or operating-system exploit chain, proves that a device is clean, or replaces the registered antivirus and native platform protections.
Privacy contract
File hashing, configured rule matching and quarantine processing happen on the device. Community 0.3 has no automatic sample upload, advertising identifier, account requirement or remote-control channel.
Local-first does not mean pretending a connected product never uses a network. Update checks may disclose only the documented product, version, platform, architecture, channel and coarse rollout cohort.
Open-core, clearly labelled
Open source means source can be viewed and modified under its licence. ZSEC Antivirus does not call hidden code “open source,” and it does not treat compilation, minification or obfuscation as a security boundary.
Before primary antivirus claims
Primary-antivirus status must be earned through platform integration, independent testing and exact-release evidence—not a polished dashboard.
Authenticode/Microsoft driver signing, Apple Developer ID and notarization, and signed Linux packages/repositories—each backed by protected signing infrastructure and provenance.
Supported services and drivers, Microsoft onboarding, HVCI compatibility and safe uninstall/coexistence behaviour.
Approved Endpoint Security entitlement, system-extension consent, Keychain vault, Universal 2 hardware coverage and Gatekeeper/XProtect coexistence.
Exact distro/kernel/filesystem support, fanotify mediation, confined services, signed native packages and verified package-manager rollback.
Dated, reproducible methodology plus maintained independent detection, false-positive, performance and compatibility evidence.
Signed staged updates, health halts, tested rollback, false-positive appeals, vulnerability intake, incident response and reliable support.
Questions, answered plainly
No. Version 0.3 adds useful automatic post-change monitoring, but it does not block access at the kernel boundary or register as a primary provider. Keep Malwarebytes, Microsoft Defender, XProtect, Gatekeeper, SIP, Linux security controls and any endpoint agent active. The fail-closed replacement-readiness command is blocked because Community 0.3 has not passed exact-platform signing, integration, efficacy, coexistence and rollback gates.
No. File hashing, configured rule matching and quarantine processing occur locally. Community 0.3 has no sample-upload path; any separate opt-in service would require explicit destination, purpose, retention and sharing terms.
The release-gated implementation is designed to create and protect keys automatically after an operator explicitly enables quarantine for a scan. Selecting a scan scope, enabling quarantine and restoring an item remain visible choices.
Zero Boundary Algebra supplies typed lifecycle and provenance records for events such as quarantine, verification and recovery. Cryptographic security comes from established authenticated encryption, signatures and operating-system key protection—not from ZBA labels alone.
A data-only updater validates current advisory metadata from CISA, Microsoft, Apple and Ubuntu using strict source allowlists, raw SHA-256 provenance, semantic rollback protection and atomic installation. Advisory text never becomes an automatic malware signature or remote command.
No. ZSEC Antivirus follows an open-core model. The scanner, data-only feed verifier, quarantine format, ZBA records, browser rules and public specifications are intended to remain auditable. Optional OEM engines, signing infrastructure and managed services may be separately licensed and are labelled as such.
Build trust in public
Community 0.3 packages post-change companions for Windows, macOS and Linux. The Windows graphical client and companion have live development-machine evidence; macOS and Linux archives were built and smoke-tested in CI, but native activation remains unverified on physical macOS hardware and a supported Linux desktop. Keep the existing primary provider active.