more content updates

_layouts/about.html

@@ -17,12 +17,12 @@
                     to problems of managing systems in a way where no single individual can compromise them.</p>
 
                 <p>This methodical approach to building systems which are resilient to single points of failure was appealing to
-                    blockchain companies, so they started to work closely with companies which managed large sums of digital
+                    fintech companies, so they started to work closely with companies which managed large amounts of
                     assets and wanted to be sure that they are taking a first principles approach to building their security
-                    posture.</p>
+                    systems.</p>
 
-                <p>From these interactions with many large protocols, blockchain labs, funds and other clients managing large
-                    amounts of funds - they learned how to build systems which are resilient to the most adversarial threat
+                <p>From these interactions with many financial institutions, and other clients managing highly sensitive data or
+                    large amounts of funds - they learned how to build systems which are resilient to the most adversarial threat
                     landscapes.</p>
 
                 <p><b>Distrust Disaster Recovery</b> is the result of years of collaboration and implementing real world systems

_layouts/landing.html

@@ -80,6 +80,12 @@
 						of failure on all levels.
 					</p>
 
+					<h3>Transparency</h3>
+					<p>Every part of the Distrust Disaster Recovery system is
+						fully open source and has been audited by leading security
+						firms. We encourage you to review our technology for yourself.
+					</p>
+
 					<h3>Reproducible Builds</h3>
 					<p>
 						Being able to ensure that all of the software that's
@@ -122,6 +128,7 @@
 						to carry out actions is a core control mechanism for
 						Distrust Disaster Recovery.
 					</p>
+
 				</div>
 			</section>
 

recovery_policy.md

@@ -24,7 +24,7 @@ valid recovery request.
 
 The main conditions of a Recovery Policy are:
 * Time lock until year/month/day
-* n of m cryptographic signatures (PGP)
+* n of m cryptographic signatures (FIDO2, PGP)
 * n of m KYC verifications
 
 At least one of cryptographic signature or kyc verification is always required.
@@ -40,9 +40,9 @@ possible. The data will not be recoverable until the day after the lock date.
 
 ## Cryptographic Signature Verification
 
-This method supports PGP cryptographic signatures. One may register as many as
-32 public keys, and set how many of those keys are required for a valid recovery
-request, for example, 3 of 7.
+This method supports several cryptographic signature schemes including PGP and
+FIDO2. One may register as many as 32 public keys, and set how many of those
+keys are required for a valid recovery request, for example, 3 of 7.
 <!-- TODO: add BTC and ETH when it's supported -->
 
 ## KYC Verification
@@ -61,3 +61,25 @@ signed by Distrust.
 individuals, and require any number of individuals to express intent to recover.
 For example, the total number of individuals may be 7, and 3 of them are
 required to initialize the recovery process.
+
+## When and How The Policy Can Be Changed
+
+A policy can only be updated by providing the authentication required to recover
+the data.
+
+A policy can be defined to be valid:
+
+* After a specific date
+* Between specific dates
+* Before a specific date
+
+Additionally, the policy can be made updateable, or non-updateable.
+
+There is also a cooldown period, which requires a specific amount of time to
+elapse before the policy is updated upon request.
+
+For example, one may choose to create a policy that's only in effect after a
+specific date, and can be updated, creating a lock on the data and the ability
+to update until after that date. Conversely, a policy can be created which is
+only valid up to a specific date and can not be updated, effectively expiring
+after that date, making the data non-recoverable.