Unfortunately, this issue isn't really a bug, so I can't use the template. This is more of a general concern.
The recommendation in README.md at this section suggests that using Secure LS makes the saved data anymore secure than what it already was.
Secure LS is completely client-side, with no unique way of differentiating different devices from each other, meaning that they are all encrypted the same way. Even if you supply a random key to every device, that key would need to be stored on a server, and would have to be linked with some other data (in which you'd probably just be better off to use an authentication method), but that's overcomplicated for learning developers to understand. This just provides new developers a false sense of security when 'encrypting' the data, when they are in the end really just obfuscating it. The way I see it, is that some junior developer with not much understanding in security will see this as an opportunity to use private API keys or some plain text password on the client side, when they hope that it will be easier than setting up a server. The TL;DR is that the way that this repo's README and the README of Secure LSisn't wrong, it's just very misleading.
The bottom line is, this repo is really popular, and it's doing very well, but a responsibility comes with that, especially when the topic of Vue is attractive to many inexperienced developers. While the library technically does encrypt the data, it's not doing it in a secure manner on it's own, and it's misleading to say that:.
protect the content of the data
as it's not protecting anything, just obfuscating it. My suggestion is to change the words "encrypted" to "obfuscated", and to have a warning that the library does not "protect anything on it's own, but rather can be used in the process of securely saving the Vuex store".
Unfortunately, this issue isn't really a bug, so I can't use the template. This is more of a general concern.
The recommendation in README.md at this section suggests that using Secure LS makes the saved data anymore secure than what it already was.
Secure LS is completely client-side, with no unique way of differentiating different devices from each other, meaning that they are all encrypted the same way. Even if you supply a random key to every device, that key would need to be stored on a server, and would have to be linked with some other data (in which you'd probably just be better off to use an authentication method), but that's overcomplicated for learning developers to understand. This just provides new developers a false sense of security when 'encrypting' the data, when they are in the end really just obfuscating it. The way I see it, is that some junior developer with not much understanding in security will see this as an opportunity to use private API keys or some plain text password on the client side, when they hope that it will be easier than setting up a server. The TL;DR is that the way that this repo's README and the README of Secure LS isn't wrong, it's just very misleading.
The bottom line is, this repo is really popular, and it's doing very well, but a responsibility comes with that, especially when the topic of Vue is attractive to many inexperienced developers. While the library technically does encrypt the data, it's not doing it in a secure manner on it's own, and it's misleading to say that:.
as it's not protecting anything, just obfuscating it. My suggestion is to change the words "encrypted" to "obfuscated", and to have a warning that the library does not "protect anything on it's own, but rather can be used in the process of securely saving the Vuex store".