Note: We are moving the topics of this forum and it will be deleted at some point
Publish your own request for comments/change or patches for the next version of phpBB. Discuss the contributions and proposals of others. Upcoming releases are 3.2/Rhea and 3.3.
Vinny wrote:Myabe this is a crazy idea, but Q&A should parse BBcode (only [ b], [ i], [ u] and [color]) to create more complex questions. Examples:
The sky is blue, but this text is ...?
------------------------
I the sentence: "Choose what is right, not what is easy." What words are bold?
The issue with that is that I know that phpBB aims to be accessible to those who cannot browse normally (i.e. blind) and have to use screen readers. As such, they will not know what color that sentence is.
But beyond that, I think that would be a very acceptable question.
I do custom MODs. PM for a quote! View My: MODs | Portfolio Please do NOT contact for support via PM or email.
Remember, the enemy's gate is down.
Oleg wrote:I think a nag in acp index would be sufficient.
+1
A lot of complex software packages do this already. Let new administrators have a basic installation and then show them some kind of advices that are permanent untill they decide to review them at least once.
Some even have a progress bar for different settings every admin should check.
Slightly better English than it was in 2005, still improving
If the user chooses to use another CAPTCHA (say a plug-in), there shouldn't be a nag because of that. So maybe only display a nag if one of the other default CAPTCHAs is chosen (with the possible exception of ReCAPTCHA).
Or, perhaps even better, if Q&A CAPTCHA is going to be the default, why not get rid of the other default CAPTCHAs completely (again with the possible exception of ReCAPTCHA)? What's the point of shipping known bad CAPTCHAs with the software?
Regarding a default question, it's really not that bad. The default CAPTCHA is basically just as easy to break, but at least Q&A would come ready to work (no double selection like people have to do now). So how about a default question and a nag if the default question is still used? That allows having Q&A work "out of the box" and still lets the user know in a very visible way that they should change the question.
Alternatively, it shouldn't be too difficult to generate a "random" question at installation using the examples above with slightly different phrasing and answers. Generate a string of between 5 and 8 random characters, choose from a set of default questions ("Type the odd characters", "Type the even characters", "Type the first, third and sixth characters", etc.) and create the answer based on the question.
callumacrae wrote:If they're generated automatically, thy can be solved automatically.
Not true. The characters and selection criteria are randomized. Just like the examples given, a spambot would still have to figure out which word was important and which characters to select.
With good AI, it could be done automatically, of course, but every CAPTCHA is based on the fact that AI isn't as good as humans at these tasks.
And remember that this would just be a starter question; the user would still be encouraged to change it.
We could really mix images with text to confuse bots.
The problem is that images would need to be generated at the moment. I was thinking of writing text in the HTML, insert an image, more text forming the question. The bot would need to read the text and the image. That is not easy! For the name of the image, it just gets the image from a ".php" page (no get variables), the forum knows the image using a session variable.
callumacrae wrote:If they're generated automatically, thy can be solved automatically.
Not true. The characters and selection criteria are randomized. Just like the examples given, a spambot would still have to figure out which word was important and which characters to select.
It's entirely true, and moderately trivial if given access to the source.
One of the benefits of having q&a configured during installation was said to be the fact that q&a would be turned on, as our current configuration process is nontrivial/hard to use/multi-step - take your pick.
Instead of addressing the problem of bad UI by doing configuration during installation, I would suggest addressing the problem of bad UI by improving the UI.
Oleg wrote:One of the benefits of having q&a configured during installation was said to be the fact that q&a would be turned on, as our current configuration process is nontrivial/hard to use/multi-step - take your pick.
Instead of addressing the problem of bad UI by doing configuration during installation, I would suggest addressing the problem of bad UI by improving the UI.
So what's more important? Fixing the UI now and holding off on implementing this until that is done, or going ahead and implementing this is the "bad" UI and changing the UI and adapting this to work with it? Anyway, the UI in general needs its own RFC.
I do custom MODs. PM for a quote! View My: MODs | Portfolio Please do NOT contact for support via PM or email.
Remember, the enemy's gate is down.