Status Update
Comments
an...@gmail.com <an...@gmail.com> #2
there are some image for help
sc...@gmail.com <sc...@gmail.com> #3
hello?
an...@gmail.com <an...@gmail.com> #4
8 months later, this issue has more stars (currently 45) than all other issues for this component, combined. It is currently also the highest priority issue (P2) for component 907884. Would it be possible to get an update here so that developers can better understand the roadmap?
Specifically, the docs state:
If you're currently using SharedPreferences to store data, consider migrating to DataStore instead.
As a developer, I'd like to understand how the DataStore library compares to EncryptedSharedPreferences and which should be the preferred choice, going forward. Using typed objects for key-value storage is nice. Having data encrypted at rest, is ideal--and in my particular case, required by the Security Team. Can we expect DataStore to do both? If so, it would be VERY useful. If not, many developers will have to choose EncryptedSharedPreferences, instead.
ol...@gmail.com <ol...@gmail.com> #5
I find following article be helpful. It might also be interesting to someone who is happy to have a custom implementation already now and do not wait until it's officially provided:
ro...@google.com <ro...@google.com>
ha...@gmail.com <ha...@gmail.com> #6
dj...@hotmail.com <dj...@hotmail.com> #7
jm...@google.com <jm...@google.com>
sz...@gmail.com <sz...@gmail.com> #8
al...@gmail.com <al...@gmail.com> #9
av...@gmail.com <av...@gmail.com> #10
ne...@gmail.com <ne...@gmail.com> #11
ye...@gmail.com <ye...@gmail.com> #12
I agree strongly with
Please consider this feature and share the plan if you decide to add it.
sk...@gmail.com <sk...@gmail.com> #13
+1 for this issue!
le...@gmail.com <le...@gmail.com> #14
So disappointed and dissatisfied about the lack of SecureDataStore for such a long period of time
+1 for this issue
wi...@azimo.com <wi...@azimo.com> #15
le...@gethomesafe.com <le...@gethomesafe.com> #16
If only EncryptedFile
was a subclass of File or DataStoreFactory::create
had an overload with a produceEncryptedFile
parameter... Looking forward to a solution for this. Thanks!
ni...@gmail.com <ni...@gmail.com> #17
I wrote a quick wrapper that uses EncryptedFile as the storage for data store. Code is based on the FileStorage from the library itself
Example usage:
@Provides
@Singleton
fun providePreferencesStorage(@ApplicationContext context: Context): Storage<Preferences> {
return EncryptedFileStorage(context, FilePreferencesSerializer()) {
File(context.filesDir, "preferences.pb")
}
}
ni...@gmail.com <ni...@gmail.com> #18
Disregard my comment above, this does not work yet, still debugging
ni...@gmail.com <ni...@gmail.com> #19
Gist has been updated, seems to work perfectly
os...@gmail.com <os...@gmail.com> #20
You beat me by a moment :)
I've just released the new version of my tiny library adding datastore creation with EncryptedFile
- DataStoreFactory.createEncrypted
and PreferenceDataStoreFactory.createEncrypted
.
Usage:
val dataStore = DataStoreFactory.createEncrypted(serializer) {
EncryptedFile.Builder(
context.dataStoreFile("filename"),
context,
MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC),
EncryptedFile.FileEncryptionScheme.AES256_GCM_HKDF_4KB
).build()
}
Or even simpler, if you use security-crypto-ktx:1.1.0
:
val dataStore = DataStoreFactory.createEncrypted(serializer) {
EncryptedFile(
context = context,
file = context.dataStoreFile("filename"),
masterKey = MasterKey(context)
)
}
It works with datastore 1.0.0
, but I've not tested it with 1.1.0
uj...@gmail.com <uj...@gmail.com> #21
pa...@gmail.com <pa...@gmail.com> #22
re...@gmail.com <re...@gmail.com> #23
se...@c24.de <se...@c24.de> #24
fr...@google.com <fr...@google.com> #25
Thanks to @os...@gmail.com for creating his extensions to use while we wait for this feature to be implemented. Otherwise I'd have to use encryptedsharedpreferences.
pi...@gmail.com <pi...@gmail.com> #26
ma...@gmail.com <ma...@gmail.com> #27
Is there any official progress on Google? When migrating a new project, I was struggling with why EncryptedSharedPreferences and Datastore cannot be combined. The datastore needs to implement its own encryption and serialization, which has forced me to temporarily give up using the datastore. I have found the implementation of the building owner, but I am worried that it may consume too much performance.
da...@iamviva.com <da...@iamviva.com> #28
+1, please!
For now, I will keep using EncryptedSharedPreferences
because it supports encryption and, during my tests, it seems more reliable, but I would like to use DataStore
and take advantage of thread and type safety.
ib...@gmail.com <ib...@gmail.com> #29
sj...@gmail.com <sj...@gmail.com> #30
An official support of DataStore
with encryption would be greatly appreciated :)
an...@gmail.com <an...@gmail.com> #31
lu...@gmail.com <lu...@gmail.com> #32
This would certainly encourage switching from the EncrypredSharedPreferences
b....@autodoc.eu <b....@autodoc.eu> #33
gt...@gmail.com <gt...@gmail.com> #34
gu...@gmail.com <gu...@gmail.com> #35
se...@gmail.com <se...@gmail.com> #36
+1
ha...@gmail.com <ha...@gmail.com> #37
da...@gmail.com <da...@gmail.com> #38
se...@asos.com <se...@asos.com> #39
gi...@gmail.com <gi...@gmail.com> #41
ch...@gmail.com <ch...@gmail.com> #42
ni...@gmail.com <ni...@gmail.com> #43
ha...@mail.ru <ha...@mail.ru> #44
mu...@gmail.com <mu...@gmail.com> #45
da...@willowtreeapps.com <da...@willowtreeapps.com> #46
sj...@gmail.com <sj...@gmail.com> #47
Now that androidx.security:security-crypto
– which provides EncryptedSharedPreferences
– was Storage
interface that
in...@gmail.com <in...@gmail.com> #48
al...@gmail.com <al...@gmail.com> #49
633 stars, and no response from Google. Status is still at New, no one cares
ma...@gmail.com <ma...@gmail.com> #50
aj...@gmail.com <aj...@gmail.com> #51
mo...@devoteam.com <mo...@devoteam.com> #52
rv...@gmail.com <rv...@gmail.com> #53
ko...@gmail.com <ko...@gmail.com> #54
to...@gmail.com <to...@gmail.com> #55
ma...@gmail.com <ma...@gmail.com> #56
mi...@wandera.com <mi...@wandera.com> #57
+1
ya...@gmail.com <ya...@gmail.com> #58
+1
jv...@adversus.io <jv...@adversus.io> #59
ni...@vishleshan.net <ni...@vishleshan.net> #60
+1
nu...@gmail.com <nu...@gmail.com> #61
ti...@gmail.com <ti...@gmail.com> #62
vo...@paykey.com <vo...@paykey.com> #63
ze...@gmail.com <ze...@gmail.com> #64
th...@c0x12c.com <th...@c0x12c.com> #65
r....@gmail.com <r....@gmail.com> #66
pi...@gmail.com <pi...@gmail.com> #67
ti...@gmail.com <ti...@gmail.com> #68
wh...@gmail.com <wh...@gmail.com> #69
as...@gmail.com <as...@gmail.com> #70
er...@gmail.com <er...@gmail.com> #71
da...@mohemian.com <da...@mohemian.com> #72
Native encryption support in DataStore would be a big step to meet modern app security requirements and simplify adoption.
mu...@gmail.com <mu...@gmail.com> #73
ed...@asos.com <ed...@asos.com> #74
I am the author of the blog post that was kindly linked in
Like ShredPreferences, data saved within DataStore is stored on the device within the app’s own sandboxed folder structure which is not accessible by default. Additionally, all devices encrypt user data on the filesystem by default as Android version 10 I believe - so what value would further encrypting your DataStore's values really add? If you are storing data that is 'sensitive' locally on the device, then perhaps you have bigger problems to worry about :-P
While I of course do not claim to represent anyone from Google, I believe this is likely also the same view taken by the JetSec team. Hence the deprecation of EncryptedSharedPreferences and the lack of a DataStore equivalent.
The TL;DR is: I'd say Android is likely plenty secure enough for almost every use-case to not need this feature and, as developers, its far better to just follow general security best practices (i.e. DO NOT store personal data on-device)
se...@zonesoft.org <se...@zonesoft.org> #75
al...@gmail.com <al...@gmail.com> #76
Happy new year! 735 stars and counting, and still no response from Google
Description