• P (unregistered)
    <li class="control-group input_id_honeypot 
            <label for="id_honeypot">If you enter anything in this field your comment will be treated as spam</label>
            <input type="text" name="honeypot" id="id_honeypot" value="frist"/>
  • Anon (unregistered)

    If you add a comment to this page, it will be treated as spam.

  • tbo (unregistered) in reply to Anon

    To be fair, most comments on this site add nothing to the conversation and aren't much better than spam to begin with.

  • WTFGuy (unregistered)

    (Hoping my attempt at markdown syntax works sorta as expected ...)

    Actually, we don't know whether the label and field are visible or not. Pitor probably knows, and Remy might know, but we don't.

    All thanks to the hideously unbalanced 3-legged stool we call modern web dev, where there's HTML as modified by CSS as further modified by script. Even back in the Dark Ages of Ye Olde COBOL we understood that self-modifying code was a bad idea. And now we've elevated it to the dominant paradigm.

  • (nodebb) in reply to tbo

    To be fair, most information on the internets add nothing to the conversation and aren't much better than spam to begin with.

  • Carsten (unregistered)

    Actually without the style definitions for control-group and input_id_honeypot it is hard to judge as they may have rather used CSS to hide it from the user. Which is probably even cleverer than flagging it as hidden as there are endless ways to do it and very hard to detect by any bot without a render engine.

  • (nodebb) in reply to Applied Mediocrity

    Most "information" is everywhere is wrong. It's a lot easier to be wrong than to be right.

  • (nodebb) in reply to Mr. TA

    To be fair, all information everywhere is based on the presupposition that truth is knowable. If you disregard this axiom then all information is exactly equivalent to spam.

  • (nodebb)

    @Zacrath Doesn't that axiom apply to your statement itself?

    Sturgeon's Law: 90% of everything is crap.

  • Argle (unregistered)

    Regarding the original premise of the story, that of saving a few bucks on an expert, I once had this conversation with someone inquiring about my rates:

    Them: I could hire college kids for $15 an hour.

    Me: Good luck with that.

  • (nodebb)

    I like spam, spam, spam, spam, spam, eggs, and spam; but hold the eggs.

  • I can be a robot if you want me to be (unregistered)

    Then next week we'll have a story about a web development shop writing the same type of code.

  • DedicatedHosting4u (unregistered)


  • Brendt Hess (unregistered) in reply to WTFGuy

    Even back in the Dark Ages of Ye Olde COBOL we understood that self-modifying code was a bad idea.

    No. No they didn't. Back before the dawn of time, when I was working for a timeshare company running on PDP 11/70s, I had to modify an arena ticketing system used by an unnamed NBA team. It used ALTER statements on GOTO statements throughout the code. This had started out as a ticketing system for a very small venue, somewhere in the Midwest, about 20 years before I got my hands on it. It had gone through at least a dozen other venues before The Team picked it up.

    It was everything you see on TheDailyWTF, and more. Arena sections? Hardcoded. Ticket prices? Hardcoded. Variable names? Short and indecipherable (in COBOL CODE!?!?!). But, unfortunately, I was the only person in the company that had any COBOL training or experience, so it fell to me to do this. But debugging through the ALTER statements was just a nightmare. I attended yeast poo therapy after that project.

  • sizer99 (google) in reply to Brendt Hess

    For those who haven't seen this horror, this is how ALTER works:


    LABEL-A. has now changed from 'GO TO LABEL-B.' to 'GO TO LABEL-C.' Yes, it uses PROCEED TO instead of GO TO. Now just try debugging that after a couple of these get done in some obscure corner of the code.

    So COBOL is actually one of the very few languages that has a keyword to explicitly self-modify code. Whyyyyyy? Well, when you have punch cards, running the whole stack through each time gets really time consuming (and error prone, and the cards wear out). So this lets you hot-patch your existing code by just feeding in a few more cards.

    Eventually when people were no longer using punch cards they deprecated it, but most compilers will still support it because you're using COBOL precisely because you have 60 year old code to run.

    Addendum 2019-06-13 19:55: This bastard comment system formatting always ganks me. Just imagine each . has a newline after it.

  • Webdev (unregistered)

    I've seen many variations on the honey pot input fields. Most of them hide the element using CSS to put them under other elements so the user can't see them, or else pushing it 9999 px to the left.

  • Gordon JC Pearce (github)

    Actually the "honeypot field" idea is pretty standard and works extremely well, because spam bots don't use CSS - so they won't see the field has { display: none: } set in the stylesheet - and they will attempt to fill in all fields.

    For such a stupidly obvious thing, it's incredibly effective. Like, 99% effective, for almost no effort.

  • RLB (unregistered) in reply to sizer99



  • DCL (unregistered) in reply to sizer99

    I can 'improve' on that example. Some old COBOL compilers I worked with, allowed you to write: "LABEL-A. GO TO." without specifying a target label. The first versions of the compiler I worked with defaulted to falling through to the next instruction. Later versions of the compiler changed that behaviour by branching to an 'unpredictable' target which led to some interesting bugs if the program didn't crash when executing the uninitialised "GO TO." Cue the wails of "But it worked before we recompiled the program for an unrelated change'.

  • sizer99 (google) in reply to DCL

    Yow, that's pathological design. I mean, I can see the intent: 'GO TO (nothing).' signals you intend it to be an ALTER target, but falling through is a good default (internally, the compiler just does 'GO TO (next line)). Jumping to whatever uninitialized memory address was there is not a good default.

  • WTFGuy (unregistered)

    Since I was the guy who brought up COBOL ...

    Agree that ALTER was a bad idea when it was introduced in 1960-ish. And that a lot of code created in those early days used it. OTOH, when I first got into COBOL maintenance in 1975-ish, the one thing we'd all learned from hard experience was not to use that abomination on any new code. To the degree refactoring was done at all (although not by that name), removing ALTERs was a common goal. At least at my shop.

    I agree with sizer99 that in a backwards sort of way, the targetless "GO TO." in source code is safer/smarter than the targeted "GOTO LABEL-X." that is subsequently ALTERed to branch elsewhere. Better to tell the reader up front that it's a dynamic branch than to have them naively believing that it's a static branch. Doubly so remembering that we had no IDE's in those days and you might be thumbing through a 1/2" or 2" thick green-bar printout trying to locate by eyeball all the places that just might contain an ALTER.

    Sure, it's a total foot-gun. but at least it's prominently labeled as such. Stealth foot-guns are so much more destructive.

  • Little Bobby Tables (unregistered) in reply to Brendt Hess

    TIL: "yeast poo therapy".


  • medievalist (unregistered) in reply to DCL

    This is why I have never allowed COBOL to appear on my resume. Those days are not to be known!

    (Of course in DCL it wasn't hard to write self modifying code either!)

  • Gerry (unregistered)

    Way to many years ago (1985ish) I worked in a COBOL shop - as an operator, not a developer.

    I recall one of the devs saying that after a couple of weeks (or whatever) of trying and failing to decipher how an old program worked, they rewrote it in a day.

Leave a comment on “The Honeypot”

Log In or post as a guest

Replying to comment #:

« Return to Article