Mobile apps users should not be shown captchas when creating accounts
Closed, DeclinedPublic

Description

It is nonstandard for mobile apps to require a user to fill out a captcha to log in. Yet, almost all of our users on the mobile apps are required to do so. The captcha presents a big problem for our users; only 40% of those who open the create account form actually manage to create an account, and many get stuck filling in captcha after captcha incorrectly. It's not uncommon for us to get reviews where users ask how many captchas they have to fill in before they can register.

Let's find some other solution that satisfies our security needs (e.g. client-side throttling) whilst avoiding having to serve users captchas on mobile apps.

Deskana created this task.Jan 30 2015, 5:13 AM
Deskana updated the task description. (Show Details)
Deskana raised the priority of this task from to Needs Triage.
Deskana added a subscriber: Deskana.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 30 2015, 5:13 AM

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

TTO added a subscriber: TTO.

Yet another problem with our notorious CAPTCHA.

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

brion added a subscriber: brion.Jan 30 2015, 5:27 PM

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

@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.

For registration, we can't skip the captcha.

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

dr0ptp4kt set Security to None.
bd808 added a subscriber: bd808.Feb 13 2015, 12:01 AM

"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.

Anomie added a subscriber: Anomie.Feb 13 2015, 3:57 PM

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.

brion added a comment.Feb 13 2015, 6:23 PM

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?

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.

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.

Anomie moved this task from Unsorted to Non-Code on the MediaWiki-API board.Feb 19 2015, 6:03 PM
csteipp edited projects, added Security-Team; removed Security.May 7 2015, 12:01 AM
Deskana triaged this task as Normal priority.Sep 9 2015, 7:59 PM

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

JMinor changed the task status from Open to Stalled.Apr 28 2017, 5:25 PM
JMinor added a subscriber: JMinor.

Hi @Trizek-WMF I think that users complaint was about the mobile website captcha, not the apps. 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.

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.

Tgr added a subscriber: Tgr.Nov 3 2017, 3:22 AM

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.

LGoto added a subscriber: LGoto.Tue, Apr 10, 9:31 PM

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

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.

Deskana closed this task as Declined.Wed, Apr 11, 3:51 PM

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.

I stand by the description. I don't think the absence of complaints in your feedback stream is reason enough to decide this isn't a problem. Captchas are not standard when creating accounts on apps, and for good reason since they drastically decrease registration rates. This task is based on both quantitative data on where people get stuck when creating accounts, and on reviews of the app where people complained about captchas.

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 is a new team being formed to look specifically at growth, but I doubt that they'll do anything substantial with the captcha system. Additionally, the Foundation as a whole has not really shown any interest in promoting editing in the mobile apps. Closing this task as declined is simply reflecting the reality of the situation, so let's do it. :-)

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.

Tgr added a comment.Tue, Apr 17, 6:06 PM

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 .