@dr0ptp4kt has some thoughts on this, which he may choose to document here.

@csteipp may also have some ideas?

Yet another problem with our notorious CAPTCHA.

And... How do you plan to achieve this securely?

For reference, the Google and Gmail apps on iOS do require a captcha when creating a new account in the app.

In T88083#1003731, @Deskana wrote:

@csteipp may also have some ideas?

For registration, we can't skip the captcha. Although we proved some of our spam bots are stupid in the last experiment, opening it up on enwiki isn't something we should plan for (at the least, we would need to plan to disable captcha temporarily until some bot figured it out).

For login, users only get a captcha if they've failed more than 5 passwords in 5 minutes. If the mobile app wants to simply say "you can't login now" instead of showing a captcha, that's up to Deskana.

In T88083#1004511, @csteipp wrote:

For registration, we can't skip the captcha.

+1, until we have a better way to fight against spam bots.

"client-side throttling" is not a viable solution as the call to the wiki would be an API request that anyone could find by reading the source for the app or sniffing the traffic from their device. So client-side throttling would only stop good guys and not bad guys.

What other ideas can we come up with for this issue? We'd need something that provides a secure challenge-response loop that is difficult to automate but relatively easy for humans to complete. Would this be a place to experiment with different kinds of captchas than we use on the desktop wiki? I think I've seen discussion threads on wikitech-l mentioning things like "click the picture of the monkey" kinds of tests. There are some mobile captcha ideas documented on this stackoverflow thread. I kind of like the "trace this path" idea as well as the aforementioned "Click the X" visual captcha ideas.

In T88083#1035719, @bd808 wrote:

as well as the aforementioned "Click the X" visual captcha ideas.

I note "Click the X" (although "Select all the Xs" would be better) requires a corpus of images that are well-curated as "X"/"not-X". And if the corpus is publicly available, it may not be too difficult for the attacker to download the whole thing to defeat it.

Should this task be closed and replaced with a "make a new, not-horrible captcha to replace FancyCaptcha in ConfirmEdit extension" task?

Other mobile apps I've seen *do* have captchas for account registration, including as mentioned popular services such as Google, and/or they have better account verification such as mandatory email or phone verification -- so I don't think there's any reason to spend effort thinking about ways to "not do a captcha".

If we want a better captcha, I recommend making it better for everyone and not being mobile-specific such as this ticket.

@Deskana, is there anything else you need from me to either close this, or change it to something else?

In T88083#1037165, @brion wrote:

Other mobile apps I've seen *do* have captchas for account registration, including as mentioned popular services such as Google, and/or they have better account verification such as mandatory email or phone verification -- so I don't think there's any reason to spend effort thinking about ways to "not do a captcha".

I don't agree. Why don't we decide to be one of the first mobile apps that has anti-spam without having to subject the user to a captcha? Think of how much our users would love us for this. :-)

If you can come up with a better solution that the server can enforce, that's great. But we can't just turn the captcha requirement off because the client claims to be a legitimate mobile app.

In T88083#1038265, @Krenair wrote:

If you can come up with a better solution that the server can enforce, that's great. But we can't just turn the captcha requirement off because the client claims to be a legitimate mobile app.

I never suggested we simply turn it off. What I'm saying is, there may be other solutions that would be better for our users, and we shouldn't just assume that either we do captchas or we don't.

For example, @dr0ptp4kt had some ideas from his previous life as a security engineer.

New feedback from French Wikiquote: impossible to access the captcha from a mobile.

In T88083#3221618, @JMinor wrote:

Hi @Trizek-WMF I think that users complaint was about the mobile website captcha, not the apps.

It is not clear but very, very probable.

Both apps support captchas, and we're not aware of any bugs with the apps captcha systems. This ticket is actually a request to remove captchas from the app, which is parked for future consideration but not likely to change any time soon.

OK, I'll search for the other one.

Android now has ReCaptcha support. We aren't using ReCaptcha on desktop for privacy reasons, I'm not sure it would make much difference on Android though.

Hi @Trizek-WMF is there any action needed from Android or iOS teams on this task?

In T88083#4121707, @LGoto wrote:

Hi @Trizek-WMF is there any action needed from Android or iOS teams on this task?

No idea. The comment has been left by an IP who never returned.

I don't recall receiving any user complaints about captchas, via ORES or otherwise, in my time on the Android team. Given that, and in the absence of a viable alternative to the status quo, I vote to close as declined.

In T88083#4123660, @Deskana wrote:

That said, I agree that it's unlikely that anything will be done about this issue. There's been no significant interest in solving the problem since the task was filed.

There was interest, but no one could think of any workable alternative. You for one didn't propose anything workable, and dr0ptp4kt never posted the insights you claimed he had.

When it was pointed out that other services do have captchas for signup, you dismissed the idea that your initial premise was flawed. I suspect if someone were to actually look into apps that have account creation without captchas, you'd find they either (1) aren't for services where one user can spam others in the first place; (2) tie the account to the existing Google/Apple account, device, or some such "strong" verification; or (3) have a lot of staff devoted to moderating and blocking rather than relying on volunteers. Even proving that guess wrong would have been useful in collecting data on how other services manage it.

Then I retract my statement. Not that it changes anything.

Hi all, I apologize for not replying on this ticket. In practice while I know of good solutions here, it's moot given current resourcing and projected projects. Now, if this becomes an area for further prioritization as part of security/privacy initiatives, I'm happy to consult.

There could be benefit to describing your ideas so if someone does decide
to work on it they don't have to track you down for an overview. If you
have time, I suppose.

It's too tall an order for today - I'll need to be tracked down should this be resurfaced.

I don't think this is particularly hard to do - just allow users to register with a Google account (use something similar to the GoogleLogin extension that allows account autocreation from a Google identity and automatic login based on proof of being logged in to that identity), which no doubt almost all Android users already have. Technically that's reasonably easy; the privacy implications need to be thought through and explained to the user, but compared to the baseline privacy level of using Google's OS and apps, it's unlikely to be much of a drop. (Captchas would be preserved as an alternative login option for people preferring not to connect their accounts.)

Some details on the privacy and security implications can be found at https://www.mediawiki.org/wiki/User:Tgr_(WMF)/external_login .