NEW FUNCTIONALITY: Google reCAPTCHA v3

We are in the process of selectively implementing Google's reCAPTCHA v3 technology into the system to protect against bots and automated spam attacks. This implementation will be rolled out in phases. Over the past few weeks (in my limited spare time), I have been getting familiar with this technology and testing its use in the FreeToastHost system.

This is a very different type of reCAPTCHA technology than has been typically used in the past in other websites. It uses a risk analysis and scoring approach to determine "bot vs non-bot" and is much less intrusive to users. (No "I'm not a robot" checkbox.) You can get familiar with it via the Google-provided YouTube video:


If you are technically inclined, you can read Google docs about it here:
developers.google.com/recaptcha/docs/v3

I have already implemented this in the New Website Request form ( www.toastmastersclubs.org/welcome/ ) and in the Admin Change form ( www.toastmastersclubs.org/change/ )

I have also implemented it in our back end system admin tools that we use. ("we" being the system support team... the "FreeToastHost Ambassadors")

Finally, I will be implementing it in selected locations in the websites. Currently, I planning to implement it in the Contact Us form (to prevent automated spam) and in the Member Password Change form. After we have some collective experience with the technology, I would expect to also implement it for the Admin and Member login forms.

This roll-out will happen in phases over the next month or so. Because this technology uses a risk-based approach that involves Google analyzing traffic and scoring certain activities as likely "bot" or "non-bot", we need to run the technology in a passive, data-collection phase for a bit so that Google can get some initial data from our activities. During this initial phase, we would not be taking any action based on what Google tells our server (e.g. bot or not-bot). That part (taking action) would come in a month or two. This intentional lag will also give us some time to "kick the tires" and see if we are going to run into any problems with this new technology roll-out.

The way that the scoring works is that our server will ask Google's server to give us a score for each activity of interest. Google's server sends us back a score from 0 (likely bot) to 1 (likely human) that we can use to determine if we should consider the activity to be a problem. Google recommends that we consider any score of less than 0.5 to be problematic.

If you are curious, here are some specific things I am concerned that we may run into with this new technology:
(I hope not, but the following are things that we cannot reliably test/determine on our own.)

1. Does it cause any issues with users using screen readers or similar technology. (I do not think it will, but it would be useful to know that.) I am considering putting a "Disable/Ignore reCAPTCHA for this website" checkbox in the Admin console, or something similar.

2. Does it cause any problems for users using form fillers or automated password logins. I am concerned that these may be misrecognized as "bots".

3. Does the "badge" that shows at the bottom right cause any issues on small (e.g. mobile) screens. Does it obscure anything or is the underlying Google provided script smart enough to hide that on small screens?

4. Uncertain about how we would deal with borderline scores. (e.g. a score of ~0.5) Google's YouTube video above alludes to a "verification queue", but we do not have any such thing--it would have to be created in the db along with appropriate verification emails and support code.

These are some things that I am hoping that collectively we can figure out. (kicking the tires) I am guessing there may be other things that will come up.

The main spammy or bot activity for my club's website is that for some time, we were getting quite a bit of spam (some in spam folder, some in inbox) because the club's email address was on the home page with a "mailto" hyperlink to it. Once I removed the hyperlink, we got a lot less spam (none in inbox anymore, one in spam folder every ~5 days). I might do something like using "[at]" and "[dot]" to replace @ and the period to try to reduce it even further, but already it's a lot better.

wrote:

The main spammy or bot activity for my club's website is that for some time, we were getting quite a bit of spam (some in spam folder, some in inbox) because the club's email address was on the home page with a "mailto" hyperlink to it. Once I removed the hyperlink, we got a lot less spam (none in inbox anymore, one in spam folder every ~5 days). I might do something like using "[at]" and "[dot]" to replace @ and the period to try to reduce it even further, but already it's a lot better.

Thanks for sharing your insight and experience. We generally recommend that clubs be very wary about making email addresses public like on a home page. (For example, see my comments in support.toastmastersclubs.org/2011-10-23...e-contact-form#83792 ) Unfortunately, it seems that not enough clubs pay attention to us, and sometimes it takes experiences like yours to make them a believer.

We have been seeing a enough automated spam through the Contact Us form and what we believe are automated attacks elsewhere that it was worth it for us to implement the Google reCAPTCHA tech. For many clubs, it probably will not matter to them other than providing some additional piece of mind, but hey, better safe than sorry.

On what page would we enable these features?