Browser compatibility

Tripwire targets current evergreen browsers. It is designed for modern browser runtimes that support JavaScript, WebAssembly, and the transport APIs required by the client bundle.

​

Supported versions

​

Status definitions

• Recommended — Best signal coverage and strongest automated test coverage. Start here.
• Supported — Works, but some timing and behavioral characteristics differ. Validate your production thresholds on real traffic.
• Validate carefully — Supported in principle, but engine behavior differs and automated coverage is weaker. Verify on real devices before enforcement.
• Supported with device validation — Manual device validation is recommended for touch-heavy flows.
• Unsupported — Tripwire relies on modern browser APIs and does not target legacy engines.

​

What Tripwire requires

In practice, Tripwire expects a modern browser with:

• JavaScript enabled
• WebAssembly support
• TextEncoder and TextDecoder
• Modern fetch support for API transport
• Event APIs used for interaction collection

Some probes and correlation features may work better when browsers also allow cookies, storage, and richer graphics or audio APIs, but those are not equally available on every engine.

​

What is tested today

The current repository includes automated integration projects for:

• Chromium
• Firefox
• WebKit
• Edge

It also includes a manual verification matrix for:

• Safari on macOS
• Chrome on macOS and Windows
• Firefox on macOS and Windows
• Edge on Windows
• iOS Safari
• Chrome on Android

​

Known engine differences

​

Chromium-family browsers

Chromium is the reference path for the current bundle and test suite:

• strongest automated coverage
• best parity across environment and behavioral signals
• best coverage for automation frameworks that target Chromium directly

​

Firefox

Firefox is supported, but some timing and input characteristics differ:

• browser timing behavior can differ from Chromium
• privacy settings such as resistFingerprinting may reduce entropy for some signals
• some behavioral tests are less deterministic than their Chromium equivalents

​

Safari and WebKit

Safari requires more caution in the current implementation:

• the repo’s WebKit test project has several engine-specific skips or relaxed assertions
• some WebKit behaviors differ enough that Chromium-oriented assumptions do not hold
• mobile Safari and other iOS browsers should be validated on real hardware, especially for touch-driven flows

This is why Safari and iOS are documented as “validate carefully” rather than “drop-in parity.”

​

Rollout guidance

If your traffic mix includes Safari, Firefox, or mobile-heavy traffic:

1. Start in report mode.
2. Observe result distribution by browser family, using latest_decision.verdict on list responses or decision.automation_status on session-detail responses.
3. Validate real user flows on your highest-volume browsers and devices.
4. Enforce gradually, beginning with the highest-confidence automated sessions and the most abuse-sensitive endpoints.

​

Embedded browsers and webviews

Tripwire can run in embedded contexts, but compatibility varies by host app and runtime. If you rely on:

• iOS webviews
• Android webviews
• in-app browsers
• Electron or other embedded shells

validate them explicitly before you depend on enforcement behavior.

​

What’s next

• Browser SDK — loading and initialization
• Testing your integration — simulate bot traffic across browsers
• Going to production — rollout checklist