My response to the questions asked:
What are your thoughts on PrivacyPass?
The benefits of implementing PrivacyPass within mCaptcha are marginal. PrivacyPass is designed to improve the experience of visitors using VPNs and Tor. So it assumes that Tor/VPN visitors have bad experiences with CAPTCHAs, which isn’t true for mCaptcha.
Also, PrivacyPass is disabled when an attack/surge is detected. mCaptcha detects surges in seconds and increases the difficulty factor to contain the surge. So if PrivacyPass is implemented, then it will only be used in normal conditions, when the CAPTCHA takes less than 200ms to solve. Using PrivacyPass in this situation doesn’t yield significant UX improvements for the increase in code complexity.
Would the Codeberg team be willing to join this project?
As mentioned in the previous email, I invited @gusted to participate in the grant, and he kindly agreed.
Gusted’s objectives:
TODO: @gusted, please add the list of tasks that you are interested in working on. Also, kindly mention your rates against the tasks.
You requested 28500 euro, equivalent to one year of fulltime work. Could you provide a breakdown of the main tasks, and the associated effort?
Tasks
The grant application includes a full list of tasks, which is also available here.
Objective 1: Proof-of-Work accessibility:
Difficulty rating: intermediate
mCaptcha currently has two Proof-of-Work libraries: WebAssembly and JavaScript polyfill. The survey must collect benchmarks using both, since a visitor might end up using either libraries. Percentile scores must be calculated on the results aggregated, so that the webmasters who integrate mCaptcha in their websites can make informed decision on difficulty factors that will work for most of their visitors. The results must also be published under open-access licenses.
The benchmark code partially exists but processing, and publishing mechanisms don’t exist yet.
Objective 2: Horizontal scaling
Difficulty rating: hard
mCaptcha uses a leaky bucket algorithm for response Proof-of-Work difficulty scaling. The implementation that currently exists within mCaptcha isn’t distributed and so is a bottleneck for deployment with popular websites.
So I must implement a distributed version of the same algorithm. The new implementation must also be verified for correctness. To verify, I’ll have to create Infrastructure-as-Code for automated deployment in test environment.
Both distributed leaky bucket algorithm and full system Infrastructure-as-Code are time-consuming, so this objective is rated “hard”.
Objective 3: Integration test
Difficulty rating: hard
mCaptcha, at the moment, is maintained solely by me. Full system integration tests covering all configuration matrices will significantly improve quality, stability and ease maintenance.
Currently, extensive unit testing exist within individual programs and libraries, but full system integration tests don’t exist. In order to set this up, I’ll have to deploy a test runner (requested part of this application), write Infrastructure-as-Code to set up test env and periodically run tests.
It is an involved and time-consuming process and so it is rated “hard”.