A portion of building secure applications is protecting them from others. But yet another portion is protecting them from ourselves. Below is a trick which may help in building applications which respect privacy.
Do note that before going further that this does not solve all security issues, and that you are still responsible for making sure sensitive information is kept secure. I present this trick simply as a concept for individual consideration or ideas. The idea requires individual implementation of which I am not responsible for any damages. It is a springboard to other privacy features as well.
Sensitive Info Container
Here is one example of a sensitive info container. The structure has two members: the item (sensitive information), and a privacy setting. To continue with this example, the privacy setting is simply an enumeration.
Code Kept Clean
Both the security and the value itself are all one parameter. It may reduce the complexity.
Data is initialized right with the privacy settings. Privacy isn't an afterthought, nor is some extra feature to be implemented later, forgotten about, etc.
Calling such a function is a constant reminder that the data retrieved is sensitive.
Notice how calling user.name in this example doesn't actually return a string, but returns the container:
To actually retrieve such value, one must call get_sensitive_info(). This acts as a constant reminder that the information kept here is sensitive, and to not be passing the value all over the place in code.
get_sensitive_info() could be implemented virtually, abstract, etc. It provides a nifty accessor by which an error could be thrown if, for example, the wrong user is trying to access the data. Careful though, as not all pieces of sensitive info should be validated the same. Consider sub-classes, or the equivalent. In Rust, this could be a Trait.
Word of Caution
Privacy should still be considered case by case
One can create other types of sensitive info containers, and adapt them to individual needs. Don't just get into the habit of sticking everything in the same type of container.
Data can still be accessed by other means
This container does not prevent from other exploits.
There is a pointer/reference to the data. Private does not prevent someone from using a hex editor. Many languages can use reflection and other means to access private variables.
Pointers can still point to it.
It is more of a design technique. While even the developer can get around it with the above suggestions, it makes it more inconvenient to do so, and simply calling get_sensitive_info() then solves it.
This reminder ends when retrieved
If the value is saved somewhere else outside the container, the point is lost. Exercise caution when assigning the value to a temporary variable.
This isn't a completely secure container
This discusses ways in which a container can be used to better organize and be reminded of sensitive information. Additional features are needed to make this more secure from other potential vulnerabilities, such as encrypting the contents.
Where is it being validated?
I personally would not do any of this logic on a client application.
This is just one arrow in the quiver
Employ all other needed security and privacy concepts which can correctly keep private data secure.
The following is presented conceptually. While I am not responsible for any damages in the use of this concept, adapted or otherwise, I hope it helps or stems ideas. Similar concepts exist already, this is simply an introduction.