ArghWebWorks

This was a riveting dissection of how to circumvent CAPTCHA checks on blogs and other forums. You know what a CAPTCHA is; it’s one method to determine if a user is human. You show an image that’s distorted enough that a computer shouldn’t be able to read it, and then the human assembles the text and inputs it, and bammo, you’re spam-free.

Not so fast, you might say, after reading this article. With 24 hours of work, this programmer put together a 90% successful captcha-defeater. That is, after he wrote it, he ran it against 96 blogs and left messages on all but a few. Not shabby; and given spammers’ willingness to spend money, I could definately see someone paying $2000 for this.

But in my mind, it gets worse. Our email bins are full of spam, and it’s because the value of success so outweighs the cost to spam; one successful purchase for mortgage-enhancing drugs pays for a million spams; if more than one in a million sign up, you’re making dough. This is because it’s automated; once you have the sales copy in one hand and the list in the other, it’s very cheap to send out a million emails.

If you pull together those two facts; you realize that someone could put together a minimally-effective captcha-defeater in a matter of an afternoon, and that someone else would be willing to pay for it. Once you combine the two, blogs will look like your email baskets. In other words, the work someone has to do to post a minimally effective captcha script to a hundred million blogs, getting one million spam entries on comment forms is minimal, and when the value of a million blog spams is greater than the cost of writing the software, it’ll break out.

This is why I don’t really believe that the letter captchas are a terrific solution. They are, however, currently successful, and so should be used. But we should continue to look for other methods; and when the annoyance factor of having to do captchas gets higher than the value of them ( which will happen when the spambots figure this out ), we should discontinue them.

I had a php script failing tonight; what was breaking was a mysql query, with err number 2000; “unknown mysql error.”

The mysql query looked like “select column1 from tablename where column2 = ‘integer’”; I put backticks around the column names and the table name, and removed the quotes around integer, and it fixed the unknown problem. So I guess the word would be: be specific with your mysql statements.

If you have a linux server (or a workstation, but servers are more prone to OS stagnation, I’ve found), there might come a day when you insert a new hard drive. Perhaps you’re migrating the /home/ directory from a full disk to its own disk. If you do this, your newer hard drive might spin faster and have more cache than the old one.

If you run ‘hdparm -i (device)’, you might get an output like this:

/dev/hda:
Model=WDC WD400BB-00DEA0, FwRev=05.03E05, SerialNo=WD-WMAD15201933
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78165360
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: device does not report version:

Compare this against:

/dev/hdb:
Model=ST3250823A, FwRev=3.06, SerialNo=5ND0B7XN
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=no WriteCache=enabled

Access to this hard drive will be quicker, in general, because of this cache. You might decide to move your cache over to this drive. Here’s how to do it. First, fire up fdisk; “fdisk /dev/hdb” (or whatever your new hard drive is set up as). Create a new small partition (I set up a 4GB one, which is overkill). When you choose what type to set it up as, instead of choosing type 83 (Linux), choose type 82 (swap). Set up any other partitions you need, and (w)rite the partition map out.

Just like a new partition needs the mkfs command run on it, you need to ‘mkswap’ your new swap partition (mkswap /dev/hdb1). This’ll take a little while, just like the mkfs command does. Once this is complete run a quick ‘top’ and notice in the top of the, err, top, how much swap you have. Now run ’swapon’ and your partition (swapon /dev/hdb1). This is a quick command, like a ‘mount’ might be. Once this is complete, you can run top again and make sure you have buckets more swap.

Before you reboot, you might want to update your fstab ( or your swap space won’t be remounted when you reboot). Back up the file (cp /etc/fstab /etc/fstab.old) and edit the file. You can change the line with ’swap’ in it to have your partition mounted (/dev/hda2 swap swap defaults 0 0). When you reboot, you should have the new amount of swap space available.