What happens when your credit card is out of your sight?

We've all done it, and it seems so normal: hand a credit card to a server at a restaurant to pay the bill.  It's an everyday activity, occurring millions of times a day around the world.  However, this comes with risks, as the media shows us:

With devices like Portable Mini 400 Magnetic Magstripe Data Card Reader, it's a wonder that more credit cards aren't stolen in that fashion.  (I guess we're just protected by either a sense of right or the risk of being caught.)  While the $230 pricetag might seem a little high at first, consider the number of credit cards a single waiter might handle in a night.  Even placing a relatively small transaction on each of those cards, a single night would be enough to make up the price of the reader.

Magnetic stripe payment technology became widely available in 1975.  While it has served us well for over 35 years, it's time to move to newer technology to protect our financial transactions.  Skimmers, these handheld recording devices, and other relatively accessible pieces of technology have rendered the magstripe obsolete.  Now is a good time, as 4 researchers at the University of Cambridge have shown significant weaknesses[PDF] in the Chip and PIN system widely deployed in Europe.  With the proliferation of cell phones, especially smartphones, maybe the time is now for Mobile payment to become a major part of the electronic payment industry.  Alternatively, new smart card implementations might extend the life of plastic just a little longer.

apc.stat=0 and Updating Software

When you're running APC on PHP and you have apc.stat=0, it's sometimes easy to forget that when you update software (WordPress) the code running on your server remains unchanged until you flush the APC cache. So, when you go to update WordPress to 3.0.5, you should flush your APC cache after running the update.  If you don't, you'll be very confused when WordPress repeatedly tells you to upgrade to the version you just installed!

This is mostly a note to myself, but I hope it helps others as well.  And if you're wondering what apc.stat does, read on!

apc.stat determines if APC should perform a stat() call on the file to see if it has changed since it was cached.  From the PHP documentation:

Be careful changing this setting. This defaults to on, forcing APC to stat (check) the script on each request to determine if it has been modified. If it has been modified it will recompile and cache the new version. If this setting is off, APC will not check, which usually means that to force APC to recheck files, the web server will have to be restarted or the cache will have to be manually cleared. Note that FastCGI web server configurations may not clear the cache on restart. On a production server where the script files rarely change, a significant performance boost can be achieved by disabled stats.

For included/required files this option applies as well, but note that for relative path includes (any path that doesn't start with / on Unix) APC has to check in order to uniquely identify the file. If you use absolute path includes APC can skip the stat and use that absolute path as the unique identifier for the file.

My Life in Big Bang Theory

I was thinking this evening about how being a generalist kindof sucks.  I don't feel like I've found my niche yet, and I'm fairly disappointed by that.  I've also been watching Big Bang Theory and realized why the show appeals to me as much as it does.  While my life is (unfortunately) not like that of the characters in the show, I see some similarities between myself and the characters:

  • Dr. Sheldon Cooper -- Much like Sheldon, I sometimes nerd out to a degree that others don't understand.  Granted, I'm not a physicist, but man, I can nerd out about computers.  Plus I'm pretty socially awkward.
  • Dr. Leonard Hofstadter -- I like to think that most of my life is like Leonard.  Except I've found and secured my "Penny" (being married and all).  I'm not very up on pop culture, sports, or all that other stuff.  Of course, neither is Leonard and it hasn't seemed to hurt him -- too much.
  • Howard Wolowitz, M.S. -- Much like Howard, I'm insecure by my lack of expertise and specialization.  I hope I'm not quite as sleazy, but I do like my wife... enough said.
  • Dr. Rajesh Koothrappali -- Again, I'm incredibly socially awkward.

Now... to find my niche.

The Importance of Verifiable Security

A number of services online claim to store data securely.  Often, this claim is attached to comparatively unimportant data.  A claim that, for example, your microblogging "direct" messages are stored securely generally results in little risk.  (Hopefully, you're not sending secret data in those sort of messages.)  However, solutions like Dropbox and LastPass (among many others) claim to store and transmit your personal data in an encrypted form.

Given that both use a closed-source binary and that neither solution has offered third-party verification, I can't quite see using them for anything involving data I want kept secret.  I certainly wouldn't use LastPass (or any other password sync solution) without being able to see that the data is really encrypted locally before being sent to a server, and that the server doesn't have access to my passphrase.  Firefox Sync, on the other hand, is included with the Firefox source, which at least allows verification.  (I haven't done so yet, but I might do so at some point.  If so, details will be posted here.)  Anything sensitive that goes into my Dropbox goes in encrypted, generally using GnuPG.

Remember: just because the marketing info says "encrypted" doesn't mean it's secure.  Dropbox obviously has access to your passphrase at some times -- how else could they build a web interface?  Even if stored encrypted, when they have your passphrase, they could store it.  If their server was compromised, both your data and passphrase could be at risk.

Ask your service providers (especially those you pay for their services) to provide either the source, third party verification, or best, both.  Even providing the client source could be enough to demonstrate security.  (If the data is encrypted with a known-good algorithm before being transmitted and the key is never transmitted, then the data should be secure.)

Major Sites that a 'tiered' Internet Would Have Killed

Again and again, we hear about the idea of a "tiered" Internet, containing 1st and 2nd class citizens.  In some variants, entire sites would be cut off by ISPs.  Let's take a look at sites that probably would not have been able to get started with the notion of a "tiered" Internet.  In this list, I'm including major sites that were started without major commercial backing, whose success only came after making it big -- something that takes users being able to access the site, of course.  Let's assume that a tiered Internet came out about a decade ago, right after the fall of the dot-com era.

  • January 15, 2001 -- Wikipedia is launched.  Wikipedia is now the #7 most-visited site on the Internet.  Due to the ad-free nature of their site, having to pay "premiums" to every ISP would likely kill Wikipedia.
  • May 27, 2003 -- Wordpress is released.  Wordpress.com, a free host for blogs, is the #19 Internet site.  Would they have to work out contracts with the ISPs to keep providing a free service?
  • February 4, 2004 -- Facebook is launched from a college dorm room.  Facebook didn't turn a profit until 2009.  They are now the #2 site on the Internet.  I'm sure they wouldn't have been able to survive those first 5 years if only some ISPs were able to access their site.
  • December 5, 2004 -- The launch of Digg.com, the first major social news site.  Digg.com was launched by Kevin Rose, and is today the #88 website in the U.S.
  • February 14, 2005 -- YouTube is launched.  YouTube was founded by 3 private individuals with $11.5 million in VC money.  Given that YouTube now ranks as #3 globally and is responsible for 10% of the world's Internet traffic, it's likely that it would never have gotten to see any amount of success in a tiered Internet.
  • July 15, 2006 -- Twitter, the most successful microblogging site in the world, is launched.  Twitter has only recently begun to generate revenues worth mentioning.  Without a significant revenue model in place, it is unlikely venture capitalists would have invested, leading to an early death for Twitter.

From just the .com, .net, .org, .info, .biz, and .us TLDs, there are over 127 Million registered domains. As of even 2002, it was estimated there were 3500-4000 ISPs in the United States.  So, are these sites supposed to sign 4000 contracts each?  A total of something like 508 Billion contracts in the US alone?  This is positively insane.

Maybe I'm crazy, but it seems that Wired.com has made this same argument.  I, for one, will never use an ISP that cuts off access to part of what I'm paying for.  Charge me for my bandwidth, just as Google's ISP charges them for their bandwidth.

[Most of the site statistics are from Alexa.com.  Founding dates from Wikipedia.]