reCAPTCHA v3 proposal

Discuss requests for comments/changes posted in the Issue Tracker for the development of phpBB. Current releases are 3.2/Rhea and 3.3/Proteus.
Post Reply
User avatar
EA117
Registered User
Posts: 21
Joined: Tue Apr 30, 2019 12:54 pm

reCAPTCHA v3 proposal

Post by EA117 »

https://github.com/phpbb/phpbb/pull/5902

This seemed like perhaps a longer or more free-from discussion than deserved to be in github comments, so starting one here.

What are the philosophical and/or technical constraints that led to a direction of adding a separate "reCAPTCHA v2" and "reCAPTCHA v3" plug-in as part of this proposal. As opposed to "making the existing reCAPTCHA plug-in support v3."

First, let me say that I think it was probably a miscalculation or missed opportunity that when switching from "reCAPTCHA v2 Checkbox" to "reCAPTCHA v2 Invisible", we perhaps didn't realize we needed to create a better migration story. When the plug-in gets upgraded on an existing reCAPTCHA v2 configuration, we could have had messages which called out that post-phpBB 3.3.0 update this existing reCAPTCHA v2 configuration wasn't going to work. In that sense, "making a separate reCAPTCHA plug-in" so that the existing configuration continued working as-is might have made sense.

But, on the other hand, it actually seems very logical to me that "there is a single reCAPTCHA plug-in" in phpBB. If Google's reCAPTCHA service offers different levels and different keys, "the first thing that seems logical" about how to handle that would be that this single plug-in knows how to deal with both kinds of keys. And/or in the future, knows how to deal with all kinds of keys that Google reCAPTCHA offers.

Meaning we won't create "reCAPTCHA v2", "reCAPTCHA v2 Invisible", "reCAPTCHA v3", "reCAPTCHA v5", etc., as separate plug-in selections with separate configurations. We would have a single reCAPTCHA plug-in, with a single configuration page. Specifying "which reCAPTCHA version am I using" will have to be part of that single configuration page. The configuration page will potentially have to change in response to the version selected, showing less or more fields, based on options which do or do not exist with one version of reCAPTCHA versus another.

This just seems like an approach which scales better if and when an even more advanced version of reCAPTCHA gets introduced in the future.

The reCAPTCHA plug-in will record what version of reCAPTCHA the phpBB operator had configured, in order for migrations and updates to work more smoothly in the future. e.g. If there was no version indication in the database at all, it was reCAPTCHA v2 Checkbox from phpBB 3.2.x. Or we recorded it was reCAPTCHA v2 Invisible in phpBB 3.3.0. Or we recorded that it was reCAPTCHA v3 in the future version with this change. Etc.

And so when a future reCAPTCHA v5-capable plug-in gets installed during a future update, the plug-in knows exactly which mode it needs to continue operating in, and what capability the currently-entered keys are expected to have. And doesn't just assume "because I'm reCAPTCHA v5 capable, the currently entered keys must be for reCAPTCHA v5", and/or that v5 behavior is what the phpBB operator even intends to have.

Yes, to support "all possible versions" means our reCAPTCHA templates perhaps have to become more conditional and versatile than they've had to be thus far, in order to correctly function for more than one version. So far Google's own reCAPTCHA support code for PHP supports multiple versions, and so perhaps we can too / can support whatever Google's provided PHP API provides support for.

User avatar
mrgoldy
Former Team Member
Posts: 64
Joined: Fri Dec 18, 2015 9:41 pm
Location: The Netherlands
Contact:

Re: reCAPTCHA v3 proposal

Post by mrgoldy »

Well, there is the simple difference that v3 keys are different to v2 keys.
So it can not just be upgraded, as v2 users will then be left with a non-working captcha.

"The configuration page will potentially have to change in response to the version selected, showing less or more fields, based on options which do or do not exist with one version of reCAPTCHA versus another."
Isn't that what is currently happening? You select v2 and can configure a different page.
You select v3, and you can select a different page.

I did however want to add the 'server' and 'method' configuration to v2 aswell, but thought I would keep it with v3 for now.
Cause then I have more of a leg to stand on to make an abstract_recaptcha plugin that gets extended by v2, v3, ...

I am not sure if I get your point, it's a long story but I am missing the exact emphasis.
phpBB Studio Proud member of the Studio!

User avatar
EA117
Registered User
Posts: 21
Joined: Tue Apr 30, 2019 12:54 pm

Re: reCAPTCHA v3 proposal

Post by EA117 »

mrgoldy wrote: Mon Mar 16, 2020 9:32 am Well, there is the simple difference that v3 keys are different to v2 keys.
So it can not just be upgraded, as v2 users will then be left with a non-working captcha.
Correct. Which is the situation we have right now updating from phpBB 3.2.x to phpBB 3.3.0. Someone with a 100% working reCAPTCHA v2 Checkbox configuration ends up with a non-working phpBB 3.3.0 configuration, because you need reCAPTCHA v2 Invisible keys. We could have instead created a separate "reCAPTCHA v2 Invisible" plug-in selection, same as we're proposing creation of a separate "reCAPTCHA v3" plug-in selection right now. Meaning we could make it so three plug-ins are listed, and you choose whichever one you have keys for.

What I'm asking is whether this would perhaps scale better design-wise if we maintained just a single "reCAPTCHA" plug-in in phpBB's spambot countermeasures list; not two or three separate ones per-API version. The reCAPTCHA plug-in configuration fields would include a drop-down with selections like "reCAPTCHA v2 Checkbox", "reCAPTCHA v2 Invisible", and "reCAPTCHA v3" to specify what version you're intending to use. The additional fields specific to v2 or v3 or vX behavior would be hidden or shown depending on the selection.

Meaning, the single phpBB plug-in would cover multiple versions of reCAPTCHA, same as Google's provided PHP library that we use covers multiple versions of reCAPTCHA. And as Google removes support for a version, so would we; same as was done with removal of reCAPTCHA v1.

Yeah, it's a long story because I'm trying to cover "two different directions": Looking back, at the way this approach could have helped (and still can help) the situation that already happened between phpBB 3.2.x and phpBB 3.3.0. And looking forward, at the way this might scale better in the future when "reCAPTCHA v3 Widget" or "reCAPTCHA v5" or whatever are introduced. To avoid repeating any situation similar to what we had with "reCAPTCHA v2 Checkbox" versus "reCAPTCHA v2 Invisible".

The key point is that "what version of keys do you have" for the plug-in would never be an unknown any more, because it's part of the plug-in's configuration. We only have to assume during migration of phpBB 3.2.x (must have been v2 checkbox if it was working) or phpBB 3.3.0 proper (must have been v2 invisible if it was working) and make that selection for them.

But from phpBB 3.3.1 on (or where ever this gets implemented), we're not "assuming" any more. Nor do we assume that just because the latest phpBB version introduced newly-released Google "reCAPTCHA v3 Widget" support that the currently-entered keys must also be "reCAPTCHA v3 Widget". We continue honoring whatever the existing configuration was, until the phpBB operator changes it.

User avatar
mrgoldy
Former Team Member
Posts: 64
Joined: Fri Dec 18, 2015 9:41 pm
Location: The Netherlands
Contact:

Re: reCAPTCHA v3 proposal

Post by mrgoldy »

Okay, just to get back on this.

Firstly, I think it was overseen that an admin needs different API keys for reCAPTCHA Invisible than for reCAPTCHA Checkbox.

Secondly, I agree with the fact that it is odd that 'working' plugin was removed and a new one added.
As the reCAPTCHA Checkbox was not proven to be 'broken', meaning it would have been solvable by bots.
The only reason I could find that it was changed to Invisible, is that it would "require one less task to complete a form".

Then towards your point, what I think you mean is that you want the reCAPTCHA settings (regardless of version and type) are persistent.
So that settings such as a RequestMethod (POST/cURL/Socket) and Domain (Google.com/Recaptcha.com) are available for all reCAPTCHAs.
That would prevent from having to (re-)create them when a new reCAPTCHA type or version comes out.
Is this your main point?

Cause the 'select box' you are talking about, is pretty much already there, when you select the captcha plugin you want to use.
They have to be different pages in my opinion still, as the API keys are most definitely different.
And with it being different pages, rather than one page for all, is that we can store API keys for different types and versions.
So if an admin decides to switch back to a type or version that was previously used, the keys would still be there for that specific type/version.

I can definitely make the reCAPTCHA plugin more 'abstract', making it easily more extendible for current and possible feature versions.
However, the more I make actual changes to the code, the more likely it will become that the Pull Request has to go against the master branch.
Rather than the 3.3.x branch, which I am currently targeting. Meaning that the plugin will not be available for quite some time.

As for an other example, the other (broken) captcha's that have to be removed, are targeted for 4.0 (against the master branch).
Plugins such as the GD Image, GD 3D Image and Simple image, that are proven to be ineffective, and thus broken.

What I would propose, is the following:
Which would leave phpBB with 4 to 5 working and effective plugins, rather than distributing faulty once.
  • Remove GD Image, GD 3D Image and Simple image.
  • Keep the QA (Question and Answer)
  • Keep the Google reCAPTCHA v2 Invisible.
  • Re-add the Google reCAPTCHA v2 Checkbox.
  • Add the Google reCAPTCHA v3.
  • (Possibly add Derky's Sortable Captcha).
The issue that is raised, is the Backwards Compatibility (BC) issue.
What I would suggest for that, is during a migration check if the board is using one of the removed captchas and replace it with QA.
QA does require configuration aswell, but that is something we can add a default for.
"What is the domain of the website?": parse_url(generate_board_url(), PHP_URL_HOST);.
It would obviously not be fool proof and completely effective, but they were coming from a broken and ineffective captcha to begin with.
So add a notice to the announcement, that people should double check their Spambot countermeasures.
Which is something that should be done regardless, cause of the fact that reCAPTCHA v2 keys have to be (possibly) changed.
And I would do this for 3.3 already, rather than 4.0 as phpBB should redistribute broken plugins and give a false sense of security.

But that's just my opinion I suppose.
Hope to hear from other people aswell.
phpBB Studio Proud member of the Studio!

koraldon
Registered User
Posts: 33
Joined: Thu Mar 10, 2005 12:06 pm

Re: reCAPTCHA v3 proposal

Post by koraldon »

I don't see the b/c case in this, just revert to default if a board used one of the removed methods.
It will not break any forums.

User avatar
EA117
Registered User
Posts: 21
Joined: Tue Apr 30, 2019 12:54 pm

Re: reCAPTCHA v3 proposal

Post by EA117 »

Agree that the change from Checkbox to Invisible was not "mandatory" but just desirable; as being potentially even less friction and "latest" technology.

So long as the "backwards compatibility" plan of re-introducing "reCAPTCHA v2 Checkbox" as a selectable plug-in (i.e. what was called simply "reCAPTCHA" in phpBB 3.2.x) includes a db migration to select "reCAPTCHA v2 Checkbox" during upgrade from phpBB 3.2.x, then I think between that action and the decision to have separate plug-ins per Google reCAPTCHA API version, this essentially provides the solution to the points I was trying to articulate.

It just seemed clearer in my head that "a single reCAPTCHA plug-in, in which the Google API version is a configuration option within the plug-in" was the more intuitive and "scaleable" way, by not growing the list of available plug-ins every time Google introduces a new API key type. But I understand and accept your position that "the plug-in selection list itself" is what will provide the "drop-down selection of which Google reCAPTCHA API you intend to use."

So someone using phpBB 3.2.x with the "reCAPTCHA" plug-in selected, when updating directly to phpBB 3.3.1, will be left in a functioning captcha scenario with "reCAPTCHA v2 Checkbox" plug-in now selected for them, and their existing reCAPTCHA v2 Checkbox keys from the phpBB 3.2.x configuration.

Similarly, someone using phpBB 3.3.0 with the "reCAPTCHA" plug-in selected, when updating to phpBB 3.3.1, will be left in a functioning captcha scenario with "reCAPTCHA v2 Invisible" plug-in now selected for them, and their existing reCAPTCHA v2 Invisible keys from the phpBB 3.3.0 configuration. I've said "phpBB 3.3.1" here, but of course I mean where ever the new proposal gets implemented.

Going forward from there, those are the last "assumptions" we ever make regarding what key type was currently in use. Each reCAPTCHA API version-specific plug-in will now have its own separate key storage in the config table. We will always be able to allow the board's existing reCAPTCHA configuration to continue working during a phpBB upgrade, unless or until Google retires that API version and we remove the corresponding plug-in.

For the upgrade case of "what if their captcha plug-in selection is no longer supported" -- be that for GD Image, GD 3D Image or Simple image now, or say when reCAPTCHA v2 API is turned off some time in the future -- it does seem important to draw attention to it. A notice in the ACP similar to the "install directory still exists" notice would be fine, saying a new plug-in selection was made and further configuration is required.

Perhaps ideally, there should also be something showing on the actual user pages where a captcha was supposed to be appearing. Like "captcha method requires further configuration", and the user cannot pass through the captcha scenario until the administrator fixes this.

Since if the phpBB operator had captcha enabled previously, they do want captcha for these user interactions. So don't default to "no captcha required" just because we made a new plug-in selection for them that hasn't been configured yet; and don't let the user interactions proceed until the captcha is actually configured.

Potentially we're talking about a non-plug-in-specific change to present this message and fail any operation that should have required captcha, whenever the currently-selected plug-in (such as the new QA plug-in selection made during upgrade) reports as "not available" because it hasn't actually been configured yet.

Post Reply