Open SamuelMarks opened 5 days ago
I don't see much value in adding an extra interface since the API would be the same between Settings
and SecureSettings
. Doing a default implementation as you describe is difficult, because any time you change the underlying implementation you break backward-compatibility since previously saved data is no longer available. I could add a module like multiplatform-settings-no-arg
that just has Android and Apple targets, but I'm not convinced the value is there since it's not that difficult to do yourself.
Related: https://security.stackexchange.com/q/279371
(for Windows, macOS and Linux support)
Your project looks great. I'm thinking about using it to store access tokens as I target iOS, Android, web, and Desktop.
Using
expect
/actual
I should be use your existingKeychainSettings
, implementEncryptedSharedPreferences
https://developer.android.com/reference/androidx/security/crypto/EncryptedSharedPreferences, and fallback to unencrypted (or trivially encrypted, e.g., shared code to unlock it [insecurely] embedded in app).Have you considered having a default
SecureSettings
interface with a default implementation? - Over time I imagine commits overriding the implementing for each target platform until there's a secure option implemented for each multiplatform-settings supported platform.