SUMMARY 1. I'd like to see Plasma Vault automatically create or remove the mounting folders inside ~/Vault/* when opening or closing a vault. This is mostly to 'clean up the residue' of history. 2. I'd like to see Plasma Search and Baloo prevent any evidence of history for any vault in particular, if possible.
(In reply to Odin Vex from comment #0) > 2. I'd like to see Plasma Search and Baloo prevent any evidence of history > for any vault in particular, if possible. Do you have a test case where Baloo indexes a vault? It looks to me that it tries to avoid it....
I don't know as whether Baloo is specific to blame but I've found entries in the Plasma menu search history relating to files inside Vaults. It's been quite a while since I saw that. I've disabled history altogether as well as in numerous editors and such so I don't have a test case I can provide.
(In reply to Odin Vex from comment #2) > ... but I've found entries in the Plasma menu search history relating to files inside Vaults ... This is a bit outside my area of knowledge - but there are also "Recent files" listed, not just search results. If you've opened something inside a vault, it might be worth checking whether this appears as a "Recent file" For the Baloo exclusions, it seems that when a vault is opened, it appears (at least under System-Settings > File Search) as an excluded folder and is therefore seemingly not indexed. When you lock the vault again, that exclusion disappears. As an aside - do *not* manually index any files in a vault, a "balooctl index secretfile.txt" will index the file despite the exclusion. If you follow the defaults and create your various vaults under the "Vault" subfolder, you can add a manual exclusion for $HOME/Vault and Baloo will ignore anything under it. It won't add and remove exclusions. As I said, outside my area of knowledge so I'll defer to anyone who really knows what should happen. YMMV...
> This is a bit outside my area of knowledge - but there are also "Recent > files" listed, not just search results. If you've opened something inside a > vault, it might be worth checking whether this appears as a "Recent file" I don't index them but I've seen them before. It's just been too long for me to remember when and where. > As an aside - do *not* manually index any files in a vault, a "balooctl > index secretfile.txt" will index the file despite the exclusion. I've never had Baloo index anything, I usually hate Baloo (sorry to whoever developed it but I find it useless). > If you follow the defaults and create your various vaults under the "Vault" > subfolder, you can add a manual exclusion for $HOME/Vault and Baloo will > ignore anything under it. It won't add and remove exclusions. I enabled Baloo and did just that to make sure. Kate still shows entries and I'd like for any software that implements a "Recent" list to use KDE (or is that not an XDG thing (yet?)?). > As I said, outside my area of knowledge so I'll defer to anyone who really > knows what should happen. YMMV... Understood, and thanks for the suggestions.
You can disable the "Recent Files" results in "System Settings > Plasma Search". Scroll down for a checkbox... It might be worth trying
(In reply to tagwerk19 from comment #5) > You can disable the "Recent Files" results in "System Settings > Plasma > Search". Scroll down for a checkbox... > > It might be worth trying I disabled all Recent Files-related stuff and Baloo long ago. I found I hated Baloo, the search in Dolphin is entirely worthless at literally searching the filesystem and it's just better to grep.
The issue with Vault files being indexed and available when the Vault is closed is already tracked with Bug 390830; let's make this about the request to automatically create and delete the mountpoints. In the future, please only request one thing in each Bugzilla ticket. I do wonder though... what's the threat model this protects against? If you want to avoid people knowing the names of your vaults, then you can just restrict access to your home folder, right? And if it's about protecting that information while you're logged in and someone is snooping over your shoulder, couldn't they see the names as well when you click on the widget which displays the Vault names? Can you clarify what the benefit of this request would be?
(In reply to Nate Graham from comment #7) > The issue with Vault files being indexed and available when the Vault is > closed is already tracked with Bug 390830; let's make this about the request > to automatically create and delete the mountpoints. In the future, please > only request one thing in each Bugzilla ticket. I was only requesting one thing in this ticket, the bit about indexed files was just a side-comment. > I do wonder though... what's the threat model this protects against? Revelation of contents, destruction of plausible deniability, the usual "models". This isn't just a home-folder restrictions issue and I'm not talking about shoulder-spies. > Can you clarify what the benefit of this request would be? Forget it. The more bugs I see the less I want to report them given things are either ignored or never fixed as "not a bug", the worst.
The request isn't insane; I'd just like to know what use case you have in mind so I can see if there might be a different way to satisfy it. Basically, what's the case where an attacker has access to the contents of your home directory without any vaults mounted, but doesn't also have access to the names via the widget? An evil maid attack where you've failed to use full disk encryption or home directory encryption, or where you've been forced to reveal your FDE password but want to conceal the existence of Vaults from an adversary who isn't aware of the feature?
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.