More typo/grammar/re-wording from @jpouellet's review

basics_dev/coding-style.md

@@ -165,8 +165,6 @@ Security coding guidelines
        height = untrusted_conf.height;
     ~~~
 
--   Use equivalent variables, without the `untrusted_` prefix to hold the sanitized values, as shown above.
-
 Python-specific guidelines
 --------------------------
 

common-tasks/software-update-vm.md

@@ -119,7 +119,7 @@ There are several ways to deal with this problem:
 
 -   Use *standalone VMs* (see below) for installation of untrusted software packages.
 
--   Use multiple templates (see below) for different classes of domains, e.g. a less trusted template, used for creation of less trusted AppVMs, would get various packages from somewhat less trusted vendors, while the template used for more trusted AppVMs will only get packages from the standard Fedora repos.
+-   Use multiple templates (see below) for different classes of domains, e.g. a less trusted template, used for creation of less trusted AppVMs, would get various packages from less trusted vendors, while the template used for more trusted AppVMs will only get packages from the standard Fedora repos.
 
 Some popular questions:
 

common-tasks/tips-and-tricks.md

@@ -46,7 +46,7 @@ Preventing data leaks
 ---------------------
 First make sure to read [Understanding and Preventing Data Leaks](/doc/data-leaks/) section to understand the limits of this tip.
 
-Suppose that you have in a not so trusted enviroment, for example a Windows VM, an application that track and report its usage, or you simply want to protect your data.
+Suppose that you have within a not so trusted enviroment - for example, a Windows VM - an application that track and report its usage, or you simply want to protect your data.
 
 Start Windows template VM (which has no user data), install/upgrade apps; then start Windows AppVM (with data) in offline mode. So, if you worry (hypothetically) that your Windows or app updater might want to send your data away, this Qubes OS trick will prevent this.
 This applies also to any TemplateBasedVM relative to its parent TemplateVM, but the privacy risk is especially high in the case of Windows.

configuration/assigning-devices.md

@@ -58,15 +58,15 @@ list of available devices, which you can select to be assigned to that VM.
 Finding the right USB controller
 --------------------------------
 
-If you want to assign a certain [USB] device to a VM (by attaching the whole
-USB controller), you need to figure out which PCI device is the right
+If you want to assign a certain USB device to a VM by attaching the whole
+USB controller, you need to figure out which PCI device is the right
 controller. First, check to which USB bus the device is connected:
 
 ~~~
 lsusb
 ~~~
 
-For example, I want to assign a broadband modem to the netvm. In the output of
+For example, I want to assign a broadband modem to the NetVM. In the output of
 `lsusb` it can be listed as something like this. (In this case, the device isn't
 fully identified):
 

configuration/external-audio.md

@@ -38,7 +38,7 @@ pactl load-module module-udev-detect
 
 Start the audio application that is going to use the external audio device.
 
-Launch pavucontrol, for example using "run command in VM" of Qubes Manager and select your external audio card in pavucontrol. You need to do that only the first time you use a new external audio device, then pulse audio will remember you selection.
+Launch pavucontrol, for example using "run command in VM" of Qubes Manager and select your external audio card in pavucontrol. You need to do that only the first time you use a new external audio device, then pulse audio will remember your selection.
 
 If you detach your external audio device, then want to insert it again, or change it with another one, you need to repeat the previous commands in terminal, adding another line at the beginning:
 

configuration/managing-vm-kernel.md

@@ -326,9 +326,9 @@ When starting the VM you can safely ignore any warnings about a missing module '
 
 ### Troubleshooting
 
-In the event of a problem, you can access VM console (using `sudo xl console VMNAME` in dom0) to access
-GRUB menu. You need to call it just after starting VM (until `GRUB_TIMEOUT`
-expires) - for example in separate dom0 terminal window.
+In the event of a problem, you can access the VM console (using `sudo xl console VMNAME` in dom0) to access
+the GRUB menu. You need to call it just after starting VM (until `GRUB_TIMEOUT`
+expires) - for example in a separate dom0 terminal window.
 
 In any case you can later access VM logs (especially VM console log (`guest-VMNAME.log`). 
 

configuration/network-bridge-support.md

@@ -42,7 +42,7 @@ First, retrieve the attachment of this Wifi article in dom0. Then apply the thre
 
 Finally restart the qubes manager GUI.
 
-A new option is now available in the AppVM Settings to enable set the NetVM in bridge mode. For a bridged AppVM, you should the select a netvm instead of a firewall vm, enable the Bridge option and restart your AppVM.
+An option is available in the AppVM Settings to enable setting the NetVM in bridge mode. For a bridged AppVM, you should then select a NetVM instead of a FirewallVM/  ProxyVM, enable the Bridge option, and restart your AppVM.
 
 NetVM patch (Qubes R2B2)
 ------------------------

configuration/resize-disk-image.md

@@ -75,7 +75,7 @@ Done.
 
 If you want install a lot of software in your TemplateVM, you may need to increase the amount of disk space your TemplateVM can use.
 
-1.  Make sure that all the VMs based on this template are powered off (including netvms etc).
+1.  Make sure that all the VMs based on this template are shut down (including netvms etc).
 2.  Sanity check: verify that none of the loop devices are pointing at this template root.img: `sudo losetup -a`
 3.  Resize root.img file using `truncate -s <desired size>` (the root.img path can be obtained from qvm-prefs).
 4.  If any netvm/proxyvm used by this template is based on it, set template netvm to none.

customization/bind-dirs.md

@@ -89,7 +89,7 @@ For example, if you wanted to make `/var/lib/tor` non-persistant in `sys-whonix`
 binds=( "${binds[@]/'/var/lib/tor'}" )
 ~~~
 
-(Editing `/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf` directly is not recommended, since such changes get lost when that file is changed in the package on upgrades.)
+(Editing `/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf` directly is strongly discouraged, since such changes get lost when that file is changed in the package on upgrades.)
 
 ## Discussion ##
 

customization/dark-theme.md

@@ -109,7 +109,7 @@ This is the result after applying the steps described here.
 Dark App VM, Template VM, Standalone VM, HVM (Linux Gnome)
 ==========================================================
 
-Almost all Qubes VM's are based on the Gnome desktop. Therefore the description below is focused on the Gnome Desktop Environment.
+Almost all Qubes VMs use default applications based on the GTK toolkit. Therefore the description below is focused on tools from the Gnome Desktop Environment.
 
 Using "Gnome-Tweak-Tool"
 ------------------------
@@ -120,7 +120,7 @@ The advantage of creating a dark themed Template VM is, that each AppVM which is
 
 1. Start VM
 
-    **Note:** In the case of App VM start the Template on which the AppVM is based on.
+    **Note:** Remember that if you want to make the change persistent, the change needs to be made in the TemplateVM, not the AppVM.
 
 2. Install `Gnome-Tweak-Tool`
 
@@ -174,7 +174,7 @@ Manually works for Debian, Fedora and Archlinux.
 
 1. Start VM
 
-    **Note:** In the case of App VM start the Template on which the AppVM is based on.
+    **Note:** Remember that if you want to make the change persistent, the change needs to be made in the TemplateVM, not the AppVM.
 
 2. Enable `Global Dark Theme`
 

customization/dispvm-customization.md

@@ -49,7 +49,7 @@ It is possible to change the settings of each new Disposable VM (DispVM). This c
 2.  Change the VM's settings and/or applications, as desired. Note that currently Qubes supports exactly one DispVM template, so any changes you make here will affect all DispVMs. Some examples of changes you may want to make include:
     -   Changing Firefox's default startup settings and homepage.
     -   Changing Nautilus' default file preview settings.
-    -   Changing the DispVM's default NetVM. For example, you may wish to set the NetVM to "none." Then, whenever you start a new DispVM, you can choose your desired ProxyVM manually (by changing the newly-started DispVMs settings). This is useful if you sometimes wish to use a DispVM with a TorVM, for example. It is also useful if you sometimes wish to open untrusted files in a network-disconnected DispVM.
+    -   Changing the DispVM's default NetVM. For example, you may wish to set the NetVM to "none." Then, whenever you start a new DispVM, you can choose your desired ProxyVM manually (by changing the newly-started DispVM's settings). This is useful if you sometimes wish to use a DispVM with a TorVM, for example. It is also useful if you sometimes wish to open untrusted files in a network-disconnected DispVM.
 
 3.  Create an empty `/home/user/.qubes-dispvm-customized` file in the VM (not in dom0):
 

customization/fedora-minimal-template-customization.md

@@ -17,7 +17,7 @@ Template installation
 
 *Note*: the template may not start in Qubes R3 when using kernel 3.19 (unstable). In this case, switch the AppVM or TemplateVM to the kernel 3.18.
 
-*Note*: If you have doubts about a set of tools or package you want to install, start installing and testing it in an AppVM. You can then reproduce it later in your TemplateVM if you are satisfied. That is the (QubesOS?) template philosophy.
+*Note*: If you have doubts about a set of tools or package you want to install, start installing and testing it in an AppVM. You can then reproduce it later in your TemplateVM if you are satisfied. That is the (Qubes OS?) template philosophy.
 
 Standard tools installation
 ================
@@ -176,7 +176,7 @@ Cleaning the whole dconf settings is also possible by removing the following fil
 rm ~/.config/dconf/user
 ~~~
 
-*Note*: lxappearance only has an effect on gtk3 theme so it won't work to change gtk2 themes (used by Firefox, Thunderbird ...).
+*Note*: lxappearance only has an effect on gtk3 themes so it won't work to change gtk2 themes (used by Firefox, Thunderbird ...).
              However, it is very lightweight and can be used to identify the name and look of themes you are interested in.
              Once you have the name, you can apply it using gsetting command line or gconf-editor.
 

customization/windows-template-customization.md

@@ -62,10 +62,10 @@ Of course I recommend starting the template regularly and checking manually for
 System properties
 ---------------------------
 
-Right click on computer and go to Properties > Advanced > Performances:
+Right click on computer and go to Properties > Advanced > Performance:
 
  * If you don't care about visual effect, in Visual Effect select "Adjust for best performance"
- * I personally tweak the page file size to win some space on my root.
+ * I personally tweak the page file size to gain some space on my root.
 
     In Advanced>Performances>Advanced tab, change Virtual memory:
 

debugging/vm-interface.md

@@ -199,7 +199,7 @@ abstraction. This will change in the future. Those tools are:
 - `gpk-update-viewer` - called by Qubes Manager to display available updates in a TemplateVM
 - `systemctl start qubes-update-check.timer` (and similarly stop) - called when enabling/disabling updates checking in given VM (`qubes-update-check` [qvm-service](/doc/qubes-service/))
 
-Additionally automatic tests extensively call various commands directly in VMs. We do not plan to change that.
+Additionally, automatic tests extensively run various commands directly in VMs. We do not plan to change that.
 
 GUI protocol
 ------------

installing/upgrade/upgrade-to-r3.0.md

@@ -100,7 +100,7 @@ Now, when you have dom0 upgraded, you can install new templates from Qubes R3.0
 Upgrading template on already upgraded dom0
 -------------------------------------------
 
-If for some reason you did not upgrade all the templates and standalone VMs before upgrading dom0, you can still do this, but it will be somewhat more complicated. This can be the case when you restore backup done on Qubes R2.
+If for some reason you did not upgrade all the templates and standalone VMs before upgrading dom0, you can still do this, but it will be more complicated. This can be the case when you restore backup done on Qubes R2.
 
 When you start R2 template/standalone VM on R3.0, there will be some limitations:
 

managing-os/templates/archlinux.md

@@ -82,9 +82,9 @@ The two lines that have just been added to /etc/pacman.conf should then be remov
 
 ### Package cannot be updated because of errors related to xorg-server or pulseaudio versions
 
-In the case of archlinux upgrade pulseaudio major version or xorg-server version, updating these packages will break the qubes GUI agent. To avoid breaking things, the update is blocked until a new version of the GUI agent is available.
+Upgrading pulseaudio or xorg-server to a newer major version will break the Qubes GUI agent. Avoid upgrading these packages until such time that a future version of the GUI agent addresses this issue.
 
-In this case, the gui-agent-linux component of Qubes-OS needs to be rebuilt using these last xorg-server or pulseaudio libraries. You can try to rebuild it yourself or wait for a new qubes-vm-gui package to be available.
+Specifically, the gui-agent-linux component of Qubes-OS needs to be rebuilt using these last xorg-server or pulseaudio libraries. You can try to rebuild it yourself or wait for a new qubes-vm-gui package to be available.
 
 ### qubes-vm is apparently starting properly (green dot) however graphical applications do not appear to work
 

managing-os/windows/windows-appvms.md

@@ -102,7 +102,7 @@ Also, the inter-VM services work as usual -- e.g. to request opening a document
 [user@work ~]$ qvm-open-in-vm work-win7 https://invisiblethingslab.com
 ~~~
 
-... just like in the case of Linux AppVMs. Of course all those operations are governed by central policy engine running in Dom0 -- if the policy doesn't contain explicit rules for the source and/or target AppVM, the user will be asked for decision whether to allow or deny the operation.
+... just like in the case of Linux AppVMs. Of course all those operations are governed by central policy engine running in Dom0 -- if the policy doesn't contain explicit rules for the source and/or target AppVM, the user will be asked whether to allow or deny the operation.
 
 Inter-VM file copy and clipboard works for Windows AppVMs the same way as for Linux AppVM (except that we don't provide a command line wrapper, `qvm-copy-to-vm` in Windows VMs) -- to copy files from Windows AppVMs just right-click on the file in Explorer, and choose: Send To-\> Other AppVM.
 

reference/glossary.md

@@ -32,7 +32,7 @@ A user-friendly term for a [VM](#vm) in Qubes OS.
 
  * "Qube" is an informal term intended to make it easier for less technical users to understand Qubes OS and learn how to use it. In technical discussions, the other, more precise terms defined on this page are to be preferred.
 
- * The term "qube" should be lowercase unless it is the first word in a sentence. Note that starting a sentence with the plural of "qube" (i.e., "Qubes...") can be ambiguous, since it may not be clear whether the reference is a collection of qubes or [Qubes OS](#qubes-os).
+ * The term "qube" should be lowercase unless it is the first word in a sentence. Note that starting a sentence with the plural of "qube" (i.e., "Qubes...") can be ambiguous, since it may not be clear whether the referent is a collection of qubes or [Qubes OS](#qubes-os).
 
 Domain
 ------

releases/1.0/release-notes.md

@@ -16,7 +16,7 @@ Known issues
 
 -   Installer might not support some USB keyboards (\#230). This seems to include all the Mac Book keyboards (most PC laptops have PS2 keyboards and are not affected).
 
--   If you don't enable Composition (System Setting -\> Desktop -\> Enable desktop effects), which you really should do, then the KDE task bar might get somewhat ugly (e.g. half of it might be black). This is some KDE bug that we don't plan to fix.
+-   If you don't enable Composition (System Setting -\> Desktop -\> Enable desktop effects), which you really should do, then the KDE task bar might get ugly (e.g. half of it might be black). This is some KDE bug that we don't plan to fix.
 
 -   Some keyboard layout set by KDE System Settings can cause [keyboard not working at all](https://groups.google.com/group/qubes-devel/browse_thread/thread/77d076b65dda7226). If you hit this issue, you can switch to console (by console login option) and manually edit `/etc/X11/xorg.conf.d/00-system-setup-keyboard.conf` (and `/etc/sysconfig/keyboard`) and place correct keyboard layout settings (details in linked thread). You can check if specific keyboard layout settings are proper using `setxkbmap` tool.
 

security-info/security-pack.md

@@ -95,7 +95,7 @@ to the Qubes mailing lists:
     very soon, the possibility of having to disclose any of the Qubes
     signing keys to anybody might have pretty serious consequences for those
     who decided to entrust Qubes with anything serious. And we would like to
-    somewhat minimize these consequences with this canary thing.
+    minimize these consequences with this canary thing.
     
     Additionally the canary is a nice way of ensuring "freshness" of our
     messaging to the community.

security/yubi-key.md

@@ -23,19 +23,19 @@ This can be configured using
 package. This package does not support sharing the same key slot with other
 applications (it will deny further authentications if you try).
 
-Contrary to instruction there, currently there is no binary packages in Qubes
+Contrary to instruction there, currently there is no binary package in the Qubes
 repository and you need to compile it yourself. This might change in the future.
 
 Challenge-response mode
 ----------------------
 
-In this mode, your YubiKey will generate response based on secret key, and
+In this mode, your YubiKey will generate a response based on the secret key, and
 random challenge (instead of counter). This means that it isn't possible to
-generate response in advance even if someone gets access to your YubiKey. This
+generate a response in advance even if someone gets access to your YubiKey. This
 makes it reasonably safe to use the same YubiKey for other services (also in
 challenge-response mode).
 
-Same as in OTP case, you will need to set up your YubiKey, choose separate
+Same as in the OTP case, you will need to set up your YubiKey, choose a separate
 password (other than your login password!) and apply the configuration.
 
 To use this mode you need to:
@@ -43,7 +43,7 @@ To use this mode you need to:
 1. Configure your YubiKey for challenge-response HMAC-SHA1 mode, for example
    [following this
    tutorial](https://www.yubico.com/products/services-software/personalization-tools/challenge-response/)
-2. Install `ykpers` package in template on which your USB VM is based.
+2. Install the `ykpers` package in template on which your USB VM is based.
 3. Create `/usr/local/bin/yubikey-auth` script:
 
        #!/bin/sh
@@ -99,9 +99,9 @@ where no one can snoop your password.
 Locking the screen when YubiKey is removed
 ------------------------------------------
 
-You can setup your system to automatically lock the screen when you unplug
+You can setup your system to automatically lock the screen when you unplug your
 YubiKey. This will require creating a simple qrexec service which will expose
-the ability to lock the screen to your USB VM, and then adding udev hook to
+the ability to lock the screen to your USB VM, and then adding a udev hook to
 actually call that service.
 
 1. First configure the qrexec service. Create `/etc/qubes-rpc/custom.LockScreen` (in dom0)
@@ -116,8 +116,8 @@ would require creating `/etc/qubes-rpc/policy/custom.LockScreen` with:
         sys-usb dom0 allow
 
 3. Create udev hook in your USB VM. Store it in `/rw/config` to have it
-persistent across VM restarts. For example name the file
-`/rw/config/yubikey.rules`. Write there a single line:
+persis across VM restarts. For example name the file
+`/rw/config/yubikey.rules`. Add the following line:
 
         ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SECURITY_TOKEN}=="1", RUN+="/usr/bin/qrexec-client-vm dom0 custom.LockScreen"
 

services/dvm-impl.md

@@ -14,34 +14,34 @@ DisposableVM implementation in Qubes
 DisposableVM image preparation
 ------------------------------
 
-DisposableVM is not started like other VMs, by executing equivalent of *xl create* - it would be too slow. Instead, DisposableVM are started by restore from a savefile.
+DisposableVM is not started like other VMs, by executing equivalent of `xl create` - it would be too slow. Instead, DisposableVM are started by restore from a savefile.
 
-Preparing a savefile is done by */usr/lib/qubes/qubes\_prepare\_saved\_domain.sh* script. It takes two mandatory arguments, appvm name (APPVM) and the savefile name, and optional path to "prerun" script. The script executes the following steps:
+Preparing a savefile is done by `/usr/lib/qubes/qubes\_prepare\_saved\_domain.sh` script. It takes two mandatory arguments, appvm name (APPVM) and the savefile name, and optional path to "prerun" script. The script executes the following steps:
 
-1.  APPVM is started by *qvm-start*
+1.  APPVM is started by `qvm-start`
 2.  xenstore key `/local/domain/appvm_domain_id/qubes_save_request` is created
 3.  if prerun script was specified, copy it to `qubes_save_script` xenstore key
 4.  wait for the `qubes_used_mem` key to appear
-5.  (in APPVM) APPVM boots normally, up to the point in */etc/init.d/qubes\_core* script when the presence of `qubes_save_request` key is tested. If it exists, then
+5.  (in APPVM) APPVM boots normally, up to the point in `/etc/init.d/qubes\_core` script when the presence of `qubes_save_request` key is tested. If it exists, then
     1.  (in APPVM) if exists, prerun script is retrieved from the respective xenstore key and executed. This preloads filesystem cache with useful applications, so that they will start faster.
     2.  (in APPVM) the amount of used memory is stored to `qubes_used_mem` xenstore key
     3.  (in APPVM) busy-waiting for `qubes_restore_complete` xenstore key to appear
 
 6.  when `qubes_used_mem` key appears, the domain memory is reduced to this amount, to make the savefile smaller.
 7.  APPVM private image is detached
-8.  the domain is saved via *xl save*
+8.  the domain is saved via `xl save`
 9.  the COW file volatile.img (cow for root fs and swap) is packed to `saved_cows.tar` archive
 
-*qubes\_prepare\_saved\_domain.sh* script is somewhat lowlevel. It is usually called by *qvm-create-default-dvm* script, that takes care of creating a special AppVM (named template\_name-dvm) to be passed to *qubes\_prepare\_saved\_domain.sh*, as well as copying the savefile to /dev/shm (the latter action is not done if the `/var/lib/qubes/dvmdata/dont_use_shm` file exists).
+The `qubes\_prepare\_saved\_domain.sh` script is lowlevel. It is usually called by `qvm-create-default-dvm` script, that takes care of creating a special AppVM (named template\_name-dvm) to be passed to `qubes\_prepare\_saved\_domain.sh`, as well as copying the savefile to /dev/shm (the latter action is not done if the `/var/lib/qubes/dvmdata/dont_use_shm` file exists).
 
 Restoring a DisposableVM from the savefile
 ------------------------------------------
 
-Normally, disposable VM is created when qubes rpc request with target *\$dispvm* is received. Then, as a part of rpc connection setup, the *qfile-daemon-dvm* program is executed; it executes */usr/lib/qubes/qubes\_restore* program. It is crucial that this program executes quickly, to make DisposableVM creation overhead bearable for the user. Its main steps are:
+Normally, disposable VM is created when qubes rpc request with target *\$dispvm* is received. Then, as a part of rpc connection setup, the `qfile-daemon-dvm` program is executed; it executes `/usr/lib/qubes/qubes\_restore` program. It is crucial that this program executes quickly, to make DisposableVM creation overhead bearable for the user. Its main steps are:
 
 1.  modify the savefile so that the VM name, VM UUID, MAC address and IP address are unique
 2.  restore the COW files from the `saved_cows.tar`
-3.  create the `/var/run/qubes/fast_block_attach` file, whose presence tells the */etc/xen/scripts/block* script to bypass some redundant checks and execute as fast as possible.
+3.  create the `/var/run/qubes/fast_block_attach` file, whose presence tells the `/etc/xen/scripts/block` script to bypass some redundant checks and execute as fast as possible.
 4.  execute "xl restore" in order to restore a domain.
 5.  create the same xenstore keys as normally created when AppVM boots (e.g. `qubes_ip`)
 6.  create the `qubes_restore_complete` xenstore key. This allows the boot process in DisposableVM to continue.
@@ -53,4 +53,4 @@ Validating the DisposableVM savefile
 
 DisposableVM savefile contains references to template rootfs and to COW files. The COW files are restored before each DisposableVM start, so they cannot change. On the other hand, if templateVM is started, the template rootfs will change, and it may not be coherent with the COW files.
 
-Therefore, the check for template rootfs modification time being older than DisposableVM savefile modification time is required. It is done in *qfilexchgd* daemon, just before restoring DisposableVM. If necessary, an attempt is made to recreate the DisposableVM savefile, using the last template used (or default template, if run for the first time) and the default prerun script, residing at */var/lib/qubes/vm-templates/templatename/dispvm\_prerun.sh*. Unfortunately, the prerun script takes a lot of time to execute - therefore, after template rootfs modification, the next DisposableVM creation can be longer by about 2.5 minutes.
+Therefore, the check for template rootfs modification time being older than DisposableVM savefile modification time is required. It is done in `qfilexchgd` daemon, just before restoring DisposableVM. If necessary, an attempt is made to recreate the DisposableVM savefile, using the last template used (or default template, if run for the first time) and the default prerun script, residing at `/var/lib/qubes/vm-templates/templatename/dispvm\_prerun.sh`. Unfortunately, the prerun script takes a lot of time to execute - therefore, after template rootfs modification, the next DisposableVM creation can be longer by about 2.5 minutes.

system/gui.md

@@ -71,7 +71,7 @@ To sum up, this solution has the following benefits:
 Security markers on dom0 windows
 --------------------------------
 
-It is important that user knows which AppVM a given window belongs to. This prevents a rogue AppVM from painting a window pretending to belong to other AppVM or dom0 and trying to steal, for example, passwords.
+It is important that the user knows which AppVM a given window belongs to. This prevents a rogue AppVM from painting a window pretending to belong to other AppVM or dom0 and trying to steal, for example, passwords.
 
 In Qubes, a custom window decorator is used that paints a colourful frame (the colour is determined during AppVM creation) around decorated windows. Additionally, the window title always starts with **[name of the AppVM]**. If a window has an *override_redirect* attribute, meaning that it should not be treated by a window manager (typical case is menu windows), *qubes_guid* draws a two-pixel colourful frame around it manually.
 
@@ -82,10 +82,10 @@ Certainly, it would be insecure to allow AppVM to read/write the clipboards of o
 Therefore, the following mechanism is used:
 
 -   there is a "qubes clipboard" in dom0 - its contents are stored in a regular file in dom0.
--   if user wants to copy local AppVM clipboard to qubes clipboard, she must focus on any window belonging to this AppVM, and press **Ctrl-Shift-C**. This combination is trapped by *qubes-guid*, and `CLIPBOARD_REQ` message is sent to AppVM. *qubes-gui* responds with *CLIPBOARD_DATA* message followed by clipboard contents.
--   user focuses on other AppVM window, presses **Ctrl-Shift-V**. This combination is trapped by *qubes-guid*, and `CLIPBOARD_DATA` message followed by qubes clipboard contents is sent to AppVM; *qubes_gui* copies data to the local clipboard, and then user can paste its contents to local applications normally.
+-   if the user wants to copy local AppVM clipboard to qubes clipboard, she must focus on any window belonging to this AppVM, and press **Ctrl-Shift-C**. This combination is trapped by *qubes-guid*, and `CLIPBOARD_REQ` message is sent to AppVM. *qubes-gui* responds with *CLIPBOARD_DATA* message followed by clipboard contents.
+-   the user focuses on other AppVM window, presses **Ctrl-Shift-V**. This combination is trapped by *qubes-guid*, and `CLIPBOARD_DATA` message followed by qubes clipboard contents is sent to AppVM; *qubes_gui* copies data to the local clipboard, and then user can paste its contents to local applications normally.
 
-This way, user can quickly copy clipboards between AppVMs. 
+This way, the user can quickly copy clipboards between AppVMs. 
 This action is fully controlled by the user, it cannot be triggered/forced by any AppVM.
 
 *qubes_gui* and *qubes_guid* code notes

troubleshooting/install-nvidia-driver.md

@@ -152,7 +152,7 @@ Specifically, the notes below are aimed to help when the GRUB menu shows up fine
    * Exit out of the chroot environment (`exit` or CTRL-D)
 6. Reboot
 
-*Note* If the kernel parameters do *not* include `quiet` and `rhgb`, the kernel messages can easily obscure the LUKS passphrase prompt. Additionally, each character entered will cause the LUKS passphrase prompt to repeat onto next line. Both of these are cosmetic. The trade-off between kernel messages and the easy-to-spot LUKS passphrase prompt is left as exercise to the user.
+*Note* If the kernel parameters do *not* include `quiet` and `rhgb`, the kernel messages can easily obscure the LUKS passphrase prompt. Additionally, each character entered will cause the LUKS passphrase prompt to repeat onto next line. Both of these are cosmetic. The trade-off between kernel messages and the easy-to-spot LUKS passphrase prompt is left as an exercise to the user.
 
 ## Gather initial `dmesg` output
 If all is well, the newly-installed Qubes OS instance should allow for user root to log in. 

troubleshooting/out-of-memory.md

@@ -35,7 +35,7 @@ sudo yum clean all
 qvm-remove <VMname>
 ~~~
 
-With this method you lose the data of one VM, but it'll more reliably work.
+With this method you lose the data of one VM, but it'll work more reliably.
 
 1.  Decrease filesystem safety margin (5% by default):
 
@@ -43,5 +43,5 @@ With this method you lose the data of one VM, but it'll more reliably work.
 sudo tune2fs -m 4 /dev/mapper/vg_dom0-lv_root
 ~~~
 
-1.  Remove some unneeded files in dom0 home (if you have any, most likely no).
+1.  Remove some unneeded files in dom0 home (if you have any, most likely not).