Feature Proposal: File Event Handling for Extensions

[Andrew M <anoa openmailbox org>]

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