getting bridges through google docs

I'm not sure this is the right repository to open this ticket, feel free to move it elsewhere if appropriate

I stumbled on a short blog post about an interesting way to query BridgeDB, routing requests through Google Docs.

The general idea is to load this payload:

data:text/html,<script>google={visualization:{Query:{setResponse:o=>document.write(atob(o.table.rows.map(e=>e.c[0].v).join("")))}}}</script><script src="https://docs.google.com/spreadsheets/d/1SOK9rEPrVLId1NR4KM-mgDO7tlmRk2K5nNi0tv-9gCY/gviz/tq?tqx=out:json"></script>

Which loads an entire html document from cells of a Google Sheet. When clicking a button on this page, it submits a Google Form, which supposedly trigger some processing somewhere. The page then query an other Google Sheet until a new line appear, which contains a BridgeDB captcha.
The user is prompted to resolve this captcha. This submits a second Google Form, triggering yet again some processing somewhere. It then poll the same Google Sheet for a new line, which contains 3 bridge lines.

In short, the client doesn't connect to anything but docs.google.com, which is used as a (very slow) communication tunnel to some server, which itself query BridgeDB, coming from a payload small enough to fit in a QR-code.

To implement something like this (for something else than GDocs), it's required to have:

• some place to store the full webpage (a first Google Sheet for this implementation)
• some (possibly low bandwidth high latency) channel for the user to request a captcha and send its answer (public writes, possibly private read, Google Form for this implementation)
• some (possibly low bandwidth high latency) channel for the user to receive the captcha and bridge lines (private writes, public reads, a second Google Sheet for this implementation)

Blocking such a way to query BridgeDB can have high collateral effect a censor might not be ready to accept