Wednesday, March 15, 2023
Fascinating history that feels very relevant today: there was recently a bank startup called TNB that tried to offer “narrow banking” which would have offered deposit accounts and plops the result directly in the Fed, passing interest to customers (nearly 2% in 2018, although obviously finance people use the obfuscated language of “basis points” to make everything seem more complicated than it really is). The opposite of fractional-reserve banking.
The Fed did not approve this, and the startup says it “seeks to offer” narrow banking to this day – it cannot accept deposits.
This is relevant to today because runs are impossible in a narrow bank, and FDIC deposit insurance (which has a $250,000 limit) is not necessary. A regular bank takes your money in deposit and immediately loans it out. The bank has a lot of money in absolute terms sitting around liquid so that customers can withdraw approximately whenever they want to, but most money they hold is actually loaned out and therefore illiquid, such that if too many of their customers withdraw at once they will not be able to access it. (This is what happened to SVB.) By contrast, a narrow bank is much simpler; it can always get all of your money immediately from the Fed.
The inimitable Matt Levine covered TNB in more approachable language. Basically, if we had that, then why would regular depositors put their money in a regular bank? Maybe they wouldn’t. And if customers didn’t use regular banks at scale, then maybe your Chase Bank and your Bank of America don’t exist any more, and maybe it’s hard to figure out of that’s bad for society or not.
So the Fed just stonewalled. I have no position on whether this was right or wrong. But it’s pretty weird! Runs are impossible in a narrow bank, but also probably business loans of various kinds are more expensive. Maybe that’s worse?
Monday, March 13, 2023 →
Imagine browsers offering synced window.localStorage, with an in-browser UI for whether you’re logged in to a site. It would be like iCloud for the web - syncing data via your browser sync password, obviating the need to create a new account for every application that wants to store data, as you’re already logged in to iCloud.
Conceptually, the user could whitelist sites to allow this; the browser would integrate the whitelist into the log-in UI. This would let the browser keep you logged in forever, fixing the terrible short cookie expiry timelines that browsers enforce now to limit tracking. The in-browser UI would be unspoofable (like eg the Firefox extension installation UI), and it would be impossible to phish the credentials (sort of – attackers could phish the credentials for the sync service, but not individual websites that use it).
Allowing data to live forever, sync across devices, and be tied to the browser sync profile would mean that apps could rely on static hosting for JavaScript/WebAssembly, and localStorage for user data. Today, lots of apps basically use a server just for hosting user data since browser storage is so unreliable – those apps could be ported to the web (many automatically with webasm) and live ~forever without requiring hosting costs and security updates. Basically any app designed to run on a desktop operating system and save data to the hard drive could be ported – MS Paint, Text Edit.app, a full Linux virtual machine with a persistent filesystem via v86.
Details to work out: Do you allow sharing data between websites? iCloud doesn’t, which is annoying, but the implementation is simpler. The best implementations would be end-to-end encrypted. Ideally, you’d be able to mix and match storage providers between different browsers, like using Firefox on Windows to sync with Safari on an iPad.
A browser extension could do this, but then sites would have to support it specifically. Might be useful as a proof of concept though. I wonder if there are enough primitives in Safari extensions to implement it today?
