Various minor spelling and grammar fixes

2024-12-25 15:29:29 -05:00 · 2017-05-11 18:48:59 +10:00 · 2017-05-11 18:48:59 +10:00 · db13ef5a33
commit db13ef5a33
parent c1cc28b3c4
49 changed files with 131 additions and 131 deletions
--- a/basics_user/doc-guidelines.md
+++ b/basics_user/doc-guidelines.md
@ -43,7 +43,7 @@ documentation change will be reviewed before it's published to the web. This
 allows us to maintain quality control and protect our users.

 As mentioned above, we keep all the documentation in a dedicated [Git
-repository][qubes-doc] hosted on [GitHub]. Thanks to GitHub interface, you can
+repository][qubes-doc] hosted on [GitHub]. Thanks to the GitHub interface, you can
 edit the documentation even if you don't know Git at all! The only thing you
 need is a GitHub account, which is free.

--- a/basics_user/user-faq.md
+++ b/basics_user/user-faq.md
@ -291,9 +291,9 @@ Open a terminal and run `sudo yum install linux-firmware` in the TemplateVM upon

 ### Can I install Qubes OS together with other operating system (dual-boot/multi-boot)?

-You shouldn't do that, because it pose a security risk for your Qubes OS installation. 
+You shouldn't do that, because it poses a security risk for your Qubes OS installation.
 But if you understand the risk and accept it, read [documentation on multibooting](/doc/multiboot/). 
-It starts with explanation what is wrong with using such setup.
+It starts with explaining what is wrong with using such a setup.

 Common Problems
 ---------------
@ -438,7 +438,7 @@ The encrypted partitions are identified and the user is prompted for password on

 A fully encrypted drive does not appear in Nautilus.

-The work round is to manually decrypt and mount the drive:
+The workaround is to manually decrypt and mount the drive:

 1. attach usb device to qube - it should be attached as /dev/xvdi or similar.
 2. sudo cryptsetup open /dev/xvdi bk --type luks
--- a/building/building-archlinux-template.md
+++ b/building/building-archlinux-template.md
@ -361,7 +361,7 @@ redirect_from:
 The `qubes-mgmt-salt` repo is not currently forked under the marmarek user on
 GitHub, to whom the above instructions set the `GIT_PREFIX`.  As Archlinux is
 not yet supported by mgmt-salt, simply leave it out of the build (when building
-the Archlinux template on it's own) by appending the following to your `override.conf` file:
+the Archlinux template on its own) by appending the following to your `override.conf` file:

 `BUILDER_PLUGINS := $(filter-out mgmt-salt,$(BUILDER_PLUGINS))`

--- a/common-tasks/backup-restore.md
+++ b/common-tasks/backup-restore.md
@ -81,7 +81,7 @@ Emergency Backup Recovery without Qubes

 The Qubes backup system has been designed with emergency disaster recovery in mind. No special Qubes-specific tools are required to access data backed up by Qubes. In the event a Qubes system is unavailable, you can access your data on any GNU/Linux system with the following procedure.

-For emergency restore of backup created on Qubes R2 or newer take a look [here](/doc/backup-emergency-restore-v3/). For backups created on earlier Qubes version, take a look [here](/doc/backup-emergency-restore-v2/).
+For emergency restore of backup created on Qubes R2 or newer take a look [here](/doc/backup-emergency-restore-v3/). For backups created on earlier Qubes versions, take a look [here](/doc/backup-emergency-restore-v2/).


 Migrating Between Two Physical Machines
@ -96,7 +96,7 @@ Here are some things to consider when selecting a passphrase for your backups:

 * If you plan to store the backup for a long time or on third-party servers, you should make sure to use a very long, high-entropy passphrase. (Depending on the decryption passphrase you use for your system drive, this may necessitate selecting a stronger passphrase. If your system drive decryption passphrase is already sufficiently strong, it may not.)
 * An adversary who has access to your backups may try to substitute one backup for another. For example, when you attempt to retrieve a recent backup, the adversary may instead give you a very old backup containing a compromised VM. If you're concerned about this type of attack, you may wish to use a different passphrase for each backup, e.g., by appending a number or date to the passphrase.
- * If you're forced to enter your system drive decryption passphrase in plain view of others (where it can be shoulder-surfed), then you may want to use a different passphrase for your backups (even if your system drive decryption passphrase is already maximally strong). On the othe hand, if you're careful to avoid shoulder-surfing and/or have a passphrase that's difficult to detect via shoulder-surfing, then this may not be a problem for you.
+ * If you're forced to enter your system drive decryption passphrase in plain view of others (where it can be shoulder-surfed), then you may want to use a different passphrase for your backups (even if your system drive decryption passphrase is already maximally strong). On the other hand, if you're careful to avoid shoulder-surfing and/or have a passphrase that's difficult to detect via shoulder-surfing, then this may not be a problem for you.

 Notes
 -----
--- a/common-tasks/dispvm.md
+++ b/common-tasks/dispvm.md
@ -18,7 +18,7 @@ A Disposable VM (DispVM) is a lightweight VM that can be created quickly and whi

 By default a Disposable VM will inherit the NetVM and firewall settings of the ancestor VM, that is the VM it is launched from. Thus if an AppVM uses sys-net as NetVM (instead of, say, sys-whonix), any DispVM launched from this AppVM will also have sys-net as its NetVM. You can change this behaviour for individual VMs: in the Qubes Manager open VM Settings for the VM in question and go to the "Advanced" tab. Here you can edit the "NetVM for DispVM" setting to change the NetVM of any DispVM launched from that VM.

-A Disposable VM launched from the Start Meny inherits the NetVM of a so-called internal TempVM, the *[DVM Template](https://www.qubes-os.org/doc/glossary/#dvm-template).* By default it is named `fedora-XX-dvm` (where `XX` is the Fedora version of the default TemplateVM) and hidden in Qubes VM Manager; it can be shown by selecting "Show/Hide internal VMs". Notice that changing the "NetVM for DispVM" setting for the DVM Template does *not* affect the NetVM of DispVMs launched from the Start Meny; only changing the DVM Template's own NetVM does.
+A Disposable VM launched from the Start Menu inherits the NetVM of a so-called internal TempVM, the *[DVM Template](https://www.qubes-os.org/doc/glossary/#dvm-template).* By default it is named `fedora-XX-dvm` (where `XX` is the Fedora version of the default TemplateVM) and hidden in Qubes VM Manager; it can be shown by selecting "Show/Hide internal VMs". Notice that changing the "NetVM for DispVM" setting for the DVM Template does *not* affect the NetVM of DispVMs launched from the Start Menu; only changing the DVM Template's own NetVM does.

 Once a DispVM has been created it will appear in the Qubes Manager with the name "dispX", and NetVM and firewall rules can be set as for a normal VM.

--- a/common-tasks/full-screen-mode.md
+++ b/common-tasks/full-screen-mode.md
@ -24,7 +24,7 @@ If one allowed one of the VMs to "own" the full screen, e.g. to show a movie on
 Secure use of full screen mode
 ------------------------------

-However, it is possible to deal with full screen mode in a secure way assuming there are mechanisms that can be used at any time to show the full desktop, and which cannot be intercepted by the VM. An example of such q mechanism is the KDE's "Present Windows" and "Desktop Grid" effects, which are similar to Mac's "Expose" effect, and which can be used to immediately detect potential "GUI forgery", as they cannot be intercepted by any of the VM (as the GUID never passes down the key combinations that got consumed by KDE Window Manager), and so the VM cannot emulate those. Those effects are enabled by default in KDE once Compositing gets enabled in KDE (System Settings -\> Desktop -\> Enable Desktop Effects), which is recommended anyway. By default they are triggered by Ctrl-F8 and Ctrl-F9 key combinations, but can also be reassigned to other shortcuts.
+However, it is possible to deal with full screen mode in a secure way assuming there are mechanisms that can be used at any time to show the full desktop, and which cannot be intercepted by the VM. An example of such a mechanism is the KDE's "Present Windows" and "Desktop Grid" effects, which are similar to Mac's "Expose" effect, and which can be used to immediately detect potential "GUI forgery", as they cannot be intercepted by any of the VM (as the GUID never passes down the key combinations that got consumed by KDE Window Manager), and so the VM cannot emulate those. Those effects are enabled by default in KDE once Compositing gets enabled in KDE (System Settings -\> Desktop -\> Enable Desktop Effects), which is recommended anyway. By default they are triggered by Ctrl-F8 and Ctrl-F9 key combinations, but can also be reassigned to other shortcuts.
 Another option is to use Alt+Tab for switching windows. This shortcut is also handled by dom0.

 Enabling full screen mode for select VMs
--- a/common-tasks/managing-appvm-shortcuts.md
+++ b/common-tasks/managing-appvm-shortcuts.md
@ -15,11 +15,11 @@ For ease of use Qubes aggregates shortcuts to applications that are installed in

 ![dom0-menu.png"](/attachment/wiki/ManagingAppVmShortcuts/dom0-menu.png)

-To make newly installed applications show up in the menu, use the **qvm-sync-appmenus** command (Linux VMs does this automatically):
+To make newly installed applications show up in the menu, use the **qvm-sync-appmenus** command (Linux VMs do this automatically):

 `qvm-sync-appmenus vmname`

-After that, select the *Add more shortcuts* entry in VM's submenu to customize which applications are shown:
+After that, select the *Add more shortcuts* entry in the VM's submenu to customize which applications are shown:

 ![dom0-appmenu-select.png"](/attachment/wiki/ManagingAppVmShortcuts/dom0-appmenu-select.png)

@ -45,4 +45,4 @@ For Linux VMs the service script is in `/etc/qubes-rpc/qubes.GetAppMenus`. In Wi
 What if my application has not been automatically included in the list of available apps?
 -----------------------------------------------------------------------------------------

-You can manually create new entries in the "available applications" list of shortcuts. See [Signal](/doc/signal/) for a worked example of creating a new menu item for a Chrome .desktop shortcut.
+You can manually create new entries in the "available applications" list of shortcuts. See [Signal](/doc/signal/) for a working example of creating a new menu item for a Chrome .desktop shortcut.
--- a/common-tasks/software-update-dom0.md
+++ b/common-tasks/software-update-dom0.md
@ -14,7 +14,7 @@ Updating software in dom0
 Why would one want to update software in dom0?
 ----------------------------------------------

-Normally, there should be few reasons for updating software in dom0. This is because there is no networking in dom0, which means that even if some bugs are discovered e.g. in the dom0 Desktop Manager, this really is not a problem for Qubes, because none of the 3rd party software running in dom0 is accessible from VMs or the network in any way. Some exceptions to this include: Qubes GUI daemon, Xen store daemon, and disk back-ends. (We plan move the disk backends to an untrusted domain in Qubes 2.0.) Of course, we believe this software is reasonably secure, and we hope it will not need patching.
+Normally, there should be few reasons for updating software in dom0. This is because there is no networking in dom0, which means that even if some bugs are discovered e.g. in the dom0 Desktop Manager, this really is not a problem for Qubes, because none of the 3rd party software running in dom0 is accessible from VMs or the network in any way. Some exceptions to this include: Qubes GUI daemon, Xen store daemon, and disk back-ends. (We plan to move the disk backends to an untrusted domain in a future Qubes release) Of course, we believe this software is reasonably secure, and we hope it will not need patching.

 However, we anticipate some other situations in which updating dom0 software might be necessary or desirable:

--- a/common-tasks/software-update-vm.md
+++ b/common-tasks/software-update-vm.md
@ -20,7 +20,7 @@ In addition to saving on the disk space, and reducing domain creation time, anot

 The default template is called **fedora-14-x64** in Qubes R1 and **fedora-20-x64** in Qubes R2.

-The side effect of this mechanism is, of course, that if you install any software in your AppVM, more specifically in any directory other than `/home` or `/usr/local` then it will disappear after the AppVM reboot (as the root filesystem for this AppVM will again be "taken" from the TemplateVM). **This means one normally install software in the TemplateVM, not in AppVMs.**
+The side effect of this mechanism is, of course, that if you install any software in your AppVM, more specifically in any directory other than `/home` or `/usr/local` then it will disappear after the AppVM reboot (as the root filesystem for this AppVM will again be "taken" from the TemplateVM). **This means one normally installs software in the TemplateVM, not in AppVMs.**

 Unlike VM private filesystems, the template VM root filesystem does not support discard, so deleting files does not free the space in dom0. See [these instructions](/doc/template/fedora/upgrade-23-to-24/#compacting-the-upgraded-template) to recover space in dom0.

@ -33,7 +33,7 @@ In order to permanently install new software, you should:

 -   Install/update software as usual (e.g. using yum, or the dedicated GUI application). Then, shutdown the template VM,

-   You will see now that all the AppVMs based on this template (by default all your VMs) will be marked as "outdated" in the manager. This is because their filesystems have not been yet updated -- in order to do that, you must restart each VM. You don't need to restart all of them at the same time -- e.g. if you just need the newly installed software to be available in your 'personal' domain, then restart only this VM. You will restart others whenever this will be convenient to you.
+-   You will see now that all the AppVMs based on this template (by default all your VMs) will be marked as "outdated" in the manager. This is because their filesystems have not been yet updated -- in order to do that, you must restart each VM. You don't need to restart all of them at the same time -- e.g. if you just need the newly installed software to be available in your 'personal' domain, then restart only this VM. You can restart others whenever this will be convenient to you.

 Testing repositories
 --------------------
@ -115,19 +115,19 @@ As the TemplateVM is used for creating filesystems for other AppVMs, where you a

 There are several ways to deal with this problem:

-   Only install packages from trusted sources -- e.g. from the pre-configured Fedora repositories. All those packages are signed by Fedora, and as we expect that at least the package's installation scripts are not malicious. This is enforced by default (at the [firewall VM level](/doc/firewall/)), by not allowing any networking connectivity in the default template VM, except for access to the Fedora repos.
+-   Only install packages from trusted sources -- e.g. from the pre-configured Fedora repositories. All those packages are signed by Fedora, and we expect that at least the package's installation scripts are not malicious. This is enforced by default (at the [firewall VM level](/doc/firewall/)), by not allowing any networking connectivity in the default template VM, except for access to the Fedora repos.

 -   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 somehow 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 somewhat less trusted vendors, while the template used for more trusted AppVMs will only get packages from the standard Fedora repos.

 Some popular questions:

 -   So, why should we actually trust Fedora repos -- it also contains large amount of 3rd party software that might buggy, right?

-As long as template's compromise is considered, it doesn't really matter whether /usr/bin/firefox is buggy and can be exploited, or not. What matters is whether its *installation* scripts (such as %post in the rpm.spec) are benign or not. Template VM should be used only for installation of packages, and nothing more, so it should never get a chance to actually run the /usr/bin/firefox and got infected from it, in case it was compromised. Also, some of your more trusted AppVMs, would have networking restrictions enforced by the [firewall VM](/doc/firewall/), and again they should not fear this proverbial /usr/bin/firefox being potentially buggy and easy to compromise.
+As long as template's compromise is considered, it doesn't really matter whether /usr/bin/firefox is buggy and can be exploited, or not. What matters is whether its *installation* scripts (such as %post in the rpm.spec) are benign or not. Template VM should be used only for installation of packages, and nothing more, so it should never get a chance to actually run the /usr/bin/firefox and get infected from it, in case it was compromised. Also, some of your more trusted AppVMs, would have networking restrictions enforced by the [firewall VM](/doc/firewall/), and again they should not fear this proverbial /usr/bin/firefox being potentially buggy and easy to compromise.

-   But why trusting Fedora?
+-   But why trust Fedora?

 Because we chose to use Fedora as a vendor for the Qubes OS foundation (e.g. for Dom0 packages and for AppVM packages). We also chose to trust several other vendors, such as Xen.org, kernel.org, and a few others whose software we use in Dom0. We had to trust *somebody* as we are unable to write all the software from scratch ourselves. But there is a big difference in trusting all Fedora packages to be non-malicious (in terms of installation scripts) vs. trusting all those packages are non-buggy and non-exploitable. We certainly do not assume the latter.

@ -140,11 +140,11 @@ Standalone VMs

 Standalone VMs have their own copy of the whole filesystem, and thus can be updated and managed on its own. But this means that they take a few GBs on disk, and also that centralized updates do not apply to them.

-Sometime it might be convenient to have a VM that has its own filesystem, where you can directly introduce changes, without the need to start/stop the template VM. Such situations include e.g.:
+Sometimes it might be convenient to have a VM that has its own filesystem, where you can directly introduce changes, without the need to start/stop the template VM. Such situations include e.g.:

-   VMs used for development (devel environments requires a lot of \*-devel packages and specific devel tools)
+-   VMs used for development (devel environments require a lot of \*-devel packages and specific devel tools)

-   VMs used for installing untrusted packages. Normally you install digitally signed software from Red Hat/Fedora repositories, and it's reasonable that such software has non malicious *installation* scripts (rpm pre/post scripts). However, when you would like to install some packages form less trusted sources, or unsigned, then using a dedicated (untrusted) standalone VM might be a better way.
+-   VMs used for installing untrusted packages. Normally you install digitally signed software from Red Hat/Fedora repositories, and it's reasonable that such software has non malicious *installation* scripts (rpm pre/post scripts). However, when you would like to install some packages from less trusted sources, or unsigned, then using a dedicated (untrusted) standalone VM might be a better way.

 In order to create a standalone VM you can use a command line like this (from console in Dom0):

@ -168,14 +168,14 @@ qvm-create <vmname> --template <templatename> --label <label>
 Temporarily allowing networking for software installation
 ---------------------------------------------------------

-Some 3rd party applications cannot be installed using the standard yum repositories, and need to be manually downloaded and installed. When the installation requires internet connection to access 3rd party repositories, it will naturally fail when run in a Template VM because the default firewall rules for templates only allow connections to standard yum repositories. So it is necessary to modify firewall rules to allow less restrictive internet access for the time of the installation, if one really wants to install those applications into a template. As soon as software installation is completed, firewall rules should be returned back to the default state. The user should decided by themselves whether such 3rd party applications should be equally trusted as the ones that come from the standard Fedora signed repositories and whether their installation will not compromise the default Template VM, and potentially consider installing them into a separate template or a standalone VM (in which case the problem of limited networking access doesn't apply by default), as described above.
+Some 3rd party applications cannot be installed using the standard yum repositories, and need to be manually downloaded and installed. When the installation requires internet connection to access 3rd party repositories, it will naturally fail when run in a Template VM because the default firewall rules for templates only allow connections to standard yum repositories. So it is necessary to modify firewall rules to allow less restrictive internet access for the time of the installation, if one really wants to install those applications into a template. As soon as software installation is completed, firewall rules should be returned back to the default state. The user should decide by themselves whether such 3rd party applications should be equally trusted as the ones that come from the standard Fedora signed repositories and whether their installation will not compromise the default Template VM, and potentially consider installing them into a separate template or a standalone VM (in which case the problem of limited networking access doesn't apply by default), as described above.

 Updates proxy
 -------------

-Updates proxy is a service which filter http access to allow access to only something that looks like yum or apt repository. This is meant to mitigate user errors (like using browser in the template VM), rather than some real isolation. It is done with http proxy instead of simple firewall rules because it is hard to list all the repository mirrors (and keep that list up to date). The proxy is used only to filter the traffic, not to cache anything.
+Updates proxy is a service which filters http access to allow access to only something that looks like a yum or apt repository. This is meant to mitigate user errors (like using browser in the template VM), rather than some real isolation. It is done with http proxy instead of simple firewall rules because it is hard to list all the repository mirrors (and keep that list up to date). The proxy is used only to filter the traffic, not to cache anything.

-The proxy is running in selected VMs (by default all the NetVMs (1)) and intercept traffic directed to 10.137.255.254:8082. Thanks to such configuration all the VMs can use the same proxy address, and if there is a proxy on network path, it will handle the traffic (of course when firewall rules allows that). If the VM is configured to have access to the updates proxy (2), the startup scripts will automatically configure yum to really use the proxy (3). Also access to updates proxy is independent of any other firewall settings (VM will have access to updates proxy, even if policy is set to block all the traffic).
+The proxy is running in selected VMs (by default all the NetVMs (1)) and intercepts traffic directed to 10.137.255.254:8082. Thanks to such configuration all the VMs can use the same proxy address, and if there is a proxy on network path, it will handle the traffic (of course when firewall rules allow that). If the VM is configured to have access to the updates proxy (2), the startup scripts will automatically configure yum to really use the proxy (3). Also access to updates proxy is independent of any other firewall settings (VM will have access to updates proxy, even if policy is set to block all the traffic).

 (1) Services tab -\> "qubes-yum-proxy" entry; check qvm-service manual for details

@ -185,13 +185,13 @@ The proxy is running in selected VMs (by default all the NetVMs (1)) and interce

 ### Technical details

-1.  Updates proxy: It is running as "qubes-yum-proxy" service. Startup script of this service setup firewall rule to intercept proxy traffic:
+1.  Updates proxy: It is running as "qubes-yum-proxy" service. Startup script of this service sets up the firewall rule to intercept proxy traffic:

    ~~~
    iptables -t nat -A PR-QBS-SERVICES -d 10.137.255.254/32 -i vif+ -p tcp -m tcp --dport 8082 -j REDIRECT
    ~~~

-1.  VM using the proxy service Startup script (qubes-misc-post service) configure yum using /etc/yum.conf.d/qubes-proxy.conf file. It can either contain
+1.  VM using the proxy service Startup script (qubes-misc-post service) configures yum using /etc/yum.conf.d/qubes-proxy.conf file. It can either contain

    ~~~
    proxy=http://10.137.255.254:8082/
--- a/common-tasks/tips-and-tricks.md
+++ b/common-tasks/tips-and-tricks.md
@ -10,9 +10,9 @@ This section provides user suggested tips that aim to increase Qubes OS usabilit

 Opening links in your preferred AppVM
 -------------------------------------
-To increase both security and usability you can set an AppVM so that it automatically opens any link in an different AppVM of your choice. You can do this for example in the email AppVM, in this way you avoid to make mistakes like opening links in it. to learn more you can check [security guidelines](/doc/security-guidelines/) and [security goals](/security/goals/).
+To increase both security and usability you can set an AppVM so that it automatically opens any link in an different AppVM of your choice. You can do this for example in the email AppVM, in this way you avoid to make mistakes like opening links in it. To learn more you can check [security guidelines](/doc/security-guidelines/) and [security goals](/security/goals/).

-The command `qvm-open-in-vm` lets you open a document or a URL in another VM, it takes two parameters: vmname and filename.
+The command `qvm-open-in-vm` lets you open a document or a URL in another VM. It takes two parameters: vmname and filename.

 For example, if you launch this command from your email AppVM:

@ -20,7 +20,7 @@ For example, if you launch this command from your email AppVM:

 it will open duckduckgo.com in the `untrusted` AppVM (after you confirmed the request).

-If you want this to happen automatically you can creatte a .desktop file that advertises itself as a handler for http/https links, and then setting this as your default browser.
+If you want this to happen automatically you can create a .desktop file that advertises itself as a handler for http/https links, and then set this as your default browser.

 Open a text editor and copy and paste this into it:

@ -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 a not so trusted enviroment, for example a Windows VM, an application that track and report it's usage or you simply want to protect your data.
+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.

 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.
--- a/common-tasks/usb.md
+++ b/common-tasks/usb.md
@ -110,7 +110,7 @@ opt to create a USB qube during installation. This also occurs automatically if
 you choose to [create a USB qube] using the `qubesctl` method, which is the
 first pair of steps in the linked section.)

-**Warning** USB keyboard cannot be used to type the disk passphrase
+**Warning** A USB keyboard cannot be used to type the disk passphrase
 if USB controllers were hidden from dom0. Before hiding USB controllers
 make sure your laptop keyboard is not internally connected via USB
 (by checking output of `lsusb` command) or that you have a PS/2 keyboard at hand
@ -319,10 +319,10 @@ Attaching a single USB device to a qube (USB passthrough)
 ---------------------------------------------------------

 Starting with Qubes 3.2, it is possible to attach a single USB device to any
-Qube. While this is useful feature, it should be used with care, because there
+Qube. While this is a useful feature, it should be used with care, because there
 are [many security implications][usb-challenges] from using USB devices and USB
 passthrough will **expose your target qube** for most of them. If possible, use 
-method specific for particular device type (for example block devices described
+a method specific for particular device type (for example block devices described
 above), instead of this generic one.

 To use this feature, you need to install `qubes-usb-proxy` package in the
@ -355,7 +355,7 @@ When you finish, detach the device:
    sys-usb:2-5     058f:3822 058f_USB_2.0_Camera
    sys-usb:2-1     03f0:0641 PixArt_HP_X1200_USB_Optical_Mouse

-This feature is not yet available in Qubes Manager however, if you would like to contribute to Qubes OS project by implementing it and are a student please consider applying for the [Google Summer of Code][gsoc-page] scholarship and choosing QubesOS Project as a mentor organization. You can find list of our our Project Ideas [here][project-page].
+This feature is not yet available in Qubes Manager however, if you would like to contribute to Qubes OS project by implementing it and are a student please consider applying for the [Google Summer of Code][gsoc-page] scholarship and choosing QubesOS Project as a mentor organization. You can find list of our Project Ideas [here][project-page].


 [mass-storage]: https://en.wikipedia.org/wiki/USB_mass_storage_device_class
--- a/configuration/assigning-devices.md
+++ b/configuration/assigning-devices.md
@ -58,7 +58,7 @@ list of available devices, which you can select to be assigned to that VM.
 Finding the right USB controller
 --------------------------------

-If you want assign a certain [USB] device to a VM (by attaching the whole
+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:

@ -66,7 +66,7 @@ controller. First, check to which USB bus the device is connected:
 lsusb
 ~~~

-For example, I want assign a broadband modem to the netvm. In the out put 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):

@ -76,7 +76,7 @@ Bus 003 Device 003: ID 413c:818d Dell Computer Corp.

 The device is connected to USB bus \#3. Then check which other devices are
 connected to the same bus, since *all* of them will be assigned to the same VM.
-Now is the time to find right USB controller:
+Now is the time to find the right USB controller:

 ~~~
 readlink /sys/bus/usb/devices/usb3
--- a/configuration/config-files.md
+++ b/configuration/config-files.md
@ -40,7 +40,7 @@ problematic device drivers.

 Note that scripts need to be executable (chmod +x) to be used.

-Also take a look at [bind-dirs][/doc/bind-dirs] for instruction how to easily
+Also take a look at [bind-dirs](/doc/bind-dirs) for instruction how to easily
 modify arbitrary system file in AppVM and have those changes persistent.

 GUI and audio configuration in dom0
--- a/configuration/disk-trim.md
+++ b/configuration/disk-trim.md
@ -10,7 +10,7 @@ redirect_from:

 VMs have already TRIM enabled by default, but dom0 doesn't. There are some security implications (read for example [this article](https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html)), but IMO not very serious.

-To enable TRIM in dom0 you need:
+To enable TRIM in dom0 you need to:

 1.  Get your LUKS device UUID:

--- a/configuration/external-audio.md
+++ b/configuration/external-audio.md
@ -38,9 +38,9 @@ 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 you 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 you 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 an other line at the beginning:
+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:

 ~~~
 pactl unload-module module-udev-detect
--- a/configuration/http-filtering-proxy.md
+++ b/configuration/http-filtering-proxy.md
@ -31,10 +31,10 @@ prevents websites that use DNS-based load balancers from working
 unless the user reloads the firewall rules (which re-resolve the DNS
 names) whenever the balancer transfer her session to another IP. Third
 the initial setup of the rules is complicated as the firewall drops
-the connection silently. As a workaround on can use browser's network
+the connection silently. As a workaround one can use browser's network
 console to see what is blocked, but this is time-consuming and one can
 trivially miss some important cases like including in the firewall
-white list sites for OCSP SSL certificate verification.
+white-list sites for OCSP SSL certificate verification.

 These drawbacks can be mitigated if one replaces iptable-based rules
 with a filtering HTTP proxy. The following describes how to setup
@ -94,7 +94,7 @@ Setup
        name.ip-address-of-app-vm

   The name part before the dot can be arbitrary. For convenience one can
-   use AppVm name here, but this is not required. It is important to get
+   use AppVM name here, but this is not required. It is important to get
   ip address part right as this is what the control script uses to
   determine for which AppVM to apply the proxy rules. One can check the
   IP address of AppVM in Qubes VM manager in the VM settings dialog, see
--- a/configuration/managing-vm-kernel.md
+++ b/configuration/managing-vm-kernel.md
@ -49,7 +49,7 @@ updatevm          : sys-firewall
 Installing different kernel using Qubes kernel package
 ----------------------------------

-VM kernels are packages by Qubes team in `kernel-qubes-vm` packages. Generally system will keep the 3 newest available versions. You can list them with the `rpm` command:
+VM kernels are packages by Qubes team in `kernel-qubes-vm` packages. Generally the system will keep the 3 newest available versions. You can list them with the `rpm` command:

 ~~~
 [user@dom0 ~]$ rpm -qa 'kernel-qubes-vm*'
@ -58,7 +58,7 @@ kernel-qubes-vm-3.18.16-3.pvops.qubes.x86_64
 kernel-qubes-vm-3.18.17-4.pvops.qubes.x86_64
 ~~~

-If you want more recent version, you can check `qubes-dom0-unstable` repository. As the name suggest, keep in
+If you want a more recent version, you can check `qubes-dom0-unstable` repository. As the name suggests, keep in
 mind that those packages may be less stable than the default ones.

 Checking available versions in `qubes-dom0-unstable` repository:
@ -212,7 +212,7 @@ This is possible thanks to PV GRUB2 - GRUB2 running in the VM. To make it happen

 1. Install PV GRUB2 in dom0 - package is named `grub2-xen`.
 2. Install kernel in the VM. As with all VM software installation - this needs to be done in TemplateVM (of StandaloneVM if you are using one).
-3. Set VM kernel to `pvgrub2` value. You can use `pvgrub2` in selected VMs, not necessary all of them, even when it's template has kernel installed. You can still use dom0-provided kernel for selected VMs.
+3. Set VM kernel to `pvgrub2` value. You can use `pvgrub2` in selected VMs, not necessary all of them, even when its template has kernel installed. You can still use dom0-provided kernel for selected VMs.

 **WARNING: When using kernel from within VM, `kernelopts` parameter is ignored.**

@ -230,7 +230,7 @@ In Fedora based VM, you need to install `qubes-kernel-vm-support` package. This
 package include required additional kernel module and initramfs addition
 required to start Qubes VM (for details see
 [template implementation](/doc/template-implementation/)). Additionally you
-need some GRUB tools to create it's configuration. Note: you don't need actual
+need some GRUB tools to create its configuration. Note: you don't need actual
 grub bootloader as it is provided by dom0. But having one also shouldn't harm.

 ~~~
@ -268,7 +268,7 @@ In Debian based VM, you need to install `qubes-kernel-vm-support` package. This
 package include required additional kernel module and initramfs addition
 required to start Qubes VM (for details see
 [template implementation](/doc/template-implementation/)). Additionally you
-need some GRUB tools to create it's configuration. Note: you don't need actual
+need some GRUB tools to create its configuration. Note: you don't need actual
 grub bootloader as it is provided by dom0. But having one also shouldn't harm.

 ~~~
--- a/configuration/network-bridge-support.md
+++ b/configuration/network-bridge-support.md
@ -42,12 +42,12 @@ 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, enabled the Bridge option and restart your AppVM.
+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.

 NetVM patch (Qubes R2B2)
 ------------------------

-You need to modify manually the NetVM iptable script inside the NetVM. The reason is that by default the NetVM only accept traffic coming from network interfaces called vif\* (in our case, we will use an additional interface called bridge0. The second reason is that all trafic is NATed by default. In our case, we want to forward traffic from the bridge interface without modifying it, while NATing traffic coming from vif\* interfaces.
+You need to modify manually the NetVM iptable script inside the NetVM. The reason is that by default the NetVM only accepts traffic coming from network interfaces called vif\* (in our case, we will use an additional interface called bridge0. The second reason is that all trafic is NATed by default. In our case, we want to forward traffic from the bridge interface without modifying it, while NATing traffic coming from vif\* interfaces.

 Modify manually the Template you use for your NetVM (not the NetVM itself). This is by default fedora-x86\_64. Edit the file /etc/sysconfig/iptables. You need to modify two parts of the file.

@ -95,7 +95,7 @@ This requires:

 Note: A wireless interface cannot be bridged.

-The bridge edition GUI is somehow buggy as it does not remember all the parameter you setup. You can fix it by editing manually the files in /etc/NetworkManager/system-connections/. Here is one example for these files:
+The bridge edition GUI is somewhat buggy as it does not remember all the parameters you set up. You can fix it by editing manually the files in /etc/NetworkManager/system-connections/. Here is one example for these files:

 -   Bridge-DHCP

@ -137,7 +137,7 @@ Note: Do not forget to put stp=false if you bridge only eth0 because sending BPD
    slave-type=bridge
    ~~~

-If you do not manager to start your bridge, you can start it manually from a NetVM terminal:
+If you do not manage to start your bridge, you can start it manually from a NetVM terminal:

 ~~~
 $ nmcli con up id bridge0-eth0
--- a/configuration/network-printer.md
+++ b/configuration/network-printer.md
@ -27,7 +27,7 @@ In order to mitigate this risk, one might consider creating a custom template (i

 However, one should be aware that most (all?) network printing protocols are insecure, unencrypted protocols. This means, that an attacker who is able to sniff the local network, or who is controlling the (normally untrusted) Qubes NetVM, will likely to be able to see the documents being printed. This is a limitation of today's printers and printing protocols, something that cannot be solved by Qubes or any other OS.

-Additionally, the printer drivers as well as CUPS application itself, might be buggy and might got exploited when talking to a compromised printer (or by an attacker who controls the local network, or the default NetVM). Consider not using printing from your more trusted AppVMs for this reason.
+Additionally, the printer drivers as well as CUPS application itself, might be buggy and might get exploited when talking to a compromised printer (or by an attacker who controls the local network, or the default NetVM). Consider not using printing from your more trusted AppVMs for this reason.

 Steps to configure a network printer in a template VM
 ----------------------------------------------------------
--- a/configuration/postfix.md
+++ b/configuration/postfix.md
@ -99,14 +99,14 @@ alias_maps = hash:/etc/aliases
@localhost your.mail@example.com
 ~~~

-`/usr/local/etc/postfix/sender_relay`. This is important file. Put there all your SMTP servers. Pay attention to port (smtp/submission). Square brackets have their special meaning, they are almost certainly needed. For more info consult Postfix manual.
+`/usr/local/etc/postfix/sender_relay`. This is an important file. Put all your SMTP servers there. Pay attention to port (smtp/submission). Square brackets have their special meaning, they are almost certainly needed. For more info consult Postfix manual.

 ~~~
 your.mail@exmaple.com         [mail.example.com]:submission
 your.other@mail.com         [smtp.mail.com]:smtp
 ~~~

-`/usr/local/etc/postfix/saslpass`. Here you put passwords to above mentioned servers. It depends on provider if you need to put whole email as username or just the part before `@`.
+`/usr/local/etc/postfix/saslpass`. Here you put passwords to above mentioned servers. It depends on your provider if you need to put whole email as username or just the part before `@`.

 ~~~
 [mail.example.com]:submission     your.mail:y0urP4ssw0rd
--- a/configuration/resize-disk-image.md
+++ b/configuration/resize-disk-image.md
@ -34,7 +34,7 @@ The basic idea is to:
 1.  Shrink filesystem on the private disk image.
 2.  Then shrink the image.

-Ext4 does not support online shrinking, so can't be done as convenient as image grown. Note that we don't want to touch the VM filesystem directly in dom0 for security reasons. First you need to start VM without `/rw` mounted. One of the possibility is to interrupt its normal startup by adding `rd.break` kernel option:
+Ext4 does not support online shrinking, so can't be done as convenient as image grown. Note that we don't want to touch the VM filesystem directly in dom0 for security reasons. First you need to start VM without `/rw` mounted. One of the possibilities is to interrupt its normal startup by adding `rd.break` kernel option:

 ~~~
 qvm-prefs -s <vm-name> kernelopts rd.break
@ -63,7 +63,7 @@ Now you can resize the image:
 truncate -s <new-desired-size> /var/lib/qubes/appvms/<vm-name>/private.img
 ~~~

-**It is critical to use the same (or bigger for some safety margin) size in truncate call compared to resize2fs call. Otherwise you will loose your data!** Then reset kernel options back to default:
+**It is critical to use the same (or bigger for some safety margin) size in truncate call compared to resize2fs call. Otherwise you will lose your data!** Then reset kernel options back to default:

 ~~~
 qvm-prefs -s <vm-name> kernelopts default
@ -75,8 +75,8 @@ 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 shut off (including netvms etc).
-2.  Sanity check: verify that none of loop device are pointing at this template root.img: `sudo losetup -a`
+1.  Make sure that all the VMs based on this template are powered off (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.
 5.  Start the template.
--- a/configuration/resize-root-disk-image.md
+++ b/configuration/resize-root-disk-image.md
@ -11,7 +11,7 @@ redirect_from:
 Resize Root Disk Image
 ----------------------

-The safest way to increase the size of `root.img` is to turn your TemplateVM into a StandaloneVM. Doing this means it will have it's own root filesystem *(StandaloneVMs use a copy of template, instead of smart sharing)*. To do this run `qvm-create --standalone` from `dom0` Konsole.
+The safest way to increase the size of `root.img` is to turn your TemplateVM into a StandaloneVM. Doing this means it will have its own root filesystem *(StandaloneVMs use a copy of template, instead of smart sharing)*. To do this run `qvm-create --standalone` from `dom0` Konsole.

 ### Resize a StandaloneVM Root Image

@ -27,7 +27,7 @@ Then start Terminal for this StandaloneVM and run:
 sudo resize2fs /dev/mapper/dmroot
 ~~~

-Shutdown the StandaloneVM and you will have extended the size of it's `root.img`
+Shutdown the StandaloneVM and you will have extended the size of its `root.img`


 ### Resize a TemplateVM Root Image
@ -51,4 +51,4 @@ to do!`.
 sudo resize2fs /dev/mapper/dmroot
 ~~~

-Shutdown the TemplateVM and you will have extended the size of it's `root.img`.
+Shutdown the TemplateVM and you will have extended the size of its `root.img`.
--- a/configuration/salt.md
+++ b/configuration/salt.md
@ -227,7 +227,7 @@ malicious target VM.

 ## Writing your own configuration

-Let's start with quick example:
+Let's start with a quick example:

    my new and shiny vm:
      qvm.present:
@ -304,7 +304,7 @@ You can set properties of existing domain:
        - netvm: sys-firewall

 Note that `name:` is a matcher, ie. it says the domain which properties will be
-manipulated is called `salt-test2`. The implies that you currently cannot rename
+manipulated is called `salt-test2`. This implies that you currently cannot rename
 domains this way.

 ### qvm.service
--- a/hardware/certified-laptops.md
+++ b/hardware/certified-laptops.md
@ -15,7 +15,7 @@ getting your company's hardware Qubes-certified, please see the [Hardware
 Certification] page.

 We aim to partner with a few select computer makers to ensure that Qubes is
-compatible with them and new users have clear path towards getting started
+compatible with them and new users have a clear path towards getting started
 with Qubes if they desire. We look for these makers to be as diverse as possible
 in terms of geography, cost, and availability.

--- a/installing/live-usb.md
+++ b/installing/live-usb.md
@ -29,7 +29,7 @@ traditional Linux distros don't have to bother with:
   version, sorry.
 2. We discovered that the Fedora liveusb-create does *not* verify signatures on
   downloaded packages. We have temporarily fixed that by creating a local repo,
-   verifying the signatures manually (ok, with a script ;) and then building
+   verifying the signatures manually (ok, with a script ;) ) and then building
   from there. Sigh.
 3. We had to solve the problem of Qubes too easily triggering an Out Of Memory
   condition in Dom0 when running as Live OS.
@ -65,7 +65,7 @@ Live USB variant:
   A nice variant of this persistence option, especially for frequent
   travelers, would be to augment our backup tools so that it was
   possible to create a LiveUSB-hosted backups of select VMs. One could then
-   pick a few of their VMs, necessary for a specific travel, back them to a
+   pick a few of their VMs, necessary for a specific trip, back them up to a
   LiveUSB stick, and take this stick when traveling to a hostile country (not
   risking taking other, more sensitive ones for the travel). This should make
   life a bit simpler
@ -90,7 +90,7 @@ expectations accordingly.)
 3. Currently there is no "install to disk" option. We will be adding this
   in the future.
 4. The amount of "disk" space is limited by the amount of RAM the laptop
-   has. This has a side effect of e.g. not being able to restore (even few) VMs
+   has. This has a side effect of e.g. not being able to restore (even a few) VMs
   from a large Qubes backup blob.
 5. It's easy to generate Out Of Memory (OOM) in Dom0 by creating lots of VMs
   which are writing a lot into the VMs filesystem.
--- a/installing/upgrade/upgrade-to-r3.0.md
+++ b/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
 -------------------------------------------

-When for some reason you did not upgraded all the templates and standalone VMs before upgrading dom0, you can still do this, but it will be somehow more complicated. This can be a 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 somewhat more complicated. This can be a case when you restore backup done on Qubes R2.

 When you start R2 template/standalone VM on R3.0, there will be some limitations:

--- a/installing/version-scheme.md
+++ b/installing/version-scheme.md
@ -17,7 +17,7 @@ From now on, it will be as follows.
 Qubes distributions and products
 --------------------------------

-We intend to make it easy to make a remix of qubes, targeting another
+We intend to make it easy to make a remix of Qubes, targeting another
 hypervisor or isolation provider. We may also create commercial products
 intended for specific circumstances. There is one distinguished distribution
 called **Qubes OS**. All source code for it is available for download under GPL
@ -28,13 +28,13 @@ Release version
 ---------------

 Qubes OS as a whole is released from time to time. Version scheme for all
-releases is modeled after Linux kernel version numbers. When announcing new
+releases is modeled after Linux kernel version numbers. When announcing a new
 release, we decide on the major.minor version (like `3.0`) and release
 `3.0-rc1`. When we feel that enough progress has been made, we put `3.0-rc2`
 and so on. All these versions are considered unstable and not ready for
 production. You may ask for support on mailing lists (specifically
 **qubes-devel**), but it is not guaranteed (you may for example get answer
-„update to newer `-rc`”). Public ISO image may or may not be available.
+“update to newer `-rc`”). Public ISO image may or may not be available.

 When enough development has been made, we announce the first stable version,
 like e.g. `3.0.0` (i.e. without `-rc`). This version is considered stable and
@ -46,7 +46,7 @@ bugfixes as `3.0.1`, `3.0.2` and so on, while new features come into the next
 release e.g. `3.1-rcX`.

 Tickets in the tracker are sorted out by release major.minor, such as `3.0`,
-`3.1` (trac calls this „milestone”).
+`3.1` (trac calls this “milestone”).

 Release schedule
 ----------------
--- a/managing-os/hvm.md
+++ b/managing-os/hvm.md
@ -48,7 +48,7 @@ The above command assumes the installation ISO was transferred to Dom0 (copied u
 qvm-start win7 --cdrom=/dev/cdrom
 ~~~

-Next the VM will start booting from the attached CDROM device (which in the example above just happens to be a Windows 7 installation disk). Depending on the OS that is being installed in the VM one might be required to start the VM several times (as is the case with Windows 7 installations), because whenever the installer wants to "reboot the system" it actually shutdowns the VM and Qubes won't automatically start it.  Several invocations of qvm-start command (as shown above) might be needed.
+Next the VM will start booting from the attached CDROM device (which in the example above just happens to be a Windows 7 installation disk). Depending on the OS that is being installed in the VM one might be required to start the VM several times (as is the case with Windows 7 installations), because whenever the installer wants to "reboot the system" it actually shuts down the VM and Qubes won't automatically start it.  Several invocations of qvm-start command (as shown above) might be needed.

 [![r2b1-win7-installing.png](/attachment/wiki/HvmCreate/r2b1-win7-installing.png)](/attachment/wiki/HvmCreate/r2b1-win7-installing.png)

@ -170,7 +170,7 @@ Cloning HVM domains

 Just like normal AppVMs, the HVM domains can also be cloned either using a command-line `qvm-clone` command or via manager's 'Clone VM' option in the right-click menu.

-The cloned VM will get identical root and private image and will essentially be an identical of the original VM except that it will get a different MAC address for the networking interface:
+The cloned VM will get identical root and private images and will essentially be identical to the original VM except that it will get a different MAC address for the networking interface:

 ~~~
 [joanna@dom0 ~]$ qvm-prefs win7
--- a/managing-os/netbsd.md
+++ b/managing-os/netbsd.md
@ -9,7 +9,7 @@ How to Create a NetBSD VM

 1. Create a StandaloneVM with the default template.
 2. Replace `vmlinuz` with the `netbsd-INSTALL_XEN3_DOMU` kernel.
-3. During setup, chose to install on the `xbd1` hard disk.
+3. During setup, choose to install on the `xbd1` hard disk.
 4. Attach the CD to the VM.
 5. Configure the networking.
 6. Optionally enable SSHD during the post-install configuration.
--- a/managing-os/pentesting/blackarch.md
+++ b/managing-os/pentesting/blackarch.md
@ -10,9 +10,9 @@ redirect_from:

 - The installation scripts and provided tools may have bugs, be vulnerable to Man in the Middle (MitM) attacks or other vulnerabilities.

- Adding additional repositories or tools for installing software extends your trust to those tool provider.
+- Adding additional repositories or tools for installing software extends your trust to those tool providers.

-Please keep in mind that using such a VM or VM's based on the template for security and privacy critical tasks is not recommended.  
+Please keep in mind that using such a VM or VMs based on the template for security and privacy critical tasks is not recommended.  

 How to Create a BlackArch VM
 ============================
--- a/managing-os/pentesting/kali.md
+++ b/managing-os/pentesting/kali.md
@ -10,7 +10,7 @@ redirect_from:

 - The installation scripts and provided tools may have bugs, be vulnerable to Man in the Middle (MitM) attacks or other vulnerabilities.

- Adding additional repositories or tools for installing software extends your trust to those tool provider.
+- Adding additional repositories or tools for installing software extends your trust to those tool providers.

 Please keep in mind that using such a VM or VM's based on the template for security and privacy critical tasks is not recommended.

--- a/managing-os/pentesting/ptf.md
+++ b/managing-os/pentesting/ptf.md
@ -10,7 +10,7 @@ redirect_from:

 - The installation scripts and provided tools may have bugs, be vulnerable to Man in the Middle (MitM) attacks or other vulnerabilities.

- Adding additional repositories or tools for installing software extends your trust to those tool provider.
+- Adding additional repositories or tools for installing software extends your trust to those tool providers.

 Please keep in mind that using such a VM or VM's based on the template for security and privacy critical tasks is not recommended.

@ -21,7 +21,7 @@ How to create Penetration Testers Framework (PTF) VM

 PTF attempts to install all of your penetration testing tools (latest and greatest), compile them, build them, and make it so that you can install/update your distribution on any machine." (source [PTF Readme](https://github.com/trustedsec/ptf/blob/master/README.md))

-**Note** PTF works on Debian testing as well as on Debian 8. PTF itself works with Debian 8, but the software tools will have missing dependencies. Metasploit for examples requires a newer Ruby version than Debian 8 has in the repositories. Therefor the best way to install PTF is by upgrading a Debian 8 into Debian testing with additional Kali repositories. Instead of installing the tools from Kali, PTF will install and update the newest tools.
+**Note** PTF works on Debian testing as well as on Debian 8. PTF itself works with Debian 8, but the software tools will have missing dependencies. Metasploit for example requires a newer Ruby version than Debian 8 has in the repositories. Therefore the best way to install PTF is by upgrading a Debian 8 into Debian testing with additional Kali repositories. Instead of installing the tools from Kali, PTF will install and update the newest tools.

 Create Debian Based Penetration Testers Framework (PTF) Template
 ----------------------------------------------------------------
@ -108,7 +108,7 @@ possible to do sudo ptf/ptf
                    [*] Exiting PTF - the easy pentest platform creation framework.
                    sudo msfconsole

-5. Create a AppVMs based on the `ptf` template
+5. Create an AppVM based on the `ptf` template

    - (Optional) Attach necessary devices

--- a/managing-os/templates/archlinux.md
+++ b/managing-os/templates/archlinux.md
@ -53,18 +53,18 @@ In order to keep the template as small and simple as possible, default installed
 * Some font packages to keep good user experience
 * leafpad: a note pad
 * xfce4-terminal: a terminal
-* thunar: a file browser that support mounting usb keys
+* thunar: a file browser that supports mounting usb keys
 * firefox: web browser
 * thunderbird: a mail browser
 * evince: a document viewer

-Note that Archlinux does not install GUI packages by default as this decision is left to users. This packages have only been selected to have a usable template.
+Note that Archlinux does not install GUI packages by default as this decision is left to users. These packages have only been selected to have a usable template.

 ## Updating a Qubes-3.1 Archlinux Template

-If you decide to use binary packages but that you where using a Qubes-3.1 Template, your can follow these instructions to enable Qubes 3.2 agents.
+If you decide to use binary packages but that you were using a Qubes-3.1 Template, you can follow these instructions to enable Qubes 3.2 agents.

-You can use a template that you built for Qubes 3.1 in Qubes 3.2. The qrexec and gui agent functionnalities should still be working so that you can at least open a terminal.
+You can use a template that you built for Qubes 3.1 in Qubes 3.2. The qrexec and gui agent functionalities should still be working so that you can at least open a terminal.

 In order to enable binary packages for Qubes 3.2, add the following lines to the end of /etc/pacman.conf

@ -76,22 +76,22 @@ Server = http://olivier.medoc.free.fr/archlinux/current/
 You should then follow the instruction related to pacman-key in order to sign the binary packages PGP key. With the key enabled, a pacman update will update qubes agents:
 ` # pacman -Suy `

-The two line that have just been added to /etc/pacman.conf should then be removed as they have been included in the qubes-vm-core update in the file `/etc/pacmand.d/99-qubes-repository-3.2.conf`
+The two lines that have just been added to /etc/pacman.conf should then be removed as they have been included in the qubes-vm-core update in the file `/etc/pacmand.d/99-qubes-repository-3.2.conf`

 ## Known Issues

 ### Package cannot be updated because of errors related to xorg-server or pulseaudio versions

-In case 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.
+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.

-In this case, the gui-agent-linux component of Qubes-OS needs to be rebuild using these last xorg-server or pulseaudio libraries. You can try to rebuilt it yourself or wait for a new qubes-vm-gui package to be available.
+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.

-### qubes-vm is apparently starting properly (green dot) however graphical applications do not appears to work
+### qubes-vm is apparently starting properly (green dot) however graphical applications do not appear to work

-They are multiple potential reasons. Some of them are described in the following issues:
+They are multiple potential reasons. Some of them are described in the following issue:
 * https://github.com/QubesOS/qubes-issues/issues/2612

-In issue 2612, check that the option `noauto` is present for all lines in /etc/fstab related to /rw or /home. This bug can appears if you come from an old Archlinux Template (pre February 2017).
+In issue 2612, check that the option `noauto` is present for all lines in /etc/fstab related to /rw or /home. This bug can appear if you come from an old Archlinux Template (pre February 2017).

 ## Debugging a broken VM

@ -101,7 +101,7 @@ In order to identify the issue, you should start by getting a console access to

 * Or by running in dom0 `sudo xl console yourbrokenvm`

-Starts by trying to run a GUI application such as xfce4-terminal in order to identify any error message.
+Start by trying to run a GUI application such as xfce4-terminal in order to identify any error message.

 Then you can check potential broken systemd service by running the following command inside the broken vm: `systemctl | grep fail`.

@ -112,7 +112,7 @@ Finally, errors related to the GUI agent can be found inside the VM in `/home/us
 ## Packages manager wrapper


-Powerpill is a full Pacman wrapper that not only give easy proxy configuration but further offers numerous other advantages.
+Powerpill is a full Pacman wrapper that not only gives easy proxy configuration but further offers numerous other advantages.

 Please check out:

@ -121,7 +121,7 @@ Please check out:
 [XYNE's (dev) Powerpill](http://xyne.archlinux.ca/projects/powerpill/)


-**Important Note:** As you are working in a template vm, by default, you will have to open network access to the template to download files manually, except for package managed which should be handled by the Qubes proxy. You can use the "allow full access for" a given time period in the FW settings of the template in the VMM or open up the various services through the same window.  Remember to change it back if you choose the later route.  Actions needing network access will be noted with (needs network access)
+**Important Note:** As you are working in a template vm, by default, you will have to open network access to the template to download files manually, except for managed packages which should be handled by the Qubes proxy. You can use the "allow full access for" a given time period in the FW settings of the template in the VMM or open up the various services through the same window.  Remember to change it back if you choose the later route.  Actions needing network access will be noted with (needs network access)

 <br>
 <br>
@ -134,7 +134,7 @@ Please check out:

 *   **$ sudo nano -w /etc/pacman.conf**
        
-* Below is the output of a correct pacman.conf file  Make the changes so your file matches this one or rename the original and create a new one and copy and paste this text into it.  Text should be justified left in the file.  The changes from your default are to make gpg sig signing mandatory for packages but not required for DBs for the archlinux repos.  Also to add the repo (at the end) for the Powerpill package.
+* Below is the output of a correct pacman.conf file  Make the changes so your file matches this one or rename the original and create a new one and copy and paste this text into it.  Text should be justified left in the file.  The changes from your default are to make gpg signing mandatory for packages but not required for DBs for the archlinux repos.  Also to add the repo (at the end) for the Powerpill package.


 <br>
--- a/managing-os/templates/debian/upgrade-8-to-9.md
+++ b/managing-os/templates/debian/upgrade-8-to-9.md
@ -116,7 +116,7 @@ Additional Information
 ----------------------

 It should be noted that Debian 9 (Stretch) is currently marked testing and
-should be treat as such. For projects that need absolute stability, upgrading
+should be treated as such. For projects that need absolute stability, upgrading
 may not be the best option.

 Debian Stretch packages were first made available in the Qubes R3.1 repositories.
--- a/managing-os/templates/fedora-minimal.md
+++ b/managing-os/templates/fedora-minimal.md
@ -29,7 +29,7 @@ The download may take a while depending on your connection speed.
 Duplication and first steps
 ---------------------------

-It is higly recommended to clone the original template, and make any changes in the clone instead of the original template. The following command clones the template. Replace `your-new-clone` with your desired name.
+It is highly recommended to clone the original template, and make any changes in the clone instead of the original template. The following command clones the template. Replace `your-new-clone` with your desired name.

 ~~~
 [user@dom0 ~]$ qvm-clone fedora-24-minimal your-new-clone
--- a/managing-os/templates/fedora/upgrade-20-to-21.md
+++ b/managing-os/templates/fedora/upgrade-20-to-21.md
@ -202,7 +202,7 @@ In this case, you have several options:
 1. [Increase the TemplateVM's disk image size](/doc/resize-disk-image/).
    This is the solution mentioned in the main instructions above.
 2. Delete files in order to free up space. One way to do this is by
-    uninstalling packages. You may then reinstalling them again after you
+    uninstalling packages. You may then reinstall them again after you
    finish the upgrade process, if desired). However, you may end up having to
    increase the disk image size anyway (see previous option).
 3. Increase the `root.img` size with `qvm-grow-root`. It should be easy to
--- a/managing-os/templates/fedora/upgrade-21-to-23.md
+++ b/managing-os/templates/fedora/upgrade-21-to-23.md
@ -185,7 +185,7 @@ In this case, you have several options:
 1. [Increase the TemplateVM's disk image size](/doc/resize-disk-image/).
    This is the solution mentioned in the main instructions above.
 2. Delete files in order to free up space. One way to do this is by
-    uninstalling packages. You may then reinstalling them again after you
+    uninstalling packages. You may then reinstall them again after you
    finish the upgrade process, if desired). However, you may end up having to
    increase the disk image size anyway (see previous option).
 3. Increase the `root.img` size with `qvm-grow-root`. It should be easy to
--- a/managing-os/templates/fedora/upgrade-23-to-24.md
+++ b/managing-os/templates/fedora/upgrade-23-to-24.md
@ -215,7 +215,7 @@ In this case, you have several options:
 1. [Increase the TemplateVM's disk image size][resize-disk-image].
    This is the solution mentioned in the main instructions above.
 2. Delete files in order to free up space. One way to do this is by
-    uninstalling packages. You may then reinstalling them again after you
+    uninstalling packages. You may then reinstall them again after you
    finish the upgrade process, if desired). However, you may end up having to
    increase the disk image size anyway (see previous option).
 3. Increase the `root.img` size with `qvm-grow-root`.
--- a/managing-os/windows/windows-appvms.md
+++ b/managing-os/windows/windows-appvms.md
@ -124,14 +124,14 @@ Qubes allows HVM VMs to share a common root filesystem from a select Template VM
 qvm-create --hvm-template win7-x64-template -l green
 ~~~

-... and install Windows OS (or other OS) into this template the same way as you would install it into a normal HVM -- please see [this page](/doc/hvm-create/) instructions. However, it would make lots of sense to store the `C:\Users` directory on the 2nd disk which is automatically exposed by Qubes to all HVMs. This 2nd disk is backed by the `private.img` file in the AppVMs' and is not reset upon AppVMs reboot, so the user's directories and profiles would survive the AppVMs reboot, unlike the "root" filesystem which will be reverted to the "golden image" from the Template VM automatically. To facilitate such separation of user profiles, Qubes Windows Tools provide an option to automatically move `C:\Users` directory to the 2nd disk backed by `private.img`. It's a selectable feature of the installer, enabled by default. If that feature is selected during installation, completion of the process requires two reboots:
+... and install Windows OS (or other OS) into this template the same way as you would install it into a normal HVM -- please see instructions on [this page](/doc/hvm-create/). However, it would make lots of sense to store the `C:\Users` directory on the 2nd disk which is automatically exposed by Qubes to all HVMs. This 2nd disk is backed by the `private.img` file in the AppVMs' and is not reset upon AppVMs reboot, so the user's directories and profiles would survive the AppVMs reboot, unlike the "root" filesystem which will be reverted to the "golden image" from the Template VM automatically. To facilitate such separation of user profiles, Qubes Windows Tools provide an option to automatically move `C:\Users` directory to the 2nd disk backed by `private.img`. It's a selectable feature of the installer, enabled by default. If that feature is selected during installation, completion of the process requires two reboots:

 -   The private disk is initialized and formatted on the first reboot after tools installation. It can't be done **during** the installation because Xen mass storage drivers are not yet active.
 -   User profiles are moved to the private disk on the next reboot after the private disk is initialized. Reboot is required because the "mover utility" runs very early in the boot process so OS can't yet lock any files in there. This can take some time depending on the profiles' size and because the GUI agent is not yet active dom0/Qubes Manager may complain that the AppVM failed to boot. That's a false alarm (you can increase AppVM's default boot timeout using `qvm-prefs`), the VM should appear "green" in Qubes Manager shortly after.

-It also makes sense to disable Automatic Updates for all the template-based AppVMs -- of course this should be done in the Template VM, not in individual AppVMs, because the system-wide setting are stored in the root filesystem (which holds the system-wide registry hives). Then, periodically check for updates in the Template VM and the changes will be carried over to any child AppVMs.
+It also makes sense to disable Automatic Updates for all the template-based AppVMs -- of course this should be done in the Template VM, not in individual AppVMs, because the system-wide settings are stored in the root filesystem (which holds the system-wide registry hives). Then, periodically check for updates in the Template VM and the changes will be carried over to any child AppVMs.

-Once the template has been created and installed it is easy to create AppVMs based on:
+Once the template has been created and installed it is easy to create AppVMs based on it:

 ~~~
 qvm-create --hvm <new windows appvm name> --template <name of template vm> --label <label color>
--- a/privacy/anonymizing-your-mac-address.md
+++ b/privacy/anonymizing-your-mac-address.md
@ -149,7 +149,7 @@ macspoof-enp0s0  meminfo-writer   updates-proxy-setup
 ~~~

 Now, also within the TemplateVM, type the following commands for each hardware device that you want to randomize a MAC 
-addresses for
+address for

 ~~~
 sudo systemctl enable macspoof@wlp0s1
--- a/privacy/whonix-install.md
+++ b/privacy/whonix-install.md
@ -19,7 +19,7 @@ Using privacy and anonymization tools like Whonix is not a magical solution that
 * Do you think nobody can eavesdrop on your communications because you are using Tor?
 * Do you know how Whonix works?

-If you answered no, have a look at the [about](https://www.whonix.org/wiki/About), [warning](https://www.whonix.org/wiki/Warning) and [do not](https://www.whonix.org/wiki/DoNot) pages (on the Whonix website) to make sure Whonix is the right tool for you and you understand  it's limitations.
+If you answered no, have a look at the [about](https://www.whonix.org/wiki/About), [warning](https://www.whonix.org/wiki/Warning) and [do not](https://www.whonix.org/wiki/DoNot) pages (on the Whonix website) to make sure Whonix is the right tool for you and you understand its limitations.

 ---

@ -37,7 +37,7 @@ After doing this, you should see two new TemplateVMs in the VM Manager called `w

 ### Enabling AppArmor

-This is an optional security enhancement (for testers-only). If you’re technical & interested, see [Enabling AppArmor](/doc/privacy/customizing-whonix/).
+This is an optional security enhancement (for testers-only). If you’re technical and interested, see [Enabling AppArmor](/doc/privacy/customizing-whonix/).

 ### Configuring Whonix VMs

@ -57,7 +57,7 @@ Great. You should be all done installing Whonix into Qubes. Use these two Templa

 ### Running Applications

-To start an application in the **Whonix-Workstation AppVM** that you created, launch it like any other- open the `Qubes App Launcher` and then select an app such as `Privacy Browser` which will then launch the Tor Browser
+To start an application in the **Whonix-Workstation AppVM** that you created, launch it like any other- open the `Qubes App Launcher` and then select an app such as `Privacy Browser` which will then launch the Tor Browser.

 ### Advanced Information

--- a/releases/1.0/release-notes.md
+++ b/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 somehow 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 somewhat 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.

--- a/security-info/security-pack.md
+++ b/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
-    somehow minimize these consequences with this canary thing.
+    somewhat minimize these consequences with this canary thing.
    
    Additionally the canary is a nice way of ensuring "freshness" of our
    messaging to the community.
@ -254,7 +254,7 @@ verifying its contents, and reading them.
    good.)

 The same procedures can be applied to any directory or file in the
-`qubes-secpack`. Two methods of verification (signed Git tags and deatched PGP
+`qubes-secpack`. Two methods of verification (signed Git tags and detached PGP
 signatures) are provided to ensure that the system is robust (e.g., against a
 potential failure in Git tag-based verification) and to give users more options
 to verify the files.
--- a/security/security-guidelines.md
+++ b/security/security-guidelines.md
@ -58,7 +58,7 @@ Observing Security Contexts
 Each VM is assigned a specific colour for its window borders. These borders are how Qubes displays the **security context** of applications and data so that users can be easily aware of this at all times. Be sure to check the colour of window borders before taking any action, particularly if it affects the security of your system. [See this blog post for more information](https://blog.invisiblethings.org/2011/05/21/app-oriented-ui-model-and-its-security.html).

 Always remember that any "red" window can draw "green" password prompts. 
-Don't let yourself be tricked into entering credentials designated to one qube into a forged input boxes rendered by another.
+Don't let yourself be tricked into entering credentials designated to one qube into a forged input box rendered by another.
 For XFCE users (which is the default desktop environment on QubesOS) it would be wise to manually move the more trusted window so that it is not displayed on top of a less trusted one, but rather over the trusted Dom0 wallpaper. 
 If you use KDE, it has a helpful feature called **Expose-like effect** that is activated in System Tools -\> System Settings -\> Desktop Effects -\> All Effects -\> Desktop Grid Present Windows. 
 Performing these steps makes it easier to tell the difference between when you're being phished and when you're genuinely being asked for credentials.
--- a/security/split-bitcoin.md
+++ b/security/split-bitcoin.md
@ -48,7 +48,7 @@ Important Notes
 * The private keys (xpriv) should never be moved outside of `offline-bitcoin`.
 * For copying out the public keys (xpub), Qubes provides two secure, convenient
  methods: the [inter-VM clipboard] and [inter-VM file copy] tools. Compared to
-  traditional physically air-gapped machines, these tools makes it very easy to
+  traditional physically air-gapped machines, these tools make it very easy to
  copy out public keys.

 [inter-VM clipboard]: /doc/copy-paste/
--- a/security/yubi-key.md
+++ b/security/yubi-key.md
@ -24,23 +24,23 @@ 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
-repository and you need to compile it yourself. This can change in the future.
+repository and you need to compile it yourself. This might change in the future.

 Challenge-reponse mode
 ----------------------

 In this mode, your YubiKey will generate response based on secret key, and
 random challenge (instead of counter). This means that it isn't possible to
-generate response in advance even when someone get access to your YubiKey. This
-makes reasonably safe to use the same YubiKey for other services (also in
+generate 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 setup your YubiKey, choose separate
+Same as in OTP case, you will need to set up your YubiKey, choose separate
 password (other than your login password!) and apply the configuration.

-To use this mode you need:
+To use this mode you need to:

-1. Configure your YubiKey for challenge-reponse HMAC-SHA1 mode, for example
+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.
@ -93,31 +93,31 @@ password associated with YubiKey. If you configured so, YubiKey will request
 confirmation by pressing button on it (it will blink).
 When everything is ok, your screen will be unlocked.

-In any case you can still use your login password, but do it in secure location
+In any case you can still use your login password, but do it in a secure location
 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
-YubiKey. This will require creating simple qrexec service which will expose
-ability to lock the screen to your USB VM, and then adding udev hook to
+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
 actually call that service.

 1. First configure the qrexec service. Create `/etc/qubes-rpc/custom.LockScreen` (in dom0)
-  with simple command to lock the screen. In case of xscreensaver (used in Xfce)
+  with a simple command to lock the screen. In case of xscreensaver (used in Xfce)
  it would be:

        DISPLAY=:0 xscreensaver-command -lock

-2. Allow your USB VM to call that service. Assuming that its named `sys-usb` it
+2. Allow your USB VM to call that service. Assuming that it's named `sys-usb` it
 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 single line:
+`/rw/config/yubikey.rules`. Write there a single line:

        ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SECURITY_TOKEN}=="1", RUN+="/usr/bin/qrexec-client-vm dom0 custom.LockScreen"

--- a/services/dvm-impl.md
+++ b/services/dvm-impl.md
@ -32,7 +32,7 @@ Preparing a savefile is done by */usr/lib/qubes/qubes\_prepare\_saved\_domain.sh
 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 somehow 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).
+*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).

 Restoring a DisposableVM from the savefile
 ------------------------------------------
--- a/system/security-critical-code.md
+++ b/system/security-critical-code.md
@ -48,7 +48,7 @@ Additionally when we consider attacks that originate through a compromised netwo
 Buggy Code vs. Back-doored Code Distinction
 -------------------------------------------

-There is an important distinction between the buggy code and maliciously trojaned code. We could have the most secure architecture and the most bulletproof TCB that perfectly isolates all domains from each other, but it still would be pretty useless if all the code used within domains, e.g. the actual email clients, word processors, etc, was somehow trojaned. In that case only network-isolated domains could be somehow trusted, while all others could be not.
+There is an important distinction between the buggy code and maliciously trojaned code. We could have the most secure architecture and the most bulletproof TCB that perfectly isolates all domains from each other, but it still would be pretty useless if all the code used within domains, e.g. the actual email clients, word processors, etc, was somehow trojaned. In that case only network-isolated domains could be somewhat trusted, while all others could be not.

 The above means that we must trust at least some of the vendors (not all, of course, but at least those few that provide the apps that we use in the most critical domains). In practice in Qubes OS we trust the software provided by Fedora project. This software is signed by Fedora distribution keys and so it is also critical that the tools used in domains for software updates (yum and rpm) be trusted.

--- a/troubleshooting/updating-debian-and-whonix.md
+++ b/troubleshooting/updating-debian-and-whonix.md
@ -58,7 +58,7 @@ Sometimes if you see a message such as:
 Could not resolve 'security.debian.org'
 ~~~

-It helps to running the following command:
+It helps to run the following command:

 ~~~
 nslookup security.debian.org
@ -135,4 +135,4 @@ Be careful. If the updated file isn't coming from Whonix specific package (some
 How could you find out if the file is coming from a Whonix specific package or not?

 * Whonix specific packages are sometimes called `whonix-...`. In the example above it's saying `Setting up ifupdown ...`, so the file isn't coming from a Whonix specific package. In this case, you should press `n` as advised in the paragraph above.
-* If the package name does include `whonix-...`, it's a Whonix specific package. In that case, your safest bet should be pressing `y`, but then you would loose your customized settings. You can re-add them afterwards. Such conflicts will hopefully rarely happen, if you use [Whonix modular flexible .d style configuration folders](https://www.whonix.org/wiki/Whonix_Configuration_Files).
+* If the package name does include `whonix-...`, it's a Whonix specific package. In that case, your safest bet should be pressing `y`, but then you would lose your customized settings. You can re-add them afterwards. Such conflicts will hopefully rarely happen, if you use [Whonix modular flexible .d style configuration folders](https://www.whonix.org/wiki/Whonix_Configuration_Files).