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
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
  • coreruleset

    OWASP CRS (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.

  • 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...

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  • Viewfinder

    Discontinued 📷 BrowserBox - Remote isolated browser API for security, automation visibility and interactivity. Run on our cloud, or bring your own. Full scope double reverse web proxy with multi-tab, mobile-ready browser UI frontend. Plus co-browsing, advanced adaptive streaming, secure document viewing and more! But only in the Pro version. Get BB today! Secure your document needs and internet, today! [Moved to: https://github.com/crisdosyago/BrowserBox]

    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