meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Archive: January 2005

Be A Parent

The Rogue Librarian is back!  And, as it happens, pointed to a New York Times article that just completely set me off.  (Yes, it requires registration to read the article, but then, said registration doesn’t necessarily have to be your own.)

I was experiencing a mixture of bemusement and wariness about the sites mentioned and what they chronicle, but then I hit the rationalizations in part 2, and that’s when my fuse got lit.  Here’s the first spark:

“A blog like this is narcissism in its most obscene flowering,” [Ayelet Waldman] said. “But it’s necessary. As a parent your days are consumed by other people’s needs. This is payback for driving back and forth to gymnastics all week long.”

You know what?  Boo [censored] hoo.  Being a parent means, to some extent, suppressing your personal needs, desires, and expression for the good of your children.  That’s pretty much A-number-one on the list of job requirements.  If you feel like you have to pay back your children for your having to drive them back and forth to gymnastics, then odds are you made a very poor choice in becoming a parent.  And your children are the ones who are most likely to end up paying for it.

Blogging about little Johnny’s poopy diapers, or Susie’s apparently sourceless temper tantrums, is in no sense of the word necessary.  It isn’t even needed, either by you or by the rest of us.  If you absolutely must write down your thoughts and feelings about how hard it is to be a parent, do so in a private journal.  Fifteen years from now, you can decide whether or not to give it to your child, and if you do, they can decide what to do with it.  But don’t throw it out into the world as if it were a list of your favorite movies.  That’s unnecessarily cruel.

As the article’s author observes:

How will the bloggee feel, say, 16 years from now, when her prom date Googles her entire existence?

That’s definitely a point of concern, and one I’ve been conscious of from the beginning.  More to the point: how will the bloggee feel to discover that he or she was, without any consent or consultation, made an object of scrutiny, laughter, scorn, wonder, and general comment to anyone who might drop by?  How many of us would like to have our lives chronicled and published without our consent, let alone our input?

Which leads us to the next bit that drove me up a wall:

At some point, however, parents may find themselves at a crossroads. Molly Jong-Fast, who has been a frequent subject for her mother, Erica Jong, said, “There comes that inevitable moment when parents who write about their children need to choose between their writing and their children’s privacy and honor.” Ms. Jong based a children’s book on her daughter as well as a pilot for a Fox sitcom. “There’s no compassionate way to do both, so either the parent or the child will end up feeling resentful.”

I can barely believe this was even raised as a potential issue.  You choose in the child’s favor. End of story.  If you can’t do that, and especially if you can’t do it without feeling resentful about it, then it’s long past time for you to suck it up, get over yourself, and seriously consider therapy.

Your child is not perfect.  Parenthood is not a sun-filled meadow of joy.  Raising children is not easy, and it isn’t a smooth ride, and you aren’t going to make the best decision every time.  There are diapers to change, mouths to feed, tantrums to weather, and sleepless nights to endure.  You don’t get to be yourself any more, not completely.  Not the way you used to before the baby.  That isn’t how it works.  Furthermore, you are not uniquely suffering, because this is how it’s been since humanity became sentient, and definitely how it’s been since civilization emerged.  So deal with it.

It’s true that many parents have, for all that time, talked with their family and friends about the challenges of being parents.  The difference is that those conversations were conducted within a social network of people who could help the parents out, and knew when to be discreet.  To blog the every detail of your baby’s life, though, is making a spectacle of your child for your own benefit.

For that stunning degree of selfishness, and for the damage I fear it will cause the children thus forced on display, I weep.

You may wonder where I get off being so hypocritical, since I write about Carolyn here from time to time.  Feel free to read what I’ve written, and see if you think I’m putting my writing above her privacy and honor.  If indeed I am, then some of my anger needs to be directed inward, and I need to change my behavior.  I can accept that, and should I need to, I will do so without resentment.

Because that’s what a parent does.

Password Production

Since I’ve been futzing about with human-friendly security of various forms recently, it occurred to me that I ought to pass along a password-generation technique I’ve used for years now.  Maybe it’s a well known technique, and maybe not.  In any case, my best recollection is that I learned it from either John Sully or Jim Nauer back in my CWRU days.

The general idea is to pick a two-word combination you can easily remember.  For example, suppose you’re a big fan of pizza and Pepsi, and would have no trouble remembering those words.  Perfect: use them the basis of your password.  No, you don’t make it “pizzaPepsi”—instead, you interleave the words.  That would yield “pPiezpzsai”.  It looks fairly random, and yet is very easy to recreate because the seed words are so easy to remember.  If you have trouble remembering the exact sequence of letters, you can just write the words down on a piece of scrap paper and follow along.

In cases where your two words have different lengths, you can always tack on numbers.  For example, maybe your seed words are “milkshake” and “fries”.  That would normally yield “mfirlikesshake”, which is okay, but you could tack the numbers “123” onto “fries” to get “mfirlikessh1a2k3e”.  Alternatively, you could put the numbers at the beginning, so you get “m1i2l3kfsrhiaekse”.

I’ve found that when I start using a new password created this way, it takes me a few days to adapt to it.  I usually have the seed words written down some place handy during that training period.  Then my fingers take over, and from then on I can type it blindfolded in less than a second.  I don’t even think about the actual characters I’m typing: I just start, and the muscle memory kicks in.

So if you’re looking for a way to generate harder-to-crack passwords, there’s one possibility.  How about you—do you have any nifty human-friendly password-creation recipes?

S5 1.1b4

As promised, I now draw back the curtain on S5 1.1b4 (try the testbed online, or download the 263KB ZIP file).  Here are the changes from 1.1b3:

  • “Meta” keys—function keys, command, control, alt, and option—should no longer be trapped by keys().  Thus, for those of you who discovered that you couldn’t use command-W to close the window in Firefox/OS X, that should be fixed; hitting F11 to invoke full-screen mode should also work; and so on, and so on.

  • While I was at it, I restructured keys() so that the only keystroke S5 pays attention to when in the outline view is “T”, to let you toggle back to the slide show view.  Anything else gets passed up by S5.  Despite this, Safari is still ignoring Page Up and Page Down while in the outline view.  I can’t for the life of me figure out why.

  • At the suggestion of Romain Herault, I’ve modified clicker(e) so that it will ignore clicks inside of embed and object elements.  This will allow you to interact with an embedded object, like a Flash file or a video, without advancing the slide show.

    I’m aware that some people have run into problems adding videos to their presentations, but I’m not at this point able to take on the task of analyzing the problems and figuring out potential solutions.  If someone else wants to work on fixes, there’s every chance I’ll be able to get fixes into the next version of S5, but very likely not this one.  I have a similar stance regarding the long pause of unstyled content while the presentation loads.  If someone devises a fix, I’ll study it for inclusion in the next version.  I personally don’t have a problem with the pause, but I realize there are those who’d like to eliminate it, and if it can be done without causing problems I’ll certainly add it.  Just likely not in this version.

  • PNG alpha channels are now honored in IE/Win, if only for img elements and not backgrounds.  You can see this happening on slide 5 of the testbed.  Woohoo!  This happens thanks to Erik Arvidsson’s pngbehavior.htc, a copy of which now resides in the default directory.  It may one day be replaced with IE7, but we’ll burn that bridge when we come to it.

    The one sort-of drawback to using this approach is that it seems to require that the call to pngbehavior.htc sits in an embedded style sheet, or else nothing happens.  This may very well have to do with the way the JavaScript monkeys around with external style sheets during startup.  If any of you IE/Win JS gurus can figure out a way to get the behavior to fire without having to embed it into the presentation, that would be stellar.  If not, it’ll just be documented as a “leave this in if you’re using alpha PNGs; otherwise you can take it out” thing.

One thing I’m still thinking about changing is the handling of the Home and End keys.  Right now, they move you forward or backward by one slide, just like the arrow keys and several others.  I’m thinking of making them jump to the first or last slide instead.  I’m hesitant because making the change means it would be much easier for a presenter to accidentally jump to the beginning or end of a slideshow with a single keystroke, and you can already easily jump to any slide by typing the slide number and hitting Return.  On the other hand, it’s a functionality that makes general sense, and it makes it much easier for a presenter to intentionally jump to the beginning or end of a slideshow with a single keystroke.  What are your opinions?

At this point, I would anticipate that 1.1 will have one more beta version to eliminate any bugs that are discovered as well as adopt any optimizations, and then it’ll go final.  I know there have been other feature requests (and may be more on this post, which is fine) but it’s really late in the beta cycle to add anything else.  Any new features will have a chance to get into the next version.

S5 Update

I know it’s been a while since the last beta version of S5 was released, but between doing client work, flying to and from Albany (speaking of that, big ups to Dan “So Fine” Feinberg, Ed “The Shark” Skawinski, Ric “Darin” DiDonato, and the rest of the ITU Crew), diversions into PHP hacking, judging a markover contest, starting ballroom dancing classes, and spending time with my family, time has been a wee bit tight.  Things will only get worse once March rolls into town, so I’m going to try to push 1.1 into final status before February is done.

In the meantime, I wanted to point to some cool things that I’ve heard about with regards to S5.

  • S5 was adapted to create an online tour of Epocrates, a popular medical reference package for handhelds.  Kat uses it, as a matter of fact.
  • Ludovic Dubost, developer of XWiki, created an XWiki-based S5 creator, which you can read more about in his blog entry about it.
  • Pelle Braendgaard launched soapbx.com, a Web-driven S5 editor.  You can pick a theme, write the content in a wiki-like form, and get a slideshow.  It was apparently developed using Ruby On Rails.
  • Not quite ten hours after getting Pelle’s e-mail, a message from Lucas Carlson arrived regarding the creation of his own S5 creator: s5presents.com.  It too was developed using Ruby On Rails.
  • Earlier today, Eric Eggert reported that S5 got coverage in the German version of Internet World magazine.  I’m sort of hoping to see a scan of the article at some point.  (Is it copyright infringement if I possess a scanned copy but can’t understand what it says?  Just wondering.)  Update: I’ve seen a copy of the article, so there’s no more need for scans.

In other, less specific news, I know that people have created or are working on creating translators of one kind or another.  A popular request seems to be an OPML-to-S5 translator of some kind, and there’s always the Keynote-to-S5 idea.  So I’m going to throw open comments for people to post links to S5-related projects, translators, and what have you.  Heck, if you’ve recently done a presentation using S5, let’s see it, especially if you created a new theme.  Just please leave this post’s comment clear of bug reports or feature requests.  As of this writing, you can drop those on the S5 1.1b3 post, or else wait for the forthcoming post on 1.1b4.  I hope that’ll go up in the next couple of days, but no promises.

Gatekeeper In Perspective

So when I said on Monday:

Got feedback?  Let’s hear it?

…what I actually meant was:

Got feedback about the code or how the package works once it’s installed in WordPress?  Let’s hear it.

I should have realized that otherwise, the comments would turn into an argument about comment spam, fighting it, ways the general idea could be defeated, and more.  Which they did.

Look, folks, despite what some people might tell you, I’m not so arrogant as to think that I could single-handedly solve the comment spamming problem for all time.  Even if I were, I very much doubt I’d be so clueless as to think that WP-Gatekeeper was that solution.  And if both those things were the case, I’m pretty darned near certain I would have very explicitly made the claim of having beaten the spammers.  Likely in big, boldfaced, red, capitalized, blinking letters, plus a background MIDI of “We Are The Champions”.

WP-Gatekeeper is not going to stop every possible comment spam attack, human or automated, for the rest of time.  Neither is any other defense you can name, without exception.  There may be measures that currently have 100% resistance to scripted attacks.  They will one day fail—I can pretty much guarantee it.  Even today, they are defeatable by actual humans sitting at computers and posting comment spam on every site they find.  That kind of spamming is very, very rare, but it happens.  I had such an incident within the last month.  If I hadn’t been keeping a close eye on new comments just then, I’d likely have missed it completely.

I’m fully aware that there are ways a spambot could defeat WP-Gatekeeper.  At the moment, none of them can.  That will one day change, of course, assuming challenges become at all popular.  Comment spam and the fighting thereof is a dance, a tennis match, an arms race.  Neither side will ever win.  As one side adopts a new tactic, the other side will move to counter it.  The countermeasure will itself be countered.  And so it goes.  Eventually, either spambots or spam defenses (or the two in combination) will become so advanced that they’ll gain self-awareness, and then we’ll all be royally hosed.

I know this.  You know this.  Let’s move on from there, okay?

In the end, the goal is to add another arrow to the quiver at the disposal of spam fighters.  Think this approach is wrongheaded, annoying, or otherwise pointless?  Fine.  Don’t use it.  For those who want to add this kind of capability—and since I instituted it on meyerweb, I’ve had not a single piece of spam make it onto the site or hit the moderation queue, whereas in my pre-defense days, I’d get at least twenty every day—then the package is there.  You can combine it with other defenses, if you like, for even more coverage.  I may upgrade it in the future, depending how far I get in learning PHP, mySQL, and form handling, and what feedback I get from people who know PHP better than I do.  I may not, in which case the system as it stands is effective, and probably will be for a while.  Even if I do one day abandon further development, the code is out there for someone else to improve if they so choose.

In the meantime, if there’s anyone who is using WP-Gatekeeper or has looked at the code, and has feedback on the coding or the way it works for the administrator of a WP blog, please feel free to share.  Also, if anyone can point me to an example of PHP code for collecting all of the HTTP_VARS that are returned by an XHTML form and then looking through them, even when the variable names aren’t necessarily known ahead of time, I’d really like to see it.  Thanks.

WP-Gatekeeper

In my post on rel="nofollow", I mentioned the use of easily human-comprehensible challenge questions like “What is Eric’s first name?” as a way to defeat spambots.  There were two points made in the comments that I had considered but hadn’t brought up, given that they were tangential to the point of the post.  They were:

  1. Spammers could set up a database of questions and answers used on sites.  They might or might not share it with each other, but the point is that if I set up “What is Eric’s first name?” as the sole challenge, the human running the spambot could build the ability to answer the question into the spambot, thus defeating it.  Quite true.
  2. In order to make it more difficult to do this, there could be a set of challenges from which one is picked randomly.  So I might have three challenges asking for the first names of myself, Kat, and Carolyn.  Every time a comment form is delivered to a browser, one of the three challenges, picked at random, is included.  This would make it more difficult for a human spammer, since he (or she) would have to find all of the challenge questions. work out the responses, and build them all into a database, keyed to each site’s domain.

So over the weekend, I built as a proof of concept (and also as an exercise in learning more about how PHP, mySQL, and WordPress work) a WordPress package to do what described in the second point above.  It’s called WP-Gatekeeper, available from my WordPress Tools page, and if you’re brave you can give it a try.  Why brave?  Because the installation involves hacking a few WP files and adding a new entry to the admin menu, not to mention firing up a plugin.  And if you do it in the wrong order, you can break commenting for a short period.  There are DIY installation instructions on the WP-Gatekeeper page, for those who still want to proceed.  You also need to be brave because if you install it, you’re running code written—well, actually, adapted—by someone with only beginner-to-intermediate PHP skills.  I’ve been testing it locally and everything seems fine, but this is even more “use at your own risk” software than usual.  Got it?  Good.

Accordingly, WP-Gatekeeper is currently considered beta software.  I’m making it available now in the hopes that people more experienced than I with PHP and WordPress can take a look, hack on the code, and make it more efficient and the whole package easier to install.  I’m already aware that in WP 1.5, adding the admin page is much easier and doesn’t require hacking files, but I wrote WP-Gatekeeper in 1.2 and want it to work there, since that’s the latest public version.  Thus, any optimizations should work in 1.2.  When 1.5 (or whatever the next version number is) comes out, then I’ll worry about it.

Of course, there’s still nothing that prevents a spammer from registering questions and answers into a database, but the admin page makes it easy for a blogger to add, remove, modify, and re-key the challenges.  That will make tracking them more difficult, so long as a blogger puts effort into maintaining the list of challenges.  It gets back, in the end, to maintaining your blog.  The more maintenance you put into something, the better its shape will stay.

I’m also interested in suggestions for how the overall system could be made harder to bypass with a bot, and easier for a WP admin to run.  One feature I plan to add before going final is the ability to have the keys replaced on a regular basis, with the interval (daily/weekly/monthly/etc.) set by the admin.  The  other driving consideration here is that the system should be fully capable of working even if JavaScript is disabled.  It’s an accessibility thing; just go with me on this.  (Accessibility is the main reason I did this rather than install an image CAPTCHA solution, as it happens.)

Got feedback?  Let’s hear it.

More Spam To Follow

So… rel="nofollow".  Now there’s a way to deny Google juice to things that are linked.  Will it stop comment spam?  That’s what I first thought, but I’ve come to realize that it’ll very likely make the problem worse.  In the last few hours, I’ve been hearing things that support this conclusion.

First, the by-now required disclaimer: I think it’s great that Google is making a foray into link typing, and I don’t think they should reverse course.  For that matter, it would be nice if they paid attention to VoteLinks as well, and heck, why not collect XFN values while they’re at it?  After all, despite what Bob DuCharme thinks, the rel attribute hasn’t been totally ignored these past twelve years.  There is link typing out there, and it’s spreading.  Why not allow people to search their network of friends?  It’s another small step toward Google Grid… but I digress.

The point is this: rather than discourage comment spammers, nofollow seems likely to encourage them to new depths of activity.  Basically, Google’s move validates their approach: by offering bloggers a way to deny Google juice, Google has acknowledged that comment spam is effective.  This doesn’t mean the folks at Google are stupid or evil.  In their sphere of operation, getting comment spam filtered out of search results is a good thing.  It improves their product.  The validation provided to spammers is an unfortunate, possibly even unanticipated, side effect.

There is also the possibility, as many have said, that nofollow will harm the Web and Google’s results, because blindly applying a nofollow to every comment-based link will deny Google juice to legitimate, interesting stuff.  That might be true if nofollow is used like a sledgehammer, but there are more nuanced solutions aplenty.  One is to apply nofollow to links for the first week or two after a comment is posted, and then remove it.  As long as any spam is deleted before the end of the probation period, it would be denied Google juice, while legitimate comments and links would eventually get indexed and affect Google’s results (for the better).

In such a case, though, we’re talking about a managed blog—exactly the kind of place where comment spam had the least impact anyway.  Sure, occasionally the Googlebot might pick up some spam links before the spam was removed from the site, but in general spam doesn’t survive on managed sites long enough to make that much of a difference.

Like Scoble, where I might find nofollow of use would be if I wanted to link to the site of a group or person I severely disliked in order to support a claim or argument I was making.  It would be a small thing, but still useful on a personal level.  (I’d probably also vote-against the target of such a link, on the chance that one day indexers other than Technorati‘s would pay attention.)

No matter what, the best defenses against comment spam will be to prevent it from ever appearing in the first place.  There are of course a variety of methods to accomplish this, although most of them seem doomed to fail sooner or later.  I’m using three layers of defense myself, the outer of which is currently about 99.9% effective in preventing spam from ever hitting the moderation queue, let alone make it onto the site.  One day, the layer’s effectiveness will very suddenly drop to zero.  The second layer was about 95% effective at catching spam when it was the outer layer, and since it’s content-based will likely stay at that level over time.  The final layer is a last-ditch picket line that only works in certain cases, but is quite effective at what it does.

So what are these layers, exactly?  I’m not telling.  Why not?  Because the longer these methods stay off the spammers’ radar, the longer the defenses will be effective.  Take that outer layer I talked about a moment ago: I know exactly how it could be completely defeated, and for all time.  Think I’m about to explain how?  You must be mad.

The only spam-blocking method I can think of that has any long-term hope of effectiveness is the kind that requires a human brain to circumvent.  As an example, I might put an extra question on my comment form that says “What is Eric’s first name?”  Filling in the right answer gets the post through.  (As Matt pointed out to me, Jeremy Zawodny does this, and that’s where I got the idea.)  That’s the sort of thing a spambot couldn’t possibly get right unless it was specifically programmed to do so for my site—and there’s no reason why any spammer would bother to program a bot to do so.  That would leave only human-driven spam, the kind that’s copy-and-pasted into the comment form by an actual human, and nothing besides having to personally approve every single post will be able to stop that completely.

So, to sum up: it’s cool that Google is getting hip to link typing, even though I don’t think the end result of this particular move is going to be everything we might have hoped.  More active forms of spam defense will be needed, both now and in the future, and the best defense of all is active management of your site.  Spammers are still filthy little parasites, and ought to be keelhauled.  In other words: same as it ever was.  Carry on.

NEOAC Talk

Just a quick note for people in the Cleveland area: I’ll be giving a talk this Saturday, 22 January, at the meeting of the North East Ohio Apple Corps in Strongsville.  The topic will be turning your Macintosh into a powerful Web development environment using resources, scripts, tricks, and tools available for free.  If you’re interested, drop by, and if you need directions, check out the NEOAC Web site.  I’m told that there will be donuts.  Mmm…. donuts.

January 2005
SMTWTFS
December February
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Archives

Feeds

Extras