[devinsit]

I agree. The trend of handing over all your data (especially your financial data) to some nebulous service isn't exactly my favourite. Which is why I built https://ufincs.com, a nebulous service where you hand over all your financial data!

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.

[false-mirror]

That is a huge "living paycheck to paycheck" upcharge!

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?

[devinsit]

Yep, I agree, it's a pretty big upcharge. That's precisely why our 'free tier' is the 'no account' option (https://ufincs.com/noaccount). I'm not kidding when I say it's the full version of uFincs; the only (real) difference is that you don't have an account to sync to. And if you make sure to never log out (or take the time to export/import your data every time), then you can basically simulate having an account. It's just a free tier of 'inconvenience' rather than 'features' or some such.

But yeah, there's definitely some pricing psychology at play there. Thanks for taking the time to leave some feedback!

[caycep]

I wonder if the "most private" way to do this would be to distribute as a jupyter notebook or some sort of local bundle/distro to run as a local webapp?

[devinsit]

Well, uFincs is a PWA, so you could 'install' it that way. We send a little in-app notification whenever a new update is pushed, so you could theoretically just ignore those and never update to keep using that one version of uFincs forever (assuming your browser never decides to update it otherwise).

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.

[TheGeminon]

I feel like this is a great use-case for WASM, being able to push down fully features apps that can run locally.

[gowld]

You could store the data in the user's cloud (or local) storage, so you don't have a copy of the data.

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"

[devinsit]

That's the thing, the key isn't controlled by me. The key is derived from your account password. If you want some more technical details, feel free to check out https://ufincs.com/policies/security. tl;dr Yes, that browser API is called WebCrypto.

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.

[Someone]

So, when you change your password, all data flows back to your browser to be decrypted, then gets re-encrypted, and sent back?

[devinsit]

Hmm, that's a good question to add to the Security doc!

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!

[Someone]

“With your new KEK, we just re-encrypt your DEK”

⇒ 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?

[devinsit]

The 'error', as you put it, is that the password change process (i.e. the changing of the KEK and the re-encryption of the DEK into the EDEK) all happens client-side (except for the part where we verify your old password against the hashed version in the database, for obvious reasons).

'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 :)

[Dennip]

This looks like exactly something i've been after! I used to use an iOS app but really missed becuase able to access it on windows....but the pricing just seems way too high. Its more expensive than a photoshop sub...

[Svenstaro]

That looks very cool and I like the security concept. Any chance you're going to open-source it?

[devinsit]

As I replied down below (https://news.ycombinator.com/item?id=26972907), I don't have any concrete plans to open-source it at the moment. However, I know this is a pretty big sticking point for some people, so I have been working through some plans on how we could do it.

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.

[calderarrow]

ufincs looks very cool! During my December holiday, I was thinking of making a web-based platform that had a more modern UI than GNUcash, and it looks like you built it already!

Just curious, what's your tech stack, how long have you been working on it, and how many users do you have?

[devinsit]

That's exactly what uFincs is, a modern version of GnuCash! I had the exact same thoughts as you did :)

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!

[dazuaz]

"but I actually did just acquire my first paying customer yesterday!"

Congratz!

[devinsit]

Thank you!

[gowld]

Is it open source? That's a critical aspect of the "Gnu" part of GnuCash.

[devinsit]

It definitely isn't. At least, not yet. I've been thinking through different ways we could handle that aspect, but I don't have any concrete plans to open-source uFincs at the moment.

[jchanimal]

Assuming you had a perfect plug-in/extension system where I could write some JavaScript to create my own behaviors, that might do 80% of what people are looking for in the open source question.