Your hardware has changed significantly since first install, it informs me, so you have to re-activate Windows. Would you like to do so now?

Sure, I installed some new devices…but they were virtual devices.

I just bought a new, larger hard drive, and today I installed it in my desktop computer. I bought this computer from NCIX and, in a moment of pure indulgent laziness, paid them to assemble it for me rather than assembling it myself. Today I had to open it and move things around—and oh, but my earlier laziness came back to bite me in the ass.

The case has two 3.5" drive cages. In spite of the case manual’s suggestion that one use the lower cage “for optimal cooling and noise reduction” (or something to that effect), both pre-installed drives were in the upper cage, which sits directly in front of the video card. By “directly” I mean that they were so close that the power cord of the lower drive was physically touching the card. By “physically touching” I mean that it was, in fact, blocked by the card, so that I had to remove the video card to unplug the drive. To remove the video card, I had to unplug the system power cord. …And so on.

And of course all the cords were zip-tied together so tightly that the drive cage could not be removed without unplugging the drives, and the lower cage could not be reached without cutting numerous zip ties. And no power connectors were left for expansions, so I had to dig through boxes to find spares; ditto SATA connectors. As a bonus, the upper and lower drive cages use different attachment systems (the upper cage has drive bays, the lower does not), and the necessary screws were of an unusual type, so I had to find those too (this one isn’t the installing tech’s fault, though).

I have never spent so much time just physically installing a hard drive, but on the bright side, I expect that moving all the drives to the lower bay will significantly improve system cooling (since the hard drives were between the front air intake and the video card, sigh), and the case could use the cleaning it got; it was a mite dusty, if you’ll pardon the pun.

Now, of course, grub reports an error, presumably because the drive order has changed, or something (the BIOS setup correctly reports all three HDDs). I don’t know, and I lack the energy to work at it tonight. Hopefully tomorrow night will be a quick fix to get the system running rather than something horribly wrong.

If you loathe the Adobe Acrobat reader half as much as I do, you might be happy to learn that Evince, the standard PDF reader for the GNOME platform, now has a Windows version (get it here). I have not used this Windows version myself, but expect good things. (This latest version of Evince also added support for the one feature I was missing: Displaying annotations.)

Evince is what made me stop hating PDF documents—it does nothing fancy, but displays PDF (and Postscript) documents cleanly, quickly and efficiently. Searching for text in a document resembles, well, searching for text in a text document rather than asking your computer to reindex all its documents while attempting to compute a cure for all cancers, or whatever Adobe make their reader do to slow it down to the startling degree I have come to expect. (If—if—this sounds like an exaggeration, it’s because (1) the Adobe reader for Linux is even worse than the Windows version, and/or (2) they have improved the Windows version since I last used it, reversing a long-standing tradition of adding more and more features that nobody uses except your CPU.)

More seriously and less sarcastically, Evince was the first application that really struck me with a “less is more” sort of beauty—an object lesson in UI design, if you will. It’s there to do one thing: Let me view PDF and Postscript files. It has almost no buttons, options, switches, or fiddly bits. And yet, in its stark simplicity, it was so vastly superior to the obvious alternative that it made me view PDFs as a good format for portable documents rather than a plague upon the internet.

I recently decided to try SpiderOak to backup documents that are either too large, or too sensitive to conveniently keep in my subversion repository. I signed up for one month at a cost of $10 to get 100 GiB of space. They offer 2 GiB completely free, and I can highly recommend this for storing smaller amounts of data (I would, except that I have, use, and like subversion for this).

Initial impressions: No problems with the packages¹ or UI. I can only assume that the Windows and Mac versions are identically smooth (with most products, after all, Linux gets the least attention and support). I had some issues where my upload speed would slow to a crawl, then a halt…but I think this is more due to Shaw, whether because the cable network gets overloaded at certain times of day, or because they throttle my connection.² However, this was not immediately obvious, so I asked SpiderOak tech support, just in case. Their response was prompt, friendly, and voiced in a way that didn’t seem to assume I’m an idiot (I’m very sensitive to perceived condescension). Thus, while SpiderOak’s support didn’t solve a problem for me, because there almost certainly was none on their part, their response seemed promising: Based on preliminary data, I like their customer support.

So far, I’ve backed up about 9 GiB of data. Of course, uploading this on a cable connection with a maximum of 0.5 Mbps upload rate, it’s rather painfully slow, but once I have the data uploaded, I won’t have to repeat it… Unlike services like DropBox, SpiderOak lets me specify which directories I want to upload (and exclude subdirectories, if I so desire), so I can keep my files organised how I want them. It also turns out to be trivial to synchronise files between different computers. Their FAQ has all the details. It’s as simple as it sounds, and probably simpler.

As you can probably tell, I’m very happy with the service so far, though I’ve only used it for a few days yet. It’s quick (except for my upload speed…), easy, and I like their security model a very great deal. Based on my limited experience, I would recommend it—especially to those among you who don’t currently have an online backup service. Why not? You can get 2 GiB of safe, automatic backup for free! And if you need more (as I do), $10 a month or $100 a year gets you 100 GiB, while most other services I’ve found charges the same for only 50 GiB of space.

Again, of course, if you decide to sign up, use my referral link and give me some extra space for free…

¹ When I installed it on Ubuntu Karmic, there was no “Ubuntu Karmic” package, but the Jaunty package worked fine. A few days later, a Karmic package was available—this was within perhaps a week of the initial Karmic release, mind. I believe the package was actually the same, though of course it’s reassuring to click a link with the correct legend.

² My solution? I’m switching to TekSavvy, who offer twice the upload speed and about the same download speed at a similar price, never throttle anything, are less likely as an ADSL provider to suffer congestion than cable, and are champions of net neutrality and deserve my money more than Shaw does. On the very remote chance that my upload issue was SpiderOak’s fault rather than Shaw’s, I expect I’ll be happy with TekSavvy. (On the very, very remote chance that I’m not, I’ll just switch back.)

After downloading this morning’s find, my first thought was I must never lose this!—so I spent some time thinking about backup strategies.

Most of my data are backed up by shoving them into a subversion repository containing most of my home directory. This is a techy, nerdy way of doing things that works very well for some data, and gives me the ability to perform very sophisticated change tracking.

It works rather poorly for some data, though. In particular, it’s not ideal for storing large sets of binary data…like an 8.1 GiB repository of scanned books [embedded] in PDF format (or like music, or video files). It also has another weakness, not intrinsic to the mechanism but significant in my usage: Because my subversion repository is housed on the same server and server account as my websites, I’m not 100% comfortable uploading very sensitive data. It’s a shared server (although I have of course disabled read permissions for other users), and it runs, with my user priveleges, my own webapps—which are of course no more secure than I made them.

So I decided it was finally time to look into alternative backup strategies. I’m quite happy with subversion for e.g. text files that I modify, my projects’ source code, and so forth, but for photos, videos, music, and large downloaded collections of RPG supplements that I’ll never edit anyway, I want something else. Having heard the name bandied about, I of course looked into DropBox, which looks quite OK. I did spend some extra time looking around, though, and came across a DropBox competitor I had not heard of: SpiderOak.

Both DropBox and SpiderOak offers a free 2 GiB storage account with paid upgrades to 50 GiB or more. Both offer secure, encrypted transport, synchronisation between multiple computers, etc. However, SpiderOak offers a few features that DropBox does not, some of which are quite interesting.

• Sharing data in place rather than having to stick them in a dedicated directory; I can backup my documents directory, for instance, instead of having to create and use .DropBox/documents.
• “Zero knowledge” security means that data are stored encrypted, and SpiderOak does not store my password. This is fantastic and wonderful (though it does come with the caveat that if my password is lost, it cannot be retrieved). No matter what I upload, encrypted transport means that no one can eavesdrop on it, and encryption means that no one, not even SpiderOak employees, can get at it. I can be as comfortable storing even very sensitive data, like passwords and personal information, in SpiderOak as I can on my local computer (however comfortable you think I should be with that).
• Extra storage at half the price is a pretty obvious advantage. $10/month gets me 50 GiB at DropBox or 100 GiB at SpiderOak.

Client software is available for Linux, Windows, and OS X, so you can share data across platforms. (This is also true of DropBox, of course.) Unlike DropBox, much (though not all) of the client software is open source, and SpiderOak claims that they are moving towards a full OSS client. (They’ve already shared some code.)

On paper, then, SpiderOak is about as close to perfect as it can get for my needs. What remains to be seen is just how smooth and seamless the experience turns out to be when I start using it (it has a reputation in some parts for being a bit of a resource hog; to me, that sounds like a small price). If it’s as good as I’m hoping, I will recommend it to everyone I know.

If this convinces you to sign up, please use this referral link to give me some bonus space in return for my time writing this up. (Pretty please?)

From this story, Strong Passwords Not As Good As You Think, by some commenter called Rob the Bold:

According to the article (cited by the citation):"Users are frequently reminded of the risks: the popular press often reports on the dangers of ïnancial fraud and identity theft, and most ïnancial institutions have security sections on their web-sites which oïer advice on detecting fraud and good password practices. As to password practices traditionally users have been advised to . . . "

-Choose strong passwords

-Change their passwords frequently

-Never write their passwords down

I would suggest that this is a case for the popular quip: "Pick two".

Personally, I can’t be arsed to change passwords frequently, which makes unique passwords all the more important: Since I rarely change them, I need to make sure that if somebody steals all the passwords from site A, that doesn’t compromise my accounts on sites B through Z. Have I plugged SuperGenPass lately?

Since I’m on a security spree, finally getting my arse in gear to do what I should have been doing for a long time, I decided to also generate a new PGP key that actually matches my current email address and perhaps (wonder of wonders) actually sign email by default. I may or may not bother about encryption; it’s certainly a nice-to-have, but I’m trying to ease into good habits, and I want to read up more on backing up public keys¹.

What this means is that I am curious about what mail client you use, because people reading this post comprise a pretty hefty chunk of all the people whom I want to be able to read my mail. Since some mail clients (notably Microsoft clients) are a bit iffy when it comes to features like PGP/MIME, from what I’m told, it would be very nice to know what I can rely on recipients being able to receive…

What mail client do you use?

…And by you I mean all of you, so please at least take the time to read and think about this. Don’t worry if there are a few technical bits thrown in here and there; the message should be quite clear.

I have been putting off securing my data for much longer than I really should have. I am not, by nature, a paranoid person, and when it comes to high-powered encryption solutions, I agree with Randall Munroe of xkcd. I don’t need 4096-bit encryption, I am not going to worry about forensic analysis…I do not live in Iran. Someone said, and I agree, that

Alltogether, encryption of /home and /tmp prevents someone to access your private data by just using a Live-CD with your computer.

I consider something secure, when the effort to bypass or break it exceeds the benefit you get from breaking it.

But I do care enough that I want my data encrypted, and you should too—especially if any of the following applies to you:

• You use a laptop. A user account password prevents somebody from just logging in as you, and is of course a must-have, but account passwords won’t help you at all if your laptop gets stolen, because all anyone needs to grab all your data is a rescue or install disk.
• You use your browser, mail client, etc., to save your typed-in passwords or logged-in sessions.
• You use only a small set of passwords, so that having one password compromised impacts you in many places. Actually, if you do, read this and start using SuperGenPass.

As it happens, all of the above apply to me, and I know the risks full well, so it’s hard to justify the fact that I have gone so long without encrypting my data. In all honesty, it’s sheer laziness. At least I am catching up now…

The biggest danger is that if you have a laptop and it gets stolen, somebody could use a combination of saved passwords and password reset mechanisms—after all, they have access to your email account!—to break into virtually any service you have electronic access to. This is not just about somebody reading your private letters (bad enough); this is about somebody able to use any electronic service you can use, possibly with the exception of your bank if their security model is good. Of course, this applies to desktop computers as well, in case of burglaries, but I consider the likelihood of a break-in to be much lower than the risk of somebody grabbing my laptop off a café table while I have my back turned, or somebody stealing my backpack, laptop and all.

I will reiterate something Jeff Atwood said, because it’s important:

1. Number one with a bullet: your email account is a de-facto master password for your online identity. Most -- if not all -- of your online accounts are secured through your email. Remember all those "forgot password" and "forgot account" links? Guess where they ultimately resolve to? If someone controls your email account, they have nearly unlimited access to every online identity you own across every website you visit.

2. If you're anything like me, your email is a treasure trove of highly sensitive financial and personal information. Consider all the email notifications you get in today's highly interconnected web world. It's like a one-stop-shop for comprehensive and systematic identity theft.

I’m not here to tell you how to encrypt your data, because I don’t know how to do it in Windows and I don’t know how to do it on a Mac. (I’m told, in the latter case, that it is easy.) I am here to tell you that you should encrypt your data! —And if you choose not to, be aware of the risks.

One thing should be added: If you encrypt your data, backups are critical. Of course, backups are always important; I would hate to lose years of work, correspondence, important data, tax files, and so on, due to a hard drive failure—or, say, an apartment fire that destroys both my computers, which is quite bad enough without data loss on top of it.

But with encryption, it’s even more important. If a regular, unencrypted file system gets damaged (software error, crappy old hard drive, …), your OS can probably cope with this and recover pretty much everything you care about, because the on-disk format is well known and understood. Encryption throws a $5 wrench into the works here, by making the on-disk format extremely obscure: That’s the whole point, after all. This means that if your encrypted file system gets damaged, there’s a significantly higher risk that all your data become unreadable. (For example, if you use Linux/LUKS, like I do, and the metadata sectuin containing the master key gets damaged, the partition is lost.)

I didn’t think twice about this, because I have a reasonably solid backup strategy in place (everything I care enough about is synchronised with a remote server). If you want to encrypt your data but don’t have a backup solution in place, though, you should come up with one first.

If you’re using Linux, you should set up encryption when you install it. (Well, you should do this regardless of your OS, but this is a Linux-centric section.) With Ubuntu, it seems extremely easy, but I wasn’t thinking about it when I got my new laptop (I was too excited about a new toy, and having a laptop I could actually use), so I had to convert to an encrypted system after the fact.

Most importantly, I am encrypting my /home partition, where all my data reside, using LUKS (referring to this guide). I consider this by far the most important part—it’s where all my data reside, all my cached passwords could be stolen, all my email is backed up. It was not at all difficult—the only problematic part is that I needed to move the data aside in order to encrypt the partition (I don’t know of a way to encrypt it in place). For this reason, I have yet to do this on my desktop computer: I have no partition large enough to hold all the data!

I also encrypted my /tmp and swap partitions, where temporary data are kept, because cached passwords, sessions, etc., could potentially be retrieved from thence (here, I used this guide). Because they are (or can be) cleared on reboot, I opted for the recommended solution of using /dev/urandom as the key file: The password is randomly generated on boot, different every time, and thus pretty damned secure. I am told I should also encrypt /var/tmp, which is a bit trickier, because I don’t want to have to type in two LUKS keywords on boot. How important is it to encrypt /var/tmp? I gather KDE caches data there, but I do not use KDE. I suppose I may generate a keyfile and store it on the encrypted /home partition, or hell, even symlink it to a /home/cryptovar directory—on rare occasions when /home is not available, I don’t imagine I’ll care much about missing /var/tmp! Thoughts?

I could use some help.

I’m pretty bad at password management. I don’t have a great memory for complicated strings of random characters—in fact I don’t have a great memory at all. In very rough terms, I use a set of passwords like

1. A secure “standard” password for sites and services I trust (with some minor variations)
2. A modified, more complicated version of the above for root passwords etc.
3. A different password for desktop and laptop user login (…these should be different)
4. My old “standard” password, now demoted to use on sites I don’t really trust to store my password securely
5. A throw-away password (this one’s actually a dictionary word!) for untrusted services where I don’t care if they get hacked but where I need a password to use them

This is a hell of a lot better than using “p4ssw0rd” for a password wherever I go, but I do knowingly commit a mistake shared by many: I reuse passwords all over the place, and while I try to make a rough judgement call (do the people running this site seem like the sort to store my password securely hashed and salted, or in a reversible form, or even [shudder] in plaintext?), that’s a very fallible call to make. Also, and this is very bad, I often let my browser save my passwords. That’s very dangerous. It’s a product of sheer laziness.

Of course there are lots and lots of password managers designed to create and manage sets of better passwords—there are ones for Windows, ones for Linux, ones for Mac, and a fair number of cross-platform managers. But from my point of view these all share a number of weaknesses:

• I need to install an application on any computer where I wish to use these passwords.
• The application needs to be cross-platform and have good usability on at least Linux and Windows.
• Most of the time I don’t worry about programs going out of vogue or dying—by the time a project dies in the Linux world, I’ll have long since moved to another—but a password manager needs staying power, because I can’t afford to lose all my passwords.

SuperGenPass is the best password manager idea I’ve ever seen. If you’re a non-technical reader, the best advice I can give you is “go here and install it”.

For the slightly more technical reader, here’s why I like the idea so much:

1. It’s implemented in Javascript and runs as a browser plugin. The web is where I should use a profusion of passwords, so this is where I need quick, easy access. And it certainly looks easy: Type in your master password, click the “SuperGenPass” bookmarklet button, and voilà!
2. It uses a hash of your master password and the domain name for a password, so every domain gets a unique password.
3. Because each domain gets a unique password, it’s relatively safe to let your browser save the passwords. The usual vulnerability inherent in saved passwords is there, of course, but you only compromise one site at a time—never the master password.
4. If the next version of your browser breaks compatibility with the plugin, the mobile version will let you retrieve your passwords. It’s a single, plain page with embedded Javascript. I can save it on my harddrive for easy password retrieval.

I can only see two obvious security caveats, one of which is easily negotiated, one of which looks like a fundamental and inevitable limitation of the design (and of its laudable goal of user friendliness). First, the fixable one:

SuperGenPass also provides some degree of phishing protection. Suppose you receive a phishing attack—for example, an e-mail that purports to be from Amazon but is actually from a malicious hacker trying to steal your password. It sends you to a page that’s set up to look like Amazon.com and has a similar URL (say, “www.amaz0n.com”), and includes a login form. Using SuperGenPass at this malicious Web site with your master password (“cornflakes”), your generated password is “uc15yrcmqI”. Compare with the previous example: though the master password is the same and the domain name is only slightly different, SuperGenPass generates a completely different password. Even if you are fooled by the phishing attack and attempt to log in to the impostor website, you haven’t sent your real password.

That’s fine, as far as it goes, but nothing prevents the website from harvesting your master password from the password <input/> before it’s hashed, and saving it via AJAX. If they know that you’re using SuperGenPass, they can then use your master password to generate all your other passwords. That sounds alarming, but I don’t think the odds of falling victim to this very specific phishing attack are very high. Additionally, there is an easy workaround for this: You can add a salt to the bookmarklet, which is not entered into anybody’s <input/>.

The second problem is that the algorithm uses the domain name as a salt for the hash…and that’s a pretty weak salt if a determined attacker wants to use something like a rainbow table attack: The salt is known. By design, SuperGenPass cannot use nonce values (it would compromise its excellent portability). Nor does the extra salt mentioned above help you here; it’s just part of your master password. (The hacker would crack your password+salt, not just your password.) If you are worried about somebody stealing your password and running that sort of thing on it, well, you’ll want to use more than one password. It never can hurt to use a separate password for extremely important sites, such as banking and email. (Yes, email should be considered extremely important: As Jeff Atwood has pointed out, anyone who hacks into your email can gain access to almost any other service you use by using the password reset function.)

But if these are weaknesses of SuperGenPass’s security, it is still a vast improvement on using only one or a small set of passwords. If I install this and reset a few passwords, I can use the same master passwords as I do now and gain a unique password for every site I use; even in the worst-case scenario of somebody running a rainbow table attack on my passwords (and why would anyone want my data that badly?), the worst-case scenario is gaining access to one of my master passwords. Right now, when for all I know some forum could be storing that password in plaintext, the barrier of entry is abysmally low.

There’s a new Mozilla project to bring multi-process support to the Gecko family.

1. Why is this good?

   Multi-process applications are better than threaded applications in some ways. Context-switching is more expensive, but in some ways they may actually scale better because the contexts are completely different and there’s a lot less shared memory to compete for. The fewer threads you run, the fewer mutexes you need to write and the fewer race conditions, deadlocks, or just plain threads wasting time waiting on locks you get.

   More importantly, it’s a lot more stable because applications crash one process at a time. Run your entire browser in several threads within one process, and if one thread dies—say, because a plugin or extension has a problem, or some bad script gives it a seizure—your browser is dead. This is notably a problem with Adobe’s Flash plugin, which not infrequently kills Firefox.

2. Why not just run Google Chrome?

   Well, for starters, Google hasn’t got around to releasing a Linux port of Chrome yet… Seriously, though, by the time Firefox is ready for multi-process mode, odds are pretty high that they will have, but competition is good; in my ideal world the web would run on a set of several modern browsers (no IE6 legacy shit!), all of which hold too big of a market share to be ignored. This would force people to follow standards. I don’t like Microsoft’s IE monopoly, but I wouldn’t like Google’s Chrome monopoly, either. I like Google, but they are scary big.

   Besides, I like Firefox, and it has other features or projects that I wouldn’t give up even for multi-process browsing. Weave is an example—I’m loving it.

A bit of a weird and frustrating problem, but I love this stuff, deep down. It’s interesting.

Since I’m rewriting the framework behind my website, and since the new framework has a lot more dynamic features to go with some other projects of mine (petterhaggholm.net is pretty static), security has been on my mind, especially as I will have a login system. Of course I started with the basics: Require a session token for every action; make sure the session token is nice and secure (it’s a big hash involving a random number); make the cookies HttpOnly… (HttpOnly cookies can’t be read or set with Javascript, so malicious scripts cannot steal these cookies. They are only present in request headers.)

The problem

CSRF means that cookies alone aren’t safe, however. If you write this sort of code and don’t know what CSRFs are, I recommend you read this very good article. The very brief version of a simple example:

• Whenever you request a resource (e.g. via GET or POST, your browser checks if it has servers matching the server.
• If the browser has any such cookies cached, it sends them in the request header (Cookie: whatever).
• Not only pages are requested via GET; other resources, like images, are as well.
• The browser doesn’t keep track of what tab or window the request comes from. (I’d be annoyed if it did, since I’d lose my session data if I opened the same site in a second tab, or closed and re-opened.)

Now suppose that your webapp has an action tied to a GET request (you shouldn’t), or is a PHP app that uses the $_REQUEST superglobal without checking if it is GET or POST. Maybe there’s a Delete button on a form that works by making an AJAX call (or plain form submission) to foopage.php?action=delete. What happens if I, on some entirely different website, create a page as such:

<img src="http://www.yoursite.com/images/pretty.jpg" title="A pretty picture" />
<img src="http://www.yoursite.com/foopage.php?action=delete" title="Another pretty picture" />

Well, your browser will parse the page source, and will issue a GET request for each image src in order to display all the picture. The Cookie: header will be issued with each request, because your browser will always issue that header when the request goes to the matching domain. This means that if the webapp relies solely on the cookie for authentication, it will think that you are issuing a delete command, and will happily go ahead and do whatever it is that deletion does.

My problem with the usual solution

There is a canonical solution to this problem. (Always using POST rather than GET isn’t it—that’s a good idea, but POST requests can be forged, too.) This solution is to include a unique token in every form on generated pages; so if you request a form from secureapp.com, it might contain something like

<input type="hidden" name="secure_token" value="384729348923498" />

Ideally, this token should

1. Be unique to this form
2. Expire in a reasonable amount of time

The advantage of this is that because this is embedded in the page, and not present in the headers, a request issued from a different page (such as with the XSRF attack described above), the information just isn’t available.

But that’s kind of a drag. For example, what if my page uses AJAX and doesn’t contain any forms? What if I have multiple tabs or windows open with the same site (as I often do, with many sites)?

I currently strike something of a compromise: A session has one such token (which isn’t nearly as good as unique tokens all over the place, but much better than none at all: It protects me against the simple cookie-based attack). I am currently working on a mechanism to generate better tokens when there are forms on the pages, but the simple token is used by default, and will probably continue to be used for AJAX requests that just don’t have forms to reference. My framework discards all POST data supplied by requests that have either a bad session key or a mismatched or missing “XSRF token”. GET variables are never used as “data”, but only as extra resource identifiers, e.g. picture.py?pic=foo.jpg.

But a single token does have serious weaknesses. If the attacker can retrieve even one page with the token embedded (e.g. via a malicious script that issues a GET request on the client’s behalf, or by stealing it from the cache, or some means that I have yet to take into consideration), the token is compromised, and we have already established that cookies are vulnerable.

An alternative?

One fairly obvious idea that occurs to me is that while it’s easy to hijack (but not steal!) cookies, and may be possible to steal the token, the information is not available simultaneously. The cookie is not visible to the attacker: This XSRF attack is based on the fact that he can make use of the cookie by tricking the client into issuing a request that will have the cookie attached, without the attacker ever needing to access it. By contrast, the token is jeopardised precisely because the attacker may see it. What I would like to do is combine the two, e.g. by requesting a hash of the cookie value and the token value.

It’s actually somewhat ironic: Normally, it is a truism in computer security that you cannot increase security by adding more data if all those data are vulnerable. Here, however, the data are vulnerable by different avenues, and what I want to do is raise the barrier by requiring an attacker to exploit both simultaneously.

Unfortunately, this idea isn’t workable in so simple a fashion, because, well, I made my cookies HttpOnly! This means I can’t use them to create hashes, no matter how nice it would be. In essence, what I want is a browser feature that doesn’t exist, where I can request a secure, one-way hash based on an otherwise unreadable cookie:

<input type="hidden" value="2487923984" hashwith="my_httponly_cookie" />

I think what I may do is set two cookies for my sessions: The primary session identifier, which remains HttpOnly to prevent anyone from stealing it; and a token cookie, included specifically for use by the page’s Javascript, AJAX requests, etc.

Internet security is a tricky and thorny issue. I find it difficult to know when I am tackling the real issues, and when I am just engaging in busywork. An awful lot of my promising ideas have turned out to be dead ends that either wouldn’t work at all (c.f. the hash above), aren’t at all secure, or just don’t add anything to the security I already have.

Thoughts?

Do any of you guys know much about Apache and mod_rewrite? I could use some help.

Update: Chutz asked me the rather obvious question, had I tried turning off all the RewriteConds? The rather sad answer is that no, I’d missed that obvious debugging step. When I did, the RewriteRules worked… With a bit of help from a very high log level, it turned out that while mod_rewrite applies the RewriteBase to the URI (here, truncating the directory) when applying the rule, it does not apply the RewriteBase when matching against a RewriteCond. Thus, the solution is to write my rules as below, but to insert the directory name—the same directory name as the RewriteBase!—in the matching rules, e.g. ^/newsite/\w+.

I’m playing around with some stuff (on my local box, so far, though I’ll be replicating it at Webfaction…if I can get the damned thing to work) with a dynamic website that uses mod_rewrite to take extensionless URIs and turn them into script invocations (mod_wsgi, as it happens, moving away from the largely-deprecated mod_python). This works beautifully when I only have one site. Now, however, I want to have two sites in different <Directory> sections in the same <VirtualHost>, and things aren’t working so smoothly. In fact, as soon as I change my DocumentRoot to something other than the path of the <Directory> the RewriteRules seem to stop working, even without adding a second <Directory> section.

All I get for every request in the mod_rewrite log is a notification that it passed through:

(In the Apache error.log, of course, I get the expected error messages about requests for resources that can’t be found.) I’ve tried to add an appropriate RewriteBase, but so far to no avail. My current setup looks like this, and doesn’t work:

Listen 80
LogLevel info
LoadModule wsgi_module /usr/lib64/apache2/modules/mod_wsgi.so

WSGIPythonPath /home/petter/projects/newsite:/home/petter/projects

NameVirtualHost 127.0.0.1:80
<VirtualHost 127.0.0.1:80>
	ServerAdmin webmaster@localhost
	RewriteLog /tmp/rewrite.log
	RewriteLogLevel 2
	
	DocumentRoot /var/www/localhost/htdocs/wsgi
	<Directory "/var/www/localhost/htdocs/wsgi/newsite">
	        Options Indexes FollowSymLinks ExecCGI

		AddHandler wsgi-script .wsgi

		Order allow,deny
		allow from all

		RewriteEngine On
                RewriteBase /newsite

                # Really, really annoying; the trailing slash fixes don't seem
                # to work on the server's document root...
                RewriteCond %{REQUEST_URI} ^$
                RewriteRule ^.*$ test.wsgi?page=index [QSA]

                # Redirect .py files
                RewriteCond %{REQUEST_URI} ^\w+\.py$
                RewriteRule ^(\w+)\.py$ test.wsgi?page=$1 [QSA]

                # Redirect extensionless URLs, unless they're for directories
                RewriteCond %{REQUEST_URI} ^\w+$
                RewriteCond %{REQUEST_FILENAME} !-d
                RewriteRule ^(\w+)$ test.wsgi?page=$1 [QSA]

                <Files *.xml>
                    Order Deny,Allow
                    Deny from All
                </Files>
	</Directory>
</VirtualHost>

So after having the weird stuff with the Weave EULA clarified, and learning that my real, important password is in fact only used locally, I took the plunge and installed the beta version of Firefox 3.1 to be able to run Mozilla Weave. Weave is a somewhat nebulous concept at the present time (or so it seems to me), but the gist of it—the gist that matters to me—is that it allows for seamless synchronisation of browser data between different computers. To someone who uses at least three computers on a fairly regular basis (home desktop, work desktop, and laptop), it’s very nice to have access to the same data—something as trivial as having my bookmarks automatically synchronised feels very valuable. It’s distinctly pre-release software, but in my first week of running it I’ve encountered no problems yet, and it does make my life easier.

At the same time, it doesn’t sacrifice my ability to manage my data locally. One of the tag lines is that Weave brings Firefox to the Cloud, but crucially it doesn’t leave you with just the Cloud. Recently, the social bookmarking site Magnolia crashed hard, losing both production and backup data. Cloud computing becomes fog when it goes down, as someone said; I’ve feared this since I first came across Cloud solutions. This is not to say that I don’t want my data to be out there, accessible from whatever machine I use—au contraire—but I also want a copy of my own that I can backup, parse, port, and do what I want with. I don’t want a single point of failure—whether that point is myself, Magnolia, Mozilla Services, or even Google. This is why I prefer Tuffmail to GMail (it’s easy to automate imap syncs and LDAP dumps of the address books), Weave to social bookmarking sites… (Privacy is another issue, where I want even more control.)

On a side note, since Weave requires it I am, as mentioned, running Firefox 3.1, which is a beta version. I’m very happy with it. Firefox 3.0 has an unfortunate tendency to crash with the combination of extensions I run (my chief suspect is Firebug); I now run Firefox 3.1 beta with Firebug 1.4 alpha, and I’ve yet to see a crash. Additionally, Firefox 3.1 is famously faster than Firefox 3.0. There aren’t a lot of obvious new features—none that I care about—but then, I was already happy with the feature set. Firefox 3.1 takes a good thing and makes it work faster and more reliably.

The <em>, <strong>, <dfn>, <code>, <samp>, <kbd>, <var>, and <cite> tags are all phrase tags. They are not deprecated, but it is possible to achieve richer effect with CSS.

This sort of remark is pretty common on the W3C website. I’ve never been able to figure out why. As far as I’m concerned, the value of phrase tags is concise markup. Certainly, I can use <span class="citation">Foo</span> to achieve the same effect as <cite>Foo</cite>, but it involves a lot more typing, and while I’m editing my source, it makes a lot less sense. Additionally, tags may represent semantic meaning, while classes are tied to presentation; I could easily harvest all the citations from a page if they are all marked with <cite>.

I also don’t see how it is possible to achieve richer effect with CSS, because I can attach CSS rules to phrase tags every bit as easily as I can attach them to classes, and sometimes I find it much easier, because I can further decorate the phrase tags with CSS classes:

Of course it’s a somewhat contrived example (I’m sure a better one can be made); the point is, I use a CSS rule to override the rule on the tag with a more specific one. To the best of my knowledge, I can’t combine classes in this sense, and if I want to use overrides, I either have to rely on the order of rules in stylesheets (ew), or use !important declarations (ew)—all this while losing semantic coherency and creating more of a typing job for myself; and while the styling benefits may not be huge, they appear to be real, with no apparent drawbacks.

So why on Earth should I heed the W3C and think that it is possible to achieve richer effect with CSS?

• The system76 laptops all look great but have terrible battery life.
• The ZaReason laptop has better battery life, but the video card only has HDMI-out, not S-video; I really like the option of plugging it into a TV, but I’d need a digital TV. I don’t have that.
• The Thinkpad T500 is lighter, has superior battery life, and is a Thinkpad, which means it’s rugged and reliable, but the graphics options are ATI (which is useless due to poor driver support) or an Intel X4500 chipset (which is slower but draws less power); but has no TV output of any kind—just a DVI port. Incredibly, the sales representative was unable to tell me what video outputs it had! It appalls me that they have agents selling computers without being able to tell me whether I can or cannot connect them to my TV. The sales agent was trying to Google for an answer.

I’ve narrowed it down a little bit, to a choice between four laptops, each with pros and cons. I’ve come to realise that if I want at least a 15" laptop,

1. It will be a bit heavy. For reference, my current, crappy laptop as a 14" screen and weighs 5.6 lbs.
2. Battery life typically isn’t fantastic.

Notes on the above:

1. NVidia only offers closed-source drivers, but they are good closed-source driver. All else being equal I’d much rather go with a more open company and architecture, but things are very far from being equal. The Intel X4500 chipset in the Lenovo laptops is pretty dinky compared to the ATI and NVidia offerings—I don’t know how well Compiz would even run…and heaven knows about getting TV-out to work.

   Meanwhile, the ATI options in the Thinkpads is the Mobility Radeon 3650, which doesn’t seem to work at all in Linux, and I gather they tend to run pretty hot. That’s not even an option; if I go Thinkpad, I go Intel graphics.

2. Meanwhile, the NVidia laptops all offer two video output ports, one of which is either VGA or DVI depending on the model, the other of which is HDMI. Nary an S-video output in sight! I want to be able to lug my laptop around and hook it up to TVs if I so desire; I’d like to do so through RCA. I’ve never used HDMI. Do TVs usually have these? Is this going to be useful? —Is it even going to be usable?

3. In spite of the insistence of some, I’m not very interested in a Macbook… I’ll freely grant that the Macbook Pro is a very nice-looking machine. If it were no more expensive than other laptops, if I were sure it had good Linux support, and if it had more mouse buttons, I might consider it for hardware. However, it is expensive, and I can’t get by on just one mouse button. And yes, I’m talking Linux—OS X drives me insane; I despise it. I might come around to it if I used it for a while, but I’m not prepared to spend ~$2000 on a ‘maybe’.

What kind of laptop should I get?

I’m currently leaning weakly towards the Strata, but thoughts and opinions would be very, very warmly welcomed.

My old Dell 600m has gone past being long in the tooth to being pretty much toothless (it’s old and slow, the optical drive is long since dead, and when I adjust my screen brightness, the keyboard tends to die). I’ve got my finances in check, I have some money, and it’s time to start thinking upgrade.

Of course, I’ll be looking for a laptop to run Linux. I want a 15"/15.4" screen (less is annoyingly small, more is annoyingly un-portable), I want a nice big hard drive, reasonable performance until I upgrade next time (which may be years), the ability to hook it up to my TV (or somebody else’s) to play movies, and crucially, I need the hardware to be supported by Linux.

Researching compatibility can be pretty tedious. This was the initial reason why I started looking at companies that ship pre-loaded Linux laptops…though on reflection, I’d also be very happy to support that decision of theirs with my business; the world could use more of it. I’ve found some very nice-looking laptops, such as the system76 Pangolin Performance and Serval Professional, or the ZaReason Strata 4660.

I really like the system76 machines, and they seem to have a very good reputation. The only problem is the battery life—the Pangolin is rated at 3 hours (which, of course, is never realistic; their sales guy was frank and told me that 1.5–2 hours is probably what I’d get), and due to supplier shortages, they don’t offer a 9-cell option. All of these systems are also a bit on the heavy side (in the approximate range of 6–7 lbs). I’d like something as light as possible for my backpack, but of course the 15.4" laptops aren’t going to weigh the same as 12.1" ultraportables…

There are other Linux laptop resellers, like Puget Systems, and of course there’s the route of buying a “regular” laptop, maybe a Thinkpad for quality or something like a Dell for price, and making sure that the model I get is fully supported in Linux. But I’m no laptop expert, I haven’t shopped around in a long time, and I don’t know what to look for—what kind of battery life should I hope for in a 15.4" laptop? What’s a reasonable, and what’s a good weight?

Any and all thoughts and suggestions are welcome at this stage.

What kind of laptop should I get?

Update: The Puget 510i doesn’t look like that much of a contender. Its battery life is also in the 1.5–2 hours class, and at that point I think I’d just go with the system76.