Don't track history for recent files, ever.

[epgfm]

It's currently possible to clear recent history from the "Go" menu, but there's been requests for a new feature to disable recent history completely for the sake of privacy.

https://ubuntu-mate.community/t/feature-request-privacy-caja-and-folder-history/8698

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/39483713-don-t-track-history-for-recent-files-ever?utm_campaign=plugin&utm_content=tracker%2F651521&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F651521&utm_medium=issues&utm_source=github).

[Tectract]

BUMP 1000000 times.

History tracking should be disabled by default. This is a MAJOR PRIVACY VIOLATION.

[kn00tcn]

uh it's a feature of every consumer workstation OS, not a privacy violation by default, come on

i believe there are some history settings in dconf & also you can set some permissions on ~/.recently-used or on ~/.local/share/ , i dont remember what i actually did to cause the go menu to never fill up & i didnt fully block everything else... then you have to deal disabling history in your image viewer, video player, etc

yes there needs to be an option, but always poke into the OS, you wouldnt know if it's all disabled (look at the shell bags registry key in windows, it's not a user facing history, but it stores folder layouts like icons vs details or column sizes & types for convenience, there is no option to turn this off, you can only reset all folders if you remember to do it, so the only workaround is changing the registry permissions to block new writes)

[lukefromdc]

GTK itself gives an option to shut off history saving. For GTK3 builds (the ones I am familar with, and to which MATE is transitioning), Adding this line gtk-recent-files-max-age=0 to ~/config-gtk-3.0/settings.ini , creating the file if it does not yet exist will shut off the saving of history for ALL the GTK3 apps. For GTK 2 MATE, the old trick of replacing ~/.local/share/xbel with a directory probably still works the way it used to, by blocking saves of history to that file. In GTK3 I know for sure setting max-age=0 keeps that file a bare template with no history saved within it.

When recovery of your history is an actual threat, you really should encrypt the entire operating system, as I do. Encryption is offered at installation by Ubuntu, Mint and many other distros. Even Windows offers this now, though only for their most expensive versions and Bitlocker is not trusted against governmental attackers. Cryptsetup (what we use in Linux) is open source and considered far more trustworty due to the potential for audit by mutually opposing parties making backdoors difficult to hide in the source.

[kn00tcn]

given the constant exploits disaster that is linux security, not to mention my assumption that any app running under the current user has access to the current user's local files (where the history is stored), it seems encryption's only purpose is if you're away from the computer

i think i did that folder trick, but i still see some xbel files with some kind of hash at the end in /.local/share/

(did i see you comment on a phoronix article a week ago? it brought up fond memories of github, hah)

[lukefromdc]

The other xbel files are those made by a single application and not copied to recently-used.xbel because the directory could not be overwritten by a file. Crashes will also generate these extra files. I doubt other applications can read them (due to not having the filename) but a malicious program could simply look for all .xbel files. That's one reason setting history days to zero (which keeps all of these files from logging anything) is the correct approach.

Oh yeah you'll see some of my comments on Phoronix, especially in regards to encryption and security.

[unxed]

Maybe just some tool for wiping (not deleting!) xbel and it's backups?

[kn00tcn]

ran into this earlier https://alexcabal.com/disabling-gnomes-recently-used-file-list-the-better-way/

[cgorgulla]

I have tried setting the parameter gtk-recent-files-max-age=0 but it works to some extend only. Often my History is empty, but sometimes a few files still show up. The problem is that I am connected to several remote sshfs, and sometimes the connection is quite slow. Everytime I try to access a folder with caja it seems it tries to access/check all the files in the history, which takes ages if an ssh connection hangs...

[kn00tcn]

i would expect (cant confirm) the history list is locally stored, not that it pings every single item every time

feel like i saw some other issue thread about slow network drives, but forgot the details

[cgorgulla]

Yes, I can confirm that the history is locally stored in ~/.local/share/recently-used.xbel. Since I set the setting gtk-recent-files-max-age=0 the file is often empty, but not always. E.g. recently I found a LibreOffice document file in there.

Regarding the slowdown of caja which I experience I can confirm that 1) my remote sshfs are related to it, because if I unmount them all is fast again 2) that the history of mate/caja/gtk is related to it, because if I empty the file ~/.local/share/recently-used.xbel the problems of Caja are immediately gone.

Therefore these two circumstances seem to imply that Mate/Caja/gtk seem to access the items in the history everytime when Caja is used.

[Tectract]

Yes, you can make it not remember history by locking this file to root, read only access.

~/.local/share/recently-used.xbel

It's good for privacy but bad for personal useability. All your base are belong to us. Make your time.

[cgorgulla]

@Tectract: The root locking approach seems to work, thanks!

To summarize there seem to be two reasons why people want to be able to disable the history. 1) Privacy reasons 2) Speed/slowdown problems due to remote network filesystems

A much better solution for problem 2) would be to stop Caja/gtk access the history files all the time when Caja is used rather than disabling the history completely. The question is, who is responsible for accessing the history files everytime a folder is changed in Caja? Is it Caja or is gtk?

[kn00tcn]

i actually wonder if it's GVFS, which might also mean the same issue happens to other file managers

[cgorgulla]

The root-locking approach seemed to have not solved the problem fully. The Mate-history is gone, i.e. the "Recent Documents" in the "Places" menu. But in Caja, the History continues to accumulate and Caja getting extremely slow (due to my sshfs), and strangely even "Go -> Clear History" in Caja does not seem to work anymore. Not sure if this is related to the fact that I have locket the file ~/.local/share/recently-used.xbel

[phu9Suop]

I agree with this demand to set logging to zero. I have

user@thispc:~/.local/share$ grep application\ name recently-used.xbel* | wc -l
38918 
user@thispc:~/.local/share$ ls -1 recently-used.xbel* | wc -l
83
user@thispc:~/.local/share$ du -sh
23M .

83 files with 38918 recently used application data of 83 MBytes generated since a fresh install in Nov 2017 of debian stretch with mate. and not anny purging of this data oldest timestamp in ~/recently_used is three month old.

[lukefromdc]

What I found in Caja is this: clear history will delete all history (on my setup anyway) from PRIOR runs of Caja but some or all locations from the current run of Caja will remain. Workaround is to runkillall caja and then clear history, only your home folder should then show. This is with gtk-recent-files-max-age=0 set in ~/.config/gtk-30./settings.ini

[killertofus]

bump