diff --git a/src/profile_encryption_and_storage.md b/src/profile_encryption_and_storage.md
index 5914b28..f92929a 100644
--- a/src/profile_encryption_and_storage.md
+++ b/src/profile_encryption_and_storage.md
@@ -1,6 +1,6 @@
 # Profile Encryption & Storage
 
-Profiles are stored on locally on disk and encrypted using a key derived from user-known password (via pbkdf2).
+Profiles are stored locally on disk and encrypted using a key derived from user-known password (via pbkdf2).
 
 Note that once encrypted and stored on disk, the only way to recover a profile is by rederiving the password - as such
 it isn't possible to provide a full list of profiles a user might have access to until they enter a password.
@@ -10,6 +10,8 @@ it isn't possible to provide a full list of profiles a user might have access to
 To handle profiles that are "unencrypted" (i.e don't require a password to open) we currently create a profile
 with a [defacto, hardcoded password](https://git.openprivacy.ca/cwtch.im/libcwtch-go/src/branch/trunk/constants/globals.go#L5).
 
+<!-- Can cwtch be updated to randomly generate a password and store it on the devices keychain/keystore (for devices/OS with a keychain API)? Also I'm not sure how secure OS level keychains are but hard coded passwords always become campfire stories years later. -->
+
 This isn't ideal, we would much rather wish to rely on OS-provided key material such that the profile is bound to a 
 specific device, but such features are currently patchwork - we also note by creating an unencrypted profile, people
 who use Cwtch are explicitly opting into the risk that someone with access to the file system may be able to decrypt