Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

· Slash
· use.perl.org
· Slash
· Pudge
· Perl
· Slash
· P
· More on use Perl
· Also by pudge

Funny Little Images

posted by pudge on 2002.04.17 13:35   Printer-friendly
use Perl
We have funny little images on use.perl.org for posting comments, making new users, and requesting passwords. They are intended to make sure you are a human and not an automated bot. They are here for testing, so if you hate them, don't freak out; we will only use them on a permanent basis if we have a problem with bots, which I don't anticipate. We are just testing some Slash code; so feel free to let me know here your experiences with it. Update: 04/19 12:41 GMT by P : The test is over, the images are gone now. Thanks for the feedback.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Funny Little Images 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Personally, I think the images are a waste of time. merlyn (Randal Schwartz) did a column in Web Techniques for the same basic thing.

    Never one to resist a pointless challenge, before the article hit print, I wrote a "cracker" for it. The write-up is here [perlmonks.org], for those that may be interested.

    You're going to have to get a lot more tricky than 3 letters with a consistent font to stop a 'bot. Most of the time is invested in creating the font table, but once you've got that, the pattern matching is trival.

    --jcwren

    • Did you try it on the images here?

    • No, mostly because I'd have to build the font maps. But in loading the images several times, the fonts all appear consistent, along with their positioning. The slight color in the background is easily worked around.

      The down side to the images is that it makes posting with lynx pretty darn impossible. And considering that a great many Perl users are *nix users, that doesn't seem like a nice thing to do. Even if lynx *does* represent a small viewer-shared.

      --jcwren

      • As to whether it is not nice for the users, that's not relevant to anything in particular that we're doing right now. Sites don't have to use this. As I said, we are testing it. I don't know of any site that we are working on that will turn it on for posting comments on a regular basis.

        And I do doubt how "easily" you could work around things. What if every letter were a different color with a different background, with dithering all throughout? As Jamie notes, it's trivial to add things like that, and
        • Could somebody shoot Tim Berners Lee so he can turn in his grave!

          Am I missing something or is this a big two fingers to blind users? Maybe you could put the letters in the ALT tag ;-)

          Helping put this in slashcode is just as bad as Adobe allowing publishers to disable "Read Aloud" on their e-books. The argument that sites/publishers don't actually have to use it is no more a defense for slashcode than it is for Adobe.
          • We're not happy about its effect on blind users, but images are not the only possibility for this kind of verification. We hope in future to offer alternate methods -- I'm thinking audio snippets, in particular. We can also set up a method for admins to exempt particular accounts. Etc.

            The nature of the internet is that it's trivial to DDoS any site that allows anonymous or semi-anonymous postings. Some Slash sites are actively targeted by hostile users for scripted attacks, and those sites need defenses.

            • I wrote a long (constructive) response to this but the combination of IE and the absolutely shit bag of a Chinese internet cafe I'm in just ate it on me!

              Basically it amounted to doing a few checks on the recent history of the IP address an account is being registered from or a check on the history of a doubtful account (all new accounts being doubtful until they prove themselves). If the checks fail, then get them to pass a humanity test.

              This should mean that a blind person would have to be unlucky when j
          • It's like the ability for an administrator to remove comments. It's probably a bad idea to use in most implmentations, but some possible uses of Slash might need it.

            From what I understand about Slash (having no more experience than reading the book) the code base isn't intended to enforce any policy on the admins of Slash systems. That policy is up to the admins - the code gives them the freedom to make their own decisions.

            • I just think it's a bad solution to the problem. Jcwren has already very quickly cracked it and making it harder to crack just excludes an even larger section of sight-impaired users.

              And when a DOSer does finally crack the latest version. you're goosed again until you can find some other way of obscuring the letters and thus exclude even more people!

              Monitoring account creation activity and the posting activity of accounts that have yet to prove themselves would be a much sturdier way of doing things and d

      • Don't forget links [mff.cuni.cz] (which I've come to like better than lynx; handles tables better) and w3m.

        As a sugguestion, maybe have an option / configuration value / something that it gets turned off after you get x karma. That way you get the benefit of suppressing automation from new accounts, but long time users aren't inconvenienced.

      • Maybe Slash could have an option to display the image as a text based image so that lynx can render it - run it through aalib or something.

        Doesn't really help blind users though.

    • You've probably noticed there is noise in the background of the Slash images. Any thoughts on how difficult that makes the problem?

      If misregistration, dithering, etc. would make things harder to crack, the Slash team can do those things too. In this case, the arms race advantage goes to the server side. Tweaking text to make it less computer-readable is easy; recoding OCR algorithms is comparatively extremely difficult. The Slash code doesn't have such things yet but it would be a matter of minutes to add

      • Perhaps it's time, then. I wrote a small utility to take the images and extract the characters. Out of the 24 images or so I pulled, I was able to decode them 100%

        Mind you, all this program does is take the image, convert it to a bitmap, run a simple threshold comparison, and if the RGB value is less than a certain value, it's black, otherwise it's white. I output this as an ASCII image comprised of '#' and '.' in the 24 x 19 array.

        All the images I tested were perfectly legible, which means they can be

        • "All the images I tested were perfectly legible, which means they can be OCR'ed at this point."

          I agree with part 1 and part 2 of the above statement, but not the "which means" part that bridges them -- there exist some legible images which can't be OCR'd.

          Example: http://www.captcha.net/cgi-bin/ez-gimpy [captcha.net]

          The Slash plugin could move to using something like this, if there's a need for it, without too much trouble. The current model is really just infrastructure to allow things like that to happen, plus o

  • why not just choke ?

    If an address or user seems to be abusive then drop the connection on the floor.

    the image thing is more annoying than the noise that would accumulate without it.

    A.
    --

    @JAPH = qw(Hacker Perl Another Just);
    print reverse @JAPH;

  • Use Perl vs. The Blind (Score:4, Informative)

    by sdague (2443) on 2002.04.18 7:08 (#7227) Homepage
    I know that the subject is very inflamatory, but I have a good reason for it. In my last job I worked on some fairly large web projects, one of the very important things to do (from both a "its the right thing" and a "don't want to get sued" perspect) was to make those websites accessible.

    This means that the website should be able to be read in a screen reader, that all images have an apropriate ALT tag, and colors used on the pages are propperly contrasting for those that are color blind (a full 10% of the male population). I spent a number of days browsing the internet with a screen reader and my monitor turned off to get a feel for what it is like. Honestly, for the most part, the internet sounds better than it looks.

    Any time I see anyone deliberately go out of their way to make sites not work in Text only environments because they are being "clever about bots" just annoys me. Any work arround which is programatically generated, and still has to be used by a user, can be programatically cracked.

    I am hoping that this change was out of ignorance of the fact their are people without 20 / 20 vision using the web, and not that it was taken into account and ignored. Otherwise you should change the text at the bottom of the page to:

    To confirm you're not a script, or using a standards based text or voice browser (in which case shuffle off, because we don't like your kind arround here) please type the text shown in this image.

    • Regardless of where you are going to use it - its still the wrong approach - wouldn't it be far better for both the Slash engine and your employer to use a choker that locks out users based on overly-heavy use (a sign of bots and abuse or addiction) or mis-use or karma or a combination of both.

      I can't think of any site or situation where it would be more help than hinderence.
      --

      @JAPH = qw(Hacker Perl Another Just);
      print reverse @JAPH;

      • "wouldn't it be far better for both the Slash engine and your employer to use a choker that locks out users based on overly-heavy use (a sign of bots and abuse or addiction) or mis-use or karma or a combination of both."

        This is already done in a number of ways. Sometimes it is not enough.

        "I can't think of any site or situation where it would be more help than hinderence."

        That's OK, as long as you recognize that your inability to imagine such situations does not mean none exist.

        The reason you can

        • I don't run a Slash site, but I *have* given this a lot of thought.

          Obviously, it's a very difficult issue that has to balance usability (I am NOT going to enter a 44 digit key every time I post) vs reliability (putting the security image contents in an ALT tag would be braindead).

          It seems that the first thing that's required is lack of anonominity, at least as far as the site is concerned. You may post as Anonymous Coward, but it should still require you to be a registered user. It does sort of limit th

        • If a tool can't be used because of unacceptable side effects, it's useless.

          I would certainly hope that any site large and popular enough to face such attacks would not consider "hoses blind people and other users of text browsers" an acceptable side effect.

      • "Slashcode vs. The Blind", however, would be quite reasonable.

        If you have no choice but to implement this feature, I do hope that you include a BIG LOUD WARNING in the documentation that the feature will make the site unusable for people who are blind or using a text browser, should be disabled in virtually all cases, and cannot be legally enabled on any site maintained by a US government agency or a company whose Slash site is in any way related to a government contract or grant.

        Thanks.
        • No warning is necessary. Anyone setting up a US government site, or contracted site, should know these things. If they don't, they are unqualified to be using my tax dollars and should mail them back to me immediately.
          • 1) A warning would still be appropriate for Slash admins who might enable the feature without realizing that they are hosing disabled users or users of text-based browsers, whether or not they are in any way connected to the government. Does it really hurt to add a two-line comment saying "WARNING: Enabling this will hose blind people and users of text browsers, and should be considered a last resort"? 2) As for the legal aspects, no, I don't think it's reasonable to expect some random grad student settin
  • The images seem to be gone now (i saw it on the comments form before, I just didn't accutally post a comment) but I'd like to go ahead and toss out a few things that have been on my mind while reading this thread so far...
    • why use.perl.org? Wouldn't slashcode.com [slashcode.com] have been a better place to beta test this, and seek peoples opinions about it? (maybe it was beta'ed there as well, but i didn't notice it, or a discussion about it)
      It's not that big of an issue, I'm just curious more then anything.
    • why are

    • "Is it something slashcode will come with defaulting to on, i hope not."

      I can upgrade that answer to "no" -- the default Slash theme will only ship with the minimal plugins that are required for its proper operation, and I can't see HumanConf ever being one of them.

      "I hope the slash team considers the comments so far with an open mind. If you sift through the negativity, there's some decent suggestions (i particularly liked the idea of admins being able to disable it on a per user basis if a particul

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.