2 ms·

> Ultimately, people should have control of their data, and they should have access to their data from all of their devices. Whether that is running their own o

> Ultimately, people should have control of their data, and they should have access to their data from all of their devices. Whether that is running their own or renting someone else's, that ultimately means the correct place to store web app data is on a server. Hrm. But I don't have control of my data on a server. The person running the server does. There is currently no good way to satisfy both of these conditions on the web: control of my data, and access from all my devices.

ocdtrekkie 5y ago
I specifically refer to self-hosting here, which does satisfy both of those conditions. (There is arguably still a lot of stress to making self-hosting a better experience for non-technical users, and unfortunately large tech companies are very motivated to maintain a paradigm opposed to self-hosting.) But I also do not feel LocalStorage is really a good way to ensure you have control of your data: It's very unlikely you (or most anyone else) are auditing the code of a site to ensure it maintains your data locally, much less ensure that doesn't change over time.
- cxr 5y ago
  > But I also do not feel LocalStorage is really a good way to ensure you have control of your data: It's very unlikely you (or most anyone else) are auditing the code of a site to ensure it maintains your data locally, much less ensure that doesn't change over time. There's nothing in this critique that doesn't also apply to hosted (server-based) storage. If anything, it's harder to do those things with servers, because (a) if you the user are truly paranoid, it's trivial to throw a switch and make sure that no data is getting out—by shutting off your network connection entirely, whereas with server-based storage for user data the user has to do some form of whitelisting or blacklisting, and (b) it's pretty straightforward to get all your data at any given time, esp. since the localStorage API is well-defined, whereas if the application author had started with a server-based approach, it probably would have been a server under their control and not yours, which means your best shot involves either intercepting all communications from the beginning (instead of after the fact, once you realize you're interested in it) or doing the legwork to figure out the protocol and issue the appropriate request(s) to get all of it (rather than just a view), if that's even possible. Overall, I don't think this post makes a very forceful argument that localStorage is bad, only that there might be a better experience for users if all the following conditions hold true: 1. they're playing across multiple devices 2. they're willing to take the time to connect to remote storage 3. the developer behind the app is sympathetic to the cause of data portability and/or user-controlled data, and is therefore willing to implement the necessary integration to enable #2 Failing that, a world where developers are defaulting to localStorage is still a much better state of affairs than what's typical of application authors today.

ocdtrekkie 5y ago

I specifically refer to self-hosting here, which does satisfy both of those conditions. (There is arguably still a lot of stress to making self-hosting a better experience for non-technical users, and unfortunately large tech companies are very motivated to maintain a paradigm opposed to self-hosting.) But I also do not feel LocalStorage is really a good way to ensure you have control of your data: It's very unlikely you (or most anyone else) are auditing the code of a site to ensure it maintains your data locally, much less ensure that doesn't change over time.

cxr 5y ago
> But I also do not feel LocalStorage is really a good way to ensure you have control of your data: It's very unlikely you (or most anyone else) are auditing the code of a site to ensure it maintains your data locally, much less ensure that doesn't change over time. There's nothing in this critique that doesn't also apply to hosted (server-based) storage. If anything, it's harder to do those things with servers, because (a) if you the user are truly paranoid, it's trivial to throw a switch and make sure that no data is getting out—by shutting off your network connection entirely, whereas with server-based storage for user data the user has to do some form of whitelisting or blacklisting, and (b) it's pretty straightforward to get all your data at any given time, esp. since the localStorage API is well-defined, whereas if the application author had started with a server-based approach, it probably would have been a server under their control and not yours, which means your best shot involves either intercepting all communications from the beginning (instead of after the fact, once you realize you're interested in it) or doing the legwork to figure out the protocol and issue the appropriate request(s) to get all of it (rather than just a view), if that's even possible. Overall, I don't think this post makes a very forceful argument that localStorage is bad, only that there might be a better experience for users if all the following conditions hold true: 1. they're playing across multiple devices 2. they're willing to take the time to connect to remote storage 3. the developer behind the app is sympathetic to the cause of data portability and/or user-controlled data, and is therefore willing to implement the necessary integration to enable #2 Failing that, a world where developers are defaulting to localStorage is still a much better state of affairs than what's typical of application authors today.