Suggestion: SecureSettings interface + default implementation

[SamuelMarks]

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 existing KeychainSettings, implement EncryptedSharedPreferences 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.

[russhwolf]

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.

[SamuelMarks]

Related: https://security.stackexchange.com/q/279371

(for Windows, macOS and Linux support)

[russhwolf]

The discussion in that link doesn't appear to be going anywhere productive. The only piece of this that I really see as actionable is adding secure implementations for more platforms. Thus I'm going to close in favor of #186. Feel free to follow up there if you have implementation suggestions