More and more websites either have straight accessibility problems or are using hCaptcha via CloudFlare; fanfiction.net is one of the latter and can serve as concrete example for this request (as I know of one actually blind person suffering from this).

With CloudFlare/hCaptcha, the CAPTCHA is not even served to Firefox users (otherwise you could probably solve it there then export the cookie and import it into lynx). hCaptcha offers an accessibility workaround, which however requires Javascript, so this also excludes lynx, links2, w3m, and similar browsers. (hCaptcha support was very unhelpful; they equal accessibility with “screen reader works on Microsoft® products”).

I’ve got the following idea to work around this problem class and was wondering if there is software already implementing it, or parts of it which one could cobble together to do the job?

  • There is a server component, ran on a machine running GNU/Linux¹
  • The server component acts as HTTP proxy, so can be used by other browsers as proxy
  • The user can use, for example, the lynx standard textmode webbrowser to communicate with the proxy
  • The server component runs a headless² X11 session, in which Firefox is run, controlled by the server component
  • The proxy part of the server component takes the page load request it got from the end user’s browser, lets Firefox load that page³, takes a DOM snapshot and submits that as well-formed HTML to the end user’s browser
  • The headless X11 session can be attached (for example using VNC or RDP⁴) by a user with sufficient visual sense in order to solve any CAPTCHAs that do still turn up³, should that be necessary

① If the end user already runs GNU/Linux, they can run this on their own machine. The split machine setup is a necessity for the blind user I know who’s using lynx on MS-DOS. ② If the end user already runs a GNU/Linux X11 session, this could be reused (e.g. put the window on another virtual desktop or in a background window), but that’s not necessary, VNC/RDP⁴ also work locally. ③ This must be a regular Firefox page load, i.e. Firefox must compose the GET or POST request fully. I’ve tried to cobble together an HTTP request that looks like Firefox’ in order to see whether it’s possible to patch lynx to look like Firefox to hCaptcha so it also isn’t served the CAPTCHA, but they look even at the capitalisation and order of HTTP headers, not just User-Agent content and the likes. ④ RDP preferred, as VNC has trouble with keyboard layouts. xrdp with xorgxrdp is a suitable server for that and available in recent Debian (and derivatives) releases, and I use it in a charity I work with and even at $dayjob nowadays. The trick here is to start one xorgxrdp session per client headlessly but in a way that makes attaching later possible. This is not entirely straight-forward but probably possible. VNC is probably set up more easily in the beginning, but suffers from problems.

I know a bit about the session management (if run locally it’s even that much easier) but have no idea about the proxy server part and the controlling Firefox and taking a DOM snapshot out of it part. (There might need to be a small delay until DOM settled, depending on the scripts executed. I’m not experienced in these things.)

The idea of not only letting Firefox do the HTTP request to the actual server but also render the response into DOM enables clients who use text browsers that can serve images (e.g. links2) or other, older, more obscure, etc. webbrowsers (e.g. in the retrocomputing scene) to show images that are only loaded by JS.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.