Currently OpenLibrary uses reCaptcha as an anti-spam measure. Unfortunately reCaptcha is a very intrusive option in terms of privacy. It runs from Google's domain, meaning that it actually tracks people logged-in to their google account, but it also tracks many aspects of browsing habits of the user (eg. plugins, user agent, IP address, screen resolution, execution times, timezone, language, mouse/touch information).
Additionally its UX is quite terrible, meaning that by extension OpenLibrary's registration UX is terrible. People tend to get frustrated when they have to spend a lot of time to solve a challenge that is designed to make it hard to solve.
A full analysis can be found here. And a short one, on how v3 will be even worse.
I understand that anti-spam is important. So dropping captcha completely is probably not an option. But since the project is in python, I'm sure there is already a python library out there that will fit the project needs. I can probably help figuring out a good candidate.
@comzeradd
No, this isn't just a feature. This is critical, and must be addressed seriously: _Librarians have a fundamental duty to protect the privacy of readers_. Walk up to any library lending desk and ask to see someone else's borrowing history if you doubt this. This is absolutely at odds with any public corporation's fiduciary duty to maximize profits. If we permit corporate interests to undermine the free exchange of ideas, libraries lose their most important reason for being.
Assigning @mekarpeles per slack discussions since he'll likely be the person corralling decision.
To add my input: I absolutely _despise_ recaptcha. I emphasize that it's privacy infridgement but on a more UX level, it is a _terrible registration experience_ and it's _not mobile friendly_ at all. I'll leave it at that so this doesn't become a rant.
Hi community (esp. @guyjeangilles , @LeadSongDog, and @comzeradd ), I know this is an important to you -- Privacy is important to me, the project, and the Internet Archive. And we try to limit where such things like recaptcha is in use.
I don't have a way to act on this issue. It's not clear what replacement we will use.
I am willing to support the community in implementing an alternative, but of the many competing issues fundamentally impacting our patron experience, I am not positioned to commit to taking on this task. I am going to close this issue, having heard it and agreeing with the premise, and invite proposals on what we could use instead, as well as welcome + support volunteers in contributing.
I'm a bit confused to be honest. If you are closing this issue where will alternative proposals be discussed? How would a volunteer spend time writing specs and code if there is no issue to track this?
Maybe it's the way you work and triage issues, so apologies if this is just a lack of understand of your workflow.
So, no answer to that? Is this something that a PR contribution would be welcome or would it be a waste of time?
@mekarpeles Could you please provide the reasoning for this closure?
@mekarpeles It's been more than half a year and yet no response.
A closed issue doesn't make me very confident that this will ever get solved — if it's out of sight, it's out of mind. The lack of response here only seems to confirm my fears.
I encourage you to reopen this issue again, or at the very least to respond to the questions above.
And as for replacement suggestions, hCaptcha seems like a good fit: https://www.hcaptcha.com/
Most helpful comment
@comzeradd
No, this isn't just a feature. This is critical, and must be addressed seriously: _Librarians have a fundamental duty to protect the privacy of readers_. Walk up to any library lending desk and ask to see someone else's borrowing history if you doubt this. This is absolutely at odds with any public corporation's fiduciary duty to maximize profits. If we permit corporate interests to undermine the free exchange of ideas, libraries lose their most important reason for being.