Cloudflare's inaccessible browser contradicts the company's mission

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Nanos - Run Linux Software Faster and Safer than Linux with Unikernels
  • Scout APM - A developer's best friend. Try free for 14-days
  • SaaSHub - Software Alternatives and Reviews
  • GitHub repo coreruleset

    OWASP ModSecurity Core Rule Set (Official Repository)

    It's quite hard, because it's not just "use known vulnerabilities on this specific address" - you can block it easily, and there are projects (such as CRS: https://github.com/coreruleset/coreruleset) that tries to emulate this. It's more of combined specific attacks, which is amplified because if CloudFlare detected an attempt on a single high-profile site, then that IP address can be propagate to all of the protected properties. Combine that with how random is an address allocated in Tor, and you've got blocks without using an explicit Tor list.

  • GitHub repo chromium

    The official GitHub mirror of the Chromium source

    There are several problems with that approach. First, there's not enough information in the serialized accessibility tree to reconstruct the DOM.[1]

    Second, the serialization format is an internal API, so there are no constraints on backwards compatibility. It can change in any version of Chromium. In fact, the interface is updated all the time.[2] Cloudflare would have to constantly update their JS client to handle those changes. It's not an abstraction that can be relied upon.

    1. https://chromium.googlesource.com/chromium/src/+/HEAD/docs/a...

    2. https://source.chromium.org/chromium/chromium/src/+/master:t...

  • Nanos

    Run Linux Software Faster and Safer than Linux with Unikernels.

  • GitHub repo ViewFinder

    :camera: ViewFinder - Remote isolated browser API for security, automation visibility and interactivity. Free web UI for headless Chrome browser. RBI. CBII. Remote browser isolation, embeddable BrowserView, secure chrome-as-a-service. Managed, variable bandwidth and co-browsing options available in Pro versions. Like S2, WebGap, Bromium, Authentic8, Menlo Security and Broadcom, but free and source-available. Integrated secure document viewing with CDR from https://github.com/dosyago/p2%2e

    I think in order to discuss this we'd need to be clear about the actual solutions we're discussing...I'm not right now I'm sorry, so I can say no more than, in general, any additional data you send opens up the attack surface.

    Tho I can say that, relevant to your idea, at least, in my RBI product[0], you can click somewhere in the viewport and say "Copy text" and then you get a HTML dialog open over the canvas viewport with the text. A screen-reader could potentially then read that.

    But I think actual accessibility tools need to do so much more...Forgive me, I'm no expert in them.

    Re the above tho, I don't see that as introducing a greater attack surface (tho I might be wrong) because on the server side we're just getting the innerText of the element the client clicked on, and sending that text back encoded in base64 (IIRC).

    [0]: https://github.com/i5ik/ViewFinder

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project