Zero Hour security and privacy audit.

On 19 May 2026, the Zero Hour extension was put through a full security and privacy audit. Manifest, build config, dependencies, every popup component, every content script, the service worker, and the built artifact actually shipped to the Chrome Web Store. The goal was simple. Find anything that could expose user data, eBay credentials, or your identity, and fix it before it ships.

This page is the result of that audit at a level appropriate for a public document. Methodology, the properties that came out clean, the issues that were uncovered, and the remediation status of each one.

Audit date: 2026-05-19. Extension version at audit time: 1.0.0. Auditor: internal review against the unminified production build.

Headline

No exploitable secrets, no credential exposure, no telemetry, no leak of user IP or identity. A small number of findings were uncovered. All actionable ones were fixed in the same session and shipped in the next build.

What was audited

• The full extension source tree: popup, content scripts, service worker, storage and API helpers.
• manifest.json permissions, host_permissions, CSP, and web_accessible_resources.
• The build config.
• The runtime dependency tree.
• The built artifact actually packaged and submitted to the Chrome Web Store. The same code Chrome loads on your machine.

Methodology

1. Credential and key-pattern scanning across source and built artifact.
2. Dangerous API scan for code-execution and unsafe-DOM patterns.
3. Network call inventory. Every outbound origin in the built bundle was enumerated.
4. Storage audit. Every persisted value was located, characterised, and its lifecycle traced.
5. Cookie and credential handling review.
6. Supply chain review of the runtime dependency tree.
7. Privacy posture review: telemetry, analytics, error reporting, advertising SDKs, fingerprinting.

Positive findings

These are the properties that came out of the audit clean. Every one is verifiable on your own machine by inspecting the unminified production extension.

1. No secrets in the bundle

No API keys, no webhook secrets, no access tokens, no OAuth client secrets, no private keys. .env files and deployment-config directories are git-ignored at the repository level. The only embedded value of any kind is the public Chrome Web Store publisher ID, which is intended to be public.

2. Only two outbound origins

Across the entire built bundle, exactly two destinations receive requests: eBay regional domains for bid placement, and zerohourbid.com for the entitlement check. Nothing else. No CDNs, no analytics, no error reporting.

3. Zero analytics, telemetry, or tracking

No PostHog. No Sentry. No Google Analytics. No Amplitude. No Segment. No Mixpanel. No Hotjar. No Fathom. No Plausible. No advertising IDs. No fingerprinting libraries. The marketing website at zerohourbid.com uses Vercel Analytics for traffic counts. The extension itself has zero telemetry of any kind.

4. Tiny supply chain

The runtime dependency tree of the extension is a handful of packages, all maintained by the React team. No surprise transitives.

5. No dangerous APIs

The built dist contains no dynamic code-execution paths and no unsafe DOM mutation paths. Cookie and network-request privileges that would let the extension read sensitive APIs are not called.

6. Honest manifest permissions

Two permissions remain declared in the manifest from earlier architecture iterations that the current code no longer calls. Both are slated for removal in a future release. They are documented in why these permissions as legacy entries rather than quietly retained.

7. Unminified build, on purpose

The production extension submitted to the Chrome Web Store is the same readability as the development build. Right-click the Zero Hour icon, choose Inspect popup, open Sources. Variable names and comments are intact.

8. No password reading

There is no form, field, or DOM query anywhere in the extension that reads a password input. The eBay sign-in form is never inspected. The popup never asks for credentials.

9. Snipes stay on the device

Active and completed snipes live in local storage on your machine. They are never transmitted. The only identifier sent off-device is a random UUID install ID that contains no PII and exists solely so the backend can recognise Pro entitlements.

Findings and remediation status

Severity	Finding	Status
MEDIUM	Diagnostic captures persisted in local storage without an upper bound. The captures could include short-lived opaque tokens, accessible to anyone with filesystem access to the browser profile (shared-machine scenario).	FIXED. Capture size capped, TTL applied, sensitive substrings redacted before write, and old captures garbage-collected.
LOW	Source maps were shipping in the production extension.	FIXED. Source maps no longer ship in the production build. Unminification is preserved, so DevTools is still useful.
LOW	Thumbnail URL from listing metadata could theoretically point to a non-eBay origin and act as a tracking pixel.	FIXED. Thumbnail URLs are validated to eBay-owned image hosts over HTTPS at extract, persist, and render time. Anything else is dropped.
VERY LOW	Item link href validation. React already blocks unsafe URL schemes at render time, but the persisted item URL was not separately validated as actually pointing to an eBay regional domain.	FIXED. Item URLs are validated against eBay regional domains at both write time and read time.
INFO	The Manifest V3 module system used by the build toolchain exposes the content-script bundles to eBay pages. The exposed files contain no secrets and are the same source already inspectable in the installed extension.	BY DESIGN. Removing this would break the extension. Documented as a transparency property rather than an issue.

What an attacker on a hostile eBay listing cannot do

This was the question that motivated the audit. The answer is unambiguous.

• Cannot steal your eBay password. The extension has no code that reads any password input. None.
• Cannot ship your eBay session anywhere outside eBay. No exfiltration path exists.
• Cannot read your install ID, your snipes, or anything else stored by the extension. Page scripts cannot reach extension storage.
• Cannot trigger an unscheduled snipe. Page content cannot influence the scheduler.
• Cannot learn that you use Zero Hour by embedding a tracking pixel on the listing, after the thumbnail-allowlist fix.

What an attacker who somehow shipped a malicious update cannot do

Chrome extensions are signed by the Chrome Web Store. Zero Hour declares a deliberately narrow set of permissions and host permissions. Any update that tried to add new permissions would be flagged to every installed user by Chrome's permission-change prompt before the update activated.

The philosophy that underwrites all of this

Unminified, on purpose

The norm in Chrome extension development is to minify the production build. Minification strips whitespace, mangles variable names, and removes comments. The shipped Zero Hour extension does none of those. The performance cost on a 500KB extension is negligible. The transparency gain is the entire product proposition.

On-device only, on purpose

Every competing eBay sniper, without exception, asks for your eBay credentials and operates from a server-side data centre. That architecture is older than the JavaScript that makes a browser-side sniper feasible. Zero Hour was built specifically so handing over a password is no longer the price of entry. Your browser already has the session. Nothing else needs it.

No telemetry, on purpose

The temptation in a product like this is to add anonymous error reporting so we can fix bugs faster. The cost is that the user has to trust the anonymisation. We have decided the cost is not worth the benefit, and bug reports come in through support email instead.

How to verify any of this yourself

1. Install Zero Hour from the Chrome Web Store.
2. Right-click the Zero Hour icon. Choose Inspect popup. DevTools opens, attached to the popup.
3. Open the Sources tab. You'll see the extension's full file tree.
4. Open the Network tab and trigger actions. Every outgoing request is logged. You will see eBay regional domains and zerohourbid.com, and nothing else.
5. Visit chrome://extensions/, enable Developer mode, find Zero Hour, click the service worker link to inspect the worker the same way.

If anything in this document doesn't match what you can verify on your own machine, the install on your machine is canonical. Email help@skella.com.au and the documentation will be corrected.