Picking up where I left off in the previous essay, I want to reflect on the causal arrows that turned up in the exploration. It seems that maybe we have a seedling of a simple framework for evaluating user-situated trustworthiness. I’d like to now zoom in a bit on software products, since this is the area where I spent most of my time. In this area, the “things that are mine” are usually the data that I, as a user associate with myself. Looking at the properties of the boundary-tracing process, I can infer that there are two challenges that any user evaluating a product for trustworthiness will face.
First, there’s the challenge of evaluating the extent of what they consider theirs. The implicit question a user asks: “What’s all the data that I need to think about in relation to this product?” When looking at the extent, two concerns pop out for me: quantity and substance of the data. Quantity of data seems to correlate with extent. When interacting with a software product, the more of my data (higher quantity) I share with this product, the higher will be the extent of the boundary-tracing. Substance is similarly correlated. The more important the data is to me, the more invested I will be in the boundary-tracing. Conversely, if I don’t consider this data to be important, I will be engaged in boundary tracing to a lower extent.
My first year in the US was one of the most culturally transformative years of my life. I might as well have arrived on an alien planet. It took me a few painful mistakes and great wisdom of caring friends to learn the strength of the spirit of individualism in American culture. Coming from the culture where very few things were truly “owned” by an individual (and thus, would be considered as insubstantial in our little framework), the discovery of property rights and proprietorship was jarring and profound. Think of “substance” as the strength of a user’s connection to their data. Comparing myself back then and now, it is fascinating how little of “what is mine“ that I consider valuable today would be viewed as such by that Soviet kid.
At least within this framework, it is now easy to see that the extent of boundary-tracing is inversely correlated to trustworthiness. The more important and more of the data, the more difficult it would be for the user to trace the boundary around it.
The second, orthogonal challenge of the boundary-tracing process that a user will face is that of clarity. How much confidence do I have as a user that the boundary I traced is accurate? The big two obstacles — or put differently, the inversely correlated components — are connectedness and fluidity. The first one stems from the idea that tracing the boundary is more difficult in a densely connected graph. If the software product I use is potentially connected to another product or a place where the data could be moved to, do I have to treat that other place as part of my boundary-tracing?
Fluidity makes things even worse. Being able to move data quickly adds ambiguity to where to trace boundaries. In my last post, I talked about floppy disks. If you ever used one, you probably remember the unmistakable grinding noise of the floppy drive writing your data down, light blinking and all that. Once the noise stopped and light stopped blinking, you knew that the data made it over to disk. Compare that to the frictionless fluidity of today’s Internet, with its seemingly instant data transfer speeds. The more the data is like water, the less confident a user is about their ability to trace the boundary around it.
So, when a user is looking at a software product, I am suggesting that they are implicitly evaluating these four components. Is the data I will share with this product substantial? How much of it will I share? How connected is this product to others? How quickly can my data be moved elsewhere? Of course, depending on whether they are a young adult from the Soviet Union or an aging Silicon Valley software engineer, results of their evaluation will differ. However, my intuition is that they will roughly follow the same process.