TOPIC:

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.

vickiiui 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?

Arlynn wrote:

On what page would we enable these features?

We will handle the enabling for now.

I was going to post a moan and groan comment about this idea, as I'm tired of having to, each time I log in to the Coursera site for online education, clicking on all the stupid bicycles or crosswalks (ugh), but it looks like V3 does away with that nonsense. I assume you've noticed bot problems and thus have decided to implement this. If so, thumbs up.

NotLiable wrote:

I was going to post a moan and groan comment about this idea, as I'm tired of having to, each time I log in to the Coursera site for online education, clicking on all the stupid bicycles or crosswalks (ugh), but it looks like V3 does away with that nonsense. I assume you've noticed bot problems and thus have decided to implement this. If so, thumbs up.

Thank you. We are trying to go about this wisely. We are very aware of the need to balance increased security with ease of use.

Ok, I have now added the reCAPTCHA stuff to the Contact Us and Set Member Password forms. You will see the badge at the bottom right of the screen when those forms are loaded.

I will likely also add it to the Login Dialogs.

One possible concern I am seeing is that while the badge is fine on desktop screens, it may be a bit too big for small screens. (like a phone screen) I am interested in hearing users' thoughts on that. Google does provide an approved workaround for the case of not wanting to use the official reCAPTCHA "badge", but I want to hear what people think first.

Ok, I have now added the reCAPTCHA stuff to the Admin and Member Login dialogs.

I also went ahead and decided to show the Google approved alternate text on the forms for small screens (e.g. phones) instead of the animated Google reCAPTCHA badge. While the badge did not seem to be a big issue on the small screens, screen space is at a premium there, so I would rather not have any part of small screens obscured by the badge if I can help it.

*** At this point, I have added the reCAPTCHA stuff to all the locations that I had planned to--I believe that Phase 1 of the implementation is *complete*. (feel free to suggest other locations) Now, we are just going to passively collect information for about a month to give Google's code some "baseline" information on our user's behavior so it can properly do the risk analysis (for bot vs non-bot) moving forward after that.

Once I think Google has collected enough information (probably in about a month), then I will proceed to Phase 2 of the implementation: figuring out what should be the default threshold for the risk analysis score, implementing an admin notification scheme for cases where a bot has been detected / blocked, and figuring out exactly what we should do if Google detects a bot.

I am interested in user feedback on this... Has anyone noticed any problems as of yet with the forms/dialogs that have the reCAPTCHA implemented in them?

I ran through all instances of the implementation on computer and mobile and observed no problems. Everything behaved as you described Steve.

The text version on the phone screen looks clean and descriptive as a line of info at the bottom of the dialog box.

Is the role sign-up in the agenda email also a suitable place for it?

rhtaylor3 wrote:

I ran through all instances of the implementation on computer and mobile and observed no problems. Everything behaved as you described Steve.

The text version on the phone screen looks clean and descriptive as a line of info at the bottom of the dialog box.

Is the role sign-up in the agenda email also a suitable place for it?

Thank you very much for your time and contribution to this effort!

"role sign-up in the agenda email" ... The thing is that because the reCAPTCHA stuff does require a bit of coding, it cannot really be put into an email itself. The agenda email is really just a bunch of creatively implemented links that redirect you to other places that do the actual work. If you actually are referring to the landing page (vs the email itself) when you sign up for a role that requires you to essentially provide your password, then yes, that may be another place to implement this. (Good thought... I had not thought of that.)

Just so that you can all see where the "Phase 1" data collection part of this is going, here are some results that Google has collected and processed for us so far (this is for all of the FreeToastHost system):

I have "fleshed out" my implementation of this functionality a bit more. I have created a system notification to be added to admin login messages when Google RECAPTCHA deems monitored actions to be suspicious. Also, I have added some website settings to enable clubs to have a bit more control over this functionality. Currently, these additional settings are located at the bottom of the Administrator Information tab in Website Settings (I am open to suggestions of other places) and they are currently locked from any changes--I want to leave some time for additional data gathering by Google before I give clubs the ability to change these settings.

Notification Message Template:
Settings Screenshot (please suggest better wording below if appropriate):

Updated results that Google has collected and processed for us so far (this is for all of the FreeToastHost system):

Steve,

I've gotten several messages from the system--the only one of concern is regarding one I got this morning; it was right at meeting time, and about our VPE, who has also had emails bounce before, though his email address IS valid.

"[Wed, 02 Jun 2021 10:58:25 UTC, FreeToastHost System Warning]

Google RECAPTCHA detected a suspicious activity likely initiated by a bot or automated script.

*** NOTE: FreeToastHost may block suspicious activities in the near future. ***

Details:

---

Club #: 2345
Club Name: Toastnotables
User's IP Address: 67.199.223.172
User's Host Domain:
Attempted Action: Website Member Login ()
Google RECAPTCHA Score: (Mininum Acceptable: 0.5)
Other Information: Member Name: Roger Storm, VPE

If you have any questions about this warning, please visit support.toastmastersclubs.org"

I will ask him if he has anything unusual in the way he logs in.

nalmasy wrote:

Steve,

I've gotten several messages from the system--the only one of concern is regarding one I got this morning; it was right at meeting time, and about our VPE, who has also had emails bounce before, though his email address IS valid.

"[Wed, 02 Jun 2021 10:58:25 UTC, FreeToastHost System Warning]

Google RECAPTCHA detected a suspicious activity likely initiated by a bot or automated script.

*** NOTE: FreeToastHost may block suspicious activities in the near future. ***

Details:

---

Club #: 2345
Club Name: Toastnotables
User's IP Address: 67.199.223.172
User's Host Domain:
Attempted Action: Website Member Login ()
Google RECAPTCHA Score: (Mininum Acceptable: 0.5)
Other Information: Member Name: Roger Storm, VPE

If you have any questions about this warning, please visit support.toastmastersclubs.org"

I will ask him if he has anything unusual in the way he logs in.

I realize that we have sort of gotten all our users trained to think in terms of good/bad email addresses, but reCAPTCHA has nothing to do with the email addresses. It strictly works off of tracking user interactions with the form in which reCAPTCHA is implemented. It is looking for interactions that indicate that the "user" is very likely a bot or automated script. (we want to block those for security reasons)

Thanks for posting about this.

***Suggestion: Ask your VPE if they use a Form / Password filler for their login.