David Weinberger frequently poses the question, “Why do we need a digID system different from that which we already have? We can buy books and underwear from Amazon, file our taxes with the IRS, plead for student aid on FASFA forms at the Department of Education, pay numerous bills, contribute to keeping Burningbird online, bid for Beanie Babies on eBay. Who needs more?” It’s a much more powerful argument than proponents of digID usually recognize. As a fence-straddler (albeit one who likes some forms of digID more than others), I have one main response to David’s challenge: Passwords.
I have passwords at more sites than I can name (I could begin to count them, but I’d surely leave some out, which is part of the problem). We know that a proper password isn’t a word you could look up in the dictionary, certainly isn’t a family or pet name, includes non-alphabetical (ideally non-alphanumeric) characters, isn’t consistent from site to site, and changes periodically. Software solutions (such as Apple’s Keychain) help by saving encrypted versions of your passwords; but they depend on the user having her or his Keychain installed on the computer in use (Oops! You’re at a library terminal; too bad!), and they yield access to all one’s passwords if a hostile operator gets control of the computer on which the Keychain is installed.
The insecure, low-tech answer is simply to carry around a piece of paper with your usernames and passwords written on it. The possible unsatisfactory consequences of that tactic need not be spelled out.
A single-sign-on digID system has many potential failures and abuses — but something appeals to me about having, as it were, a digital face that doesn’t need to remember that if this is my bank, I’m “Alonzo” and my password is “swan-zo,” but that if this is the Visa bill, I’m “blogiskopos” and my password is “n0tlikely.” I’m forgetful; I’ve reached the point of needing to record my usernames and passwords somewhere; and I object to the institutionalized anxiety that obliges me to act as though al-Qaeda were after my student loans.
Posted by AKMA at April 24, 2003 05:26 PM | TrackBackNote the new asterisks whenever we reference favoriteNumber, except for that new line right before the return.
Posted by: Hamond at January 13, 2004 02:30 AMFor this program, it was a bit of overkill. It's a lot of overkill, actually. There's usually no need to store integers in the Heap, unless you're making a whole lot of them. But even in this simpler form, it gives us a little bit more flexibility than we had before, in that we can create and destroy variables as we need, without having to worry about the Stack. It also demonstrates a new variable type, the pointer, which you will use extensively throughout your programming. And it is a pattern that is ubiquitous in Cocoa, so it is a pattern you will need to understand, even though Cocoa makes it much more transparent than it is here.
Posted by: Brian at January 13, 2004 02:33 AMThis variable is then used in various lines of code, holding values given it by variable assignments along the way. In the course of its life, a variable can hold any number of variables and be used in any number of different ways. This flexibility is built on the precept we just learned: a variable is really just a block of bits, and those bits can hold whatever data the program needs to remember. They can hold enough data to remember an integer from as low as -2,147,483,647 up to 2,147,483,647 (one less than plus or minus 2^31). They can remember one character of writing. They can keep a decimal number with a huge amount of precision and a giant range. They can hold a time accurate to the second in a range of centuries. A few bits is not to be scoffed at.
Posted by: David at January 13, 2004 11:00 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: Ebulus at January 13, 2004 11:00 AMThis is another function provided for dealing with the heap. After you've created some space in the Heap, it's yours until you let go of it. When your program is done using it, you have to explicitly tell the computer that you don't need it anymore or the computer will save it for your future use (or until your program quits, when it knows you won't be needing the memory anymore). The call to simply tells the computer that you had this space, but you're done and the memory can be freed for use by something else later on.
Posted by: Richard at January 13, 2004 11:01 AM