Captcha and few variants...

I'm downloading some stuff from the Internet, and as a part of that process I had to solve captcha in order to prove that I'm a human. Captcha can be thought of as a puzzle that have to be solved and, by assumption, only a human can solve it. But, the reality is that there are automated ways that can solve capthcas, particularly badly designed ones. So, I was thinking a bit about captcha and decided to write about it...

There are several way of circumventing captcha. Two I heard of a very interesting. The first one, and the older one, is that some sites that host piracy materials or sexual materials, require you to enter chaptcha prior to accessing materials. But that captcha is from another site that is being abused. Let me provide a simple hypothetical example. Suppose that spammer wants to register as much mail addresses as posible with gmail. Gmail actually has protection in the form of captcha that is aimed at just that, preventing mass registrations. So, what spammer does is that he starts to provide some service to users, e.g. download of pornography. But, in order for the user to download something it has to first solve captcha, and the captcha to be solved is the one presented by GMail to spammer, which is redirected to the user.

The other form of captcha is even more bizarre. There are companies in India and China that employ humans that manually solve captchas. You are provided with API through with you send request, this request is routed to some human that solves it and sends back results. What a combination of automation!? And cheap one while we are at that, few dollars for thousands captchas, something like that.

So, what can be done? Well, there is a reload button on captcha that allows you to request another puzzle, so, there could be a sentence that requires you to reload and if you try to enter that particular captcha, you are banned. This would help for two cases. The first ones are automated recognitions that actually don't understand what's written in the captcha. The case when humans solve captcha could be restricted by localizations. Namely, if you require reloading you would present that in, e.g. Croatian because request comes from Croatia. But, if that someone sends then captcha to India, the gay there wouldn't know the meaning of the sentence and so wouldn't be able to solve captcha. Another possibility is to give a sentence that requires you to enter only third word, or to choose synonymous for a given word between several words.

Bringing this idea to a higher level would mean that apart from requiring user to retype what's written in captcha it would also require him/her to understand what's written in there and to do some particular action based on that!

In the end, this isn't perfect solution, but only a step in a play of catch between cat and mice which, for a short period of time, gives advantage to mice (or cat, depending on the view)...

Why I think it is in RedHat's interest to help CentOS...

Today I was asked if there are any security implications in selecting particular licensing model from Microsoft. Basically, I know nothing about that particular subject, and as far as I can remember from some previous experiences, this is something that requires specialization in itself. To cut the story short, I don't intend to waste my time in studying Microsoft's licensing models! So, in the end I basically said that any option is valid from my perspective as long as we have access to security updates. No more no less...

But since everything was about selecting the least expensive solution, I mentioned that it might be beneficial to introduce LibreOffice (OpenOffice) instead of Microsoft Office and/or Linux on certain workstations because people don't use all the functionality of Windows and especially Microsoft Office. It is true that LibreOffice isn't quite a match to Microsoft Office, but for people that only write a single page of something and then send this to a printer it is to much to pay for a whole office suite! Or, those that access remote machines and do their work there it is also to much to maintain the whole workstation with a full productivity suite on it. My idea was, unsurprisingly, rejected because of a slew of problems, like compatibility between different office suites, support for equivalent functionality of Outlook, potential problems with user support, etc. Those might or might not be the problems, but in the end, I was asked what distribution I would recommend if there would be (partial) migration?

I said, without almost any thinking, latest version of Ubuntu LTS! Let me first clarify that I'm actually die hard user of Fedora, and also CentOS, and I use them as much as I can. But, I also stand firmly on the ground and I'm aware of problems associated with that route. First, you'll probably ask why I didn't recommend RHEL? Well, the reason is simple, it costs, and price cut wouldn't be large enough to justify such transition. Scientific Linux, as I already blogged about, has a problem with a name. If I'm going to say "Use Scientific Linux!" probably I would be rejected with a comment something in a line with "Wow, we are not scientific institution!". And for CentOS, well, no timely security updates! Period. Ok, to be honest, I do install CentOS on servers in a good hope that things will become better, but it is on a small scale and I'm usually directly in charge of those servers. Note that I didn't mention Fedora as an alternative. Well, the reasons are bitten to death by now, so I won't go into that.

So this leaves me with Ubuntu or Debian. The clear winner is definitely Ubuntu, more specifically, Ubuntu LTS. The reasons in favor are strong. First, quite user friendly, second, long time support (LTS!), third advanced almost like Fedora, but without Fedora's short support timeframe. Finally, there is possibility of obtaining support contract.

And what's the conclusion? The conclusion is that Ubuntu slowly and certainly is introduced into business environments which might or might not pose a threat to RHEL... decide for yourself...

CentOS... something is happening!

I just noticed that RPM packages from RHEL 6.1 appeared on mirrors. Actually, they announced it few days earlier but that was sooner that I was expecting. :)

There is a small catch. In order for yum to be able to catch those packages you'll have to add new repository. Namely, CentOS team decided to go with a mechanism they call Continuous updates. In that way they'll try to be faster, but, time will tell if it will work or not.

The quickest way to do that is to run the following command:

rpm -ivh ftp://ftp.funet.fi/pub/mirrors/centos.org/6/cr/i386/RPMS/centos-release-cr-6-0.el6.centos.i686.rpm

or for 64-bit systems:

rpm -ivh ftp://ftp.funet.fi/pub/mirrors/centos.org/6/cr/x86_64/RPMS/centos-release-cr-6-0.el6.centos.x86_64.rpm

This will install necessary data for yum. Then, just run 'yum update' and that's it!

Still, we'll have to wait a bit more for 6.1, and especially for FreeIPA 2 that I'm waiting for!