Manual entry is not privacy

The comfortable assumption

People who care about financial privacy usually converge on the same instinct: do not connect the accounts. Refuse the aggregator, refuse the API key, type the balances in yourself. The instinct is sound, and the conclusion drawn from it is usually wrong — because it treats the connection as the leak, when the connection is only one of two.

What manual entry actually buys you

It buys you one specific thing: no third party is given standing access to an account you own. That is worth having. An aggregator connection is a live credential path into a bank or an exchange, and not creating one is a genuine reduction in what can go wrong. Most trackers on the market let you do this — you can type a balance into Kubera, into CoinStats, into a dozen others, and never hand over an address or a key. Anybody claiming their product is the only one that permits manual entry is selling you something.

What it does not buy you

It does not make the figure private. The number you typed is written to a database, in readable form, in a row that also carries the email address you signed up with. The company running the product can read it. So can anyone who obtains a backup of that database, anyone who compromises an employee account with the right permissions, and anyone who serves a valid legal demand. None of that is a criticism of any particular company's intentions — it is a description of what a plaintext column is.

• The provider can read it, because their application does, on every page load.
• A breach reads it, because a stolen backup is the same rows without the login screen.
• A subpoena reads it, because a company can only refuse to hand over what it cannot produce.
• A future owner reads it, because a database survives an acquisition and a privacy policy does not.

The distinction that matters

There are two different promises a product can make, and they are routinely described in the same words. The first is 'we will not look at your data'. That is a policy: it is made by people, it binds only as long as those people run the company, and it cannot bind a court. The second is 'we cannot look at your data'. That is a property of the system: it holds whoever runs the company, and it holds against a legal demand, because there is nothing readable to produce.

What has to be true for the second promise

The encryption has to happen before the data leaves your machine, and the key must never arrive at the server. That is the whole requirement, and it is unglamorous to implement and expensive in what it costs you elsewhere. A server that cannot read your figures cannot sort them, cannot search them, cannot compute a total for you, cannot send you an email about your portfolio, and cannot recover anything if you lose the key. Every one of those is a feature somebody would like, and giving them all up is the price.

The cost, stated plainly

This is why most products do not do it, and the reason is not laziness. If the server cannot read the data, all the arithmetic moves into the browser, backups become useless to support staff, and 'I forgot my password' stops being a recoverable situation. A company that has built its product around server-side computation cannot add client-side encryption as a feature; it is a rewrite from the schema up. That is also precisely why the promise is worth something when a product does make it.

How to check a claim

Ask one question of any product that advertises privacy: if you lost your password and your recovery method, could they show you your own numbers again? If the answer is yes, they can read your data. That is not a gotcha — it is the same fact stated from the support desk instead of the architecture diagram. A product that cannot recover your figures is a product that cannot read them, and a product that can do you that favour can do it for someone else too.