Considering adapting the protocol for the "pre-meetings" approach to man in middle attack. They actually improve the "Turing test" (PP not a turing test since it is human-centric, but the metaphor can be useful) or "memetic biometrics" a bit since people meet before the actual event. And, I think it is least confusing to the user. To make it streamlined, I have considered running two systems in parallel, overlapping with a period like this (see image below. ) This means there will always be pre-meeting time ongoing, and always registration (transaction processing) time ongoing. Wastes no time. The only difference to the user is that they have to opt-in twice (each ”timeline” its own system), and when they opt-in it takes 1.5x the time to get their proof-of-unique-human. If they miss an event on one timeline they only re-opt-in on that timeline. Once in the system, the user experiences the same periodicity as in original design, the only difference to them is that they have a comfortable way to prevent the man in the middle attack.
.png)
There are other approaches too to defend against man in the middle attack, it is perfectly defendeable, but I liked "pre-meetings" for some reason (it relies on randomly agreeing on times to pre-meet, using a commit-reveal mechanism. The man in middle cannot attack this. The users can choose comfortable times. The security provided is actually way overkill but, it seems like a good approach still. For one, it likely even improves the memetic biometrics. )