Interesting that you are experiencing a delay. I thought the Qubes Firewall would reject requests to IP addresses not in the whitelist instead of silently dropping them. Maybe you could fine-tune your firewall here to improve the user experience?
Very important in this day an age. Unfortunately, when I reisntalled qubes this feature got corrupted by my qubes back up somehow. Is there a packet to install to fix this in dom0 if it isn’t working properly?
Sorry for the delay in replying. It has been quite a busy week. I have been pondering your point about the timeout and the more I think about it, the more perplexed I get.
I have always in the past assumed that it was at the bank’s end that timeouts were coming from. A system where the bank’s server receives a request from the client at my end, for a whitelisted domain address …
… but then, inside that allowed web page some overpaid, underqualified cretin has added links to all the usual googleapps garbage, which is denied at my end by the firewall …
… so, the bank’s server keeps trying to send the denied domain address data for a while until it gives up and tells my client to render the blimmen page with what it can best use at the time.
That doesn’t seem to make much sense now I think it over. There are no timeouts at the transfer end of the hypertext transfer protocol. It just doesn’t work that way as far as I can imagine.
The best answer I can come up with now, having just thought it over a bit more while typing, is that my Qubes firewall is smart enough to identify a whitelisted web page domain address and still deny any embedded external links which are not whitelisted.
Curious to me, since you mentioned it. I’ve always just put up with the delays without too much question because after all it works sufficiently to do my banking operations with reasonable security.
I have never tried running the Web-Bank VM to access my bank’s website without the firewall, so there’s no standard to measure Qubes’ with or without a firewall, and I can’t be bothered with that anyway. Now that my Qubes OS has died of bootstrap disease an I am having to resort to Linux Mint though, it is clear that accessing the bank website with plain old Linux without a firewall and taking all the googleapps crap in the process is far quicker and smoother than doing the same banking chores with Qubes OS and a firewall.
Sorry I could not provide more reliable answers, phi.
I like the idea from here: > 1. By default, there is no need for an attacker to find a local exploit to get... | Hacker News. I would probably call it split root.
I agree that it should be harder to go from domU user to domU root. However I think having to manage passwords for every AppVM also negates a lot of the benefits of the template setup in qubes (I currently have about 30 AppVMs).
My ideal solution to this problem, which I might implement at some point, would be to implement a PAM module for domU that asks dom0 whether escalation to root is okay. That way, dom0 can prompt the user whether to allow it or not, and no per-AppVM passwords have to be remembered.
There’s actually already a documentation for that:
Never used it myself, though.
2 Likes
I’ve used this in StandaloneVM’s because there the logic for the passwordless root AFAIK doesn’t apply.
it’s neet. Even though a propt shows up, it’s still faster and more convenient than having to type out a password 
2 Likes
As a desktop user, I’d find exportable qubes extremely useful. My laptop is Mac and it cannot run Qubes.
1 Like
Just realised that I could do that also to separate “real” work from personal stuff, by letting the Qube that I work from connect to ETH only.
Makes for a very neat routine of plugging in before starting work at home & then unplugging, rituals like these have a lot of impact.
Added security and splitting up possible data harvesting is a great plus too, but for me its mostly about workflow & blocking big data surveillance which I hate with a vengeance.
1 Like
When we can say “Qubes now suitable for the Normal People”?
Is it a good idea or it is risky for noops?
I’d say that this has absolutely wrong premise. Can you imagine a youngster first to be introduced to a modern car, telling him that it is not for young people because it has a lot of safety features he/she can’t use because the features are complicated?
You want to drive? Especially beginners should start with modern car with as much as possible safety features.
You want to compute? Especially beginners should start with as much as possible Qubes computer.
Using your logic, would you call people who drive cars without seat belts. airbags, ABS, all the working lights, without bumpers, shatter resistant glasses and without both side view mirrors - normal? Probaly no. And you are calling people who are using computers without even more safety features - normal. It just ain’t right to us using Qubes. 
3 Likes
Yes, I agree with you…
(People caring for Privacy without advanced experience )
But I think about the “the future of qubes” and “The concept of simplicity” I think we can see soon qubes is simple for all the people …
Why I say that ?
Some features in qubes are simple more than linux distribution (of course qubes depend on linux templates):
- you can see how it’s simple to install qubes and update the templates.
I don’t know if the aim of the developers of qubes wasto make it simple for the normal user. - I think the idea of qubes is “The Ultimate privacy” and “compartmentalization”
- To illustrate, when I say for the normal people I was thinking of the people who are caring of privacy and " don’t have a lot of experience with programing and linux "
So I hope we could see qubes more simple for the "Normal User " in the future…
“Now You’re Thinking with Qubes”
The toughest concept for me to grasp was the bare metal virtual machines offered by Xen, and how beautifully Qubes built a collection of OS’s and VM’s to leverage them all, especially the chaining of VM’s providing networking services to other VM’s. Once I swallowed the pill, and made myself comfortable with it, I went hog wild.
I love lots of networking options, and this is where Qubes excels. As a linux junkie, I like renting VPS servers from various providers around the world, and using those servers for whatever I want. For $5/month each, they are dirt cheap, but gives me lots of great experience. I usually put a private VPN server on each one, to access it that way. Sometimes I’ll also install a tor entry-node server on it, to play around with tor. Most VPS providers don’t mind entry-node servers, they just don’t like exit nodes, so it’s not a problem.
I like to create a variety of networking options, frequently changing too, like:
sys-net-eth
sys-net-wifi
sys-vpn-losangeles
sys-vpn-chicago
sys-vpn-tokyo
sys-vpn-amsterdam
sys-tor-vpn-losangeles
sys-tor-vpn-tokyo
sys-tor-vpn-amsterdam
then work/play VM’s to access each of those, easily changeable, like:
play-vpn-tokyo
play-tor-vpn-amsterdam
work-vpn-losangeles
Qubes makes it so easy, that once you get used to it, the sky really is the limit. As new things pop up, like wireguard, I’ll play with those too.
As a rule, I don’t put anything sensitive or important on the laptop. It’s just for fun learning really. If it gets screwed up, I’ll just wipe the drive and start over.
I played around with “minimal” installs, minimal firewall, blah blah blah. In the end, it’s just not necessary, for me anyways. A Debian template and a Fedora template give you more than enough to handle almost anything. Sure, there are niche situations, and multiple templates can be necessary. We all do different things, which is another reason why Qubes is so great. The flexibility to do things so easily that other platforms do poorly, if at all, to me, is the greatest appeal.
Sorry I’m late to this thread. Couldn’t resist!
2 Likes
Not sure if you’re logged into facebook or trying to view posts without an account, but if you’re logging into facebook, they have a .onion domain that you could use in whonix.