[GH-ISSUE #41] RFC: Sunset Client Side Encryption #7018

New Issue

GiteaMirror · 2026-04-10T16:41:56-05:00

GiteaMirror commented

2026-04-10 16:41:56 -05:00

Originally created by @Silvenga on GitHub (May 5, 2022).
Original GitHub issue: https://github.com/actualbudget/actual/issues/41

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

The original security concerns are moved to individuals, allowing them to choose their threat model.
Not only is this client-encryption less useful, the encryption introduces additional complexities:
- Additional error checking is required.
- Additional API surface area needs to be maintain.
- Multiple logic flows (encrypted and unencrypted) would need to be tested and maintained.
- The server is unable to modify the Actual data without the involvement from a client. This may make largely desired features, such as automatic bank import, more difficult.
- etc.
Encryption is currently not supported by the OSS server per this comment: 44d045f546/app-sync.js (L126-L135) Additional work will be required to support client-side encryption.

Against Removal

Some individuals may not have the technical ability to secure a server effectively (e.g. full disk encryption is only useful with physically protected, physical hardware, which may be out of scope for many). Services like https://fly.io/ should be considered as the lowest common denominator that should still support a secure encryption model.
Client side encryption is a features that is best added at the beginning of development. The code largely already exists and should be maintained.
If a community maintained cloud service is every considered again (similar to https://www.home-assistant.io/cloud/), client-side encryption would be largely desirable.

Commentary

I personally found this client-side encryption feature a major factor in ultimately selecting Actual for personal use. I still believe client-side encryption is a killer feature.
I personally run full-disk encryption on my own infrastructure, and while I support the inclusion of any time of client-side encryption (and would actively use it), the developer side of me likes the idea of being able to modify Actual data from the server without a client (aka a developer API). I would want to prioritize features like Plaid fetching or stock value tracking over client-side encryption - as I personally can secure the Actual data in a way that is acceptable.

Originally created by @Silvenga on GitHub (May 5, 2022). Original GitHub issue: https://github.com/actualbudget/actual/issues/41 ## 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)](https://actualbudget.com/docs/overview/syncing-across-devices/#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 - The original security concerns are moved to individuals, allowing them to choose their threat model. - Not only is this client-encryption less useful, the encryption introduces additional complexities: - Additional error checking is required. - Additional API surface area needs to be maintain. - Multiple logic flows (encrypted and unencrypted) would need to be tested and maintained. - The server is unable to modify the Actual data without the involvement from a client. This may make largely desired features, such as automatic bank import, more difficult. - etc. - Encryption is currently not supported by the OSS server per this comment: https://github.com/actualbudget/actual-server/blob/44d045f546ceb2440f2a681bc5821bbb8eefb80f/app-sync.js#L126-L135 Additional work will be required to support client-side encryption. ### Against Removal - Some individuals may not have the technical ability to secure a server effectively (e.g. full disk encryption is only useful with physically protected, physical hardware, which may be out of scope for many). Services like https://fly.io/ should be considered as the lowest common denominator that should still support a secure encryption model. - Client side encryption is a features that is best added at the beginning of development. The code largely already exists and should be maintained. - If a community maintained cloud service is every considered again (similar to https://www.home-assistant.io/cloud/), client-side encryption would be largely desirable. ## Commentary - I personally found this client-side encryption feature a major factor in ultimately selecting Actual for personal use. I still believe client-side encryption is a killer feature. - I personally run full-disk encryption on my own infrastructure, and while I support the inclusion of any time of client-side encryption (and would actively use it), the developer side of me likes the idea of being able to modify Actual data from the server without a client (aka a developer API). I would want to prioritize features like Plaid fetching or stock value tracking over client-side encryption - as I personally can secure the Actual data in a way that is acceptable.

GiteaMirror closed this issue

2026-04-10 16:41:56 -05:00

GiteaMirror commented

2026-04-10 16:41:58 -05:00

@genebean commented on GitHub (May 5, 2022):

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.

@genebean commented on GitHub (May 5, 2022): 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.

GiteaMirror commented

2026-04-10 16:41:59 -05:00

@Silvenga commented on GitHub (May 6, 2022):

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. 😁

@Silvenga commented on GitHub (May 6, 2022): 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. 😁

GiteaMirror commented

2026-04-10 16:42:00 -05:00

@genebean commented on GitHub (May 7, 2022):

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.

@genebean commented on GitHub (May 7, 2022): 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.

GiteaMirror commented

2026-04-10 16:42:01 -05:00

@Silvenga commented on GitHub (May 7, 2022):

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).

@Silvenga commented on GitHub (May 7, 2022): 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).

GiteaMirror commented

2026-04-10 16:42:01 -05:00

@utf8decodeerror commented on GitHub (May 7, 2022):

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

@utf8decodeerror commented on GitHub (May 7, 2022): 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

GiteaMirror commented

2026-04-10 16:42:02 -05:00

@Silvenga commented on GitHub (May 7, 2022):

Hmmm... that's a good idea.

@Silvenga commented on GitHub (May 7, 2022): Hmmm... that's a good idea.

GiteaMirror commented

2026-04-10 16:42:02 -05:00

@jmiguel-hdez commented on GitHub (May 12, 2022):

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.
I understand that perhaps there are other priorities right now but if encryption is not considered from the beginning it will likely very hard to add it back again in the future.

@jmiguel-hdez commented on GitHub (May 12, 2022): 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. I understand that perhaps there are other priorities right now but if encryption is not considered from the beginning it will likely very hard to add it back again in the future.

GiteaMirror commented

2026-04-10 16:42:03 -05:00

@jnimmo commented on GitHub (Aug 3, 2022):

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.

@jnimmo commented on GitHub (Aug 3, 2022): 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.