GNOME stores thumbnails in ~/.cache/thumbnails/, regardless of where the pictures are. Meaning pictures viewed on an encrypted or external drive leave a trail in your home folder. GNOME does not communicate this in any way to the user, and none of the 3 buttons to clear history in Settings > Privacy & Security delete thumbnails. Further, GNOME Disk utility's option on whether to save a password or not misleads users into thinking GNOME's security model respects defense-in-depth, when in reality they consider read-only access to a user's home folder to be game over, in contrast to web browsers giving easy ways to clear history or browse incognito.
In other words, everything exposed to the user, as well as their experience with common applications like web browsers, gives a false sense of security.
This was reported to Nautilus, and closed as not in their threat model. Then it was raised to the GNOME design board, but has been ignored for nearly 3 months now. I am hoping posting it here will raise some much needed attention, and at least make the 'Delete Temporary Files' button do what it promises.
As usual GNOME devs ignore the problem, because for them it's not a problem on their software, it's is the users are using their software in some wrong way.
As a mitigating control one can mount the thumbnails directory as tmpfs accepting that it can grow rather large so one must calculate what size to set that tmpfs mount. Also tmpfs is swap backed so one would have to disable disk based swap and use zram or just dont have swap if memory permits. Be sure to set the owner and group to that user or use autofs with variables.
Of course, there are many ways it can be solved or mitigated. The problem is that even very experienced users simply won't know there is anything to solve.
Of course, there are many ways it can be solved or mitigated. The problem is that even very experienced users simply won't know there is anything to solve.
Absolutely agree. Keep fighting the fight. I was just attempting to assist with a mitigating control for anyone reading this. For what it's worth using tmpfs wherever someone can is one way to extend the life of SSD's/NVME for tiny rapid writes such as these. Downside being one may have to buy a bigger RAM kit and RAM prices are increasing.
Another mitigating control would be to encrypt /home but that is loaded with caveats and gotchas especially related to LUKS2 information disclosure.
I feel the modern systems are so complex, there will always be some record somewhere. Thumbnails are an extreme examples, but the filenames themselves can leak via LRU list, logs, history etc...
GNOME stores thumbnails in ~/.cache/thumbnails/, regardless of where the pictures are. Meaning pictures viewed on an encrypted or external drive leave a trail in your home folder. GNOME does not communicate this in any way to the user, and none of the 3 buttons to clear history in Settings > Privacy & Security delete thumbnails. Further, GNOME Disk utility's option on whether to save a password or not misleads users into thinking GNOME's security model respects defense-in-depth, when in reality they consider read-only access to a user's home folder to be game over, in contrast to web browsers giving easy ways to clear history or browse incognito.
In other words, everything exposed to the user, as well as their experience with common applications like web browsers, gives a false sense of security.
This was reported to Nautilus, and closed as not in their threat model. Then it was raised to the GNOME design board, but has been ignored for nearly 3 months now. I am hoping posting it here will raise some much needed attention, and at least make the 'Delete Temporary Files' button do what it promises.
As usual GNOME devs ignore the problem, because for them it's not a problem on their software, it's is the users are using their software in some wrong way.
As a mitigating control one can mount the thumbnails directory as tmpfs accepting that it can grow rather large so one must calculate what size to set that tmpfs mount. Also tmpfs is swap backed so one would have to disable disk based swap and use zram or just dont have swap if memory permits. Be sure to set the owner and group to that user or use autofs with variables.
Of course, there are many ways it can be solved or mitigated. The problem is that even very experienced users simply won't know there is anything to solve.
Of course, there are many ways it can be solved or mitigated. The problem is that even very experienced users simply won't know there is anything to solve.
Absolutely agree. Keep fighting the fight. I was just attempting to assist with a mitigating control for anyone reading this. For what it's worth using tmpfs wherever someone can is one way to extend the life of SSD's/NVME for tiny rapid writes such as these. Downside being one may have to buy a bigger RAM kit and RAM prices are increasing.
Another mitigating control would be to encrypt /home but that is loaded with caveats and gotchas especially related to LUKS2 information disclosure.
The title is misleading. It would be justified if it leaked over network or outside of home directory.
If file history features are a privacy threat then it should be disabled.
The post helpfully gives several scenarios in which calling it a leak is justified, as it endangers the user.
I feel the modern systems are so complex, there will always be some record somewhere. Thumbnails are an extreme examples, but the filenames themselves can leak via LRU list, logs, history etc...