I'm forking this from bug 10408. The word "hits" tends to produce unfortunate CAPTCHAs whenever it gets appended to a plural word. While we discuss the reasonability of adding a blacklist regexp for naughty words at the original bug, in the mean time it would be reasonable to simply remove the offending word from Wikimedia's word list.
Version: unspecified
Severity: minor
URL: http://en.wikipedia.org/wiki/Image:Peashits.png
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T18166 Remove "hits" from CAPTCHA dictionary | |||
| Resolved | Emufarmers | T23025 Include a default word blacklist for FancyCaptcha |
Do we actually have a "dictionary", or is this farmed off to google using ConfirmEdit/Recaptcha...?
We use/used a system dictionary file I think (eg /usr/share/words or some such) to generate the captcha images via the python script included with ConfirmEdit. Not sure whether they're being actively generated now or if we're just using a large existing image pool.
(Wikimedia doesn't use Recaptcha due to its proprietary licensing.)
Yes, we use that file with a few filters (I prefer not to give too much details here, although our wordlist is public).
I don't think the files are ever regenerated.
Anyone with shell should be able to fix this and regenerate the files, giving to Tim just because he is familiar with it.
(In reply to comment #4)
(Wikimedia doesn't use Recaptcha due to its proprietary licensing.)
We do for fund-raising stuff, the reason we don't normally is because of the external reliance stuff (as of the last discussion), but we apparently pay no attention to that for the fund-raising.
We shouldn't. The developer which worked on it didn't really know how to use our FancyCaptcha at that time.
(In reply to comment #8)
What's left to even do on this one?
I think resolving bug 21025 would be a better use of time than focusing energy on this bug.
Marked as depending on bug 21025, as they are closely related.
RobLa, this is one of those 10-minute bugs that lag for years because they need shell access.
Steps to take:
Captchas just being sent (but not answered) will still work.
MW (ConfirmEdit extension) territory -> no "ops" in this case.
(In reply to comment #11 by Aaron Schulz)
Looks like /mnt/upload7/private/captcha2 has has word lists, including a bad
one.
Does this need any help from another team? I assume not.
Now that bug 21025 is resolved, this bug just needs someone in ops to verify which blacklist is being used on Wikimedia wikis.
There isn't one really. The one in my home dir on fenari should be put somewhere standard...probably in puppet to (though it would be an amusing commit to make).
I assume Wikimedia wikis are using captcha.py. The only question then is whether it's already passing the --blacklist option currently. If not, the default value should get picked up in the next code update. Maybe.
(In reply to comment #16)
I assume Wikimedia wikis are using captcha.py. The only question then is
whether it's already passing the --blacklist option currently. If not, the
default value should get picked up in the next code update. Maybe.
We only run it manually I did the last run...it should really happen periodically with proper image rotation though...I think that's a bug report.
The word "hits" tends to produce unfortunate CAPTCHAs whenever it gets appended to a plural word
Already resolved by T23025.