I’ve always wanted a type system that would keep me from exposing sensitive data with minimal developer effort, so I took a crack at designing it for Go. It requires two new container types (inproc[T] and xproc[T]) and a global function that are all removed at compile-time, but results in a nearly zero-cost data privacy setup. Besides reflection-based checks, no runtime changes are required.
This is somewhere between a thought experiment and a proper proposal for inclusion in a language. It’s certainly not ready for an RFC anywhere, but there’s perhaps a kernel of value here.
There’s a class of data in many applications that’s sensitive and/or secret, but must still be accessible in plain-text for the application to work. The space is unbounded so a few examples help:
In any scenario, this information is required for the application to function. Clearly, users can’t log in if we make password hashes unreadable on the server, and we can’t display a user’s shipping address if their addresses aren’t readable. Users can’t perform any actions after logging in if we make auth tokens unreadable on the client. And we can’t decrypt the user’s password store without accepting their passphrase.