LJ Enhancements

Folks might want to read the report of the latest LJ release. It has several interesting changes, including two that sound downright useful -- an official mechanism for "sticky posts" that show up permanently at the top of a journal (which a number of people work around today), and a new <lj-spoiler> tag that is apparently just like <lj-cut>, but expands in-line. Which means that I suspect it is usually just plain better than <lj-cut>. Let's try that out: Aren't you disappointed at being spoiled?.

Anyway, there's more in the linked article: it's probably worth a skim if you're a regular LJ poster...

Keeping spam out of Google Forms

Okay, the answer to my question from yesterday seems to be: there is no good answer. Looking around, I find a lot of people frustrated at Google Forms' lack of even primitive captcha capability, and some who are getting 1000+ spam entries a day in their public forms.

There seem to be three practical workarounds.

First is the one suggested by laurion and Aaron: wrap the Google Form in a homebrew page that *does* contain adequate security measures. This is the most effort, but allows more or less arbitrary security -- at that point, you can implement pretty much whatever you think is appropriate. IMO it's overkill for the project at hand, but probably best for any form that is going to get really wide distribution. (And thus, is likely to get more seriously attacked.)

Second is an idea talked about in some of the Google forums: use page branching to honeypot the spambots to death. While Google Forms is quite simplistic, it *does* have basic branching capabilities: that is, depending on Answer A on page 1, you get to page 2, 3, or whatever. So you can theoretically define a single answer which is obviously correct to a human, but not to a computer, and branch to a dead end if the wrong answer is given, or even just sit and loop back to the same page. Nice in principle; however, it only works for multiple-choice answers, so a spambot that simply chooses those randomly is still going to get through unacceptably often.

So the third option, which I think is probably best for the use case I have, is a variant of that: have a question that requires *text* entry, for which the answer is trivially easy for the intended audience but unguessable for a spambot, ideally one that requires at least slight knowledge of the problem domain. Then you add a script to the spreadsheet itself (yes, as it turns out Google Docs is pretty nicely scriptable), that fires when a form is submitted, checks the entry, and deletes the row if the answer isn't correct. The result is a lot of traffic for Google, but is basically invisible for us.

It takes only a few minutes to implement (assuming you have an appropriate question for your audience), so it's a reasonable workaround until and unless Google comes up with a real answer. (Indeed, it's probably *better* than ordinary captchas in most cases, because it's less mental effort for your real audience...)