GNOME Bugzilla – Bug 757452
Privacy purging misses gvfs
Last modified: 2021-06-09 16:10:30 UTC
In Gnome 3 > Settings > Privacy there are concise and reasonably clear options to control account-wide private data. "Clear Trash" empties the trash; "Temporary Files" deletes ~/.cache. "Clear Recent History" wipes the virtual gvfs recently-used folder (which I have not found on disk yet). These functions some history, leaking it. I noticed this first because Evince would still remember my page numbers even after I cleared my history. After grepping, I discovered that gnome is recording files opened plus a bunch of other data about how I use my machine in files scattered throughout ~/.local/share/gvfs-metadata/ ~/.local/share/zeitgeist/ For example, if I erase ~/.local/share/gvfs-metadata/home then Evince finally forgets about the files I'm working on. To reproduce: - open a pdf in Evince, and scroll to a random page; leave it open for a minute or so (there seems to be a syncer on a timer?) - close and reopen the pdf; confirm that it is at the same page; close it - Use the GUI to erase as much as the GUI will let you erase: Settings > Privacy > {Clear Recent History, Empty Trash, Purge Temporary Files}} - reopen the pdf; it will still be at the same page; close it; - rm ~/.local/share/gvfs-metadata/* - reopen the pdf; confirm that it is at the start of the file I would expect that "Clear Recent History" would also erase gvfs-metadata along with whatever Zeitgeist is doing. It's not obvious where these logs are stored (I spent months hoping for a clue in some hidden folder named "evince"). Now, Gnome is not responsible for every piece of data on a machine. That would be unbounded (though, perhaps, as a UX issue, the Privacy pane should explicitly mention that it is only erasing Gnome's logs, like how Chrome explains that your ISP can still log you). ~/.lesshst and ~/.bash_history and ~/.mozilla are not Gnome's problem, but GVFS and Zeitgeist *are*. (It's super useful that Evince remembers state like this, but until today it was an unsettling mystery that Evince knew more about me than I knew about it). I am seeing this on Arch Linux with the latest Gnome, but it's been like this since the Privacy panel came out. Here's the package info: $ pacman -Qi gnome-control-center Name : gnome-control-center Version : 3.18.1-3 Description : The Control Center for GNOME Architecture : x86_64 URL : http://www.gnome.org Licenses : GPL Groups : gnome Provides : None Depends On : accountsservice cups-pk-helper gnome-bluetooth gnome-desktop gnome-online-accounts gnome-settings-daemon gsettings-desktop-schemas gtk3 libgtop libnm-gtk sound-theme-freedesktop upower libpwquality gnome-color-manager smbclient libmm-glib libgnomekbd grilo clutter-gtk libibus cheese libgudev Optional Deps : system-config-printer: Printer settings gnome-user-share: Bluetooth and WebDAV file sharing rygel: media sharing vino: screen sharing [installed] openssh: remote login [installed] Required By : None Optional For : gnome-shell Conflicts With : None Replaces : None Installed Size : 17.23 MiB Packager : Jan Alexander Steffens (heftig) <jan.steffens@gmail.com> Build Date : Wed 28 Oct 2015 06:36:14 PM EDT Install Date : Fri 30 Oct 2015 11:26:52 PM EDT Install Reason : Explicitly installed Install Script : Yes Validated By : Signature $ pacman -Qi evince Name : evince Version : 3.18.1-1 Description : Document viewer (PDF, Postscript, djvu, tiff, dvi, XPS, SyncTex support with gedit, comics books (cbr,cbz,cb7 and cbt)) Architecture : x86_64 URL : https://wiki.gnome.org/Apps/Evince Licenses : GPL Groups : gnome Provides : None Depends On : gtk3 libgxps libspectre gsfonts poppler-glib djvulibre t1lib libsecret desktop-file-utils dconf gsettings-desktop-schemas gnome-desktop libarchive Optional Deps : texlive-bin: DVI support [installed] gvfs: bookmark support and session saving [installed] Required By : sushi Optional For : None Conflicts With : None Replaces : None Installed Size : 12.72 MiB Packager : Jan Alexander Steffens (heftig) <jan.steffens@gmail.com> Build Date : Wed 21 Oct 2015 01:35:12 PM EDT Install Date : Tue 27 Oct 2015 05:56:24 PM EDT Install Reason : Explicitly installed Install Script : Yes Validated By : Signature
Zeitgeist isn't part of GNOME, so we're not going to touch that. Ross, Ondrej, should we nuke the gvfs metadata when clearing history in the Privacy panel?
(In reply to Bastien Nocera from comment #1) > Zeitgeist isn't part of GNOME, so we're not going to touch that. > > Ross, Ondrej, should we nuke the gvfs metadata when clearing history in the > Privacy panel? Hmm, the gvfs metadata is kind of like an abstraction of xattrs and anything could be stored in them. I guess this would be equivalent to a "Clear some application data" button which is inconsistent. On the other hand, the data that is stored in gvfs metadata is probably _mostly_ history and so it wouldn't be a problem clearing it. Not sure about this one.
(In reply to Ross Lagerwall from comment #2) > On the other hand, the data that is stored in gvfs metadata is probably > _mostly_ history and so it wouldn't be a problem clearing it. gnome-documents uses GVfs metadata for storing bookmarks. I don't know if that can be classified purely as "history".
Metadata database is used for wide spectrum of info and it doesn't make sense to clear all of them. I personally don't know all use cases and all applications using metadata. Most common usage is storing position in files and other view preferences (e.g. gedit, evince, nautilus). But it is also used for storing bookmarks as Debarshi pointed out... It was partially discussed in Bug 597017. I agree with Alex, who wrote there: "Say you tag a file as "important" or add a comment about it, or add an emblem. Why would you want to remove that after a few hours?"
To me, this means that the metadata should rather be saved as an xattr, or on per-application basis (inside evince's cache in this case).
Does moving the metadata on another place solve anything? Metadata will be still there and "Clear Recent History" button won't clear them...
(In reply to Ondrej Holy from comment #6) > Does moving the metadata on another place solve anything? Metadata will be > still there and "Clear Recent History" button won't clear them... Yes, because then the metadata is then the applications' job, just as removing history and cookies from a web browser.
I am happy that this has sparked debate. I was worried it might fall on deaf ears; that in the wash of all the other usability bugs you need to deal with the security ones would slip under. Pushing the privacy issue to applications doesn't solve the problem, it just makes it more likely to get forgotten. If Gnome is going to provide these "Clear History" buttons then they should actually do what they say and cover everything, or else they are dangerously misleading. As an end user, it is very difficult to know just what my computer is tracking about me. I see the gnome-control-center Privacy panel as a great place to lead the way in making it very clear what my system knows and helping me control it, even if getting to that point won't happen immediately. Gnome can compete with Windows's laughable excuse for a system-wide privacy policy <http://www.thewindowsclub.com/privacy-settings-windows-10> I can see that Bug 597017 is the right place for discussing the bigger issues here, so I'm going to take most of my discussion over there.
"Clear Recent History" erases ~/.local/share/recently-used.xbel, which is the file spec'd by http://www.freedesktop.org/wiki/Specifications/desktop-bookmark-spec/. UX-wise, I would expect it to also erase other forms of desktop app history, but of course that's difficult at the moment for reasons discussed in Bug 597017. "Empty Trash" erases ~/.Trash-$UID/ and everything in .Trash-$UID/ folders at the root of mount points. This is good, to have a redundant option to centralize data controls. But what does "Purge Temporary Files" do? It doesn't erase ~/.cache (aka $XDG_CACHE_DIR), which is what I would expect it to do.
(to be clear: this contradicts my comment in OP about "Temporary Files" because I didn't actually experiment)
Can gvfs-metadata at least exclude /tmp/ and /run/ from storage? Those are mounted as tmpfs and not expected to be there after reboots. It makes little sense to store metadata about them. "cat /home/hussam/.local/share/gvfs-metadata/root" shows names of files in /tmp/ and /run/
(In reply to Hussam Al-Tayeb from comment #11) > Can gvfs-metadata at least exclude /tmp/ and /run/ from storage? Unless you want your desktop to stop working, that's a very bad idea.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.