Update README

.gitignore

@@ -34,3 +34,4 @@ artifacts
 rattlesnakeos-stack
 .vscode/
 *.toml
+.DS_Store

README.md

@@ -11,7 +11,7 @@ RattlesnakeOS is a privacy and security focused Android OS for Google Pixel phon
 * Advanced build customization options
 
 ## Background
-RattlesnakeOS was created initially as an alternative to [CopperheadOS](https://en.wikipedia.org/wiki/CopperheadOS), a security hardened Android OS created by [Daniel Micay](https://twitter.com/DanielMicay), after it stopped being properly maintained back in June 2018. To be clear, this project is not attempting to add or recreate any of the security hardening features that were present in CopperheadOS. Instead, it is looking to fill a gap now that CopperheadOS is no longer available as there are no real alternatives that provide the same level of privacy and security.
+RattlesnakeOS was created initially as an alternative to [CopperheadOS](https://en.wikipedia.org/wiki/CopperheadOS), a security hardened Android OS created by [Daniel Micay](https://twitter.com/DanielMicay), after it stopped being properly maintained back in June 2018. To be clear, this project is not attempting to add or recreate any of the security hardening features that were present in CopperheadOS. Instead, it is looking to fill a gap now that CopperheadOS is no longer available in its previous form, as there are no real alternatives that provide the same level of privacy and security.
 
 RattlesnakeOS is truly just stock AOSP and has all of the baseline privacy and security features from there. Unlike other alternative Android OSes, it aims to keep security on par with stock Android by keeping critical security features like [verified boot](https://source.android.com/security/verifiedboot/) enabled, ensuring monthly OTA security updates not only update the OS but also the device specific drivers and firmware, and by not adding additional features or software that will needlessly increase attack surface. By not deviating from stock AOSP, updating to new major Android releases doesn't require any major porting effort and this means devices running RattlesnakeOS continue to receive proper security updates without delay.
 
@@ -39,10 +39,10 @@ Rather than providing random binaries of RattlesnakeOS to install on your phone,
 
 
 ## Prerequisites
-* An AWS account. You'll need to [create an AWS account](https://portal.aws.amazon.com/billing/signup) if you don't have one. <b>If this is a new AWS account, make sure you launch at least one paid instance before running through these steps.</b>  To do this you can navigate to the [EC2 console](https://us-west-2.console.aws.amazon.com/ec2/), click `Launch instance`, select any OS, pick a `c5.4xlarge`, and click `Review and launch`. <b>After it launches successfully you can terminate the instance through the console</b>. If you can't launch an instance of this size with your new account, you may need to request a limit increase through the web console for that instance type.
+* An AWS account. You'll need to [create an AWS account](https://portal.aws.amazon.com/billing/signup) if you don't have one. <b>If this is a new AWS account, make sure you launch at least one paid instance before running through these steps.</b>  To do this you can navigate to the [EC2 console](https://console.aws.amazon.com/ec2/), click `Launch instance`, select any OS, pick a `c5.4xlarge`, and click `Review and launch`. <b>After it launches successfully you can terminate the instance through the console</b>. If you can't launch an instance of this size with your new account, you may need to request a limit increase through the web console for that instance type.
 * In the AWS web console, you'll need to setup AWS credentials with `AdministratorAccess` access. If you're not sure how to do that, you can follow [this step by step guide](https://serverless-stack.com/chapters/create-an-iam-user.html). You'll need the generated AWS Access Key and Secret Key for the next step.
 * On your local computer, install the [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) for your platform and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) it to use the credentials from previous step. Verify that the CLI credentials are configured properly by running a command like 'aws s3 ls' and make sure no errors are returned.
-* On your local computer, using the CLI, generate an SSH key and upload the public key to all regions in AWS. By default we'll name the keypair `rattlesnakeos` in AWS. The public and private keys will be dumped to the current directory, make sure to save these to a safe place.
+* On your local computer, using the CLI, generate an SSH key and upload the public key to all regions in AWS as shown below. By default we'll name the keypair `rattlesnakeos` in AWS. The public and private SSH key will be dumped to the current directory, make sure to save these to a safe place.
 ```
 keypair_name="rattlesnakeos"
 ssh-keygen -t rsa -b 4096 -f ${keypair_name}
@@ -80,7 +80,7 @@ INFO[0005] rattlesnakeos-stack config file has been written to /Users/username/.
 ```
 
 ## Deployment
-The rattlesnakeos-stack `deploy` subcommand handles deploying (and updating) your stack. After stack deployment, you will need to manually start a build. By default it is configured to automatically build once a month on the 10th of the month so that monthly security updates can be picked up and built without the need for manual builds.
+The rattlesnakeos-stack `deploy` subcommand handles deploying (and updating) your stack. After stack deployment, you will need to manually start a build. By default it is configured to automatically build once a month on the 10th of the month so that monthly security updates can be picked up and built without the need for manual builds. <b>Anytime you make a config change, you will first need to deploy those changes using this command before starting a new build</b>.
 
 #### Default Examples
 Deploy stack using default generated config file:
@@ -206,7 +206,7 @@ Global Flags:
 
 * Use this factory image and [follow the instructions on flashing your device carefully](FLASHING.md).
 * After successfully flashing your device, you will now be running RattlesnakeOS and all future updates will happen through the built in OTA updater.
-* <b>I highly suggest backing up your generated signing keys</b>. To backup your signing keys:
+* <b>I HIGHLY suggest backing up your generated signing keys and storing them somewhere safe</b>. To backup your signing keys:
 
     ```sh 
     aws s3 sync s3://<rattlesnakeos-stackname>-keys/ .
@@ -309,15 +309,19 @@ It's also possible to add remotes and projects to the AOSP build manifest file.
 #### Can I change the boot animation?
 It is possible to change the boot animation using patches, there is an example repo [here](https://github.com/RattlesnakeOS/example_patch_shellscript).
 #### Can I add microG to the build?
-I don't recommend installing microG as it requires you to enable signature spoofing. By enabling signature spoofing, this is a global change to the OS even though it has to be requested by each application as a permission. Just having the possibility for an application to request this ability reduces security of your OS. Having said all that, if you are fine with the security implications of doing so - it is possible to install microG using the custom patches and prebuilts features.
+I don't recommend installing microG as it requires you to enable signature spoofing. By enabling signature spoofing, this is a global change to the OS even though it has to be requested by each application as a permission. Just having the possibility for an application to request this ability reduces security of your OS. Having said all that, if you are fine with the security implications of doing so - it is possible to install microG using the custom patches and prebuilts features. See the [microG community supported repo](https://github.com/RattlesnakeOS/microg) for details on how to do this.
 
 ### Security
-#### What are security best practices for builds in AWS?
-Note that cloud based builds are never going to be quite as locked down as a secure local build environment with dedicated HSMs with a high level of protection. There are still steps you can take to maximize your security within a cloud environment. RattlesnakeOS generates and stores signing keys in AWS (optionally encrypted) which means the security of your AWS account becomes critical to ensuring the security of your device. Some minimimum steps worth considering are having an account solely for building RattlesnakeOS with a strong password, enabling two factor authentication, enabling auditing with CloudTrail, and making sure you don't let anyone get a hold of your API credentials would be a good starting spot. A weak spot worth mentioning here could still be your workstation if you have your AWS credentials stored on it.
+#### How secure is this?
+Your abilty to secure your signing keys determines how secure RattlesnakeOS is. RattlesnakeOS generates and stores signing keys, optionally encrypted, in AWS, which means the security of your AWS account becomes critical to ensuring the security of your device. If you aren't able to properly secure your local workstation and your AWS account, then these additional security protections like verified boot become less useful. Using the encrypted signing keys option can reduce impact of an AWS account compromise by keeping signing keys encrypted at rest and only decrypted into memory at build time. Is this infallible? Absolutely not, as your unencrypted keys are going to be in memory on a VM running in the cloud. So if your threat model includes more targeted attacks that try to extract signing keys while they are in memory, then RattlesnakeOS is probably not for you.
+
+Cloud based builds are never going to be as secure as a locally built AOSP signed with highly secured keys generated from an HSM or air gapped computer, so if this is the level of security you require then there really is no other way. Would I recommend cloud builds like this for a large OEM or a company like CopperheadOS where the signing key being generated is protecting thousands of users? No, this becomes a high profile target as getting a hold of these keys essentially gives an attacker access to thousands of devices. On the other hand, for a single user generating their own key protecting a single device, there is less concern in my mind unless your threat profile includes very targeted attacks. 
+#### What are some security best practices for AWS accounts?
+Some minimimum steps worth considering are having an account solely for building RattlesnakeOS with a strong password, enabling two factor authentication, enabling auditing with CloudTrail, and locking down access to your AWS API credentials.
 #### What's the difference between the default option and encrypted signing keys option and what one should I use?
 There are different configurations for RattlesnakeOS builds based on your threat model. Here's a breakdown of the two primary build configurations and how they compare:
-* Using the standard RattlesnakeOS build process, your keys are autogenerated and stored in S3. This means your AWS account security become the most important part of maintaining secure signing keys. This default build option is a good fit for someone that is OK with putting some trust in AWS, wants hands off builds with no manual intervention, and doesn't want to deal with maintaining a passphrase for encrypting/decrypting signing keys. Even with this setup, this still means AWS has potential access to your signing keys. So if your threat model for example was the government, they could still request access to your AWS account and get your keys.
-* The encrypted signing keys option allows you to prevent storing signing keys in an unencrypted form within AWS. It does this by using GPG symmetric encryption to store your keys at rest. This means that even AWS or someone that got control of your account wouldn't be able to extract your signing keys assuming the passphrase used to encrypt them was strong enough to prevent a brute force attack. Using this option puts less trust in AWS and more trust in your ability to secure the passphrase used for encrypting/decrypting your signing keys. That said, during the build process the keys have to be decrypted still, so in terms of a threat model it could still be possible for someone to get access to the decrypted keys in memory during a build.
+* Using the standard RattlesnakeOS build process, your keys are autogenerated and stored in S3. This means your AWS account security become the most important part of maintaining secure signing keys. This default build option is a good fit for someone that is OK with putting some trust in AWS, wants hands off builds with no manual intervention, and doesn't want to deal with maintaining a passphrase for encrypting/decrypting signing keys. Even with this setup, this still means AWS has potential access to your signing keys. If your threat model included an attacker compromising your AWS account, then this would not suffice as they would be able to get access to your unencrypted signing keys.
+* The encrypted signing keys option allows you to prevent storing signing keys in an unencrypted form within AWS. It does this by using GPG symmetric encryption to store your keys at rest. This means that even AWS or someone that got control of your account wouldn't be able to extract your signing keys assuming the passphrase used to encrypt them was strong enough to prevent a brute force attack. Using this option puts less trust in AWS and more trust in your ability to secure the passphrase used for encrypting/decrypting your signing keys.
 #### How does the encrypted signing keys option work in practice?
 When using the encrypted signing keys option - the workflow is not fully automated like the standard build process. It requires a user to provide a passphrase to encrypt/decrypt signing keys to be used during the build process. The general workflow looks like this:
 * Stack is deployed with config option `encrypted-keys = true`.