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.
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 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.
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.
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?
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.
It’s not really complicated, you can see how it was done in the linked guide as an example.
Yes, periodic (with some randomness) updates would be better from the privacy standpoint.
To be precise in the guide that I’ve linked it’s not a browser that is initiating the extension update but a python script in the cacherVM is doing it before the browser in browserVM is even started.
It’s not really complicated, you can see how it was done in the linked guide as an example.
I don’t “speak” Python but I will see what the documentation offers.
To be precise in the guide that I’ve linked it’s not a browser that is initiating the extension update but a python script in the cacherVM is doing it before the browser in browserVM is even started.
Indeed. That implies a call home even without a browser.
So you can replace the python script that’s just doing the extension download/update with bash script and at the end of bash script add the line above.
Yes, it’s worth considering.
For TB it’s better to make the same configuration for uBO as in Tails (and maybe there is some other configs which are different from default TB) so you’ll at least in the fingerprinting pool of Tails users and not unique.
For firefox with clearnet/VPN I’m using default uBO filter lists.
But for one of the VPNs I’m using additional regional filter list for a specific disposable template.
Thanks but I have no idea what qfile-agent does or how it is supposed to be used. The only info I found is a single sentence mentioning it:
The rpc action for regular file copy is qubes.Filecopy, the rpc client is named qfile-agent, the rpc server is named qfile-unpacker.
That surely doesn’t explain enough. No man page, not even --help. Is there any official documentation about all this?
Yes, it’s worth considering.
OK.
For TB it’s better to make the same configuration for uBO as in Tails (and maybe there is some other configs which are different from default TB) so you’ll at least in the fingerprinting pool of Tails users and not unique.
Perhaps the only way to “hide in the Tails crowd” is to use Tails (not Whonix or Qubes).
AFAIK, Tails explicitly disables uBO’s filter list updater (perhaps it also freezes uBO’s version). Since the goal is obviously to protect anonymity for the general (non-expert) user, these extra measures make sense.
quBO explicitly works to keep everything up to date and assumes a careful user who understands that the more browser features one enables (CSS, scripts, 3p stuff), the more info the remote host can get. This makes quBO useful if e.g. one wants to hide one’s traffic from the ISP and not to be tracked for marketing purposes.
