Hi Nautilus team, I'm a university student currently participating in the Google Summer of Code program for QubesOS.[1] Qubes is a security-oriented operating system designed to compartmentalize different areas of your digital life through the use of Virtual Machines, i.e one for Work, one for Banking, one for Personal activities, etc. The idea is that if one domain is ever compromised, the rest are unaffected.
The goal of my GSoC project is to be able to take that up a notch with the concept of untrusted files. QubesOS has a nice feature of temporary, or disposable, VMs. These are virtual machines that you can spin up on the fly, test things in and load up potentially dangerous files, all with the knowledge that whatever happens inside of them will be completely erased once they're shut down. An untrusted file is one that, whenever opened, is opened within a new or existing disposable VM. For instance one may mark their Downloads folder as untrusted, and thus any new files that pop into it from the internet cannot be accidentally opened locally until they are either manually moved out from the untrusted folder or explicitly marked as trusted. Most of the work towards this project has been completed. The final steps involve having tools such as the file manager being made aware of trusted versus non-trusted files. Obviously this problem could be approached in many ways, but it was thought best to create a purpose-agnostic solution that works for Qubes, and perhaps upstream it if it's of any interest to the Nautilus project. The work involves both an adaptation of libnautilus-extension and NautilusPython to allow extensions to be notified when a file is requested to be opened, as well as have the ability to deny that request from the extension. For our use case, this would allow an extension to first check if a file is trusted or not. In the case that it is not, trying to open it locally would be blocked, and instead a request for a new disposable VM with that file inside of it would be fulfilled. In a more general sense, this would allow for the opening of files by a specific program on a basis other than by MIME-type alone. There have been two major rebuttals that I've come across against giving extensions this ability: 1. Could an extension use this maliciously to block the user from opening their files? Yes, if a malicious extension was installed on your system then it could stop you from opening a file in Nautilus. This is sort of a moot point though. Extensions are written in C/Python, which if malicious code is already running within, a bad actor can already do much worse things on your system, such as deleting files or messing with entirely separate programs. In this case, I believe the benefit of giving extensions more flexibility outweighs the potential for any negative actions that extensions are already capable of. 2. Is it bad UX to have an extension block the user from opening a file? If no warning is given or nothing happens, then sure, however the blame then should really fall on the extension itself for not behaving in a predictable manner. It's also bad UX for an extension to change the icon of every file or to add useless menus, but again the responsibility is thus on the extension authors to write their extensions correctly. To wrap this all up, I wanted to get some feedback from the community on this as a concept before I start writing code. I've already spent some time delving into the Nautilus and NautilusPython source and have gotten some great help from folks over on GIMPnet who seem interested. I'm 'anoa' on matrix over there if you want to have a chat :) Do let me know what you think, and best regards. Andrew Morgan [1] https://qubes-os.org -- nautilus-list mailing list nautilus-list@gnome.org https://mail.gnome.org/mailman/listinfo/nautilus-list