From my understanding, FHE can represent Boolean circuits, so you don't write an "FHE application"; you can send an encrypted input into an encrypted Boolean ci

From my understanding, FHE can represent Boolean circuits, so you don't write an "FHE application"; you can send an encrypted input into an encrypted Boolean circuit and get an encrypted result. Since FHE operations are Boolean circuits, we can consider basic stuff like "AND" or "NOT" - but all the inputs, outputs and the operation itself are encrypted, so the owner of the server won't even know if someone called an AND gate, a NOT gate, or something else. Which means that if primitive Boolean operations are supported, you can chain them to create a general purpose, Turing complete computer. However if you were a nefarious actor looking at the order and frequency at which various primitives were called, then you could be able to discern a call graph (or at least, a statistical "heatmap"), and you might figure something about the nature of the program, and therefore be able to glean some kind of understanding of the information passing through it, however abstract. However since FHE can represent boolean circuits, we're not just limited to primitives. A futuristic compiler could create a single boolean circuit to represent a complex application - however for something like a blog or eCommerce store, that would result in inordinate amount of cyphertext to represent the code, and undoubtedly be very slow to run. I think more likely is the compiler would optimise layers or stacks of black-boxes that are not simply boolean primitives. Your plaintext code (in the language of you choosing) would have every branch of the call stack from input, processing, and output analysed n-levels deep optimising for a balance of runtime and obfuscation. In such a case, the nefarious actor would see a blob of cypher going into a blob of other cypher to generate a blob of cypher as input into the next blob of cypher. Maybe there are parallel cypher blobs, but their internals are completely hidden. An inside actor might have intimate knowledge of how long each blob takes to execute for various inputs, so assuming that knowledge is shared we're back at good old timing attacks - which would probably become irrelevant on the next compiler pass anyway. Use-cases I can think of are any kind of transactional situation where various actors have competing interests, where it may be in one or more actor's best interests to game the system. Anything peer-to-peer is a good example. Gaming seems trite, but in the early days, gaming was full of client side cheats. The current model for multiplayer gaming to avoid cheating is centralised - every client has to interface with a central server that then has to figure out which moves were legal in the game's rules - peer-to-peer is fraught with cheaters since they can analyse and change the code client-side. Realtime FHE would allow game developers to come back to peer-to-peer gaming, since it would be mathematically improbable that a peer is cheating. Escrow is another peer-to-peer type activity, where it would be useful to have a trusted middleman. Maybe provenance for digital / physical goods (that's a bit of a stretch). But essentially, right now, a lot of development effort is expended to make sure individuals in a system can't gain an advantage on the client side - if we didn't have to trust a user's computer to do the right thing, then the client/server trust barrier collapses.