Text & everyday tools · Password Generator
Generating a password on a shared computer: clipboard and history risks
· Why it matters
passwords shared-computers clipboard
Explains where a freshly generated password can linger on a shared machine — clipboard managers, browser autofill prompts, page history, form autosave — and how a tool that stores nothing helps but does not solve everything.
The password that stayed on the hot desk — the places a secret can remain after you log out of the website
A hot-desk or library machine can retain or expose a credential through software ToolAcre does not control: keyboard capture, screen observation, clipboard managers, browser profiles or hostile extensions. Logging out of an account does not prove those layers forgot what appeared. The project’s own limitations page therefore says not to generate credentials on a shared or untrusted device.
Local processing removes a ToolAcre server copy, but it does not make the endpoint trustworthy. This distinction matters because “nothing is stored by the page” can be true while the operating system or another process records the same value. The safe recommendation starts with device control, not a cleanup ritual after exposure.
The clipboard — clipboard history features and managers that keep the last dozen copies
ToolAcre writes to the clipboard only when Copy is pressed and only through `navigator.clipboard.writeText`. It does not inspect whether clipboard history is enabled, enumerate prior entries or clear them after a timer. The temporary “Copied” label resets after 1.6 seconds, but that visual feedback has no effect on clipboard contents.
If clipboard permission is missing or refused, the page reports the failure and suggests manual selection. Manual copying can still reach an operating-system history. Do not interpret the absence of an automatic fallback textarea as automatic cleanup; it merely keeps the live credential out of a temporary form field.
Browser features — autofill offers, session restore and form data that survive closing a tab
Browser features vary outside this codebase. ToolAcre does not call autofill, session restore or form persistence APIs, and it renders output in a paragraph rather than an input. That design reduces accidental form submission and built-in field handling, but it cannot certify what an extension or browser profile records from page text.
Closing the tab discards ToolAcre’s in-memory state, yet a screenshot, accessibility capture or extension may already have observed the output. A shared profile may also sync unrelated browser data. These risks are reasons to avoid the machine, not reasons to promise that clearing one history menu repairs every possible copy.
What the generator itself can leave behind — and why a tool with no autosave, no history and a Clear data control leaves nothing
Inside its own state, the generator holds one string. Pressing Generate replaces it; changing a setting that changes meaning clears it; reloading or navigating away loses it. Source-level tests prohibit writes to localStorage, sessionStorage, cookies, IndexedDB, Cache Storage, URLs and the console. There is no generated-value history.
The workbook says a Clear data control exists, but the interface has no such button. That contradiction requires a heading correction. The value can be replaced or cleared by settings and navigation, but claiming a dedicated control would misdescribe the shipped UI. The current DOM value remains readable until one of those actions occurs.
What the generator leaves in its own page state: one replaceable value and no stored history
A routine that generates first and promises to change the credential later still creates an unnecessary exposure. On a machine you do not control, do not generate the live credential at all. Wait until a trusted device is available, follow the destination’s approved process and create a unique value there.
If an account must be accessed from a public terminal, use whatever temporary or delegated access method the service explicitly provides rather than inventing a credential-handling workaround. ToolAcre cannot assess those alternatives. Its only defensible shared-machine guidance is the boundary already stated in product content: use something else.
The safer shared-computer routine is not to generate a live credential there
Imagine needing to create an account while away from your own device. Instead of opening a generator at the library, postpone the account setup or use a trusted managed device under an approved process. Once on that device, verify the generator page, let the list load, create one value and hand it directly to the intended manager or form without publishing it.
The example intentionally contains no generated password and no steps for sending one between devices. Transmission would create another copy and could defeat the endpoint decision. The lesson is about timing and trust: move generation to the trusted context rather than trying to sanitize an untrusted one afterward.
Worked example: postpone generation until a trusted device is available
A keylogger or compromised browser can capture any text the user types or sees. No local generator, clipboard reset or history deletion is sufficient against software with that access. The tool also cannot detect screen recording, shoulder surfing or firmware compromise from inside a tab.
These limitations are why a generated value is not labelled safe for every threat model. Cryptographic selection protects the choice process; it does not cleanse the display environment. Security claims must end where the implementation’s visibility ends.
The takeaway — the Password Generator keeps nothing between visits, which removes one risk; the routine handles the rest
ToolAcre keeps no persistent history, sends no Generate request and copies only on demand. Those properties remove specific copies under the page’s control. It does not clear the clipboard automatically, provide a Clear data button or make a shared endpoint safe.
Use the absence of storage as one verified product fact, not as permission to generate on any machine. Trust the device first, keep each credential private and unique, and use a password manager or destination workflow for storage rather than expecting a generator to manage the result.