From experience and past communications with some journalism/freedom defenders organisms, trying to get data and help those organizations more directly myself, judgements on their use case is not recommended. Facilitating their use cases is. This is the general problem of enforcing security against needs. If people are not able to do what they intend to do, they will bypass security measures and processes, which outcome is generally worse.
What I read in the previous article is such an attempt to use Qubes to fit a certain “general” use case, which doesn’t go against the compartimentalization for security/prevention mechanisms enforced by Qubes OS.
At current state, and last time I checked, killick’s windows installer helper scripts were nearly reaching Qubes OS compartmentalization goal (Qubes’s Windows tools being last maintained for windows 7 being a limitation of that capacity). I say nearly here, since Qubes non-updated Windows tools were the reason why Windows templates are not really Templates, but more StandaloneVM which misses the compartmentalization goal. Since then, tabit-pro made a lot of progress, which deserved a Qubes News article, while newer version of Windows Tool is still not being packaged, nor distributed per Qubes OS yet (unless that changed and I missed something, which should definitely deserve another Qubes news). But when that updated tool will be distributed, I do not see any reason why Kellick’s repo would not get traction to include that work and facilitate deployment, to a testing point where that work can as well be deployed per Qubes in main repositories. I personally do not see any contradiction into using Windows Templates as a base for disposable qubes, with internet through Whonix, or without any netvm associated if a use case justifies it. But I agree with you that current state of Windows support is not in par with the compartmentalization guarantee as of now.
Hear me out here, having Windows templates, permitting to create Windows qubes with proper compartmentalization, is still desired and requested per certain use cases. Not providing for those use case or judging those needs would get in the way of filling such use cases and requirements. Being able to deploy proper Windows templates for such organizations is not to be dismissed and should still be a priority. That definitely facilitates onboarding, and a really good way to transition out of Windows.
As for your point on installing software in dom0, I did not see anything in the article (WiP as I see) that is really concerning. Installing tlp, instead of powertop, is actually better at controlling power usage since tlp is made to talk better with sensors (again, on newer hardware) from usage from past personal tests, but suggesting tlp usage is again a liability problem for anyone that would decide to deploy that. Again I agree with you that adding software under dom0 is to be made really cautiously, but better hardware control is needed if not using computer on AC adapter all the time. Again, I do not deploy powertop myself for others, but I wish I could, since I receive a lot of messages about battery draining, which would be partly mitigated by powertop --autotune
, where higher gains are attained by tlp deployment. But I do not feel comfortable at all deploying patch, make and cups-client that comes with installing tlp in dom0 without further modification. But if one justifies longer battery life to be more important than the risks associated in having those risky tools into dom0, who am I to judge. Ideally, those risky tools should not be deployed under dom0. Again, the problem there is not tlp itself, but forced dependencies and automatic download of such dependencies. And the liabilities into deciding for a user which will not witness such dependencies and will be unaware of attached risks. But we must agree that having 7 hours of battery time vs 3 is impactful to say the least and might be needed in some use case. Fact to remember is always “it depends”. And this is where things are complicated.
From my experience and communication with groups that would desire to deploy such pre-packaged deployment, liability issues are the main problem as of now for anyone trying to pre-deploy anything prepackaged. Those organizations have problems endorsing the usage of some software versus the other, and prefer to let the user choose for himself, to not have any liabilities.
So I would go to precedent posts recommendations as well. The need, now, is to get data points from journalists. Some organizations are willing to have some of their employees participate in such a focus group.
As said previously, and since 2018, FPF is testing Qubes for their SecureDrop workstation Partnering with the Freedom of the Press Foundation | Qubes OS. This is to address a really defined scenario.
They are also interested into having Qubes deployed for journalist’s day to day work. But as you can imagine, the prior use case is way more easy to scope: the goal is to get SecureDrop submissions and be able to deal with those in a really confined way, permitting to deal with untrusted files and producing output that is exportable without compromising source related information in any way. An isolated workstation that never leaves a confined area, for that specific scenario. Going further and for them to suggest/propose/deploy or create deployment guides and/or salt recipes for such a vague “journalist” use case scenario comes with all those liabilities. And having experience of my own into deploying such applications and customized workflow myself leaded to many challenges to say the least, leading me to reduce the customizations and the pre-installed software myself, leading to more support time with the majority of the customers.
As said in other posts on this forum, I think the end solution might be a mix of the following:
- extrepo and ext-repo-offline being deployed and back-ported to Qubes repo in time. Now available into bookworm unman’s debian-12 template. This will permit documentation to fill the gap of enabling custom repositories securely.
- working caching update proxy (cacher project from unman being fascinating solution), well tested and stabilized. So that salt recipes that specialize debian-minimal templates are doing what they intend to do and nothing else, reducing liability issues into promoting one thing or the other, while minimizing download throughput required to maintain all those specialized templates (otherwise, having 6 specialized templates for multimedia, redaction, communication, etc will consume 6x the bandwidth which does not fit the bill here for precarious requirements. Nobody has time to wait for the same updates to be downloaded 6x including repository data.)
- Have Windows Templates if needed and be able to compartmentalize usage as in any other Templates, including disposable Windows Template.
And then, in parallel, understand and fill the gaps in upstream projects, like extrepo to have the tools required available. Have tlp not depend on make patch mailx?
And then, create salt recipes to address those needs is form of use cases. But we need use cases. And definitely not to judge them at first sight. But understand them, play with them. And come with alternatives that do not change their use cases.