That technical support problem from the other day never did fully make sense… This is why I don’t trust user-friendly graphical interfaces. It’s a lot of work to get the appearance on screen of work on a computer to reflect the reality of what is going on deep inside the box.
I’m back to my old favorite distinction: I like a Graphical User Interface when I don’t know what I want to do, and exploring the possibilities could give me inspiration. I consider it a “Toy” that is best suited to “Play”. When I need to do well rehearsed daily chores, I want a command line. All those windows and buttons and dialog boxes just get in my way.
But, realize that all that presentation is more work for the programmers. And, frankly, more opportunity to make a mistake. Even in a command line environment, I make my changes, then I double check that the changes took hold. Yes, I might still be fooled, but in a GUI, there are more layers of simulation and more chances for reality and appearance to diverge.
So, let me take you on a tour of my lethally boring example: Somewhere in the midst of writing PHP scripts for my coworker to update the author event database through HTML forms, my FTP client started asking me to verify files I hadn’t commanded it to transfer. Using the program is almost as easy as drag-and-drop. It is an XUL specification that runs in Firefox as a browser tab. I’ve used it for years now with several different FTP servers. It gets updated automatically with minor revisions. The worst bugs so far have been mild annoyances that I could blithely work around. But I selected the PHP files I wanted to upload, hit the send button, and it started the transfer. Since this is the umpteenth time I have uploaded these files - Whenever I make drastic changes, the server just throws a fit, so I’ve learned to be very incremental - they all prompt an overwrite warning from the program. I really do look at these warnings and verify the file names. This time one or two caught me off guard and I realized it was more than I had selected… So what was the last one I said yes to? It shows up in the running command log in the bottom pane. (You see, the programmer knew that I needed the reassurance of command history) But the second part of my failure was not looking there. It was the next box asking me about a filename I didn’t recognize - mainly because it had some articulated path text that I instantly knew couldn’t have anything to do with me.
Or could it? I remembered later that the full path to my root directory is a big complicated mess. (When I asked about symbolic links in an email to technical support, they didn’t answer me - just gave me a standard form email that suggested I call and talk to somebody. When I asked the operator directly, he said “No, unfortunately we can’t do a symbolic link to the home directory on those Linux hosting accounts.” - Yeah, I believe that.)
Anyway, my first instinct was the very naive belief that someone there would be able to help me. When my first call yielded only the most confused front-line operator who eventually agreed to ‘escalate’ my trouble ticket, I had some time to consider the problem a little deeper… It really was just the one directory - sensitive information in files and scripts that can modify the database - that needed password protection, because whether anybody knew it was there, a simple scan would find it. It’s called “admin” after all - a bit of a no-brainer there. I can write a script to just hammer away at sequential IP addresses all day requesting the admin directory - I wonder what I would find.
First, the infuriating brush-off: The email that advised me of a bad ‘.htaccess’ file. I had to do a double-take: One of the more recent updates to the FTP client disabled the “show hidden files” checkbox buried in the settings. If you were able to read this far, then I’ll assume you’re some Beard-and-sandals Unix Guru… NO, I’M WRONG - THAT PERSON WOULD HAVE LOST INTEREST IN THIS STORY LONG AGO.
So I downloaded the ‘.htaccess’ file to have a look. I didn’t see anything weird. Oh damn! I’ve been burned once again: Looking at the literature, I found the remark about “Error 500 means you’ve got a bad line in your .htaccess file.” They didn’t even look at the file - they just found it on a FAQ or something. Later when I was talking to the guy, I asked which line was causing the problem - and, he didn’t know!
So We’re Back Down To Superstition…
“Have you backed up the contents of the directory?”
Oh great.
No, it’s not that bad yet - he just suggested a slash-and-burn approach: remove everything, then build it back up from the pieces.
And here is today’s GUI complaint: The web interface for the hosting package has a page of “Security Settings”. It allows you to establish 1) Directories eligible for password protection, and 2) Login accounts that may be linked to one or more of those eligible directories. Some central dispatcher actually makes the changes, but you see the results on the page right away. That’s poor feedback. I’ve successfully changed the indicator - but has the real change been made?
When I see new file permissions on the command line, I have better confidence that my chmod command worked. It’s still quite possible that I’ve been fooled - but for some reason I still feel more comfortable - there were fewer programmers in between me and the real file permissions.
Posted in web-craft, computer-interface | no comments | no trackbacksPosted by Evan Bittner
Thu, 18 Sep 2008 02:24:00 GMT
Inline Functions - I never learned about these functions for scripting webpages. I didn’t even know how they fit into the syntax. They are a sufficiently advanced form that you won’t learn the technique by cribbing from amateurs, which is something I find myself doing a lot. Or, maybe I should say, when I did see them in unexplained code, there wasn’t enough context for me to learn what was happening.
Posted in programming, web-craft | no comments | no trackbacksPosted by Evan Bittner
Fri, 12 Sep 2008 23:45:00 GMT
Yesterday, with some time on my hands and preparing for today’s email newsletter to go out this morning, I realized that I have no idea how much longer I can rely on the old Author Event Calendar page before it gets turned off. Therefore, I shouldn’t be linking to it in new emails, which will have dead links for as long as anybody cares to leave it unread in their inbox.
Well, I have built the new page already. And, it’s populated with the bare minimum of author events, which I can always augment in short order. So I put the new links in the email.
This story would have a happy ending if I hadn’t somehow wrecked the “admin” directory on the web server… The scripts I’m writing and troubleshooting for editing the schedule were coming along nicely yesterday afternoon. It’s the age-old battle (well, a few years is a long time in Internet history) of Form Posting an CGI parameters that I never mastered completely in hopes that a better way would come along. And, honestly, PHP makes picking up the parameters much easier. But I still have this byzantine network diagram of all the ways one script can submit form details to another, and all the different SQL queries each page has to run based on different parameters. As long as the code doesn’t screw up the HTML tags too badly, the CSS file can render everything in harmony and I can move on to thinking about Javascript enhancements.
Then I broke it.
Now I’ve got an entire directory that I can ftp from and to, but won’t load in a browser. So I can’t run any of the scripts at their permission level. And that is all the scripts I just wrote. Fabulous.
I thought it was just the browser. That director is password protected, so it doesn’t affect any customers. But that was a clue: maybe the browser got confused about password management. Restarting Firefox didn’t work. Loading it from my laptop didn’t work. Trying IE didn’t work. I just kept getting “500 - Internal Server Error”. I doubt having shell access would even matter. The server configuration files would still be beyond my reach… I think. Well, forget it: shell access cost extra.
So, I just took a deep breath and hoped that a good night’s rest would solve the problem. The server and I could wake up refreshed and get back to business. It was not to be.
There is a distinct form of embarrassment in dealing with the first responders at a big Internet hosting company. They aren’t the engineers, so they don’t get the benefit of my clues. They just seem puzzled, then eventually decide to “escalate the ticket”. I just know it’s something simple, but my operator doesn’t have any background. He can’t eliminate ridiculous possibilities out of hand. And, he is not at liberty to try solutions and note the result. Even minor solutions. He is, essentially, on the outside, just like me.
I Hear Back… Gee, Thanks.
I got an email back from the engineers a few minutes ago. They diagnosed the problem, and closed the ticket.
“The error you are encountering is caused by a bad .htaccess file in your /htdocs/admin folder. If you repair or remove this file, your issue will be resolved.”
Okay… That file is the password protection for the directory. So I’m not getting rid of it. I want to repair it. I didn’t mess with it in the first place. They discourage you from dealing directly with these files anyhow, and they’ve chosen an odd time to assume I have technical mastery over the idiom. If you’ve been reading this blog, you know that I’ve struggled with .htaccess files here on this server.
I think that they’re brushing me off as someone who modified his file, and therefore deserves his fate. But I didn’t modify that file, the only changes I ever made to it were through their hosting management web interface. I’ve looked at the file now, and I don’t see any damage. But, then again, how would I know? Maybe there’s some non-printing character code in there that I don’t see in my text editor. Maybe I need a hexdump (I could write a quick one in Ruby…)
Here’s the file in question, with some specific information redacted:
Options +Indexes
AuthType Basic
AuthName "restricted area"
AuthUserFile /data/10/1/66/160/XXXXXXX/user/XXXXXXX/htdocs/admin/.access.pwd
AuthPam_Enabled off
require valid-user
It reminds me of the time I learned the hard way that “make” files have to have Tab indentation. In the book it looked like spaces, and the error message just said it was wrong. This situation isn’t so different. There is no signature “way it should look”. I think I understand what each one of these lines does. I see one or two things I could try modifying. But, beyond that, I’m at a loss.
And I sure didn’t get any help from customer service. They took six hours to tell me that my first guess was correct, and that they couldn’t be bothered to give me the help I was so implicitly asking for.
A file very much like this one was doing its job perfectly. What changed? How did it change if I didn’t consciously make changes? Did my FTP client freak out and go modifying files. I wouldn’t be surprised if it did… There was a small incident yesterday afternoon - but I was in a different directory altogether, and I aborted the moment it started prompting me about other files I wasn’t working on. No, customer service - a place I might have to call once a year - should be happy to help me untangle the mess, even if I made it. This is no-fault territory. I’ve got a job to do and I sometimes don’t have much choice but to rush through it. Because the rest of the time I can actually take care of myself.
And, Another Thing…
When I get such a glib response, I can’t help wondering if they didn’t delve deeply enough into the problem. What was their thought process? Was it radically different from mine? Did they think up several different possibilities and work by a process of elimination?
They might have missed several interesting things that are not my fault.
And is customer support about placing blame?
Posted in web-craft, olssons | no comments | no trackbacksPosted by Evan Bittner
Thu, 11 Sep 2008 14:48:00 GMT
I started looking at a tutorial for JQuery yesterday, and now I’m convinced that it will be a good framework for some of the site work I need to do at Olsson’s. I have a suite of backend database manipulation pages I have to write because I need to spare some people the anguish of using the MySQL-PHP interface - It’s far too complicated for the limited interaction I need these people to have. Who am I talking about? Oh, they’re casual data entry clerks who have other things to do with their time than listen to me yell at them for deleting a database table by mistake. That interface is great for the all-powerful wizard - I use it to try out a lot of database design - but, I need to set up a whole middle level of interaction, and that means writing a bunch of PHP pages behind the password wall, with only the SQL queries my code allows.
And with that middle level, I am tempted to provide a lot of user-friendly features. Good feedback for when changes are made, fancy date selectors, collapse and expanding page elements. So it’s a whole mess of Javascript, right?
Not so Fast… This is about the time I read about JQuery. It’s a whole mess of Javascript! AHEM. It’s a prepackaged library of Javascript with simpler document object handling and a dot-chained syntax not unlike Ruby. Okay, a lot of you didn’t know how significant that is, but the main thing to take away from all this is that I think I will be able to learn JQuery very fast since it shares a certain look with Ruby that I am already comfortable with. I had been dreading what I assumed would be reinvention of the wheel, but now I’m not.
Posted in web-craft, programming, olssons | no comments | no trackbacksPosted by Evan Bittner
Thu, 04 Sep 2008 22:35:00 GMT
Before I go to Dupont to fiddle with the label printer again (stage whisper: It turned out that I used the wrong cable, so I’m going to string some Cat-5 today. However, there were other interesting problems that also prevented it from working…), and get home too late to start laundry again, I thought I’d prepare for the imminent disaster of dropping the partner site at the end of the month…
I have to write my own event schedule system, and here it is so far.
All my complaints about the current system can now be addressed in the new one. On the other hand, I have to work fast if I want it to work at all. So far so good.
I keyed in some of the data to the mySQL database at the web host, then I had to pull teeth to get my PHP script to connect properly. Part of the problem was my choice to set it up as a separate database. I used a new schema name, login and password. Then I forgot that I was copying code with an old IP address. That had me stumped for a few days. I considered every problem, but I didn’t get every solution in the proper combination until today.
One really embarrassing thing about the current setup is the hand-typed dates. For some reason, they would not convert the date fields into human-readable form. I know how to do that in mySQL, so I no longer have to deal with things like “Wednesday, September 11, 2008”. Inevitably, someone asks if we mean Wed 10 or Thu 11. But of course, the data entry person sees the day of the month they just specified in a drop-down menu, and is then personally responsible for figuring out the day of the week. Just have the computer do it!
Since I should know how to do it both ways, I wrote the front end in PHP - it makes for a simpler URL anyway. My wish list includes a bunch of stuff I think I’m going to implement in JavaScript - I thought about abbreviated listings that expand with a plus-sign button. The back end I plan to do all in Perl. Since it needs to be in a password-protected directory, and I already have that set up for some data export chores I had been doing, I have a perfect place to put it. The back end needs to be somewhat user-friendly for the data entry people. And, I need to be able to manage artwork and locations. I decided to use a table of locations where I could store related information that I can use for image tags, directions to the place, and hyperlinks. If you notice, the schedule - old and new versions - include a “Metro accessible” image for the closest Metro station. Since that doesn’t change much, I don’t want to make someone responsible for reproducing it themselves every time we key in a new event.
That means I get to write some awesome INNER JOINs in SQL.
Oh, and I guess I skipped over my story about how the database allowed me to name tables with reserved words that broke the syntax of the SQL statements. Why would it allow me to do that? Without a warning or anything. Who knew “EVENT” was a reserved word in mySQL 5.0? So then I had to use some ‘variable decoration’ for my table and field names.
Posted in databases, web-craft, olssons | no comments | no trackbacksPosted by Evan Bittner
Wed, 20 Aug 2008 20:19:00 GMT
For a long time I thought my role here on Earth was to understand the concepts. With exploration, then repetition, those concepts become familiar friends, supporting me in everything I try to do. Even when things work the way I expect them to, I like to consider the fringes, where anything might go wrong. Problems crop up when you don’t expect them, so it’s nice to be prepared.
Wherever I thought I was weak in taking action, it made sense to have a more solid grasp of the ideas behind the action… Well, it made sense to me. On a normal day it simulates an infinite regress into the netherworld of ignorance - me paralyzed by the bottomless pit of the unknown, and unable, really, to act at all.
Apparently, nobody else sees concepts as helpful support. This is made clear when the people around me get progressively more confused. Without those concepts, how is anybody supposed to digest the colossal blocks of information being served? Everybody needs handy ways of chunking, filtering and prioritizing all that information. I thought they called that “Education”.
It’s a personal prejudice, I know, but it is hard for me to accept when people balk at mastering something technical. I don’t expect them to get it right away… I understand that some things take time - these are usually things that it took me some time to learn, let alone master, and I know that a particular person, learning a particular thing, may never get the whole way. But, in many of these cases, part way would actually help out a lot.
If (hypothetically) you’re my boss, and you want me to find ways to reduce the cost of the company website, the least you can do is figure out the broad strokes of our current situation, and how to communicate with me. Your misconceptions are just more work for me. And if you’re going to be ignorant, that’s fine - as long as you respect your ignorance.
Is this making sense? I only ask that people not try to walk around in boots that are too big to fit.
Please don’t let technical details confuse you: Cut everything back to the basic concept. Master that concept. Then take the next step. Refine as you go along.
My boss just demonstrated how profoundly confused she was about where our company website resides. We went over this two years ago! It was a painful process, and I shudder to think that after all those discussions, she has simply forgotten what is involved. To this day, a bill for web hosting can cause a whole new round of soul searching based on terrible misunderstandings of who we pay and for what service.
In the mean time, I’ve only become better at explaining it all. Every file transfer; Every database record insert or query; Every patch to the scripts or styles: It all caused me to consider the structure of what we have, how the parts work together, and what I might do in a contingency.
It all reflects my odd personality. I can’t just do anything. I wonder at the surrounding network of knowledge and ability, and I wonder at the inner workings. I am Extensive and Intensive at the same time. Depth and Breadth.
Posted in ontology, web-craft, olssons | no comments | no trackbacksPosted by Evan Bittner
Mon, 04 Aug 2008 16:46:00 GMT
Web site maintenance can be easy some days. And then, there is today…
I have been dragging my feet on the latest re-design project. It is surprisingly easy to update the main page on the site - it functions in many ways as a switchboard. And, a name change is easy to patch through the server because it’s the default page. Every other page links back to the default, not an explicit named page. I suspect there must be some .htaccess file tricks I can use. This blog in particular makes heavy use of redirection - that leaves a server log file full of plain names without file extensions, and that’s a bit annoying when I get to the site statistics.
But I should explain the redesign: I wrote about it here and here. Briefly, I was getting ready to recast the Olsson’s pages in PHP, for no greater reason than to use the ‘include’ function to store common chunks in named files - all the better for those following after me to understand their purpose at a glance. It was also an inspired bit of “Refactoring”.
This week, I got some redesign instructions from the Marketing Director, and (finally!) some feedback on the new design. So, basically, I have the go-ahead to update the ‘department’ pages with the new design. I don’t have to make them PHP files. I can always use script output for to make static pages and upload those. But, I made my decision. Now I’m not so happy.
Blogger Doesn’t Want Me To Change…
This afternoon, I finalized the department pages: Books, Music, & DVDs. Now all I have to do is update the navigation bar on every static page and partner site. Some of these updates were simple, easy, clean and fast. Blogger.com has so far been none of those.
I’m starting to rue the day - and it’s still the same day! Ignoring the potential “.htaccess rewrite rule” solution, there was a small change I had to make to the navigation anyway - no escape for me on that one. I haven’t tried to publish several blogs at a time for months now. One is bad enough. Seven is a disaster (this includes the obsolete ones… can’t have them pointing to the wrong place, too). Recently it seemed like the publish problem had cleared up. Today it seems as bad as ever.
The worst part is that Blogger goes to a lot of trouble to present the illusion of work being done… and then nothing happened!
Posted in web-craft, olssons | no comments | no trackbacksPosted by Evan Bittner
Thu, 17 Jul 2008 21:50:00 GMT
I guess I always suspected this, but within a few days of deciding to protect the feedback form with a captcha, I spotted “How CAPTCHA got trashed” over at Computerworld.
Now I suppose it’s just another fun intellectual puzzle for me to get one working. Otherwise, the whole notion is one more flimsy barrier that might not get knocked down for a little while.
The sad part to me is the futility - wait, I’m not talking about the futility of doing my job, I’m talking about the futility of the spam itself - There are about three people in the organization that ever even see it, so it doesn’t reach a lot of eyeballs. It only gets in the way of doing work, and improves my chances of deleting real customer feedback when I’m click happy from deleting the junk.
Some of this was fresh in my mind from “The Future Of The Internet”. Zittrain mentioned the scripted outsourcing of challenges: Reward someone for answering the challenge (ahem - with naked ladies…) and send those answers back to the original. So that means that any conceivable challenge to prove yourself can be fed to someone currently surfing.
Posted in web-craft, olssons | no comments | no trackbacksPosted by Evan Bittner
Wed, 16 Jul 2008 18:28:00 GMT
I haven’t done any work on the feedback form yet, because I’m faced with choices.
If you’re a web developer, then you know: There are two sides to a form. The page or script that generates the fields for the user to fill out, and the action script. Or, as we might put it, the “Sender” and the “Receiver”. This is only mildly complicated by the fact that a script can be written to generate the “Sender” by default - i.e., if no form data is submitted.
Legitimate visitors to the bookstore site are presented with the form, fill in some details, click the “Submit” button, and the script is run. I’ve got some Javascript code to stop people from submitting the form without a name or a proper email address.
But who cares about the “Sender”! All the ways to abuse this system are crafted calls to the “Receiver”. It is up to the Receiver to handle every irregularity.
Enter The Captcha…
At the heart of it, a captcha is like a password. Every time the form is generated, it should include a random password - but the script needs to know, through some back-channel, what word to expect each time. If somebody is sending HTTP requests directly to the script, they won’t have any way of knowing what password to include, so each one of those requests will be ignored. I think there must be a simple way to send a hashed token or something. But this absolutely requires the page generating the form to run code. The embedded scripts (PHP, eRuby) are a natural for this. I already know that there has to be code to invoke the captcha.
Now that I’ve thought about it some more, I think I am going to move the form pages anyway. Any time you move files on a web server, somebody is going to have the old URL bookmarked or external sites are going to have it linked. At least I have control over the site linkages… I’ve been tempted to move a lot of stuff to PHP so I can take advantage of the ‘include’ function and store commonly used page code in named files.
Followup…
It is really annoying to work really hard on something and then wind up falling back to a second challenge. I’m still flying blind with the Perl module - I don’t know how to let the script find it on the server, and I have no reasonable way to troubleshoot the server error that always comes up. Heck, maybe I forgot a semicolon somewhere in the code.
Now I have a PHP version of the form in place and I can link to it later once everything else is ready. The “Receiver” script correctly verifies the captcha. Now I have to either rewrite the whole ‘email and log to a file’ bit in PHP - Or figure out how to reuse the Perl script I already had. Although, that’s not likely - as code that doesn’t strictly verify anything, it must be removed when I’m done. We have to climb into the boat that isn’t leaky.
The worst part is that I’m leaving a big mess to clean up. Lots of files to raid for code fragments. I’m going to have to clarify the dependencies and clean up what isn’t needed. I can’t do it until the whole project is finished, but I can scarcely remember what is what as it is.
Posted in web-craft, olssons | no comments | no trackbacksPosted by Evan Bittner
Mon, 14 Jul 2008 22:07:00 GMT
(Or, More Letters Home From The Turing Wars)
Statement Of The Case…
Spread out over the last week or so, we’ve been getting a rash of robotic spam form submissions on the server at work. This is nothing new, but the volume suddenly got taken to “a whole ‘nother level”. Mostly overnight, there would be about 150 form submissions with every field crammed full of random text. Back when these submissions were the rare exception, I thought it was in a non-Western script - like Chinese - but, I didn’t really think that, because it didn’t look quite like that either. I’ve seen plenty of Chinese/Japanese, two-byte, escape-sequence switched inline garbage, and it isn’t this:
Date: Sun, 13 Jul 2008 11:02:07 -0400
Message-Id: <200807131502.m6DF27Jr011874@vux.bos.netsolhost.com>
Content-Type: text/html
From: zvykfe@uxfteu.com
To: olssons@olssons.com
Subject: Website Contact Form
Website Contact Form Results:
Formtype = Mail Order Request
sourcepage = /mailorder.htm
Name = lqycwtz
Street = PNxLwkcb
Street2 = irCjUSMQRkAnVSE
City = ouKfcjAgA
State = ZpJcBWKg
ZIP = VXvQpwIHsNsyJUP
Country = ZjpNTNseqWVIkCwyyCN
email = zvykfe@uxfteu.com
Phone = ICASVfjZHBIxHkqZs
Fax = bdcAxUHI
Product = CD
Title = aAjpwjbcLFB
artist_author = lqycwtz
Questions = pogWS3 ...
They came in all night long, several nights, at ten minute intervals, not always just one at at time. It was relentless. I had them cleaned out of my inbox in a couple of minutes, but there are several people who monitor that email account, so it inconveniences more that just me - and I get copies at home and at work. Oh, and lest I forget: After my last round of trouble with the script, I started sending them all to a log file for backup. Now if I’m not careful, there can be a megabyte of junk in there.
Usually I would just ‘grin and bear it’, but how could I pass up the opportunity to install a Captcha box on the forms and maybe learn something valuable in the process?
And Then We Get To The Crux Of The Matter…
It seems like it ought to be very easy, but it isn’t. I appear to be hobbled by no permission to install Perl modules. If I even knew where to put them, I don’t have command line access for that server (we’ve been over this _so_ many times). I’ve got working Perl scripts on the server, but they can’t do anything beyond core modules, or whatever other wonderful things are secretly installed. The action script on those forms is a Perl script, and I stuck the module in a couple likely directories, but no dice: Merely adding the library call causes a server error. So that library isn’t in the right place, or in the right form, or something. This is one of those times where it probably doesn’t even help me to know the right answer - it will turn out to be something I don’t have the permission for anyway.
So then there’s PHP. It gets a little weird when I think about all the trouble these people went to write sample code when that code is the least of my worries. With a good manual page on the interface, I can write all the code I need. But, I also have to be able to effect a lot of behind-the-scenes magic. Like installing Perl modules. Bear with me while I brainstorm…
The original page with the form has to call out to the mothership for a freshly created random captcha box. I’ll need a strategy for this: either rename and re-link to a PHP file instead, or build the form in an IFrame. Pages that were happily static suddenly need to be dynamic. Is PHP passing all my HTML files? Could I have always included PHP code in all my static pages without renaming them? My guess is “NO”, because it would slow down every static page, but then there ought to be a way for me to switch this on and off - I might change my mind some day… It’s a hundred times faster for me to experiment then it would be to have someone answer my question…
And the answer is “NO”. I know from fussing with Apache settings on this server that I don’t have access to that sort of thing at work. So I won’t have PHP preprocess all the HTML files anytime soon.
I think of PHP as a toy. That’s because I have Perl. But Perl in this case is like a nice set of precision tools - they’re just locked away in a cabinet so I can’t injure myself. The toy label is probably unfair, but it’s time to see what the toy can do. Immediately I have to build the PHP version of the form. After that, I have to rewrite the action script, since I know I can’t make one work in Perl anyway. Hmmm… I’m not sure that I’ll get to that today.
Hey… I know you can’t see it yet, but this Captcha version I found at Carnegie Mellon has a color scheme just like ours. And now that I actually stopped to read the thing, it appears that the challenge-response process give them data-points for improving their OCR system for automated book scanning. Only this morning I was reading the part in “The Future Of The Internet” where Zittrain talks about the creative ways people have used Captchas for distributed efforts at OCR - or, more ominously, outsourced Captcha response to click-workers in a sweatshop somewhere so that their spam can go through anyway.
Posted in programming, web-craft, olssons | 2 comments | no trackbacksPosted by Evan Bittner
Sun, 13 Jul 2008 18:47:00 GMT
