Goal: Ensure the Inspera Integrity Browser (IIB) launches an exam that is authentic and runs the expected build.

IIB uses multiple-layered integrity controls that together provide “defense in depth.” These checks begin before installation and continue at download, install, startup, and runtime. They verify the app’s origin, content, and state, and they fail-safe (block or degrade) when authenticity cannot be established.

How integrity is ensured

• Signed installers (Windows and macOS)

Installers are signed with platform-trusted code-signing certificates. The OS verifies the signature to confirm the package was produced by Inspera and has not been altered since signing.

• Code signing of the application binaries

Post-install, key executables and libraries remain signed. The operating system and IIB’s own checks validate these signatures before launch and when loading sensitive modules.

• Notarization on macOS

On macOS, IIB is submitted to Apple for notarization. Gatekeeper validation confirms the app is notarized and unmodified; otherwise, the OS prevents execution without user override.

• Cryptographic hashing and “digital fingerprint.”

Each build has computed cryptographic hashes for the installer and core binaries. During download, installation, and startup, the app (and distribution pipeline) compares calculated hashes to expected fingerprints to detect any change in content.

• Runtime integrity checks

At launch and periodically, IIB verifies the integrity of key files, embedded resources, and configuration. Suspicious changes (unexpected size, signature, or checksum mismatch) cause the app to reject exam launch or switch to a blocked state.

• Server-side verification and attestation

When connecting to Inspera Assessment, IIB presents build metadata (version, platform, fingerprints). The server validates that the client matches an approved release and channel. If verification fails, the session is denied or restricted.

• Update channel verification

Updates are fetched from trusted channels. Manifests and payloads are signed, and their hashes are validated before applying. Mismatches abort the update and keep the prior trusted version.

If verification fails

• Installer stage: OS blocks installation or shows an untrusted publisher warning. Action: acquire the official installer from the approved distribution location and retry.
• App launch: IIB refuses to start the exam or displays an integrity error. Action: reinstall from a trusted source; do not bypass system warnings.
• Server attestation: Exam start is denied or downgraded due to an unapproved build/channel. Action: switch to the approved version/update channel and reattempt.

Best practice: Always download IIB from the official distribution page, avoid third-party mirrors, and keep the application updated. Do not attempt to run exams if any trust prompt indicates the app or installer is unverified.

Tester checks (quick triage)

• Source of installer: Confirm it was obtained from the official distribution page (paste the page URL into the ticket using an inline link).
• Version/build metadata: Capture IIB version and build info from the About dialog or logs.
• Signature status:
  • Windows: Installer Properties → Digital Signatures; note signer and timestamp status. Optionally record PowerShell Get-AuthenticodeSignature output.
  • macOS: Right-click app → Open shows Gatekeeper prompts; collect spctl -a -vv result and codesign -dv --verbose=4 for signature/notarization status.
• Hashes/fingerprints: Compute SHA-256 of the installer and main binary; attach values to the ticket for comparison with expected release fingerprints.
• Runtime and attestation logs: Collect IIB client logs around startup/launch (including any integrity/attestation error codes) and server-side event IDs if available.

Reproduction details: Distribution channel used (stable/beta/internal), network path (proxy/VPN), and any security software that may intercept or repackage downloads.