http://www.cakespy.com/2009/01/taking-it-to-sweet-cupcake-street-art.html
Sure they’re handing out cupcakes instead of backstabs, but it’s still pretty hilarious. And awesome.
If that doesn’t make any sense, play Team Fortress 2 and look for this spray in-game.
Any discussion of encryption from a programmer’s perspective almost inevitably leads to public key encryption. This elaborate handshaking process ensures a totally private connection between two distinct parties, and is the basis for SSL/TLS encryption. The most common encryption programs are GnuPG and OpenPGP.
However, what about when the only party involved is yourself? Ever run into a situation where you’re own software is the only thing encrypting and decrypting a set of files? After all, at some point your code has to read and use both public and private keys. In cases where the sender and recipient are the same party in the same location, the entire benefit of public/private key pairs goes out the window, and all the complex handshaking illustrated above becomes pretty meaningless.
Note that I said “same location;” if the data is encrypted on one server, then delivered and decrypted on another, key pairs still offer extra security. A breach on the server using the public key won’t gain the attackers access to the data, as they would still require the private key to decrypt the data.
So assuming we have a piece of software that performs encryption and decryption in a single location, it makes sense to use a single key. This single-passphrase encryption is called symmetrical encryption. The problem: the vast majority of encryption discussion out there cover key pairs, or symmetrical on an individual, “one-off” basis. However you can use GPG to perform symmetrical encryption that…
Enough chatter, here’s the command line call:
gpg --quiet --no-tty --cipher-algo AES256 --passphrase-file /secure/path/.passphrase -c important_file
--quiet and --no-tty
Ensure that GPG doesn’t output anything to the terminal, including errors. These should be added after you’ve thoroughly tested your setup.
--cipher-algo
Allows you to choose which encryption method to use. GPG uses CAST5 by default, which is good, but not nearly as strong as AES 256-bit, which we use here by including AES256 after the parameter.
Using AES256 also allows us to avoid getting the WARNING: message was not integrity protected warning message when we decrypt our files. This warning only appears when doing symmetrical encryption using a cipher that’s 64 bits or smaller. A cursory web search reveals a lot of people run into this issue. Switching algorithms to AES256 is enough to avoid the problem entirely, as the cipher is now 256 bits in length. Alternatively, you can pass the --force-mdc parameter.
--passphrase-file
Tells GPG that your passphrase is stored in the specified file. You can name this file whatever you want, and locate it wherever you’d like. However, the user under which you perform the encryption must have access to the file. So in the case of a web-based program, you probably need to grant read access to your web server user (e.g. apache or www-data). Read access is all you need, and should be chmod’d to something like 640 or lower. 400 (read only by user) is ideal.
You can further improve the situation with two small extra steps. First, make sure the file sits outside the web root of your site (i.e. not under public_html, www, or whatever). Second, prefix the entire file name with a period. Looking at the example again we see that the file is actually called .passphrase. This only makes Linux consider the file hidden, and thus invisible to typical navigation. But while it isn’t true security, a little bit of “security through obscurity” on top proper permissions and location doesn’t hurt.
Finally, remember that since you are storing the passphrase in a file, you have almost no limits on the length and complexity of the password. Maximize that benefit by picking a really complex passphrase. No words, upper and lowercase, symbols. Better yet, let GPG do the work for you:
Here’s a quick hack for generating a very secure passphrase using GnuPG itself. The passphrase will not be easy to remember or type, but it will be very secure. The hack generates 16 random binary bytes using GnuPG then converts them to base64, again using GnuPG. The final sed command strips out the headers leaving a single line that can be used as a passphrase:
gpg --gen-random 1 16 | gpg --enarmor | sed -n 5p
You can easily pipe this text directly into your new passphrase file:
gpg --gen-random 1 16 | gpg --enarmor | sed -n 5p > /secure/path/.passphrase
I have a friend who showed me something on the WineAccess homepage tonight that just made me laugh. Check it out.
See anything wrong with that picture? How about the “What You Missed” section at the bottom? It contains wine bottles that you can’t purchase, because they’re sold out. Hence the title. Worthless information with which the user can do nothing, essentially wasted primo homepage real estate.
Homepage design is a very complex topic, but you can definitely tuck this one in the “What not to do” column.
When I’m not coding, I’m gaming. Pretty standard formula. My latest gaming indulgence is Valve’s Left 4 Dead, offering the most original take on the first person shooter formula that I’ve ever seen (and I play a LOT of FPS).
Okay, 30-second summary. L4D sets itself apart through its 4-man survivor team mechanic. Whether you play cooperatively or versus, you and 3 buddies have to navigate a level chock full of zombies. How many zombies? Your pistol has unlimited ammo, if that helps put things in perspective. While you’ll enjoy a surplus of zombies to shoot, you’ll simultaneously suffer from a strong lack of health. Maps will usually have 4-8 health packs, but each person can only carry one at a time. When — not if — you run out of health, you don’t die right away, but become incapacitated, lying on the ground with only your pistol. Your health slowly ticks down until it runs out, or a teammate picks you back up. Fall three times and your done. Finally the big kicker: friendly fire is not a selectable option, it is always on. The fastest way to failure is through the back of your teammates, so you must watch where you run and shoot.
Suffice it to say, it’s new, different, and I love it. With a little practice I quickly learned to check my fire, leave no man behind, and keep an eye behind for flanking hordes or player-controlled zombies when playing versus.
Unfortunately, I seem to be in a very select group of players who have grasped the best tactics for these mechanics. I’ve never seen such extended suckiness in a multiplayer game. We’re well past the window of general introduction, and I’m still finding n00bish behavior to be the norm (I play L4D on PC, jackass console gamers are almost a rule). Co-op campaigns going horribly awry when someone runs way ahead, lags way behind, or empties half a clip into a teammate. Outclassed versus matches where survivors don’t make it 30 feet, or zombies that don’t scratch said survivors. I try to instruct the unenlightened, but alas, he’s been killed by the tank, or wiped out by survivors after running headlong out in the open as a boomer.
It’s so bad that I now start each map with the same phrase: “Stick together, keep moving, focus on the tanks.” Here’s some more detail on what I’m trying to convey. Be sure to pass the information along to any rage-quitting ass-clowns you may encounter…
Stick Together
Can’t over-emphasize this one. All zombie classes have an incapacitation ability: general horde impede your movement, which can get bad when you’re hit by boomer puke; hunters and smokers both eliminate your ability to do anything. The solution is obvious: you count on your teammates to rescue you…which is really tough when you’re halfway across the map!
Your teammates should always be 1 turn away or less. Don’t go off on your own. Ever. Clear enough?
Keep Moving
Running behind is just as bad as running ahead. Aside from slowing everyone down (boring!), you also run the risk of incurring the random horde. If your team lingers for too long without advancing in the map, the game penalizes you with an automatic and unscheduled horde assault. Special zombies also pop randomly from behind when you stall. Campaigns are often slow and steady, but keep emphasis on the “steady.”
Keep Moving FASTER
After applying the previous rule in campaign mode, double triple it in versus. Your team scores points in versus based on how far you make it through an individual area. Even if your team dies, you still gets points for distance. In addition, your zombie opponents can maximize their damage when they have time to set up coordinated ambushes (e.g. hunter-hunter-smoker-boomer). It’s much more difficult to cause damage when they’re chasing a track team.
Don’t scour every room and kill every zombie. Take the shortest, fastest route, and never, ever stop!
“Everyone on the tank!”
I say it every time I encounter one. When a tank shows up, everyone has to unload on it. At once. Until it’s dead. No exceptions. If you are not shooting the tank, you are passively contributing to your team’s imminent demise. All other targets are secondary, including special zombies. The “stick together” rule works fantastically here, because you’ll kill the tank really fast — I’ve seen him go down in versus in less than 30 seconds — and cover each other from special zombies.
Shape up, L4D n00bs. I’m begging you. It feels like an endless suckfest far too often. Win or lose, I just want a good game!
Well this is interesting. White House spokesman Robert Gibbs said security on the device has been “enhanced.”
Reality-check: it’s still on the BlackBerry network (as far as I know), which means it’s still subject to the same points of access. And failure.
Any one taking odds on how long it takes until someone has hacked his device or accessed his account? I give it a year. Somebody remind me on Jan 22, 2010.
Jeff Atwood’s latest post on Coding Horror provides great insight into the history and mindset of one of the Computer Science greats, Alan Kay. It’s a good read for any computer professional looking to delve further into the advances that Kay worked on.
Unfortunately, Jeff has a pretty strong distaste of PHP, and blindly jumps on a perceived opportunity to back up his case. He cites an ACM Queue article where Kay discusses why software development does not happen faster. Here’s the important section that Atwood quoted. Bolding is Atwood’s emphasis:
Let’s say the adoption of programming languages has very often been somewhat accidental, and the emphasis has very often been on how easy it is to implement the programming language rather than on its actual merits and features. For instance, Basic would never have surfaced because there was always a language better than Basic for that purpose. That language was Joss, which predated Basic and was beautiful. But Basic happened to be on a GE timesharing system that was done by Dartmouth, and when GE decided to franchise that, it started spreading Basic around just because it was there, not because it had any intrinsic merits whatsoever.
He follows his citation with this comment:
Any similarity between the above and PHP is, I’m sure, completely coincidental. That sound you’re hearing is just a little bit of history repeating.
His link here goes to an earlier post where he lambastes PHP for, well, existing really. I took issue with the post at the time, finding several glaring holes in his logic and generally disagreeing with the premise (obviously). I replied in the comments (look for my name), and expounded further in a rebuttal post on my own site. I didn’t let him get away with unfounded arguments then, and I’m not going to now.
In the ACM Queue article, Alan Kay discusses the evolution of programming languages. He and his colleagues expected the next big leap in programming language structure to occur somewhere around 1984, with the introduction of a new generation of programmers. It never happened — to Kay’s satisfaction, anyway — and he believes that commercial software development doomed this advancement, and has stagnated the evolution of programming theory. This leads to Jeff’s quote and PHP quip.
Two problems here. First, Kay was discussing evolutionary leaps, not the quality of the current crop. Kay doesn’t know how language theory will evolve, he’s waiting for someone to come along with the next bright idea (otherwise he would have done it, duh). Labeling any current language as subpar simply because someone theorizes “we can do better” is complete non-sequitor. I believe Kay knows this and his words in the article back it up.
To put it another way, using Atwood’s logic, wouldn’t VB.NET would fall into the same category of failure? Kay may not be worshiping at the altar of PHP, but I don’t see him anywhere near Microsoft’s temple either.
Second, PHP is successful because of its merits, not in spite of their lacking. Jeff needs to read the Wikipedia article on PHP. The very first paragraph on the page reads:
PHP originally stood for Personal Home Page. It began in 1994 as a set of Common Gateway Interface binaries written in the C programming language by the Danish/Greenlandic programmer Rasmus Lerdorf. Lerdorf initially created these Personal Home Page Tools to replace a small set of Perl scripts he had been using to maintain his personal homepage. The tools were used to perform tasks such as displaying his résumé and recording how much traffic his page was receiving. He combined these binaries with his Form Interpreter to create PHP/FI, which had more functionality. PHP/FI included a larger implementation for the C programming language and could communicate with databases, enabling the building of simple, dynamic web applications. Lerdorf released PHP publicly on June 8, 1995 to accelerate bug location and improve the code. This release was named PHP version 2 and already had the basic functionality that PHP has today. This included Perl-like variables, form handling, and the ability to embed HTML. The syntax was similar to Perl but was more limited, simpler, and less consistent.
PHP is 100% grass-roots success, starting out as one guy’s collection of useful tools for building websites. I refuse to believe that, in this age of abundant choice, all these programmers picked up PHP because it was “easy.” The numbers are just too big, features and power must enter into the equation at some point.
Nonetheless, Atwood’s application of Kay’s quote would lead you to believe that PHP exists because Zend Technologies pushed the language financially, just as GE backed BASIC. The truth is exactly the opposite: Zend Technologies exists because of PHP’s overwhelming success. Coming from a hard core VB.NET programmer, I find the insinuation here a little insulting; Zend Technologies is hardly MS Borg.
When it comes to having a discussion about programming philosophy, I wouldn’t even put myself in the room with Kay. I don’t know enough on programming language evolution to even join the discussion. Atwood, on the other hand, gets too close to the fire and gets burned. He erroneously applies Kay’s argument to his own beliefs which, when scrutinized, deflate much like the previous one.
This is the second time now Jeff has taken a unfounded shot at PHP. The complete lack of substance behind his claims make him look like nothing more than your average “my language is better than yours” fan boy. I could ignore it, but his audience is large enough to effect real influence. So like anyone else in a position of power, he must be called on the outlandish claims.
I read your blog all the time, Jeff, I know you can do better than this.
FYI if you run Mirror’s Edge on your PC and the sound effects are all outta whack, check to see if you have a Realtek sound card installed. Their older high definition drivers don’t work properly with the game, and you’ll have to download the latest version.
Now, chances are that your Realtek is built into your motherboard; that’s how they sell most of their gear. In most cases, you should install drivers for onboard devices — aka stuff built into the mother board, network card, sound card, etc — provided directly by your motherboard retailer. However this update is new this month, so chances are they haven’t picked it up. It’s also very likely that your mobo company doesn’t make changes to the sound card at all.
So, if your Realtek soundcard came in a computer provided by Dell, Gateway, HP, etc., check their update sites for an upgrade. If they do not have one, or if you built your own computer — good for you, great money-saver! — you can grab the latest version directly from Realtek (click the “Software” link, pass agree screen, and get the “Executable file” version).
Secondarily, I found reports that the K-Lite Codec Pack can cause the same behavior. I suggest you try the sound card first. If that doesn’t work, then try removing K-Lite.
Thirdly, if you haven’t heard of Mirror’s Edge or haven’t checked it out yet, I highly recommend that you do. Hard core FPS fans will get a refreshingly unique experience — you can beat the entire thing without firing a gun — and everyone else can pretend to be a free runner. Neat.
Ran into another cool hurdle today for my Fwd:Vault development. When I grab the message content to archive it in the system, first thing I do is scrub it out to ensure that (a) it displays properly, and (b) there are no misbehaving characters. I grab both plain text and HTML email formats (if present), so the scrubbing process is a little different in each case. For the plain text, I take some extra steps to ensure there is no HTML whatsoever. Naturally, at one point this involves a call to PHP’s ultra-useful strip_tags() function.
However, in the course of testing today, I realized that when a message is forwarded, sometimes the forward header will encode the email address, which gets stripped when I process the message. Allow me to demonstrate. Here’s the body an example message that someone might send to Fwd:Vault for safe keeping…
---------- Forwarded message ---------- From: "Office Flirt" <flirt@example.com> Date: Wed, Jan 14, 2009 at 10:14 AM Subject: Delete those images To: you@example.com My boss is sniffing around. I want you to delete those pictures I sent you right away. Signed, Office Flirt
Obviously you’re tucking this one away in Fwd:Vault to provide a little CYA-insurance when the boss calls you into his office. Good call. Now, before today, this message would come out of the scrubbing process looking like this:
---------- Forwarded message ----------
From: Office Flirt
Date: Wed, Jan 14, 2009 at 10:14 AM
Subject:
To: you@example.com
...
Look at the bolded red line. The email address is gone. You don’t have any other copies of it, so your boss doesn’t believe your story, and you get the blame. You’re forced to attend one of those god-awful sexual harassment classes. Fail.
So, what happened? Remember, you are looking at the body of a message in plain text. That “Forwarded message” block at the beginning is just part of the body text. So when the text was scrubbed by strip_tags(), the function picked it up as just another tag, which it dutifully removed.
To handle this situation, I came up with a piece of code that will look for email addresses in “tagged format” — i.e. surrounded by < and > — and remove the surrounding symbols, leaving us with harmless text.
$test = 'some surrounding text'; $test = preg_replace( "/(\<)(.+@[^\(\);:,<>]+\.[a-zA-Z]{2,4})(\>)/", ' $2 ', $test); $test = preg_replace('/[\s]+/', '', $test); echo $test;
Let’s break this down. First, we have a regular expression that identifies email addresses: .+@[^\(\);:,<>]+\.[a-zA-Z]{2,4}. This is the same expression set in the example on the Quanetic Software Regular Expression Tester (an excellent tool). We surround that in parentheses to isolate it as a subpattern. Then on either end of the expression, we tack on more regex voodoo to look for tag syntax: (\<) and (\>). These also get parentheses to identify them as subpatterns. Once its finished, we have an expression that will only match addresses wrapped in tagging structure.
The second argument in preg_replace() is the replacement, or what we should replace any matches with. In this case, we’ve isolated the address from the tags using subpatterns. So all we need to do is make a single call to the proper reference, which is $2, because its the second set of parentheses in the expression. Confused? You can learn about subpatterns on the PHP manual page for preg_replace().
Note the spaces around the $2 in the second argument. Sometimes the address will not have any spaces between the person’s name and the actual address. This could lead to the address being combined with the name which, in the case of Fwd:Vault, would screw up our search indexing. So we add spaces during the replace, then make a second call to preg_replace() to eliminate extra spaces: $test = preg_replace('/[\s]+/', '', $test);.
Legal Disclaimer: In case you do end up using Fwd:Vault when it launches, I’m fairly certain the service wouldn’t be liable in this silly hypothetical. Just make sure you read the terms before you sign up if you play the field at your office. Sorry to everyone going “duh” right now; it’s a sue-happy world.
Update: When I went to implement this change today, I discovered that the code was catching newlines (\n or \r) in the crossfire. It was actually due to the second call to preg_replace(), the “\s” character class includes not only spaces but line terminators as well. Oops. The revised version looks like this:
$body_text = preg_replace('/[ ]{2,}/', ' ', $body_text);
I’ve been working furiously on the back end logic for Fwd:Vault for the past few weeks, specifically the logic that processes incoming messages/attachments, archiving them in the system, or returning stored data per user request. As I got into the final nitty gritty, I confronted a serious design issue: should the system use one email address for all processes (storing new data and retrieving stored data), or should I split the processes into separate addresses (one to store data, another to retrieve)? I’d like to share the process I went through to reach a decision, and the rationale for the final decision; I thought someone out there might find it useful.
Fwd:Vault’s claim to fame is the marriage of email with backups, eliminating the software in the middle (details in the launch announcement and the official site). Consequently, how the addresses are arranged from the systems end is critically important. The signup process and basic use instructions must make it clear where and how to send requests to store and retrieve data. Two addresses could confuse the issue, but then again so could one (“Hello, CS Rep, my request for my stored document got stored as a new item instead…”). I see this issue as one of the most fundamental hurdles I’ve faced with the system yet, so I sat down and laid out pros and cons for each. I came up with the following lists…
Arguments for 1 Address:
Arguments for 2 Addresses:
When I sat down and compared the lists, the decision to use a single email address became a no-brainer. Here’s the trick: do you see the natural break occurring in those lists, making the decision so easy?
As the post title indicates, its all a matter of perspective. Each list represents problems and benefits for entirely different sets of people. If you still don’t see it, reread each bullet, then ask yourself, “Who is this actually a problem for?” Easy use, less instructions, and simpler mail headers are all benefits to the user, while separation of processes, message analysis, and bugs are all problems that the developer can overcome with enough time and attention.
In short, if I chose two addresses instead of one, I’d be robbing the user of a better experience in exchange for saving myself some development effort. This of course turns around and robs me of more users down the road, effectively nullifying any short term gain in time I might have. In an age of endless choice, the best overall experience always wins.
When putting together any product or service for any target audience, tie always goes to the customer. If it improves the experience, and costs of both time and money are within reason, then you should always go the extra mile. Long tail economics will pay back that effort in spades over time.
From a recent post in the Signal vs. Noise blog…
(1) Windows 7 Explorer vs. (2) Dance Dance Revolution.
I’ve never seen an illustration, written or visual, that flawlessly encompasses everything wrong with Vista. Awesome.
The author references the Windows 7 beta, but the interface is identical to Vista as far as I can tell. Any parallels to Vista are probably the last thing Micro$oft needs, let’s hope they deliver some more bang to go along with their DDR-inspired flash this time around.
Data security without software or hardware
Latest Posts Fwd:Vault Blog