Comment 6 for bug 1996267

> What is there to prove? The documentation *literally* says it is plain
> text.

The documentation isn't the code that is executed. The only source of
truth is code and the proof is in the pudding, namely execution. However
that was not my point at all, you didn't read what I said carefully enough.

You can prove me wrong easily, grep the Chromium state files (or the
whole filesystem if you want) for your password and see if it returns
something. Or else show me the plain text file where it is stored.
Answer: It is

Now I've already investigated the issue and the file where your
credentials are stored is:

--->
% less "$HOME/snap/chromium/common/chromium/Default/Login Data"
".../Login Data" may be a binary file. See it anyway?
% file "$HOME/snap/chromium/common/chromium/Default/Login Data"
.../Login Data: SQLite 3.x database
<---

So much for plain text[1]. You could even go ahead and SQL dump it and
see if you could find the password in the clear. I didn't. Which of
course does not mean it is not easy to retrieve it.

> Also: Any attacker can just copy the entire browser profile to another
> machine and then access the passwords. So he does not have to care about
> the implementation details of the password storage at all.
 >
> On the other side, normal Chrome/Chromium (without Snap and this command
> line argument) is using Gnome Keyring to protect the passwords. In that
> case, the attacker would need the login password or a equivalent secret
> from PAM and friends.

Right. But as I said this was declined by policy reviewers and you are
welcome to follow up in that link.

[1] https://en.wikipedia.org/wiki/Plain_text