Hi,
I have been working on this for some time and I would like to share it with the community, as I have seen people asking for similar:
The README contains complete information which you can use as a guide. If the forum administrators consider it more appropriate, I can paste it here too (I just thought it might be better to have it just in one place in case of future edits).
Comments and suggestions are welcome.
You may be also interested in this way to automatically update the firefox extensions on DVM start instead of updating them manually from dom0:
Nothing is updated from dom0. What makes you think that?
At first glance I thought you’ll need to run ubo-sync in dom0 to update the extension, but now I see that it’s just a convenient one time script and normally you’ll need to run ubo-update in ubo either manually or using cron.
Still it may considered to update the extension on new DVM start instead of updating it periodically using cron.
At first glance I thought you’ll need to run
ubo-syncin dom0 to update the extension, but now I see that it’s just a convenient one time script and normally you’ll need to runubo-updateinuboeither manually or using cron.
It is not one-time script. It is as-many-times-as-one-wants script. Its only function is to starts/stops relevant qubes, run whatever is necessary in them (not in dom0) and then stop the qubes. The cron job should be set in dom0, e.g. to run ubo-sync every N hours.
Keeping a running ubo and scheduling inside it is not a good idea, as it requires ubo and tb-dvm to run all the time and running more than one torified qube is discouraged. Additionally, it implies extra resources for 2 qubes which need only a very short time to do their job.
Still it may considered to update the extension on new DVM start instead of updating it periodically using cron.
I suppose by DVM you mean the disposable, not the disposable template?
This is sub-optimal for 2 reasons:
That is not only a privacy issue (fingerprintable behaviour) but also means additional traffic (not much but it does matter on limited mobile plans) + extra time to download. If one starts a browser disposable 50 times a day, this means 50 times downloading the same data.
quBO avoids both those problems.
Once you have the extension and the filters locally, you can use them with any Firefox-based browser in any qube (I will add easy support for clearnet Firefox later).
Yes.
The linked guide is not downloading the extension every time, it’s checking in caching qube (e.g. sys-whonix) whatever the extension already downloaded and whatever it’s the latest version and only downloading the extension if needed:
url = 'https://addons.mozilla.org/api/v5/addons/addon/ublock-origin/versions/?page_size=1'
response = requests.get(url, proxies=proxies)
addon_latest_json = response.json()['results'][0]
if not os.path.exists(addon_dest_file) or sha256sum(addon_dest_file) != addon_latest_json['file']['hash'].split(':')[1]:
download_file(addon_latest_json['file']['url'], proxies, addon_dest_file)
OK, so AFAICS, the difference is:
The other method you discuss:
sys-whonix for cachingquBO:
I.e. quBO separates (compartmentalizes) configuration, updates and browsing without requiring changes to existing domUs.
I’m not talking about whatever the guide that I linked or quBO is better to be used, I’m only talking about an idea to update extension/filter list not periodically but on DVM start.
Lets say you have 10 different disposable templates with firefox with different netvms. With quBO if you set cron job to update it every hour then you’ll have to start 11 VMs every hour to update them.
With the linked guide approach it won’t be an issue, but the caching qube will access update servers to check for extension/filter list updates when you start new DVM. And that’s a valid privacy concern.
Personally I’m not sure which way is better but it’s worth considering.
Or at least an idea of periodically updating the extension/filter list in caching qube and transferring the extension/filter list from caching qube to DVMs on DVM start instead of updating the disposable templates looks better to me.
an idea to update extension/filter list not periodically but on DVM start.
Why would you start the disposable template at all, if the extension data is not stored in it anyway?
Lets say you have 10 different disposable templates with firefox with different netvms. With quBO if you set cron job to update it every hour then you’ll have to start 11 VMs every hour to update them.
Is that a realistic scenario, i.e. what is the goal of having 10 different DVMs for web browsing?
I mean: we need a valid actual requirements before considering the approach. Obviously, it is not the same to serve 1, 3, 10 or 200 client qubes.
DVM here is DisposableVM, not disposable template. When you start new disposable qube it’ll get extension from the caching qube.
Well, I have 8 of them for different VPNs. Though my case is rare and 2-3 will be enough for most users.
When you start new disposable qube it’ll get extension from the caching qube.
IMO, the main security advantage of Qubes-Whonix, compared to using a locally running Tor service, is that it separates the gateway and the workstation.
In the guide you linked, the caching qube is sys-whonix, i.e. the actual downloading happens on the gateway itself. This completely eliminates the essential advantages of Whonix’s split-security model.
Well, I have 8 of them for different VPNs.
With the approach from the other thread, you would need as many downloading/caching gateways as the number of different VPNs. quBO uses only one - ubo.
I am not saying quBO is perfect. I surely don’t like that it duplicates data from one qube to another, but since it is not possible to have independent volumes attachable to qubes, I have no better solution for the moment.
See also:
I was interested in using quBO for non-Whonix debian+firefox disposable templates, my bad here, I should’ve point it out specifically at the beginning.
The dedicated caching qube could be used instead of sys-whonix, but this qube should be running all the time so I guess sys-whonix was used as an example to save up resources and not waste them on a dedicated qube.
Why? One downloading/caching qube is enough to serve any number of disposable templates.
Also worth noting for Tor Browser usage case:
I was interested in using quBO for non-Whonix debian+firefox disposable templates, my bad here, I should’ve point it out specifically at the beginning.
Glad we clarified that! 
Well, you can still do it. You would just have to modify the directory tree to the one used by Firefox. Or wait until I do it, as it is in my TODO list.
The dedicated caching qube could be used instead of sys-whonix
I have considered this possibility in the beginning of creating quBO but it is not as simple as it sounds, especially with Tor.
Why? One downloading/caching qube is enough to serve any number of disposable templates.
Because the cacherVM must be between the browserVM and the VPN gateway, i.e. all browser VMs should have netvm=cacherVM. How will the browserVM connect to a desired VPN gateway then? If you set cacherVM to be a router too, you add another function to it (instead of compartmentalizing it). If you compartmentalize it, how will you secure the traffic? - Firewall, complexity… Maybe I am wrong, I don’t know.
I guess I should have used quotes and said “caching” instead of caching.
The idea is not to download the extension with e.g. curl in browserVM and then have the cacherVM in between to cache these downloads.
In the linked guide the browserVM will get the extension from cacherVM using qrexec with something like qvm-copy-from-vm (like qvm-copy-to-vm but for copying the file from VM instead).
When browserVM is started it’ll send qrexec request to cacherVM to get the extension. On receiving this request the cacherVM will check whatever it needs to download/update the extension and then send the extension file back to the browserVM.
The firefox won’t start in browserVM before the qrexec is finished and the extension is copied from cacherVM.
Also worth noting for Tor Browser usage case:
That is in the disclaimer of the README.
Where does it clearly state that it’s strongly recommended by the tor project you do not install any plugins, and doing so can result in you deanonymizing yourself?
something like
qvm-copy-from-vm
This is very different from a network caching proxy. I have considered it when starting quBO but I still need to learn how to do it.
When browserVM is started it’ll send qrexec request to cacherVM to get the extension. On receiving this request the cacherVM will check whatever it needs to download/update the extension and then send the extension file back to the browserVM.
This is a behaviour pattern (fingerprint): someone who always checks if a defined file set has changed, optionally downloads changed files, then starts browsing.
I don’t like the whole idea of the browser initiating a background home call to whatever host for whatever reason. IMO, if a caching VM should be used, it should be completely offline and ubo should start periodically, push files to it, then shut down. No updates parallel to browsing activity.
The firefox won’t start in browserVM before the qrexec is finished and the extension is copied from cacherVM.
Note that this is about Tor Browser in the first place. The possibility that it can be used for Firefox is just a beneficial side effect (a convenience). The goal is to use uBO without additional undesired privacy reducing procedures. Since Firefox is not a privacy-focused browser, I assume that by default the user is fingerprinted when using it. So, stock Firefox privacy is a non-goal.
Check the disclaimer in the README.