3 ms·

"Local Data Storage. No Subscriptions, No Cloud" This is what we need more often from our software, especially from software that works with sensitive data. I

"Local Data Storage. No Subscriptions, No Cloud" This is what we need more often from our software, especially from software that works with sensitive data. I do typically want sync options though since I tend to use several different devices and it sucks not being able to reference information on the go from my phone. Sync options can include locally/self hosted options or use something like iCloud that don't depend on a software vendor's running a service though.

jxf 2y ago
> Sync options can include locally/self hosted options or use something like iCloud that don't depend on a software vendor's running a service though. Don't most sync options depend on a software vendor running a service? (Your VPS hosting company, your SaaS handling cross-device syncing, your cloud provider, et cetera.)
mr_mitm 2y ago
If I can specify the data location, I could just use syncthing or dropbox or whatever. Syncing directories is mostly a solved problem.
picardo 2y ago
> This is what we need more often from our software, especially from software that works with sensitive data. Storing sensitive data in local storage makes you vulnerable to XSS attacks and Man-in-the-Browser attacks. You're exposing your sensitive data to an attacker that injects a script to the website and to malicious browser extensions. All sensitive data stored in local storage must be encrypted using a key stored in the server or somewhere on your hard disk. Otherwise, you're not reducing your risk, but substituting one type of information disclosure vulnerability with another.
- diggan 2y ago
  > Storing sensitive data in local storage makes you vulnerable to XSS attacks and Man-in-the-Browser attacks. You're exposing your sensitive data to an attacker that injects a script to the website and to malicious browser extensions The app in question runs locally and only with trusted code. How is the attacker supposed to get in there to place the XSS or even do a MITM attack when there is no exposed website at all? Neither are there browser extensions involved here. > All sensitive data stored in local storage must be encrypted using a key stored in the server Huh? Please don't do this, especially not for "local first" applications, would defeat the entire purpose.
  - picardo 2y ago
    > only with trusted code That's a big assumption. Have you read all the code, and the dependencies of the dependencies of your code? If you haven't, how do you know it can be trusted? What if there is a backdoor in an obscure dependency that can inject a script into your website to steal your sensitive data? Don't laugh it off. When there is money on the line, someone is going to try it. > Neither are there browser extensions involved here. What about the extensions you installed in your browser? What about the user scripts (if you use them)? > Huh? Please don't do this, especially not for "local first" applications, would defeat the entire purpose. Why not? Why do you want a local first app in the first place? What's the purpose of a local first app, if not security?
    - diggan 2y ago
      I think you're misunderstanding what kind of application this is. It's not a website, it doesn't run in your normal browser. It runs as a standalone application. > Why not? Why do you want a local first app in the first place? What's the purpose of a local first app, if not security? Because as soon as those keys aren't available (either because the endpoint no longer exists, or you cannot connect to the endpoint for whatever reason (like being offline)), you can no longer access your data. That isn't "local first" at all, it's something else entirely.
      - picardo 2y ago
        > Because as soon as those keys aren't available (either because the endpoint no longer exists, or you cannot connect to the endpoint for whatever reason (like being offline)), you can no longer access your data. The encryption key doesn't have to be stored in the cloud. It just has to be stored somewhere else -- it could be in the file system. > It's not a website, it doesn't run in your normal browser. It runs as a standalone application. Even if it's a standalone application, it doesn't mean the code can be entirely trusted. I wouldn't take that risk.
        diggan 2y ago
- keyle 2y ago
  This 100%. People need to stop thinking that somehow their browser storage is a safe place to store sensitive information. It isn't and it is volatile and can get trashed by software updates and other reasons.
- amenod 2y ago
  This app is using "local storage" (storage that is local to your computer), not browser "window.localStorage".
deleted 2y ago
[deleted]
LifeUtilityApps 2y ago
I built a similar tool to what OP shared, mainly for debts instead of investments, and I completely agree with you. My app only uses iCloud to sync and it keeps all sensitive data on the user's phone. Another benefit I want to share about this approach is it means that apps built local-only will never have the risk of one day going offline and being inaccessible due to the company closing down or turning off the server.

jxf 2y ago

> Sync options can include locally/self hosted options or use something like iCloud that don't depend on a software vendor's running a service though. Don't most sync options depend on a software vendor running a service? (Your VPS hosting company, your SaaS handling cross-device syncing, your cloud provider, et cetera.)

mr_mitm 2y ago

If I can specify the data location, I could just use syncthing or dropbox or whatever. Syncing directories is mostly a solved problem.

picardo 2y ago

> This is what we need more often from our software, especially from software that works with sensitive data. Storing sensitive data in local storage makes you vulnerable to XSS attacks and Man-in-the-Browser attacks. You're exposing your sensitive data to an attacker that injects a script to the website and to malicious browser extensions. All sensitive data stored in local storage must be encrypted using a key stored in the server or somewhere on your hard disk. Otherwise, you're not reducing your risk, but substituting one type of information disclosure vulnerability with another.

diggan 2y ago
> Storing sensitive data in local storage makes you vulnerable to XSS attacks and Man-in-the-Browser attacks. You're exposing your sensitive data to an attacker that injects a script to the website and to malicious browser extensions The app in question runs locally and only with trusted code. How is the attacker supposed to get in there to place the XSS or even do a MITM attack when there is no exposed website at all? Neither are there browser extensions involved here. > All sensitive data stored in local storage must be encrypted using a key stored in the server Huh? Please don't do this, especially not for "local first" applications, would defeat the entire purpose.
- picardo 2y ago
  > only with trusted code That's a big assumption. Have you read all the code, and the dependencies of the dependencies of your code? If you haven't, how do you know it can be trusted? What if there is a backdoor in an obscure dependency that can inject a script into your website to steal your sensitive data? Don't laugh it off. When there is money on the line, someone is going to try it. > Neither are there browser extensions involved here. What about the extensions you installed in your browser? What about the user scripts (if you use them)? > Huh? Please don't do this, especially not for "local first" applications, would defeat the entire purpose. Why not? Why do you want a local first app in the first place? What's the purpose of a local first app, if not security?
  - diggan 2y ago
    I think you're misunderstanding what kind of application this is. It's not a website, it doesn't run in your normal browser. It runs as a standalone application. > Why not? Why do you want a local first app in the first place? What's the purpose of a local first app, if not security? Because as soon as those keys aren't available (either because the endpoint no longer exists, or you cannot connect to the endpoint for whatever reason (like being offline)), you can no longer access your data. That isn't "local first" at all, it's something else entirely.
    - picardo 2y ago
      > Because as soon as those keys aren't available (either because the endpoint no longer exists, or you cannot connect to the endpoint for whatever reason (like being offline)), you can no longer access your data. The encryption key doesn't have to be stored in the cloud. It just has to be stored somewhere else -- it could be in the file system. > It's not a website, it doesn't run in your normal browser. It runs as a standalone application. Even if it's a standalone application, it doesn't mean the code can be entirely trusted. I wouldn't take that risk.
      - diggan 2y ago
keyle 2y ago
This 100%. People need to stop thinking that somehow their browser storage is a safe place to store sensitive information. It isn't and it is volatile and can get trashed by software updates and other reasons.
amenod 2y ago
This app is using "local storage" (storage that is local to your computer), not browser "window.localStorage".

deleted 2y ago

[deleted]

LifeUtilityApps 2y ago

I built a similar tool to what OP shared, mainly for debts instead of investments, and I completely agree with you. My app only uses iCloud to sync and it keeps all sensitive data on the user's phone. Another benefit I want to share about this approach is it means that apps built local-only will never have the risk of one day going offline and being inaccessible due to the company closing down or turning off the server.