Security & Privacy

GetWebP CLI is designed with an offline-first architecture. Image conversion runs entirely on your machine, and the CLI only contacts the network for license-related operations. This document explains the security model, data practices, and network behavior so you can evaluate GetWebP for personal or enterprise use.

Table of Contents#

• Image Processing: Fully Local
• Data Collection Statement
• License Verification
• Device Identity and Binding
• License Key Storage
• Network Communication
• Token Revocation
• Supply Chain and Binary Integrity
• Security Best Practices
• Privacy Policy
• Contact

Image Processing: Fully Local#

All image conversion happens on your machine. Your images are never uploaded to any server. The CLI reads source files from disk, converts them in memory, and writes the output files to disk. No image data, file names, directory paths, or metadata leave your computer at any point during conversion.

Data Collection Statement#

What GetWebP CLI collects#

What GetWebP CLI does NOT collect#

• Image files or image content
• File names, directory paths, or folder structures
• Conversion settings (quality, concurrency, etc.)
• Operating system version, IP address, or browser fingerprint
• Usage analytics or telemetry
• Crash reports

There is no telemetry, no analytics SDK, and no phone-home behavior outside of the license operations described in this document.

License Verification#

GetWebP uses asymmetric cryptography (RSA with SHA-256 signatures) to verify licenses:

1. Activation -- When you run getwebp auth <key>, the CLI sends your license key and an anonymized device identifier to the license server over HTTPS. The server validates the key and returns a signed license token.
2. Offline verification -- On subsequent runs, the CLI verifies the token signature locally using a public key embedded in the binary. No network request is required for day-to-day usage. The private signing key never leaves the server.
3. Expiry checking -- The token includes an expiration timestamp. The CLI checks this locally; an expired token downgrades the session to the Free tier.

This design means that after a one-time activation, the CLI works fully offline. An internet connection is only needed to activate, check real-time status, or log out.

Device Identity and Binding#

Each device is identified by a one-way SHA-256 hash of the operating system's hardware identifier:

The raw hardware identifier is hashed before it is sent to the server. The server only ever sees the hash -- it cannot reverse-engineer your hardware ID. This hash serves two purposes:

• Device counting -- Enforce the device limit for your plan (e.g., 3 devices for Starter, 5 for Pro).
• Machine binding -- Prevent token sharing by tying the encrypted config file to the originating machine.

If the hardware identifier cannot be read (e.g., inside a restricted container), the CLI falls back to a hash of hostname and username. This fallback is less stable and is noted with a warning.

License Key Storage#

The license token is stored in an encrypted configuration file on disk:

Encryption at rest#

The config file is encrypted using a key derived from the machine's hardware identifier. This provides two guarantees:

1. The token is not stored in plaintext. Opening the config file reveals only encrypted data.
2. The file is non-portable. Copying config.json to a different machine will not transfer the license because the decryption key is different on every device.

File permissions#

The config file is created with the default permissions of the running user. For additional hardening on shared systems, you can restrict access:

# Linux / macOS
chmod 600 ~/.config/getwebp-nodejs/config.json     # Linux
chmod 600 ~/Library/Preferences/getwebp-nodejs/config.json  # macOS

Network Communication#

When the CLI connects#

The CLI contacts the license API server (api.getwebp.com) only in these scenarios:

The heartbeat is a lightweight, fire-and-forget request that runs in the background after the CLI verifies the token locally. It does not block or delay image conversion. If the network is unreachable, the heartbeat silently fails and the CLI continues normally.

HTTPS encryption#

All network communication uses HTTPS (TLS) exclusively. The API base URL is hardcoded to https://api.getwebp.com at build time. There are no plaintext HTTP fallbacks.

Timeouts#

Network requests use short timeouts to prevent blocking:

• API requests (activation, status, logout): 5-second timeout
• Heartbeat: 3-second timeout

If a request times out, the CLI falls back to cached data or reports a network error. No retry loops are used.

No proxied image data#

To be explicit: the CLI never sends image data over the network. Conversion is entirely local. The only data that crosses the network is license-related metadata described in the Data Collection Statement.

Token Revocation#

If the server indicates a token has been revoked (e.g., after a refund or manual deactivation from the dashboard), the CLI immediately clears the local token and status cache. The next conversion session will operate in Free tier mode.

You can also manually revoke a device by:

• Running getwebp logout on the device
• Removing the device from the web dashboard

Supply Chain and Binary Integrity#

SHA-256 checksums#

Every release includes SHA-256 checksum files (.sha256) alongside the binaries. Verify the download before running:

# macOS / Linux
shasum -a 256 -c getwebp-macos-arm64.sha256

# Windows (PowerShell)
$expected = (Get-Content getwebp.exe.sha256).Split(' ')[0]
$actual = (Get-FileHash getwebp.exe -Algorithm SHA256).Hash.ToLower()
if ($expected -eq $actual) { Write-Host "Verified OK" } else { Write-Host "MISMATCH" }

Embedded public key#

The RSA public key used for offline token verification is embedded in the binary at build time. This means the binary is self-contained for verification -- it does not fetch keys from the network at runtime.

Security Best Practices#

• Verify downloads -- Always check SHA-256 checksums before first use.
• Keep the binary updated -- Download the latest version from getwebp.com/download to receive security patches.
• Do not share config files -- The encrypted config is machine-bound and non-transferable by design. Use getwebp auth on each device.
• Log out when decommissioning -- Run getwebp logout before decommissioning a machine to free the device slot and clear credentials.
• Restrict file permissions on shared systems -- Apply chmod 600 to the config file on multi-user machines.
• Use the dashboard for lost devices -- If a device is lost or inaccessible, unbind it from getwebp.com/dashboard.

Privacy Policy#

For the full privacy policy, including data retention and GDPR compliance details, visit:

getwebp.com/privacy

Contact#

If you have security concerns or want to report a vulnerability, please contact:

[email protected]

Related Documentation#