Is that really the case? The Chromium documentation states the opposite.

> Why aren‘t physically-local attacks in Chrome’s threat model?

> We consider these attacks outside Chrome's threat model, because there is no way for Chrome (or any application) to defend against a malicious user who has managed to log into your device as you, or who can run software with the privileges of your operating system user account. Such an attacker can modify executables and DLLs, change environment variables like PATH, change configuration files, read any data your user account owns, email it to themselves, and so on. Such an attacker has total control over your device, and nothing Chrome can do would provide a serious guarantee of defense. This problem is not special to Chrome ­— all applications must trust the physically-local user.

https://chromium.googlesource.com/chromium/src/+/master/docs...

At least passwords and cookies are encrypted with DPAPI on windows. Stealers get around it by simply decrypting the vault on the victim's machine and sending the unencrypted credentials back to attacker.

Maybe they only mean that it's locked while Chrome is running, but Chrome docs are about when it's closed?

I think locked in windows means you can't do write operaions. You should still be able to do read-only stuff if I am not mistaken.

Really? I use the `pycookiecheat` python package to read out the cookies from Chrome while it's running no problem. Great for automating certain private APIs that need the correct cookie to keep functioning.