You're on the road, your phone has no signal, and you need to rebook a hotel fast. At the front desk is a business- center PC, the browser is open, and a friendly attendant tells you to "just sign in". You hesitate a beat, think of two alarming Reddit threads you once read, and type your Gmail password anyway. A week later you learn your account was taken over at the same time you were at that kiosk.
Shared computers aren't necessarily malicious, but they aren't yours. You don't know what runs in the background, whether passwords get saved, whether someone nearby is watching, whether the browser store has a keylogger disguised as an extension. The risk is real; the practical advice is usually vague. This post sorts out what actually happens, and shows a setup that sidesteps the problem.
What shared devices actually capture
Keystrokes. On a compromised device, a small keylogger captures every password you type. Hardware keyloggers between keyboard and USB port are one variant; software keyloggers disguise themselves as system services and are invisible to non-admin users.
Stored passwords and autofill. When the browser offers to save your password and you accidentally click "yes", it lands in the local password store and is recoverable by any later user, often behind only the OS password, which you know, but so do the machine's owner and their family.
Browser history and cookies. Even after a clean logout, URLs and session cookies often sit one "History" click away. Incognito helps, but only if you remember to use it, and only against local traces, not keyloggers or screen recording.
Clipboard. Copy a password from a manager and it lands in the system clipboard until something else overwrites it. Many clipboard managers silently log what's been copied.
Three scenarios, three risks
The hotel or library kiosk. The PC is public, managed by a non-technical person, often running outdated software, and rarely cleaned between users. The baseline risk is a keylogger someone installed before you. The probability isn't huge; the worst-case outcome is a full account compromise.
A friend's computer. The device is personal and probably not malicious, but you don't know its state. A good friend may have installed a browser extension that logs every password field. Worse, your password ends up in their browser password store if you accidentally save it.
A colleague's work laptop. Here the IT department joins the picture. Work laptops often run endpoint monitoring that logs keystrokes and browser traffic. It isn't malicious, but your personal password ends up in the logs of an employer who hasn't even hired you.
Classic precautions, honestly rated
| Measure | Stops keyloggers | Stops cookie theft | Practical |
|---|---|---|---|
| Incognito mode | No | Partial | Yes |
| Password manager + autofill | No | No | Only if installed |
| Log out after session | No | Yes | Yes |
| Clear browser history | No | Partial | Yes |
| Hardware key (FIDO2) | No | Yes | Only if prepared |
| Cloud browser | Yes | Yes | Yes |
Incognito and logging out solve the cookie problem, not the keylogger problem. A hardware key protects the login moment itself, but not the session afterward; if the attacker has an infostealer on the device, they grab the session after you authenticate. For more on that path, see Session Hijacking.
The only measure that's effective against every relevant attack on shared devices is to not let the login happen on the device at all.
Why a cloud browser dissolves the problem
A cloud browser is a browser running on foreign infrastructure that streams only its picture to you. You see it in a tab on the local browser, but the real processing happens in a disposable VM in a datacenter. When you type your password, this is what happens: the characters travel as an encrypted packet to the remote session, which uses them inside its own browser form and then sends the result encrypted to the authenticating service. Nothing of this touches the local machine at any layer a keylogger could attack, because the password never exists on the local machine as a password, only as an encrypted stream.
At the same time, no session cookie is left on the shared device, because the cookie lives in the cloud container, which is thrown away when you close. Autofill and password storage don't even run locally. The browser history only contains the URL of the cloud browser itself, not the sites you visited inside it.
In short, the local machine is no longer part of the login path. It's a screen and a keyboard proxy passing encrypted events along.
A practical workflow
For the rare case you genuinely have to work on someone else's device, this is enough.
- 1
Don't open the local browser, open a cloud browser
The local Chrome or Edge installation stays untouched. You start a cloud session in a new tab. - 2
Log in to your password manager vault once
Inside the cloud browser. From there, autofill handles every other login. The only secret you ever type on the guest keyboard is the master password. - 3
Use one-time 2FA for high-stakes accounts
If you have a hardware key, plug it in only for as long as the login takes. For TOTP, a code from your phone is fine. - 4
End the cloud session deliberately
Not just the tab, the session. Hitting "End session" tears down the cloud container. What remains on the local device is a browser tab history showing only the cloud service's URL.
Ready to unlock desktop power on any device?
Try Browser.lol free and experience true mobile productivity.
Start Your Desktop BrowserNo downloads required • Works on any device
