Replies: 11 comments
-
I’d suggest keeping client side encryption since, if I understand things correctly, this would protect data on a sync server even if said server is compromised. Full disk encryption doesn’t help when a running server is compromised as everything is unencrypted while the system is up. e2e encryption is virtually always better from a security perspective. |
Beta Was this translation helpful? Give feedback.
-
Question around that @genebean, would you rather focus on encryption or features like automatic bank import, stocks import, developer API, multiple users, notifications, etc.? It's always easier to say "security is good", but it's still something that should be prioritized. 😁 |
Beta Was this translation helpful? Give feedback.
-
That’s a fair question @Silvenga. Financial information can tell someone how we live our lives so I’d actually lean towards security being paramount. That said, I wonder if some of the import bits being done client side via a mobile app that has the data decrypted might help allow both to progress. Alternatively, maybe the import processes could be run on a separate box that has no inbound access allows to it and it could have the decryption keys on it. That could make for a reasonable balance that reduces the likelihood of the system with decrypted data being compromised as the system open to the internet to facilitate devices syncing wouldn’t have knowledge of the data contents. Users less concerned with the security implications could even choose to run both processes on the same system while those of us more concerned could use separate systems like I described. The import system could even be a home computer as opposed to a public one since it’d only need outbound access. |
Beta Was this translation helpful? Give feedback.
-
My thinking of not adding encryption support is so that the client side wouldn't need to be coded to support every plugin. Rather, we can use standard developer API's and not require plugin developers to use JavaScript. Encryption might double or tipple development time for features, making them significantly less likely to be worked. I wonder @genebean, If security is most paramount, then wouldn't it be most appropriate for the server to only operate inside a private network with no internet access? Again, the idea being that security concerns are of the hoster. Remember the client data isn't encrypted in either case. Aside, another problem, what if the importer would need ingress access to operate? I know that's how some of the bank scrapers would need to operate e.g. ingress webhooks. This importer would have access to all your finances anyway (and such data would likely need to be cached and stored unencrypted). |
Beta Was this translation helpful? Give feedback.
-
It may be possible to provide encryption capability as a flag on the server that would enable/disable other features like plugins that need a full instance of actual to operate on the data. It would essentially be swapping sync-simple for sync-full here based on a flag passed in when the server starts: https://github.com/actualbudget/actual-server/blob/master/app-sync.js#L126-L133 |
Beta Was this translation helpful? Give feedback.
-
Hmmm... that's a good idea. |
Beta Was this translation helpful? Give feedback.
-
I personally would rather have end to end encryption. I am kind of worried that my self deployed server could be hacked. If we can keep the feature flag in settings and slowly work on it that would be great. |
Beta Was this translation helpful? Give feedback.
-
I would support the removal of client side encryption, considering your well thought out arguments. Users with requirements for higher levels of security can always host locally for example, and the work involved with maintaining two different models here seems fairly high. Especially given the OSS server doesn’t currently support it. |
Beta Was this translation helpful? Give feedback.
-
Client side encryption was a major win-over because it allows me to use an affordable hosting provider to sync data across devices in a user friendly way while minimizing risk. I do not share the opinion that client side encryption is less useful now that Actual is OSS. Architecturally it would make sense to keep the sync-server dumb with a single purpose of synchronizing encrypted state. Any processing, importing, development API access, etc. could be provided as separate modules which may contain the appropriate keys. I agree with @genebean's follow-up on this. Quoted from @Silvenga
@genebean was arguing the validity of the client side encryption feature which is; it allows handling sensitive data in a public (hostile) environment where you may not be able to trust the hoster or the service may get compromised.
In response to ingress access: Instead of direct ingress access, an importer could use a pull based messaging integration with a public ingress service for webhooks. This decision has fundamental consequences for the overall architecture. I cannot properly estimate the impact on complexity and velocity and therefore cannot judge whether or not this is a sustainable feature at this point in time. |
Beta Was this translation helpful? Give feedback.
-
Hi, as a user who doesn't have the capacity to run my own, physical self-hosted server (I'm using fly.io, I imagine as do many) I would greatly appreciate a working implementation of End-to-End Encryption in this version of Actual.
In my case, for example, it's not really feasible to host Actual on my own, even if I'd prefer that to using a cloud provider. As Actual went the web-app route, rather than offline app route, end-to-end encryption is still very much needed in my opinion. |
Beta Was this translation helpful? Give feedback.
-
👋 Just reading through this now. We actually re-enabled e2e encryption. It will be available in the next release (23.2.xx). |
Beta Was this translation helpful? Give feedback.
-
Introduction
This is a request for comment (RFC) on if client-side encryption should be sunset in Actual OSS.
Actual clients support syncing between many instances using a centralized server (sync server). As clients make modifications, the changes to their internal state are set to the sync server to be received and applied by other individual client instances.
Further, under Actual (in the before times), the client supported encrypting all data locally before the data was sent to the sync server, as documented here (end-to-end-encryption).
Effectively, client side encryption allows for a zero-trust model for the syncing server. The end-user could assume both the data was encrypted on disk in a format that even the operator of the server would not be able to access.
Terminology
When I refer to the sync server, I refer to a hypothetical server that only handles syncing of encrypted data between clients. The OSS server is functionally different from the previous implementation.
When I refer to a client, I refer to the full-fat clients in the model of the before times Actual e.g. the Mobile client and the Electron Desktop client. The OSS server blurs the lines.
Proposal
In Actual OSS, servers are hosted and maintained by the same individuals using the Actual OSS client. These individuals may employ full-disk encryption or other security measures if they believe such protections are warranted. Since there is no longer a third-party operator who may have access to the Actual data, the zero-trust model is less useful.
Client-side encryption should be considered for removal from Actual OSS.
Pro Removal
Against Removal
Commentary
Beta Was this translation helpful? Give feedback.
All reactions