Better explanation when demanding a CAPTCHA for an HTML comment

[swaldman]

Title:
Better explanation when demanding a CAPTCHA for an HTML comment

Area:
Commenting

Summary:
It is possible for a commeter to be shown a CAPTCHA even when the journal owner has set "Show CAPTCHA to nobody". It would be good if the reason for this was explained somewhere.

Description:
This is pretty obscure (only discovered due to bugfix-testing), but bear with me...

- Users set in account settings -> Privacy who will be shown captchas when they try to comment.

- In addition to this, and entirely independent of this setting, there is a site-wide configuration setting that causes captchas to be shown to people who use HTML in comments (by default on Dreamwidth this is shown only to anonymous commenters who use HTML. There is an option to enable it for all HTML commenters, which other sites using the code could turn on).

- It is thus possible for somebody making a comment (which includes HTML) to be shown a captcha even though the journal owner has set that captcha will be shown to "nobody". The text with the captcha doesn't indicate the reason that it is being requested, but simply says "Please fill out the CAPTCHA as an anti-spam measure".

I don't think it's actually a bug, hence I'm putting it in dw_suggestions, but I think that some journal owners might feel aggrieved about this - for instance if they have assured readers with accessibility needs that they will not need to complete a captcha to comment.
I imagine that there are good reasons for preventing robots from using HTML in comments, but I think that the text shown to the commenter when they are presented with the captcha should be amended to explain why it is happening.
An alternative (or additional) solution would be to add text to the Account Settings page to explain that setting "nobody" may still be overridden - but I think this would add unnecessary complexity to Account Settings for something that few will encounter or be bothered by.

Poll #11557 Better explanation when demanding a CAPTCHA for an HTML comment

Open to: Registered Users, detailed results viewable to: All, participants: 50

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
37 (74.0%)

Should be implemented with changes. (please comment)
4 (8.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
8 (16.0%)

(Other: please comment)
1 (2.0%)

Comments

[erik]

So this would only affect non-logged-in users, who use HTML tags in their comments, and who have been assured by someone-or-other that they would not have to face a CAPTCHA to comment?

I don't think it shouldn't be implemented, but that seems like a vanishingly small number of people; is this really worth allcating resources to?

[kyrielle]

On Dreamwidth, yes.

On other sites, should they use the Dreamwidth code but set the option differently, it could affect logged-in users, based on what I'm reading.

And those anonymous (read no-login-here) users may be the easiest ones to lose over something like this, since they aren't tightly tied to the site.

Assuming this can be done easily (and it seems like it should be fairly trivial), I think it's a good idea, given that it could potentially deny access to a few people and considerably aggravate a larger number.

[matgb]

I agree with this.

I find captchas incredibly annoying and, when I'm writing, a lot of my comments come from other sources, and some of them aren't even switched on enough to know they've got an openid.

[azurelunatic]

I think it should be done in both places by inserting a FAQ-link to help keep option overload down.

There are other site-wide antispam settings besides HTML in comments that could cause a CAPTCHA to be shown to an anonymous commenter, but those are less likely to be run into by someone who is not using HTML.

[kyrielle]

I like this approach. Most people won't care to know that much about it, but someone who wants to know why they're seeing a captcha can follow the link.

[swaldman]

I like this. And as Azz said, it should more generally apply to any captchas-when-commenting that the journal owner hasn't asked for.
(or just show the "why am I seeing this?" FAQ link with every captcha on a comment, which would be the easy option)

[ninetydegrees]

+1

[cesy]

+1

[matgb]

I'm ticking 'as is' because I don't have a 'with changes'. I definitely think that having capchas show up when they're not supposed to be according to my journal settings isn't on.

But I can also see why the site might want to have them as an anti-spam measure, especially for abandoned accounts and similar.

Perhaps only allow the override if the account is inactive?

[azurelunatic]

I actually really really like the idea to create the capability to add captchas for anonymous users on inactive-to-be-determined-by-careful-discussion, from an antispam perspective. *snags and runs to the queue*

[matgb]

Stealin' ma ideahs agin. Theivin varmint ;-)

[azurelunatic]

*cackles*

[azurelunatic]

My spinoff is posted at http://dw-suggestions.dreamwidth.org/1375800.html