Thinking and reading about Wikipedia’s dominant editing culture has helped me clarify what I like to get out out of Wikipedia, what its controlling forces want, and the difference between the two.  At one point, Jimmy Wales (Wikipedia’s cofounder) presented a vision that greatly appeals to me:

“Imagine a world in which every single person on the planet is given free access to the sum of all human knowledge. That’s what we’re doing. “

Unfortunately, one aspect of this vision (access to the sum of all human knowledge) is at odds with, one of Wikipedia’s current guiding principles, namely notability:

“Article and list topics must be notable, or ‘worthy of notice’.”

A focus on notability means that articles on obscure topics, on little-known people, places, and things, are looked down upon, and deleted, by many Wikipedia editors.  Yet such articles are a big part of what I look for in Wikipedia.  In contrast to traditional, print encyclopedias (which I also love, by the way), I expect Wikipedia to give me access to the long tail of human knowledge–not just the most popular or noteworthy topics.

Some Wikipedia deletionists might say I should satisfy my hunger for obscure, factual information in other parts of the web, or in a specialized wiki geared toward a niche.  Yet I greatly prefer it when I can find such information directly in Wikipedia.  In contrast to information on the rest of the web, Wikipedia entries tend to have a consistent tone and layout, making them easier to navigate and process.  I know that the top part of the entry usually contains a helpful summary of the topic at hand, followed by a table of contents for the rest of the entry.  On the right near the top, there’s usually a box full of categorized facts, a box whose format tends to be consistent across articles of the same kind (such as countries of the world).  Near the bottom there is often a “see also”, “references”, “further reading”, and/or “external links” section, each of which is chock-full of helpful links.  Also, there is often a link to a Wikipedia list of items belonging to a category described by or related to the entry.  The main value Wikipedia provides to me lies in its wikification of information that’s available elsewhere, making it more readily accessible to me.  The deletion of articles on niche topics (or their exile to specialized, external knowledge bases) thus reduces Wikipedia’s value to me.

Some Wikipedia editors are concerned about the quality of entries on obscure topics.  I do care about quality, and want Wikipedia’s articles to be factual and well-written.  There may be some entries that may merit deletion or drastic editing.  However, I don’t see why a properly researched and well-written entry on a niche topic should be deleted.  Such entries don’t consume paper or inordinate bandwidth. They also don’t get in the way of the bulk of readers who aren’t interested in them and don’t care to look them up.  They will be missed, however, by those who are interested in their facts, those who wish that Wikipedia would remain a great starting point for inquiries into all sections of human knowledge.

How about you?  What do you desire from Wikipedia?

Basic ergonomics

Since most laptops’ screens are attached to the keyboard, I need to choose between either of two uncomfortable positions. If I place the laptop at elbow level, for comfortable typing, I need to bend my neck down to look at the screen. If I place the laptop on a stand for a comfortable viewing angle, I need to raise my arms to type. Barring the use of an external keyboard or screen, laptops force me to make this uncomfortable tradeoff.

The mouse

I much prefer using a mouse over a touch pad (or over the essentially-extinct pointing stick). Having a touch pad below the space bar on the keyboard is mildly annoying, but fortunately I can disable it and use an external mouse. I mildly dislike many users’ preference of a touchpad to the exclusion of a mouse, since that means I need to remember to bring my own mouse to plug in when providing them with tech support. A much greater annoyance stems from the placement of USB, audio, or power ports on various laptop models. If they’re placed on the right edge (and even worse, on the bottom, right-hand edge) they cause any cables I connect to obstruct the area through where I move my mouse. (A left-handed version of myself would likely complain about ports on the left edge.)

The keyboard

Probably the main reason why I’m significantly less comfortable using laptops has to do with the keyboard. I much prefer a desktop keyboard to a laptop keyboard. [1] I prefer the sturdy feel and action of full-height keys over that of the thin slivers of plastic on laptop keyboards. I like having a full set of keys and prefer the traditional location and arrangement of the arrow and navigation keys. Though I don’t use it as often, I also like having a numeric keypad. [2] I’ve also noticed that I much prefer typing on a cool or room-temperature keyboard than on the inevitably warm keyboard offered by a laptop. A warm keyboard feels a bit icky to my picky palms and fingers. Unfortunately, given current designs, a laptop’s keyboard can’t help but absorb the heat generated by the laptop’s internal electronics.

An additional, tactile consideration

For all their wonders, Mac laptops get a special mention for a particular annoyance. Current MacBook Air and MacBook Pro models have an anodized aluminum case. Its metal finish looks sleek and elegant… yet I really dislike its tactile feel. Yes, the keys on the keyboard are plastic (and pretty nice, actually) but the palm rest has an anodized aluminum surface–rough and uninviting to my palms. I don’t like how such an aluminum case feels in my hands or against my bare arm when I carry it, either. When I have to carry such a laptop, I prefer to move it as quickly as possible to its next resting place, or insert it into a case or sleeve for carrying. Older MacBooks with polycarbonate cases may not look as elegant but feel much better. If I ever own an aluminum-encased Mac laptop, I’d probably take steps to cover the aluminum with a more tactilely-appealing surface.

Price, performance, maintenance

I have also long preferred desktops due to price, performance, and maintenance considerations. An equivalent level of computing power has historically been cheaper to obtain in a desktop. Since components inside a desktop aren’t packed together as closely, they tend to last longer and perform more reliably. Also, it’s not as difficult to open, upgrade, or maintain a desktop. I’ve thus preferred desktops’ value propositions over laptops’. (My current impressions in this area are likely to become obsolete, though at present it’s a bit hard for me to imagine that hard drive and processor capacities and performance would ever become equivalent on desktops and laptops. I doubt that high-quality laptops would ever offer the same performance for the same price as high-quality desktops.)

Conclusion

For all the benefits I see in desktop computers, laptops’ portability is an extremely important feature, one that trumps other user-experience considerations for most users. The various design tradeoffs laptop makers have made in pursuit of portability are very reasonable and understandable. Yet I still haven’t found a laptop that would tempt me to give up my desktop. You probably won’t see me working on my computer at your local coffeehouse anytime soon.

Notes

[1] I actually use an ergonomic keyboard, which no laptop is ever likely to incorporate. In any case, even a standard, 104-key desktop keyboard beats a laptop keyboard hands down, in my opinion.

[2] I do wish a numeric keypad could be detached from the rest of the keyboard and placed elsewhere when not in use. For a right-hander like me, the keypad forces my mouse hand to travel much farther between the mouse and the letter keys. But that’s a topic for a different article.

I’ll call this kind of window “Opie” for the rest of this article.  Occasionally, a program will prompt a user not for a file, but for a folder.  In such cases programs will typically bring up the Folder Selection dialog window, which I’ll call “Dopey“:

Had I never known Opie, I might not dislike Dopey.  Since I do, however, I find Dopey to be a vastly inferior and annoying UI element, for several reasons:

1. Dopey can’t get to a folder directly.  Most of my files are nested four or five levels down from My Documents.  When I’m working on a project, I’ll typically have one or more of these level-4 folders open in Windows Explorer.  When I need to open one of these folders’ files from a Windows program [1], I’ll typically copy the folder path from Windows Explorer,  paste it into Opie’s “File Name” field, and press Enter.  Voilà, I’m now looking at the folder I want, and can select the file I need.  Dopey doesn’t let me cut and paste a path like this.  (Some programs complement Dopey with a field where a path can be typed or pasted, which helps a bit.  Most programs, however, leave you alone with the klutz.)

2. Dopey can leave me disoriented.  Dopey provides very little context to let me get my bearings inside the file system.  I often find myself looking at a list of neighboring subfolders, without any idea of who their parent is:

If I want to determine a folder’s parent, I’ll have to scroll a bit, and scroll quite a bit further if I need to determine its complete ancestry.  Once I determine the full path, I’ll have to scroll back to my original location (if I can find it).  Opie, on the other hand, lets me determine the full path (without getting lost in the process) by clicking on a drop-down arrow: [2]

3. Dopey makes me stumble my way down into the file system.  Navigating the file system with Dopey is cumbersome.  I start out with a little window displaying just a few folders.  I have to switch between clicking, scrolling vertically, and scrolling horizontally as I dig down into the file system.  With Opie, on the other hand, I can often get where I want  just by double clicking, often without any scrolling.  [3]

I’ve run into a few programs that show me Opie instead of Dopey when prompting for a folder.  I wish more Windows programs did this (hear ye, hear ye, Windows application developers!)  Ultimately, I hope (in vain?) that Dopey will be deprecated by Microsoft, banished from our UIs, and sent to join Clippy in exile.

 Notes:

[1] Yes, most files can be opened by double-clicking them in Windows Explorer.  However, I still find myself using File -> Open pretty frequently.  Somehow it’s more convenient than Explorer at times.

[2] For some programs in Windows 7, you don’t even a need to click a drop-down, since Opie looks just like Windows Explorer, and includes an address bar.

[3] This is due to the fact that Opie displays only a single level of subfolders at a time, and can display them in a multi-column list, which reduces the need to scroll or enlarge the dialog window.

I recently read “How to Safely Store a Password”, an article by Coda Hale. For years I’ve thought that salting and hashing passwords with MD5 or SHA-1 prior to storage was sufficient to thwart password-cracking efforts (in cases where the user-account database table is stolen or publicly divulged). Apparently, this approach is not much better than simply storing plaintext passwords (a practice widely scoffed at). It was fascinating to find out about a better approach, that of using bcrypt instead of ordinary hash functions. Unfortunately, it seems to me that bcrypt creates a new problem even as it solves an old one…

The New Problem

The use of bcrypt turns password-cracking into a computationally-prohibitive task for attackers. However, bcrypt also hurts defenders, for whom password-hash generation or verification is now much more expensive than with ordinary hash functions. A popular online service having thousands of users might need to acquire additional processing power simply to process user log-ins. Moreover, by using bcrypt a service would become more vulnerable to denial-of-service attacks. Attackers could tie up its servers’ CPUs through numerous, automated log-in attempts. (These would make the servers call bcrypt repeatedly, once for each of the many log-in requests.) Addressing this threat would seem to require problematic tradeoffs between security, cost and convenience.

Could there be a way of lowering a service’s computational bill while retaining bcrypt’s advantages? This article presents a system which might accomplish this. I haven’t heard of this approach and would like to know if I’m on to something (or if others have already devised equivalent systems). Be forewarned, I am not a computer-security expert. (Thank you for reading this article anyway.)

A Potential Solution

The following protocol attempts to reduce the frequency with which bcrypt is called by an online server. It ensures that clients also pay for the cost of using bcrypt. (The server still has to pay, but the client now has to “split” the computational bill with it. This could reduce the appeal and effectiveness of brute-force or dictionary attacks on live systems.) This protocol redesigns the account-creation, account-log-in, and password-reset processes for an online service.

Account Creation

1. Joe Turing, a user (or a bot, perhaps), visits the account-creation page for SecureR, a hypothetical (yet surprisingly-popular) online service.
2. Turing types in his desired username and password and submits them (securely) to SecureR.
3. The SecureR server creates a bcrypted hash from the password, using a random salt value and the cost parameter currently mandated by SecureR’s security policy.
4. The username, password, salt, cost, and bcrypted hash are stored in a record in SecureR’s user-account table. The record also includes at least two verification fields. One indicates whether the password hash has been verified (successfully computed by the client). The other indicates whether the account as a whole has been verified. Both fields are initially set to “false”.
5. SecureR sends the salt and cost parameters used to bcrypt Turing’s password back to Turing.
6. Turing (that is, his web browser) computes the bcrypt hash corresponding to his password and submits it to SecureR.
7. SecureR compares Turing’s hash with the hash previously computed by SecureR itself. If the two hashes match, the password-hash-verification field is set to “true”.
8. Once other essential checks (such as e-mail-address verification) have been successfully performed the account-verification field is to “true”. Turing’s account is now fully verified and active, and he can start using SecureR’s services. (For now I won’t suggest when and where additional verification steps should take place, since bcrypt is my focus here.)

Account Log-in

1. Turing types his username and password into the SecureR log-in page.
2. Turing’s browser sends his username to SecureR.
3. SecureR looks up the salt and cost parameters contained in Turing’s user-account record.
4. SecureR sends the salt and cost values to Turing’s browser.
5. The browser uses these parameters and Turing’s typed-in password to generate the bcrypt hash for Turing’s password.
6. The browser submits Turing’s username and bcrypted hash to SecureR.
7. SecureR directly compares the hash submitted by Turing with the one stored in his user record. If they match, account access is granted.

Password Reset

1. Turing types his username into SecureR’s password reset page and clicks the Submit button.
2. SecureR sends a verification link to Turing’s e-mail address. (This link is to verify that Turing himself initiated the reset process. This password-reset system never generates nor sends temporary passwords to the service’s users.)
3. Turing checks his e-mail, and opens up the link with his web browser.
4. The page brought up by the browser has a password field, into which Turing enters his new password and clicks on a Submit button.
5. The password is hashed and verified using a process analogous to steps 3 through 8 in the account-creation process.

Observations

According to this protocol, SecureR’s server only runs bcrypt when an account is created or when a password is reset. During log-in attempts, it is the client (Turing’s browser) and not the server which runs bcrypt. The server performs a computationally-inexpensive direct comparison between the client-submitted hash and the hash stored in its database. Thus the server avoids paying the bcrypt bill when processing a log-in request. (In theory, the client could also avoid calling bcrypt during log-ins. The bcrypt hash could be stored by the client after generating it during the account-creation phase. The client wouldn’t necessarily have to recompute the hash each time the user logs in. In practice, it’d be easier to design the client-side code so that it recomputes the bcrypt hash based on the user’s plaintext password, rather than dealing with hash storage and retrieval. The bcrypt-induced client-side log-in delay is tolerable to each individual user anyway.)

Relocating bcrypt invocations from a frequent process (account log-in) to other, less frequent processes (account-creation and password-resets) reduces the risk of a successful DoS attack. It doesn’t eliminate the risk completely, though. The account-creation and password-reset processes are the new weak spots, and must be hardened. This is why the password-reset process is more complex (and mildly annoying to legitimate users) under this protocol. Additional security methods (such as CAPTCHAs and rate-limiting) could also help harden the system against attack.

A Request for Feedback

My proposed protocol omits certain security-related details which would be important in a production system. I’ve also omitted some tweaks which could further improve the protocol’s security. However, I’d first like to make sure that this protocol is essentially sound. Please let me know if you find any logic errors or problematic side-effects I’ve failed to account for. As I said before, I am not a computer-security professional, and would appreciate assistance from others who are further along.

Sometime after watching this scene, I was struck by the realization that Facebook is like the island of the lotus-eaters to me.  I usually log in with a definite purpose in mind, such as looking up an old friend or confirming an invitation to an event.  However, immediately after logging in and before I know it, I find myself scanning through the News Feed, looking at random, yet interesting tidbits about friends and old-time acquaintances.  Many minutes will pass…  Once I finally realize what I’ve been doing and break out of the hypnotic effect, I’ll typically have forgotten why I initially logged in.  It takes me a couple of minutes to remember.

Facebook is not the only “island of the lotus-eaters”, but it is a very striking example.  The digital world is full of such islands.  It takes superhuman levels of self-discipline to stop landing on those islands or binging on lotuses.  Yet there are more important and substantial things, and I must resume my quest…

As happened with my inaugural article, strong sentiments drew out an article from me, this very night.  I’ll post it very soon.  Perhaps others will follow it…

As a nascent, independent, software entrepreneur, I’d like to share various ideas pertaining to software development.  My primary audience will be fellow coders.  However, laymen may be interested in my other articles, which will cover topics in software usability, IT, and digital culture in general.

I expect to post an article at least once a month, for starters.

If you’d like to receive an e-mail whenever I post an article, please e-mail me at andres@HashCollisions.com .  You can also subscribe to the RSS feed.

I’ll allow comments on this blog., but will review them prior to publication.  Here’s the RSS feed for the comments.

Before signing off, I’d like to thank several strangers.  They are talented software coder/writers whose respective blogs were a serendipitous find for me.  I’ve picked up other influences since then, but my first Fab Four will always be (in the order I met them) Joel, Eric, Paul, and Jeff.  Let’s see if I can make the most of not only your writing but also your coding advice.  Thank you.

Here we go…

P.S.  I know there’s not much on this blog for now, but how about if we get the comments rolling?  Fellow developers: who are your favorite coder/writers?  Who are your own Fab Four (or Fantastic Five, or Stupendous Six, or Superb Seven, etc.)?