Eric has surfaced a lively discussion, a lively renewal of the discussion on digital identity (current participants include Doc and David, and the blogthread goes backward from these most recent posts). Earlier, Doc was concerned that we were getting “testy” (thatnks for reminding me about that word, Doc—it’s a good one), but I don’t think Eric or I is (am?) feeling any but energized and provoked by an invigorating discussion on a topic we both care about. I trust Eric to let us know when he’s testy.
One wild card in the discussion so far may involve the different interests each participant has in the topic. Eric’s all about digital identity and, specificially, its engagement with commerce; Doc wants to gird up the N E A character of the ’Net; I’m particularly exercised about the ways that crossing over more fully into digitially-mediated reality changes what we think about ourselves as “human”; and Dr. Weinberger is so smart he thinks about all these things at once, plus twelve others, and sounds funny and self-deprecating at the same time. When you put those differences into a discussion, we can get side-tracked, testy, harmonious, and confused all in a matter of moments depending on who has the conversational ball and toward which goal the ball is moving.
So, in response to all this wisdom, I’ll blogback at Eric, point by point, with animadversions involving Doc and David where it suits me.
Eric’s Point One (edited): “1. The Internet brings (in essence) ubiquitous Access and Connectivity, but it does so with a high degree of anonymity and an inefficient implementation of reputation.”
Eric clarifies this to note that the Web is a nearly frictionless environment for economic transactions, but that anonymity engenders a twofold drag on transactions: first, in that “anonymity” makes for awkward transactions. We know that some vendors, given the opportunity to act anonymously, will defraud customers—and vice versa. That sort of anonymity will kill most, if not all, deals.
Eric cites “inefficient implementation of reputation” as a second problem, but that’s really just the other side of anonymity, isn’t it? If we had efficient means of establishing someone’s reputation, their anonymity would be shot, whereas anonymity entails a certain lack-of-reputation.
I agree with Eric that we can’t have both anonymity/lack-of-reputation and frictionless commerce at the same time. But David points out that we have them now, only in divergent loci. I’m not anonymous to Amazon (except when i’m in a hurry, in which case their cookie has always just disappeared), but I can be very anonymous when I visit Umbrella R Us, because I have never bought an umbrella, never plan to, and have no cookie from them in my browser.
One of the catches, though, at this point is that Umbrellas R Us can pop a cookie onto my browaser uninvited (unless I scrupulously monitor all such attempts, which I and most other folks are too indolent to do). That invokes the demon of Big Brother, observing your every click, watching you over your shoulder, and ready to siphon all your identity markers into the central database of Information Acquisition. I’m not fretful about DigID, but John Poindexter (working for George Bush) gives me the creeps; this kind of situation makes me want a way of manipulating my digital profile without putting in hours playing Cookie Detective.
So, relative to point one, my answer to Eric is, “Yes, the two-pronged feature/problem of anonymity and reputation introduces drag into the economic function of the ’Net. But. . . ,”
and I’ll say more tomorrow.
Earlier I mentioned that variables can live in two different places. We're going to examine these two places one at a time, and we're going to start on the more familiar ground, which is called the Stack. Understanding the stack helps us understand the way programs run, and also helps us understand scope a little better.
Posted by: Adam at January 12, 2004 11:58 PMSeth Roby graduated in May of 2003 with a double major in English and Computer Science, the Macintosh part of a three-person Macintosh, Linux, and Windows graduating triumvirate.
Posted by: Manasses at January 12, 2004 11:58 PMWe can see an example of this in our code we've written so far. In each function's block, we declare variables that hold our data. When each function ends, the variables within are disposed of, and the space they were using is given back to the computer to use. The variables live in the blocks of conditionals and loops we write, but they don't cascade into functions we call, because those aren't sub-blocks, but different sections of code entirely. Every variable we've written has a well-defined lifetime of one function.
Posted by: Ciriacus at January 12, 2004 11:58 PMOur next line looks familiar, except it starts with an asterisk. Again, we're using the star operator, and noting that this variable we're working with is a pointer. If we didn't, the computer would try to put the results of the right hand side of this statement (which evaluates to 6) into the pointer, overriding the value we need in the pointer, which is an address. This way, the computer knows to put the data not in the pointer, but into the place the pointer points to, which is in the Heap. So after this line, our int is living happily in the Heap, storing a value of 6, and our pointer tells us where that data is living.
Posted by: Augustine at January 13, 2004 09:10 AMThis code should compile and run just fine, and you should see no changes in how the program works. So why did we do all of that?
Posted by: Gillam at January 13, 2004 09:10 AMLet's take a moment to reexamine that. What we've done here is create two variables. The first variable is in the Heap, and we're storing data in it. That's the obvious one. But the second variable is a pointer to the first one, and it exists on the Stack. This variable is the one that's really called favoriteNumber, and it's the one we're working with. It is important to remember that there are now two parts to our simple variable, one of which exists in each world. This kind of division is common is C, but omnipresent in Cocoa. When you start making objects, Cocoa makes them all in the Heap because the Stack isn't big enough to hold them. In Cocoa, you deal with objects through pointers everywhere and are actually forbidden from dealing with them directly.
Posted by: Charity at January 13, 2004 09:11 AM