diff --git a/appvm/qubes.sudoers b/appvm/qubes.sudoers
index 58411299..8087a90a 100644
--- a/appvm/qubes.sudoers
+++ b/appvm/qubes.sudoers
@@ -1 +1,46 @@
 user ALL=(ALL) NOPASSWD: ALL
+
+# WTF?! Have you lost your mind?!
+#
+# In Qubes VMs there is no point in isolating the root account from
+# the user account. This is because all the user data are already
+# accessible from the user account, so there is no direct benefit for
+# the attacker if she could escalate to root (there is even no benefit
+# in trying to install some persistent rootkits, as the VM's root
+# filesystem modifications are lost upon each start of a VM).
+#
+# One might argue that some hypothetical attacks against the
+# hypervisor or the few daemons/backends in Dom0 (so VM escape
+# attacks) most likely would require root access in the VM to trigger
+# the attack.
+#
+# That's true, but mere existence of such a bug in the hypervisor or
+# Dom0 that could be exploited by a malicious VM, no matter whether
+# requiring user, root, or even kernel access in the VM, would be
+# FATAL. In such situation (if there was such a bug in Xen) there
+# really is no comforting that: "oh, but the mitigating factor was
+# that the attacker needed root in VM!" We're not M$, and we're not
+# gonna BS our users that there are mitigating factors in that case,
+# and for sure, root/user isolation is not a mitigating factor.
+#
+# Because, really, if somebody could find and exploit a bug in the Xen
+# hypervisor -- so far there have been only one (!) publicly disclosed
+# exploitable bug in the Xen hypervisor from a VM, found in 2008,
+# incidentally by one of the Qubes developers (RW) -- then it would be
+# highly unlikely if that person couldn't also found a user-to-root
+# escalation in VM (which as we know from history of UNIX/Linux
+# happens all the time).
+#
+# At the same time allowing for easy user-to-root escalation in a VM
+# is simply convenient for users, especially for update installation.
+#
+# Currently this still doesn't work as expected, because some idotic
+# piece of software called PolKit uses own set of policies. We're
+# planning to address this in Beta 2. (Why PolKit is an idiocy? Do a
+# simple experiment: start 'xinput test' in one xterm, running as
+# user, then open some app that uses PolKit and asks for root
+# password, e.g.  gpk-update-viewer -- observe how all the keystrokes
+# with root password you enter into the "secure" PolKit dialog box can
+# be seen by the xinput program...)
+#
+# joanna.
diff --git a/dom0/qubes.sudoers b/dom0/qubes.sudoers
index 726b0974..43995f12 100644
--- a/dom0/qubes.sudoers
+++ b/dom0/qubes.sudoers
@@ -1 +1,29 @@
 %qubes ALL=(ALL) NOPASSWD: ALL
+
+#
+# What we're saying above basically means: if the attacker got user access in
+# Dom0, then you're screwed already, as there are dozens of ways for the
+# attacker to escalate to root from user (e.g. via xend).
+#
+# Even that is not necessary, in fact! As all the VM control actions can be
+# done by user -- after all this is why you can easily start/create VMs and
+# apps in VMs from GUI -- all that the attacker needs is user access in Dom0.
+#
+# So, because in Qubes OS, in Dom0, user account is just as sensitive as root
+# account, we don't pretend otherwise, and try to make life a bit easier for
+# the user allowing for easy escalation (no need to choose and remember a root
+# password in Dom0).
+#
+# This is also why we don't pretend that Qubes OS is a multiuser system -- it
+# is not! (for the reasons given above). The assumption is that there is only
+# one user that logs into GUI manager: YOU. This is hardly a limiting factor
+# these days, when it's not uncommon for a single person to own not one, but
+# several computers, which are not shared with others (phone, tablet, laptops).
+# We live in a PC-era! :)
+#
+# This means that the user password you choose during installation servers only
+# one purpose: it allows you to lock your screen while you're away via the
+# screen saver. Nothing more!
+#
+# joanna.
+#