Skip to content

Does Apple Have The Greenest Notebooks?

Infoworld poses the question but misses the point entirely.

My guess is if you measure the carbon footprint of notebook X against notebook Y — for manufacture, lifespan, and disposal — you’ll either see there’s a huge difference (where one notebook is from a manufacturer that simply doesn’t care) or they’ll be within a few percent of each other. It’s not like — in hardware terms — Apple has access to secret alien technology.

Unfortunately for PC manufacturers who aren’t Apple, the big difference will be when you divide that carbon footprint by (a) the productivity of that computer’s user multiplied by (b) the likely useful lifetime of that computer. Every study of these subjects (this blog entry links to a few, one of the more recent of many such studies discussed here) shows that Mac users are considerably more productive than their Windows-using counterparts, and that Macs remain in use far longer than Windows PCs (this isn’t hard to prove — check the resale prices for five year old Power Mac G4s on eBay, think you could sell a three year old PC for that much? OK search for Pentium 4 PCs… QED). Linux probably fares better than Windows on the second front, but unless “tinkering with the damn thing to try to get videos to play” counts as productivity, not so much on the first.

So while HP, Dell, Lenovo, Sony, Toshiba, ASUStek, Acer et al can try to argue that their latest boxen are 2% more efficiently built than the latest Macbook Pro, they’ll lose out big time (for now and the foreseeable future) on the denominator.

gile[s] is now freeware

Back in the dark (pun intended!) days before Cheetah 3D added lightmapping support, perhaps the best lightmapping tool for indie game developers was a program written in BlitzBasic or Blitz3D (not sure which) called gile[s]. (I don’t know about the [s] bit, but I guess it looks cool or something.) If you don’t know what lightmapping is, or you’re past that now (most modern console games have real-time shadows) then you won’t care, but if you’re interested, you can get gile[s] here.

Meanwhile, the developer of gile[s] has been working on a rather impressive little game called Youropa, which appears to be built around gravity and other physics fun. Worth a look when it comes out, I think. If nothing else, it’s beautiful. More Youropa screen shots and videos here.

The Video Tag

Firefox 3.5 is out, and, among a slew of major improvements, it now supports the HTML 5 <audio> and <video> tags. I don’t post many video clips to Daring Fireball, but henceforth, when I do, it’ll be with the <video> tag. IE users can suck it.

John Gruber, Daringfireball

I couldn’t agree more. It would be especially nice if the <video> tag were to support FLV, (a) eliminating the need for idiotically customized FLV players, and (b) Flash.

Upgrade your web browser to Firefox 3.5 or Safari 4 or better to watch this video.

Do you see a video above? If not, the video tag on your browser isn’t fully supported (at least for QuickTime).

There’s just one problem: Gecko (i.e. Firefox’s HTML engine) only currently supports .ogg containers, which is about as useful as, er, something that isn’t useful. It doesn’t even support H264 or MP4v.

Secure over http

So I implemented my ideas for secure login over http. Here’s the actual client-side code:

function(){
	$.getJSON(
		edu.ua.lib.inferRelative('./u/logon/' + document.log_on.name.value + '/'
		+ MD5( edu.ua.lib.salt + MD5(document.log_on.password.value) ) ),
		function(data){
			if( data.error != '0' ){
				$('#log_on_feedback').slideDown( 1000 ).text('Log on FAILED');
			} else {
				$('#log_on_feedback').slideUp( 1000 );
				$('#logged_on_as').text('Logged on as ' + data.user);
				$('#log_on_ui').slideUp( 1000 );
				$('#log_off_ui').slideDown( 1000 );
				if( data.admin == 'yes' ){
					$('#admin_menu').slideDown( 1000 );
				} else {
					$('#admin_menu').hide();
				}
			}
		}
	);
}

The dependencies are jQuery 1.3+ and an MD5 function written in JavaScript (of which I found several). Note that the code above implements an AJAX (well AJAjson) login with in-page feedback and modeless UI rebuild after successful login. It could be even simpler. Of the code above, exactly one line handles the security portion, the rest is UI. Also note that the server-side is even simpler, since it doesn’t do any UI stuff. The key bit is:

$user = $db->simple_search('user', 'name', strtolower($params[2]));

if( count( $user ) != 1 ){
	echo $bad_login_attempt; // always give identical feedback for failed attempts
} elseif( md5( $_SESSION['salt'] . $user[0]['password_hash'] ) == $params[3] ){
	$_SESSION['logged_in'] = true;
	... // snip highly specific stuff
} else {
	echo $bad_login_attempt;
}

The server provides the same feedback for all failure modes, and generates a random salt per session which is included inside the master JavaScript object (edu.ua.lib) which handles the UI (it’s probably not a very good random salt, but this isn’t intended or expected to stop the NSA).

Web Site Design Advice That Sucks: Cleartext Passwords

Most websites (and many other applications) mask passwords as users type them, and thereby theoretically prevent miscreants from looking over users’ shoulders. Of course, a truly skilled criminal can simply look at the keyboard and note which keys are being pressed. So, password masking doesn’t even protect fully against snoopers.

More importantly, there’s usually nobody looking over your shoulder when you log in to a website. It’s just you, sitting all alone in your office, suffering reduced usability to protect against a non-issue.

Jakob Nielsen, Stop Password Masking

I started but didn’t finish a post along almost the opposite line a few weeks back after playing around with one of my digital cameras for a while. What happened was I noticed that it was very easy to photograph a computer screen from a significant distance with an inexpensive digital camera and read the display without the slightest problem. (It started when I realized that I could read a stranger’s computer screen perfectly in a photo I had taken of my children on a plane trip.)

This could be your password!

This could be your password!

A recent Scientific  American article points out that security researchers have been doing things like reading screens using cheap telescopes from hundreds of feet away (the distance between nearby office buildings in New York, say), or magnifying reflected images in users’ eyeballs (something I actually predicted about twenty-five years ago in my old science fiction setting).

Of course, users usually aren’t being watched, but simple security isn’t for the usual case. Sure, leave your front door open, burglars usually aren’t wandering through your neighborhood. Displaying cleartext passwords is just asking for it since snapping a high resolution still photo is ridiculously more easy than filming a user’s keystrokes or packet sniffing. In Nielsen’s world, I could sit in any Starbucks and collect dozens of userids and passwords over coffee. What’s worse, as each happy notebook user tried out their three favorite hard-to-remember passwords I’d be able to collect information which would let me break into multiple accounts.

Of course this would never happen, because users would probably shy away from the lack of perceived security on any sites taking Nielsen’s bad advice. In this case, they’d be absolutely right.

A huge problem with Nielsen’s argument is that the usability angle is virtually irrelevant (most people type passwords from muscle memory and don’t rely on visual feedback) and the use-case is wrong (entering passwords is a common operation which people can remember how to do, not an obscure operation people need help remembering).

Now, Nielsen’s observations are based on observing usability tests of mobile devices accessing password-protected sites, and I have no doubt the observations are valid. But herein lies the problem with usability testing — it may show you a problem, but it doesn’t show you the solution. Go do a real test of Nielsen’s “solution” and see what really happens. I have no doubt entering a password in a cleartext field is easier, but the downstream costs aren’t part of the test.

Gruber’s point (in providing the link) is well-taken:

The iPhone strikes an interesting middle ground here — it shows you each letter you’ve typed in a password field for a second or so before turning it into a bullet.

John Gruber, Daringfireball

The iPhone solution is excellent because it doesn’t open up any new security hole (filming an iPhone user’s password is exactly as hard as filming someone typing). Nielsen’s proposed solution opens you up to having your passwords recorded by random security cameras being watched by random guys many of whom aren’t earning much more than minimum wage and who are really bored.

Nielsen proposes a checkbox to mask password entry for insecure situations. Great. So we’re making a technically simple gizmo more complex in the interest of reducing security. Please, if you’re going to add a bunch of JavaScript to make your password entry field work better, use it to make your logins secure over http. How many people will remember to click the “mask” checkbox, or inadvertently type cleartext passwords before they realize what’s going on?

The only really relevant use-case where seeing your password improves usability is when you’re entering a new password for a new account, and even then Nielsen’s argument fails — having visual feedback when entering and confirming a password would encourage users to invent new passwords they have virtually no hope of remembering, which in turn would lead to more “security questions” and “mail my password to me” garbage which is where the really huge security holes lie.

So, in summary, in this particular case Nielsen is wrong, and not even wrong in a useful way. He’s wrong on the following counts:

  • The usual failure mode for logging in is not mistyping but failing to remember a password.
  • Cleartext passwords would encourage users to choose a larger number of harder-to-remember passwords, increasing the primary problem people actually have logging in to websites.
  • Cleartext passwords are a gaping security hole
  • Even if Nielsen were right in theory, any website taking his advice would lose customers owing to a perceived lack of security

So the cost is far greater than Nielsen suggests and the benefits either negligible or illusory. And you’ll lose customers.

Next, let’s get rid of smoke detectors. They’re a pain to install, and make annoying high-pitched squealing noises when their batteries run down. And buildings usually don’t catch fire.