Currently converting documents in bulk on Qubes is slow. One document opens in one disposable qube. This means that more often than not the overhead of VM startup is higher than the file conversion itself.
To solve this problem we could use one single disposable qube for all conversions.
If we consider the risk of documents being able to change each-other relevant, one mitigation would be to use podman within the disposable qube. Then the risk would be as mitigated as it is on non-qubes platforms. It would certainly add some code complexity due to the need to reuse some code components but I think it's feasible.
Challenges
Parallel conversion may become a challenge. I don't know if we can open multiple qrexec calls to the same disposable, unless it's a named one since we the calling VM does not know the dispXXXX name of the one created.
If we choose to use named (destroy-after use) disposable VMs (yes, that's a thing), then it'll be easier because we can target the same disposable with multiple qrexec calls. But this is at the cost of increased attack surface due to some minimal dom0 logic. I go into detail in a similar proposal for the SecureDrop Workstation.
So the most likely scenario with a dispXXXX like disposable is that we'd have to multiplex multiple parallel conversions in the same channel.
However, as it currently stands, we have disabled parallel conversions due to the resources involved. So, even if we don't add parallel conversions it will still be a much faster conversion speed.
Currently converting documents in bulk on Qubes is slow. One document opens in one disposable qube. This means that more often than not the overhead of VM startup is higher than the file conversion itself.
To solve this problem we could use one single disposable qube for all conversions.
The Risk
The major risk I can think of is that this makes it easier for one malicious document can manipulate other files in the same set. https://github.com/freedomofpress/securedrop-workstation/issues/333
The Mitigation
If we consider the risk of documents being able to change each-other relevant, one mitigation would be to use podman within the disposable qube. Then the risk would be as mitigated as it is on non-qubes platforms. It would certainly add some code complexity due to the need to reuse some code components but I think it's feasible.
Challenges
Parallel conversion may become a challenge. I don't know if we can open multiple qrexec calls to the same disposable, unless it's a named one since we the calling VM does not know the
dispXXXXname of the one created.If we choose to use named (destroy-after use) disposable VMs (yes, that's a thing), then it'll be easier because we can target the same disposable with multiple qrexec calls. But this is at the cost of increased attack surface due to some minimal dom0 logic. I go into detail in a similar proposal for the SecureDrop Workstation.
So the most likely scenario with a
dispXXXXlike disposable is that we'd have to multiplex multiple parallel conversions in the same channel.However, as it currently stands, we have disabled parallel conversions due to the resources involved. So, even if we don't add parallel conversions it will still be a much faster conversion speed.