Yes, that was a joke.
In reality, uFincs is more of a stop-gap between what you seek (native app where you own the data) and what the status quo is (web-based app where your data ownage is dubious). Yes, uFincs is a web app, but we take the extra step to do client-side encryption so that the only financial data being stored in our database is a jumble of base64; I don't want to touch your actual financial data with a 10-foot pole.
Of course, like some other people in this thread have mentioned, having a completely client-side app is also pretty important. Well, we have exactly that: https://ufincs.com/noaccount. You can use uFincs right away, without any account, and the app works completely client-side, completely offline. You can even export your data and then re-import it later if you so prefer!
Of course, the tech that enables this 'no account' option is also what makes the logged-in app work offline-first, so I think it's pretty cool :)
And if anyone asks "Well, why a web app at all then?", it's because I wanted a web app. Yes, I do enjoy accessing my finances on all my devices, thank you very much. But we do have plans to build out standalone desktop/mobile apps in the future.
I get the incentive, but considering how financial planning can be most vital to folks with spotty income, I'd strongly encourage you to bring the price of the monthly plan down. Or perhaps a bare-bones "free" tier folks can use between paid months?
But yeah, there's definitely some pricing psychology at play there. Thanks for taking the time to leave some feedback!
But yeah, in terms of more standalone distribution and sandboxing, that's where the future desktop/mobile apps would be more appropriate. Of course, they'd be Electron-esque, but that would at least fulfill my end-goals of being privacy-first, offline-first, and providing 'long-term' software.
Having an "encrypted" copy of the data, with a key controlled by you (unless there's some browser API for encrypting using the user's key?) is a lot shorter than a "ten foot pole"
As for storage, all data is kept in-browser in local storage (specifically, IndexedDB), until it gets saved to our database. And before it leaves the browser to be saved in our database, it gets encrypted using the user's key.
Finally, if you only ever use the 'no account' option (https://ufincs.com/noaccount), then all your data is only ever stored in-browser; it never gets saved to our database because you don't even have an account to save it to! Feel free to monitor the network requests to prove it for yourself (or even turn off your network connection).
Hopefully that makes things more clear.
Not quite. See, we make use of a scheme called envelope encryption. That means we have two separate keys: one to encrypt your data (the 'data encryption key' or DEK) and one to encrypt the DEK (the 'key encryption key' or KEK). We use the KEK to encrypt your DEK to get something called the 'EDEK' (or 'encrypted data encryption key'). The EDEK is what we store in our database.
Something that never changes after you sign up is your DEK. This is completely random and not dependent on your password.
What is dependent on your password is your KEK. So when you change your password, all that actually changes is your KEK. With your new KEK, we just re-encrypt your DEK to get a new EDEK, and we store that new EDEK in our database. Again, the Security doc (https://ufincs.com/policies/security) outlines the basic process.
So no, all your data isn't passed back to the browser to be decrypted and re-encrypted when you change your password, but thanks for the question!
⇒ when users change their password, you have access to the DEK (you decrypt it and then encrypt it with the new KEK)
“one to encrypt your data (the 'data encryption key' or DEK)”
⇒ when users change their password, you could decrypt their data.
I think this boils down to “you don’t store user passwords, but when users change their password, they must trust you to not look at your data or store the KEK”.
Where’s my error?
'We' have 'access' to your DEK at all times — if you define 'we' as the 'client-facing portion of the app'. All of the encryption/decryption, key management, etc happens on the client-side (i.e. in-browser). Remember, as part of signing in to the app, the EDEK is transmitted from our servers and decrypted client-side so that the client can then use that DEK to decrypt your data.
If we instead redefine 'we' to be the backend servers, database, or even myself personally, then 'we' never have access to your keys nor data.
The fact is, there's nothing special about the password change process itself. It's essentially the same as the sign-up process. Nothing is especially exposed during the password change process that isn't exposed during the sign-up process (again, the DEK is present on the client-side the moment you sign up or sign in, although the KEK is slightly more ephemeral than that).
However, I do understand the implication you're making here, and here's the darker side of it: 'we' (uFincs) could change the client-facing portion of the app to steal your DEK (or your password, or even your data) and send it off elsewhere. This is... just true of any piece of software. It just so happens that, since web apps can be arbitrarily updated, it's a lot easier for us to act maliciously if we so chose (although, at least with web apps, inspecting network requests is quite easy).
So indeed, there is an element of trust here. You trust that I (or the entity known as 'uFincs') won't change the code in such a way that the security of the app is compromised. You also have to trust that we have such security measures in place that make it harder for some third-party malicious actor to forcefully change the operation of the app.
uFincs is not a trust-less system. Unfortunately, due to the nature of web apps (or even most apps for that matter), it simply cannot be. Anytime the code can be updated (and can't be audited), there is effectively zero security (for those who are particularly security-conscious). So if your (the general 'your') financial data is so sensitive that any chance of a leak would be utterly catastrophic, then don't even think of using uFincs.
But I like to think that putting these measures in place (particularly, using client-side encryption, not connecting to banks, not using any in-app analytics beyond our own, etc) is at least a step better — in terms of security and privacy — than what most other services do. And I like to think that, even if it's not perfect, it was still worth doing. Otherwise, I wouldn't have 'wasted' 2+ years of my life building uFincs :)
I think a few pictures showing how passwords and data flow between the user’s browser and the backend when you do various things would make your technical description easier to understand.
Lacking that, using phrases such as “our code, running in your browser” rather than that ambiguous “we”, would have made things clearer for me, too.
In particular (but again, no promises), I want to start by open-sourcing the custom Redux middleware that we use to handle data encryption. I feel like that's one of the most important parts to open-source (ya know, since it's the foundation of uFincs' security), but it's a matter of getting everything in order.
Just curious, what's your tech stack, how long have you been working on it, and how many users do you have?
The simple tech stack breakdown is that the client-side is React + Redux + TypeScript + Sass. Of note, I use redux-saga, which has been an absolute boon for some of the more complex flows.
Design system is completely custom.
Backend API is Node + Feathers. Database is Postgres.
Marketing site is served separately from the app and is React + NextJS + Tailwind CSS.
I intend to write up a more complete breakdown of the tech stack sometime in the future.
In terms of how long it's taken to get this far, longer than I'd like to admit... there was a version '0.1' that was built as a capstone project over the course of 2019, then the redesigned version (uFincs as it exists now) that's been ongoing since the start of 2020.
And the user situation can look... misleading. I only 'officially' launched last week, so for the longest time the only user has been le-moi (and some friends that did testing), but I actually did just acquire my first paying customer yesterday!
Congratz!
Very few people I know understand and appreciate double entry bookkeeping for finances. I learned about it recently from beancount [1] and it was a revelation. I don't go overboard with detailed transactions and keep it high level with around 5 accounts salary/mortgage/cc/investments etc.
I now personally keep my raw data (monthly income/expense/balances) in a spreadsheet. I have 1 html file with js embedded that does my homegrown calculations (works great on a phone). Spreadsheet is updated monthly. I add data from my monthly bank statements (same day I pay my credit card bills so I don't forget). Run the calculations whenever I need to (so far has been very rare).
My takeaway: discipline around personal finances is more important than what tool, services or process I use.
Looking at my income/expense/balances and mapping to what happened last month, looking at trends is valuable. For me that comes from piggybacking on the critical routine/ritual of paying my bills.
1: https://beancount.github.io/docs/the_double_entry_counting_m...
Now I use hledger, which has been fantastic. I back up the file to a shared drive that's sync'ed to my phone, so every time I get a message from the bank or pay with cash, I can immediately note it down (this would have been much less workable before I found the "cone" app) and track my spending across dozens of accounts.
There are some improvements that could be made as to the visualization of data, which I might write a quick webapp for, but in terms of simplicity, robustness, and ease of use, plaintext is definitely the way to go.
> If the Company is involved in an asset sale, Your Personal Data may be transferred.
The Personal Data is the asset. This is like saying: If we want to sell your financial data, we will do so.
> We may share Your personal information in the following situations:
> With business partners: We may share Your information with Our business partners to offer You certain products, services or promotions.
Rather than ameliorate concerns about privacy, this intensifies them. This is the approach I would expect from a megacorporation hellbent on mining my private data to death while pointing to the by-sheer-coincidence-hidden option to opt out of telemetry. And the choice to pay for the ability to not be data-mined to death.
These are the design choices I expect from a product team that regards privacy as something to be defeated and evaded. It's the sort of thing I would expect from Facebook.
Perhaps a privacy-centered approach might be worth considering? What might the user experience look like if behavior was not tracked until the user explicitly consented to just specifically that? What if the ability to upload your data was a premium option, with the local-only privacy-preserving experience the default? What data do you need to let people do incredibly personal calculations, as opposed to what data do you want?
1. User arrives on the site, no google analytics activated unless user accepts cookie settings (which includes option to accept some types and not others).
2. User onboards and creates a plan for free, experiments with app -- no plan data or results are transmitted. Everything done client-side in JavaScript and goes away on page refresh.
3. User decides to upgrade to premium. If they do, the app asks if they would like to enable persistent data. If they enable this feature, only then is plan data saved.
It sounds like you've put genuine thought into this, and your privacy policy is very readable, but it suffers from the generic "WTFPL" clauses.
For example, you clearly specify who the third-parties are and what data is shared, which again is commendable. But it's combined with "we may use your data for [any] other purposes", "we may sell and may have sold [extremely personal PII]", and so on.
Are you doing this? Doesn't seem like it. Could you? Apparently, and that's part of the concern.
Do you keep database backups?
You might want to reconsider the name -- it looks way too similar to Google's Project Fi. Or at least the logo, which looks like cell phone reception bars, which even further reminds me of Project Fi.
But yes, this should really be an client-side / offline app.
Maybe another analogy would be like if you had to give your full banking information to every restaurant your family dines at?
Cough syrup not being evil -used as intended to alleviate symptoms but not cure OR chugged like a panacea ambrosia delivered by the gods- is such a weird analogy to write as the burden of use falls on the individual rather than the collector.
How dare people prescribed highly addictive advertised as nonaddictive cocaine start taking it spoonful up the butthole~
imo this is the single correct perspective to have about data
- Offer a service.
- Claim that your service exists to make the world better in some vague way.
- Train yourself to sound like a compassionate, altruistic person that cares about others.
- Sell user data. Hide the information about what data is being sold and who is buying it and why as much as possible.
- Become wealthy selling data from users who trusted you.
- Buy bona-fide companies and put them to the service of your evil cause.
- Normalize evil behavior. Force other companies to become evil in order to compete.
- Turn the Internet into a privacy nightmare.
- Turn the field of computer science into satanism.
Everytime I see a tool that shouldn't need to be hosted remotely as a service and could reasonably be deployed to the client where they have more control over their data (not as a service), it's a non-starter for me. I get it, that's the industry model now and it's how you can get comped for your time investment, gain passive income, control IP, etc.
Unfortunately, those cost models will get no comp from me in any way. Having more data rights and ownership for a week or so free trial version where you can later shift to a pay model in which your data is still owned entirely by you during the entire course of the application usage would make more sense for people like me who still want privacy. I'm probably not the target market for something like this though and the number of people like me seem to be on the decline, so there's that.