The individuation of populations into single Users is not a technological necessity, but from the perspective of The Stack looking up, it is an accommodation and a way of making its own emergent platforms interoperable with the conventions of identity we have inherited. <sup>82</sup> The function of User individuation is as much to accommodate the cultural logics of human self-identity predicated on naming, autobiography, lineage, moral self-accounting, and bureaucratic management as it is a real systems requirement. User IDs make it easier to regularize patterns among multiple variables, but they are a function of the fact that Users understand their interactions with platforms over time as the accumulation of events that are temporally unique to themselves. Some people are surprised to learn that many Cloud platforms are not overly interested in their name and address, only in their actual and predictable behavior. The idea that their identity could be reduced to what they do instead who they are seems counterintuitive, even insulting. At the same time, interfacial security regimes can demand highly specific identification of one exact User versus all possible other Users. Access to secure locations, such as a data center, is controlled by highly demanding interfacial apertures. In general, a combination of identification criteria must be satisfied, all of which are effective for identifying human Users but equally effective identifying nonhuman Users as well, and so as in Kafka ’ s “ Before the Law, ” all who come before the door are made equal, but this door will open only for you. This triumvirate of User identity is: “ something you know ” like a password, or a specific response to a specific question; “ something you have ” like an identification card, a dongle, key, or specific chip; and “ something you are ” like a fingerprint, retina pattern, or other hard-patterned information. These are the three sides of the triangle that individuates one User from a population: knowing, having, being. So long as something can know, have, and be, it can be a User. To some, that may seem unnatural; to me, that looks like universal suffrage.
In order to design more robust transformations at the User layer, it is not enough to expand the criteria for admission only to who and what counts as a User; it also demands a shift in how (and indeed if) the User is made to account for the intentions and effects of every column that he, she, or it initiates. A crash may be put down to driver error, but from a wider perspective, the entire transportation system collaborates in allowing for the possibility that this error might result in catastrophe. The preponderance of attention paid to the legal rights of human Users to interact with one another without regard to “ externalities ” and largely without governance other than the carnival of “ reputation, ” has the secondary effect of diverting energy from these other two (likely more) important design problems: the representation of nonhuman Users and the codification of enforceable accountability within a complex composite technical system. One starting point is to peel apart the User of an interface from the owner of an interface, as the demands of each may continue to diverge significantly. As discussed above in in relation to the ownership or stewardship of data within an Internet of Things ecology, it is not enough to simply say that the legal owner of a device should have control over its data, and not only because “ the ” owner is not likely a single identifiable entity. A sensor may be owned by X and capture data about Y, and here the former is the owner while the latter is the User, who may also claim durable rights over what the sensor senses about themselves. The owner can ’ t possibly own all that what he knows about everyone, but at the same time that User (person Y) cannot possibly claim that anything and everything any sensor senses about himself is really a part of his expanded sovereign person and should remain under his control. The sound waves disturbed by your voice that my eardrum picks up are as much mine as yours, and in a world of trillions of sensors, dividing the City layer up into zones of reasonable privacy and zones where one has no expectation of privacy makes no sense because, if no other reason, no zone is ever discrete; it is always overlapped and overlapping. In some cases, we will definitely wish for the interests of the User to trump those of the owner. As in Cory Doctorow ’ s example cited in the User layer chapter, someone who falls behind on the payments for his or her child ’ s smart ocular implants and has to choose between a bankruptcy and an ability to see should rightly claim that the needs of the User, in this case her daughter, trump those of its owner, her bank. <sup>83</sup> Whether the same is true of driverless cars that drive themselves back to the dealer lot, automatically repossessing themselves from delinquent Users, is less clear. It is precisely this fog, this gray area the size of the User layer itself, that needs our most concentrated and critical design attention. <sup>84</sup>
The Stack to Come
345