Why would I or majority of users use dispVM for browsing in the first play? People want browser history to be preserved, cache to be used, bookmarks to be saved, auto-login to be working. So, I see no dispVM is most cases in this scenario.
Why? Users do assume and they are right. If Snowden recommends OS as the most secure, everybody calls it the most secure on the market: it is only LOGICAL to assume that browsing in it is not as unsecure as in Fedora mass-market distro.
I like this idea.
Part of my problem with just using whonix workstation for everything is that some apps that access the Internet have to access servers that don’t like tor exit nodes for some stupid reason. (I’m not pointing fingers, but fuck you cloudflare.)
When I try to connect a whonix workstation to a vpn service it results in errors.
A parrot template would solve a lot of these problems if Firefox comes at least a bit hardened. Is there a command I can type to force a 4.1 template to work in 4.2 /s?
Does the Kali template come with a hardened browser? I am not that experienced with Kali. I think it comes with a less hardened browser.
Why not?
Yes this is right.
I’ve applied arkenfox to Firefox in Qubes. It takes a long time and it’s annoying and not intuitive and it does need to be done again whenever there’s a new template. It’s almost as bad as having to customize the tor browser to turn off javascript in about:config every time it updates.
Its not that Qubes needs to keep me secure from spilling a milk. It’s that when nothing comes hardened out of the box it means with every new template then I have to spend an extra 2 hours configuring things to make them harder and when there’s an update I sometimes have to spend another hour.
The extra hours here and there add up. It just doesn’t need to be this way when most people using Qubes want hardening.
I would rather see Firefox not included in templates than included this way. It’s too easy for Firefox to open and then suddenly it’s sending a whole bunch of crap to Mozilla and other trusted partner companies (anyone). It’s different than Firefox coming with Debian and you just configure it once or delete it once.
This is all exactly possible when properly compartmentalized, while for auto-logins it is exactly possible with dispVMs (copying profile to /etc/skel directory of the template then recreating dvm-template) and for bookmarks there is split-browser solution which works across whole Qubes while bookmarks hidden from the outer world and all of them on a single place not spread across countless qubes, and so on, and so on…
When you answer from whom you are defending from, you’d probably get easy solution that doesn’t need such an effort…
Then use the minimal template.
The standard template obviously focuses on usability, it doesn’t cater to your or anyone else special needs, it’s meant to be useable by everyone.
Me as well, and yes Qubes certinaly provides the foundation for the most privacy focused OS you can use. I’ve had fun learning it and know I’ll continue to find ways I haven’t yet explored to increase privacy. I suck in a new topic each day. Security is 100% the foundation that is needed for privacy to even matter. doesnt matter if you’re wearing a ski mask if your ID is taped to your shirt wide open to the world.
I may be mistaken but wouldnt it be easier for the Qubes team to just integrate Mullvad browser as a second shipped browser for standard Qubes? I mean it’s just a mix of Firefox and Tor, seems like a ready to go solution. They already intergrated Tor so why not one of it’s hardened off shoots meant for everday use. unless there’s something about that browser that doesnt play well with Qubes. it also takes the work of the Qubes team of having to keep any configs up to date, it’s Mullvads browser they will handle that for them, they just have to push the updates to Qubes.
Well, even adding an existing fedora package to the dom0 and fedora-* default templates can take a couple of years nowadays. And you want devs to add and support their own QubesOS-specific package with such a huge thing as browser.
If Mullvad browser, or any improved Firefox out-of-box browser, is available in Fedora main repos, then it will be available in Qubes OS. The only realistic solution.
I looked through the preferences set in arkenfox. Even accepting that QubesOS users likely have a strong interest in privacy and ignoring maintenance costs for QubesOS developers there are only a few settings that would actually make sense to apply by default. 2 of them are actually security issues, while the final one is a particularly sensitive privacy issue. There might be a couple of others that would make sense, as I am not familiar with all of the involved technologies - for example, the setting that forces WebRTC to use a proxy if one is set sounds like a good idea on the face of it, but I don’t actually know the implications of WebRTC connections. I’m not going to go through every setting (there are a lot of them) but I will explain the 3 which I think make sense and go through some representative examples of why I think others do not make sense. In one case, the setting that arkenfox sets is actually counterproductive based on the link that they provide as justification, which I see as a red flag that they are not fully thinking through the implications of their decisions (see the section on captive portals). I am speaking as a user with some technical knowledge and interest in customizing QubesOS, but with no responsibilities for maintaining QubesOS.
The 2 security settings are requiring OSCP verification in order to connect to a website and rejecting HTTPS connections that do not support TLS renegotiation (RFC 5746). Both of these features are designed to decrease the likelihood of an attacker impersonating a website. The notes in the “HTTPS Only” section do not apply here because the websites are providing HTTPS, indicating that they have some interest in establishing a secure connection.
Caveat: I do not know how many sites would break with these settings enabled, so it might be that enabling these would make the web unusable for a large number of people, and once adoption is more widespread these will become enabled by default upstream.
Arkenfox disables geolocation. I think that it makes more sense to solve this at the OS level - that is, do not provide a geolocation service to begin with, as this will protect the user regardless of which application is being used. Both the xfce and minimal templates have geoclue2 installed on my machine. I have installed additional packages, but I don’t believe this is the cause: dnf reports that geoclue2 is a dependency for xdg-desktop-portal, which provides support for flatpack (1). Removing flatpack support seems likely to cause problems for a lot of users. It is not clear to me if this is truly required for flatpack, or if it is optional; if it is optional, then I think that removing this package would be a reasonable exception to the general rule of “provide the base distro’s defaults” (saying this as a user who is not responsible for maintaining the images that QubesOS ships). If it is truly required, then it would be worthwhile to work with upstream to make things work well without the geolocation package - although I have no idea how receptive they would be to this.
Personally, I don’t use flatpack so I uninstalled geoclue.
(1) GitHub - flatpak/xdg-desktop-portal: Desktop integration portal
Arkenfox disables captive portal detection and, as justification, provides a link to an EFF article explaining how captive portals cause problems by training users to ignore security warnings (1). However, looking at the documentation for what captive portal detection actually does (2), it addresses the problem described by the EFF by first trying to connect to an HTTP website so that the user will see the captive portal before trying to establish an HTTPS connection. So disabling this setting actually causes the problem that it is ostensibly trying to solve.
(1) How Captive Portals Interfere With Wireless Security and Privacy | Electronic Frontier Foundation
(2) Captive portal detection | Firefox Help
Arkenfox enables HTTPS only mode, which is not a bad idea, but it’s not clear that this is the correct default. For example, I read some blogs from individuals who do not support HTTPS and would be disappointed if my browser would not let me view them. The blogs do not contain sensitive information, they don’t have user accounts, etc, so it’s not clear that HTTPS provides significant benefit. (Unless someone has a particular grudge against this niche audience. I would like it if they supported HTTPS, but I have bigger things to worry about.)
There are a few different settings like this in arkenfox: block things that aren’t as locked down as the could be, but prevent connections to or break legitimate websites in the process. This is a tradeoff that sometimes makes sense, but it’s not clear that this would be a good default even for the privacy-sensitive QubesOS audience. See also the note in the “Telemetry/Crash Reports” section about following upstream.
Telemetry and crash reports is a contentious issue. Many people consider it to be automatically malicious, many people consider sending data to be a responsible action which supports the community. Personally, I enable telemetry for organizations which I feel have treated me respectfully because I do want developers to have the data they need to do their job effectively, but I don’t want that to become an excuse that businesses use to treat people as exploitable resources.
I think that the QubesOS default of “follow upstream’s expectations/defaults” is reasonable here. I would expect that more privacy-sensitive distributions would disable telemetry in browsers (or ask the users if they want to opt-in) while general-purpose distributions (like Fedora) would leave it enabled. The beauty of QubesOS is that it gives me the power to choose who I trust with what, and when. If I am concerned about things like telemetry then Fedora is not the vendor I would go to.
Debian also has this enabled by default which I find somewhat disappointing given my second-hand impression of Debian culture, but that is (possibly) an upstream issue.
TOR browser from whonix-workstation does not have this enabled.
They didn’t integrate Tor: it’s done by the Whonix team, i.e., Community.
See also: What is Qubes’ attitude toward changing guest distros?