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