Thea

You are asking for something impossible, and it is worth being precise about why, because the precise version tells you what to do instead.

Anything your client possesses, the user possesses. A secret in JavaScript is readable. A signed token issued to an anonymous visitor can be requested by anyone. Even in a compiled mobile app the same holds — it is harder, not different. There is no arrangement in which an anonymous client proves it is "the real client", because there is nothing about it that an attacker cannot also have.

The origin restriction you added is worth understanding correctly too: it is a browser policy. It stops another website's page from reading your responses. It does nothing about a script, a command line tool, or anything that is not a browser obeying rules voluntarily.

So drop the goal of authentication and pick up the goal of cost control. That one is achievable.

Worth separating that guarantee from the things that genuinely are shared, because your instinct to ask is a good one and there are real answers nearby.

The page cache is shared. Containers reading the same file from the same host filesystem can share cached pages. That is not a leak of freed memory, but it does mean containers are not as independent as they look, and it has been used as a side channel for inferring what another container is doing.

Hardware side channels do not respect namespaces. The processor's caches and branch predictors are shared between everything on the machine. Container boundaries provide no defence against that class of attack, because the boundary is a kernel construct and the leak is below the kernel.

The kernel itself is shared. One kernel vulnerability affects every container on the host simultaneously. This is the fundamental difference from virtual machines and the main reason multi-tenant platforms often use virtualisation underneath containers.

So: memory contents on reallocation, no problem. Isolation strength against a determined co-tenant, weaker than the mental model suggests.

Even granting real encryption, the gaps against a password manager are structural rather than cryptographic:

• Protected at rest only. Once open, everything is in memory, on screen, and often in a temporary file. A password manager decrypts one entry at a time and clears the clipboard.
• No access control granularity. Anyone who can open the file gets every credential. A manager gives per-item sharing, so a contractor gets the two entries they need.
• No audit trail. You cannot answer "who saw the production database password", which matters enormously when someone leaves.
• No rotation workflow. When somebody departs you must change everything in the file, and nothing tells you what depends on what.
• Copies proliferate. Spreadsheets get emailed, backed up, synced and attached. Every copy is a permanent snapshot of your credentials at that moment, and old copies are not invalidated by changing anything.

That last one is the killer in practice. The exposure is not the file you know about; it is the four copies you do not.

The core principle in this field is worth stating plainly, because it is the whole basis of your position: what separates a penetration test from an attack is authorisation. Not intent, not professionalism, not the quality of the report afterwards. Written permission from the party who owns the system.

Your customer owns their account. They do not own your platform, and on a multi-tenant system they cannot authorise testing that affects infrastructure shared with other customers. They gave permission they did not have to give.

So you are not being unreasonable and you are not obliged to treat the findings as a favour. A competent testing firm asks who owns the target and requires authorisation from them before starting — if the firm did not ask, that is a finding about the firm.

How hard to press this is a commercial decision. But go into the conversation knowing you are the party who was wronged, not the party who failed an exam.

The reason it persists is a straightforward and legitimate trade.

Coverage is universal. Every phone can receive a text. No app, no smartphone, no installation, no account, no battery-dependent hardware token. For a service with a hundred million users of every technical level, nothing else comes close on that axis.

It is enormously better than nothing. The comparison people make is against an authenticator app, and by that standard it is weak. The comparison that matters to a large service is against password-only, and by that standard it eliminates the entire category of credential-stuffing attacks, which is the volume threat.

Recovery has to work for ordinary people. The alternatives fail badly when a user loses their device, and a security control that permanently locks out a meaningful fraction of users is not a viable control.

So it is a rational institutional choice that is simultaneously the weakest option available to any individual user who has a better one.

The reasoning breaks at the assumption that this behaviour is a property of malware. It is a property of a strategy, and strategies respond to what defenders do.

The reason some families check for virtual environments is that a virtual machine used to be strong evidence of an analyst's sandbox rather than a real target. Refusing to run avoided being studied, at the cost of skipping a few real victims — a good trade when virtual machines were rare.

The moment ordinary users are all in virtual machines, that trade inverts. Skipping virtual environments would mean skipping everyone, and the check would be removed in a week. You cannot build a defence out of your adversary's cost calculation when your defence is what changes the calculation.

This is the general shape of the objection, and it applies to a lot of clever inversions of attacker behaviour.

The short version, and it is worth memorising because it settles a lot of questions in this area: anything you can read, a compromised device can read.

Encryption protects the message in transit and at rest. It cannot protect the moment where the message is plaintext, and that moment necessarily exists at both ends — on the screen you read it from and on the keyboard you type it into. Software with sufficient privilege on the device sits inside that boundary, not outside it.

So against a genuinely compromised endpoint, end-to-end encryption provides no protection for the content of your conversation. This is not a weakness in the design; it is a statement about where the design's boundary is, and the boundary was never claimed to include the device.

What it still gives you, even on a suspect device, is worth listing rather than dismissing.

The traffic inspection point deserves expanding because it is the one that generates most of these decisions in banks and similar sectors.

Organisations under regulatory obligations frequently have to be able to see what leaves the network — for data loss prevention, for retention, for monitoring. That is implemented by terminating and re-encrypting connections at a gateway, which requires the browser to trust an internal certificate authority.

A browser that ships its own trust store, and that will use its own encrypted name resolution unless told otherwise, breaks that arrangement by default. The gateway stops seeing anything and the organisation stops meeting its obligations.

It is usually configurable rather than impossible. But "configurable if every managed device is correctly configured" is a weaker guarantee than "not installed", and a security team that has been burned once will choose the stronger one.

On whether it is safe to use one, the honest answer is assume it is compromised and behave accordingly, because you cannot tell the well-managed ones from the badly-managed ones by looking.

A hardware keylogger between the keyboard and the machine defeats every software control listed above and costs almost nothing. A machine that has not been reset since the last person used it looks identical to one that resets hourly.

So the practical rules:

• Do not type a password you care about. Not email, not banking, not anything reused.
• If you must sign in to something, use a one-time code and change the password afterwards from a device you trust.
• Log out and close the browser, and do not rely on private browsing to have removed anything.
• Treat anything you download or leave behind as public.

Browsing, reading, printing a boarding pass — fine. Anything involving a credential — assume it is now somebody else's.