jo-inc/camofox-browser: technical due diligence, read from its repository

Strings shaped like credentials appear only where fakes are usual: test fixtures, examples, documentation, placeholders and local stacks. They are almost always fakes. Ask someone to confirm that none of them works anywhere, because a real key in a development file is still a real key. 2 other matchs set aside: expired tokens, licence tokens a vendor verifies with a public key, or placeholder text where a key would go. None grants access to anything.

No USER instruction switches away from root, so the process runs with full privileges inside the container. It is a one-line fix and an ordinary expectation, which is why its absence is worth asking about: it usually says more about whether anyone has reviewed the deployment than about this container specifically.

12 of 183 locked dependencies match 20 published advisories in OSV, 7 of them rated high or critical. A lockfile says which version is installed, not whether the flawed code is reachable from this product, so each needs a look. Most are fixed by an upgrade, and the advisory names the version.

Nothing references a structured logging library. Logs that are written to be read by a person are not searchable by a machine, which means incident response here is proportional to how well someone remembers the codebase rather than to what the tooling can find.

83 `print` or `console.log` calls in the service's code, and 2 calls through a logger. Printed lines carry no level and no context, cannot be switched off, and are hard to find again in production.

Nothing in the service carries a request or correlation id, and there is no tracing. When a customer reports a failure, the log lines that belong to their request cannot be picked out from everyone else's.